RE: Charset policy - Post Munich

[Ned Freed <Ned.Freed@INNOSOFT.COM>]

> Sorry I'm somewhat late with responding.

> On Fri, 19 Sep 1997, Ned Freed answered me:

> > > Specifically, I also agree that language tags are a big help
> > > to current stupid machines. But if we put an absolute requirement
> > > for language tags into our policy, a requirement that in the
> > > extreme might say: "Every protocol has to be able to language
> > > tag all the characters it sends around, with potentially
> > > different tags for each character.",
> >
> > Martin, this is nothing but a strawman and you know it.

> NO! If it were just a strawman, I wouldn't have any reason
> to mention it. The above sentence is my quintessencial
> summary of a position that has quite recently been used
> in discussions you have participated in. The above is far
> from being a strawman, and you know it.

Fair enough: Prove it. Please cite the protocol design being undertaken at this
time where there's a proposal on the table with the specific goal of allowing
and encouraging individual character tagging.

Please note that designs like MIME encoded-words and MLSF which do allow
individual character tagging, do NOT qualify. The fact that these designs allow
individual character tagging (albeit in a very painful and artificial way) is a
artefact of the design constraints these things operate under. It is NOT an
explicit goal of the design in either case, and as such these designs would not
be invalidated in any way by any rule we make here. The most that would happen
is that they would have to adopt some very complex and confusing profiling
rules that will almost certainly cause more problems than they solve, which is
one of the reasons why I don't want this door opened to begin with.

Until and unless you can come with a case of a design where this goal is
specifically present and being pursued I will continue to regard this entire
thing as a strawman.

> > This also presupposes a level of cluelessness on the part of WG chairs, area
> > directors and directorates, the IESG, and the IAB that I almost find offensive.
> > We do have checks and balances in this process, you know.

> I know. And I had absolutely no intent to offend any of the people or
> functions you have mentionned above. But making explicit that language
> tagging is something one should think about, and try to find a solution
> that is well adapted to the protocol, will be a great help in avoiding
> discussions as they have taken place, in which experienced protocol
> designers have refused to do serious technical discussions because
> they thought they had some document to back up their claims (which
> they didn't), and the truth on their side anyway, and claimed to
> do this in the name of the IETF.

You are confusing the issue of whether or not language tags need to be present
at all with the issue of what level of granularity at which they need to be
present. These are very different things. When people refuse to discuss these
matters with you it is because you persist in dragging in the "should they be
there" consideration and they regard that issue as settled. You may not like it
and frankly most of the time they may not either, but the requirement is a done
deal informally and is about to become a done deal formally. And thus people
aren't interested in listening to you go on and on about how language can be
deduced from content and thus eliminate the need for tagging entirely. They are
instead interesting in building protocols that will be able to  make it onto
the standards track.

The granularity issue, on the other hand, is still there, but the design
constraints on it typically arise from the protocol in question rather than any
need, real or imagined, for a given level of granularity to exist because a
particular level of tagging is a Good Thing. And I will be the first to state,
and even proclaim, that the level where tags are added often ends up being less
than ideal, as it certainly is in, say, encoded-words. (In particular, comment
string level granularity is OK, but the ability to switch character sets and
languages on a character by character basis in phrases is overkill. But
unfortunately the minute you set out to build a system that allows different
phrases to be in different character sets and languages you either end up with
one that has too small a level of granularity or one that is much too complex
to be useful. I should know since I was the author of one of the too complex
alternatives back when MIME was designed.)

And this is why I don't want to make rules about the level of granularity that
has to be provided: It presupposes not only that protocol designers and the
IESG are incompetent to decide these things themselves, it also presupposes
that we can at this time know all the constraints designers will be operating
under. For all you or I know the next 200 protocols that language tagging are
added to in the IETF will all be of a sort where the only viable alternative
due to the characteristics of the protocol itself will be to build facilities
that allow tagging down to the individual character. (I doubt very very much
that this will be the case, but it is nevertheless possible.)

> Anyway, if you an others assure me that my concerns are not
> (or not anymore) justified, I am ready to accept that.
> I sincerely hope I don't have to come back to it later.

I see no evidence that supports a view that you will have to.

				Ned