[Ltru] Re: 4646(bis) typo / issue

Frank Ellermann <nobody at xyzzy dot claranet dot de> wrote:

>> What or who was harmed?
>
> The integrity of the registry until it's fixed.

There is no restriction that a tag may not be grandfathered if it is 
syntactically eligible to be converted into a generative tag consisting 
of valid subtags, nor that the subtags may not subsequently be 
registered.

That was a difficult sentence to write, and probably to read, so let's 
try again:

The fact that 'en' is a valid subtag, and 'boont' could have been, does 
not mean there cannot be a grandfathered tag "en-boont".  Similarly, the 
fact that "en-boont" existed does not mean 'boont' could not then be 
registered, making "en-boont" redundant.

RFC 4646, Section 2.2.1, item 7:
The single character subtag 'i' is used by some grandfathered tags (see 
Section 2.2.8) such as "i-klingon" and "i-bnn". (Other grandfathered 
tags have a primary language subtag in their first position)  [Tags that 
start with a valid primary language subtag may still be grandfathered.]

Section 2.2.2:
Example: In a future revision or update of this document, the tag 
"zh-gan" (registered under RFC 3066) might become a valid 
non-grandfathered (that is, redundant) tag in which the subtag 'gan' 
might represent the Chinese dialect 'Gan'.  [Grandfathered tags may 
subsequently become redundant.]

Section 2.2.8:
Grandfathered tags contain one or more subtags that are not defined in 
the Language Subtag Registry (see Section 3). Redundant tags consist 
entirely of subtags defined above and whose independent registration is 
superseded by this document.  [Does not say the undefined subtags cannot 
later be registered.]

Section 3.3:
The grandfathered entries include those that can never be legal under 
those same provisions.  [Does not say *only* those that can never be 
legal.]

Records of type 'grandfathered' MAY have their type converted to 
'redundant': see item 12 in Section 3.6 [recte: 3.4] for more 
information.

Section 3.4, item 12:
Stability provisions apply to grandfathered tags with this exception: 
should all of the subtags in a grandfathered tag become valid subtags in 
the IANA registry, then the field 'Type' in that record is changed from 
'grandfathered' to 'redundant'. Note that this will not affect language 
tags that match the grandfathered tag, since these tags will now match 
valid generative subtag sequences. For example, if the subtag 'gan' in 
the language tag "zh-gan" were to be registered as an extended language 
subtag, then the grandfathered tag "zh-gan" would be deprecated (but 
existing content or implementations that use "zh-gan" would remain 
valid).  [Does not say this cannot happen by registering a variant.]

Section 3.6:
Subtags proposed for registration that would cause all or part of a 
grandfathered tag to become redundant but whose meaning conflicts with 
or alters the meaning of the grandfathered tag MUST be rejected.  [Not 
the case here.]

RFC 4645, Section 2, item 8:
Tags in the [RFC3066] registry that contained one or more subtags that 
either did not match the valid registration pattern or were not 
otherwise defined by [RFC4646] were converted to corresponding records 
of type "grandfathered" in the ILSR.  These records cannot become type 
"redundant" except by revision of [RFC4646], but may have a "Deprecated" 
and "Preferred-Value" field added to them if a subsequent subtag 
assignment or combination of assignments renders the tag obsolete.

Section 2, item 11:
All remaining [RFC3066] registered tags were converted to records of 
type "grandfathered" in the ILSR.  Interested parties may use the 
registration process in [RFC4646] to attempt to register the variant 
subtags not already present in the Language Subtag Registry.  If all of 
the subtags in the original tag become fully defined by the resulting 
registrations, then the original tag is superseded.  Such tags will have 
their record changed from type "grandfathered" to type "redundant" in 
the registry.  Note that previous approval of a tag under [RFC3066] is 
not a guarantee of approval of a variant subtag under [RFC4646].  The 
existing [RFC3066] tag maintains its validity, but the original reason 
for its registration might have become obsolete.  [Describes exactly the 
present situation.]

I don't see it written anyplace that there is an integrity problem. 
There may be an implementation problem if applications make an 
unwarranted assumption, that grandfathered tags cannot consist of a 
well-formed sequence of subtags, but that is not supported by the RFCs.

> But it helped me to find a bug in my XML-converter, a reference to a 
> variant subtag must not collide with a language subtag of length 5..8 
> like the hypothetical "gaulish".

There is no namespace collision between language and variant subtags.  I 
made a misstatement earlier about somebody needing to register 'gaulish' 
as a macrolanguage; I should have said "as an umbrella term" when the 
distinction between Cisalpine and Transalpine is unimportant or it is 
unknown which language is present.  (Both have been extinct for 1,500+ 
years and the primary difference was regional, so this scenario is 
plausible.)

> Adding underscores to _all_ non-primary subtag IDs (not only those 
> starting with a digit) would work until 4646bis-00.  But not for 
> 4646bis-01, where the Preferred-Value of an extlang can be a language. 
> Odd situation:
>
> Language subtags of length 3 use the same namsepace as extlang 
> subtags.  Language subtags of length 5..8 do NOT use the same 
> namespace as variant subtags.  For case insensitive operations they 
> also don't use the namespaces of region or script subtags.

While primary and extended language subtags do occupy the same 
namespace, I'm not sure there is any reason a parser needs to care about 
this.

> Apparently my registry converter needs its own minimal parser to get 
> this right... <sigh />

--
Doug Ewell
Fullerton, California, USA
http://users.adelphia.net/~dewell/
RFC 4645  *  UTN #14 

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