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