Re: [art] [Last-Call] Artart last call review of draft-ietf-core-problem-details-05

["Martin J. Dürst" <[e-mail]>]

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.