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(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf