draft-phillips-langtags-08, process, sp ecifications, "stability", and extensions

ned.freed at mrochek.com ned.freed at mrochek.com
Fri Jan 7 01:39:08 CET 2005


> And I will assume that it was that perceived insult that caused you to be
> dismissive,

I was dismissive because your correction, while accurate, was irrelevant
to the current discussion of the change to country code semantics.

> with your statement below about "Fine, whatever." I assume that
> otherwise you would not so readily conclude that it didn't matter whether
> RFC 3066 said "if X then Y" vs. "if Y then X". Those are, after all, very
> different statements, and a confusion between them would cause incorrect
> conclusions to be drawn.

Of course they are, but I fail to see how any of this impacts the country
code issue I have been discussing.

> > > (c) Every single tag that could be generated under RFC 3066bis is a tag that
> > > could have been registered under RFC 3066.
> >
> > True but irrelevant.

> Not at all irrelevant.

I meant, of course, that it is irrelevant to the issue at hand.

> Suppose someone is using a RFC 3066 parser, and is
> faced with either:

> (a) a registered tag from a future version of the RFC 3066 registry, or
> (b) a 3066bis tag (that uses generative features not in RFC 3066).

> ...

I am well aware of the value of this sort of backwards compatibility. I
am not, I hope, a total fool, which I would have to be to be unaware of this.

> If they update to a 3066bis parser, then they can reliably extract much more
> information from the tag. And because 3066bis was written to be backwards
> compatible, anything RFC 3066 generated language tag parses out exactly the
> same as it would with an RFC 3066 parser.

> Now you yourself may not care much about the extra information in the
> 3066bis language tag.

I never said that. In fact I have repeatedly said exactly the opposite.

> But IBM, and many other companies and organizations
> do. This is not some theoretically problem; it is a real current issue that
> many are faced with. For example, without reliable script information many
> languages are severely underspecified. One simply cannot mix content with
> different scripts and have happy customers.

I am well aware of this. You are presenting a strawman argument here.

> And if you don't care about the extra information, you are no worse off than
> if you were trying to parse a registered RFC 3066 tag.

It is somewhat axiomatic that if I don't care about something I don't
care when that something changes.

> For matching
> purposes, the commonly used truncation mechanism will work just as well with
> all 3066bis tags as it does with RFC 3066 tags, for all tags you will
> encounter.

Given that the matching approach I have been talking about is not simple
truncation, I'm afraid this is yet another strawman.

				Ned

_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf


More information about the Ietf-languages mailing list