--On Thursday, 06 January, 2005 15:28 -0500 John Cowan
<jcowan@xxxxxxxxxxxxxxxxx> wrote:
> John C Klensin scripsit:
>
>> Content-language: <3066-tag>
>> X-Extended-Content-language: <new-tag>
>
> This reflects a fundamental misunderstanding of what the draft
> does compared to what RFC 3066 does. It imposes *more*
> restraints on language tags, not fewer.
It also very explicitly permits talking about scripts, not just
languages and countries. That, to me, is an extension,
regardless of the additional constraints. But I could have used
a different word; this was just an example.
> The RFC 3066 language
> tag registration process can register tags with almost
> unpredictable meaning once one gets past the first subtag.
> The draft *limits* the possible tags to a small subset, and
> tightens up the allowable semantics. It allows no tag to be
> used that was not already registerable under RFC 3066.
The "extension" that I see involves more semantics and formal
variations, not more possible registered tags. And, as Ned as
pointed out repeatedly, there are things that can be done in
3066 parsers/interpreters in practice that have to be done
differently in this new system. I could, of course, have used
"X-Incompatible-Content-Language" in my example, but that
presumably would have set you off in some other direction.
> In RFC 3066, it is only a heuristic (or examination of the
> IANA registry, which is not machine-parseable) that tells the
> meaning of the second subtag the existing registered tag
> sr-Latn. In the draft, its meaning is unambiguously specified
> a priori.
So?
john
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf