Re: [Ltru] Re: Small bibliography error in RFC 4930

At 17:42 07/06/18, Frank Ellermann wrote:
>Hollenbeck, Scott wrote:
> 
>> That's not an error. The references are correct as published for
>> promotion to draft standard status.

Like others, I have problems understanding that. Randy made
the procedural argument (both RFC 3066 and RFC 4646 are BCPs).

There is also an implementation argument:
There are no legal language tags in RFC 4646 that aren't legal
according to RFC 3066. I have absolutely no clue what could
break in an implementation when using a tag that became
legal in RFC 4646. The only thing that I can see break is
things such as "language not available", but then that kind
of error was always possible.

>At the moment you can reconstruct a 3066 registry by looking at
>the redundant / grandfathered tags in the 4646 registry, and in
>the source standards (i.e. the language and region subtags in the
>4646 registry).
>
>IOW just stay away from scripts, variants, and UN region numbers.

This is one interpretation, but there is also a different,
in my view more plausible, interpretation: RFC 4646 did a
bulk registration of language/region/script/whatever combinations.
Because it became obvious that there would be scaling problems
when registring all combinations, we took the path of changing
the registry structure. The old (RFC 3066) registry has been
obsoleted, there is only the RFC 4646 registry, which is
a direct continuation of the RFC 3066 registry. All the
tags you can generate from the new registry using the rules
in RFC 4646 are legal tags according to RFC 3066, and have
to be considered under RFC 3066 as if they were in fact
registered one-by-one.

Frank's interpretation would mean that only the variants
registered at the time RFC 3066 was replaced by RFC 4646
would be usable. That would lead to weird requests. I remember
that in the transition period from RFC 3066 to RFC 4646,
we had somebody requesting registration of el-Latn.
We rejected this because with RFC 4646, there would be no
such need anymore. With the interpretation above, that would
no longer be true.

>With the 4646bis registry it will be more convoluted, you'd also
>have to stay away from 639-3 languages (+ extlangs, if any pop up).
>
>Should 4646bis do something for protocols wishing to emulate the
>old 3066 registry ?  We could flag the source of language tags in
>the description field (just an idea).  Or add a how-to as appendix.

No. There is no old registry. There is only one registry.
The current registry IS the RFC 3066 registry, just slightly
overhauled.

With this, of course the reasons for citing RFC 3066 when
RFC 4646 was out become even less understandable.

Regards,   Martin.

#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:duerst@it.aoyama.ac.jp     

_______________________________________________
Ltru mailing list
Ltru@ietf.org
https://www1.ietf.org/mailman/listinfo/ltru