> 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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf