Fixing the lost el-Latn

Doug Ewell dewell at adelphia.net
Sun Mar 26 11:10:03 CEST 2006


Luc Pardon <lucp at skopos dot be> wrote:

>> Assuming that IANA does add "el-Latn" to the old Tag Registry, the
>> question for the new Subtag Registry is whether the passage above
>> refers to:
>>
>> (a) the complete list of tags approved for registration under RFC
>> 3066, including those not yet included in the registry, OR
>>
>> (b) the complete list of tags registered under RFC 3066, as indicated
>> by their presence in the registry at the time of approval of RFC
>> 3066bis.
>> ...
>
>      I would argue that it's (a). As I read RFC3066, registration
> takes place on this list and ends with the approval. The registry is
> just that, a public record of what has happened here.

I don't see any wording in RFC 3066 that distinguishes between the 
Reviewer sending the registration request to IANA and the revised 
registry being published.  RFC 3066 appears to suffer from the same flaw 
as RFC 3066bis: neither defines what happens in the event of unexpected 
delay or inaction on the part of IANA.  This is where I think a ruling 
is needed.

>    I would argue that those drafts (and hence their IESG approval)
> only covered the transformation process, judged from a sample run on
> the then current contents of the registry, rather than the output of
> the sample run itself.

Draft-initial covered both the process employed to determine the initial 
registry contents *and* the output of that process.  It was not a 
"sample run."  The date of conversion was clearly defined, and the 
contents of the ISO and UN standards and the RFC 3066 registry at that 
date were well known and were used as specified.

>   Therefore only the process was approved and frozen, not the list of 
> entries.

I do not believe this to be the case.  The entire raison d'être of 
draft-initial was to provide an initial registry that IANA could post.

>    Evidence:
>
>    1) RFC3066bis section 3.3 says (my emphasis):
>
>    The decision making _process_ about which tags were
>    initially grandfathered and which were made redundant is described
>    in [initial-registry].
>
>    2) As I am sure you know <g>, that [initial-registry] document
> (which btw is no longer at the url indicated because it has increased
> its version number from 00 to 06)

The references in both draft-registry and draft-initial will not be 
finally resolved until the AUTH48 period for both documents, which is 
waiting until draft-matching passes IESG Last Call.

> does indeed contain a list of entries
> but says just above it:
>
>    The remainder of this section specified the initial set of records
>    for the registry.  This material was deleted on publication of this
>    memo, to avoid any potential confusion with the registry itself.
>    The IANA language subtag registry can be found at
>    <http://www.iana.org/numbers.html> under "Language Tags."
>    [RFC EDITOR NOTE: the remainder of this section is to be deleted
>    upon publication.]
>
>    So there is not even a need to insert a redundant entry in this
> (frozen?) document as well as in the actual registry.

Nobody is proposing, or should propose, inserting anything into the 
initial registry.  It's not even The Registry any more; we just made six 
additions and one modification.  The initial registry RFC was already 
obsolete before it even received an RFC number.

>    Bottom line: I see no problem in retrofitting a "redundant" entry 
> that went missing by, well, accident. No ruling needed.

Well, I see controversy, and John Cowan's Rule of Controversy applies: 
if one person sees controversy and the other doesn't, there is 
controversy.

>    In any case, the question of the apropriateness of new
> registrations has come up during the el-Latn review period. The
> consensus of the ietf-languages community was to go ahead. Wouldn't
> that count as an IETF ruling?

It's a decision made by members of this mailing list, which is 
affiliated with the IETF.  It is not a decision by an IETF Area Director 
or Area Advisor.  That is the kind of ruling I am talking about.

I really don't see what the problem is.  The standard (lowercase 's') 
for Internet language tagging is now RFC 3066bis, which allows "el-Latn" 
as a generative tag.  Only those applications that support RFC 1766 and 
RFC 3066 registered tags, but do not support RFC 3066bis, are affected 
by the failure of IANA to add "el-Latn" to the tag registry.

I would like the LTRU co-chairs, the IETF Applications Area Advisor, and 
IANA to provide some statements on this before it gets any farther 
along.

--
Doug Ewell
Fullerton, California, USA
http://users.adelphia.net/~dewell/
Editor, RFC-ietf-ltru-initial-06




More information about the Ietf-languages mailing list