Hello John, others,
On 2022-06-24 08:35, John C Klensin wrote:
I have trouble imagining any issues turning up that would
require or justify a revision to 5646 that would not be forward
compatible from the existing spec. I can imagine a different
explanation of the extension mechanism, standards-track specs
for new extensions or even a consolidated description of them,
and so on. It is every easier for me to imagine an updated or
replacement document that would get rid of the <privateuse> use
of "x-" (following the conclusions of RFC 6648 which probably
should have updated 5646 too), but that mechanism does not
appear to be at issue with the current I-D.
For the record, I think the situation with "x-" for private use in RFC
5646 is slightly different from the general problem discussed in RFC 6648.
The discussion in RFC 6648 assumes a wide-open, flat space of values
(e.g. message headers). In that case, just using e.g.
"My-New-Header:" from the start rather than starting with
"X-My-New-Header:" has a lot of benefits and (assuming provisional
registration) extremely little potential for harm.
However, language tags and language subtags are not a wide-open, flat
space. They are a highly structured, tightly controlled space. It's not
possible to just create your own language tag, e.g.
"my-OWN-language-TAG". The "x-" extension for private use is the only
way to extend language tags without going through registration and
approval. So getting rid of "x-" doesn't seem to be an option. The only
thing to do to get closer to what RFC 6648 wants would be to either
change "x-" to an extension with a first-come-first-served registry or
to take one of the other remaining 23 one-letter extensions ("t-" and
"u-" being taken) and designate that for use with a
first-come-first-served registry.
Regards, Martin.
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
