Fixing the lost el-Latn

[Luc Pardon]

Doug Ewell wrote:
> Luc Pardon <lucp at skopos dot be> wrote:
> 
>>    Of course, if the old registry is fixed and the new is not, this
>> would kind of invalidate the sections of RFC3066bis that deal with the
>> initial contents of the registry (e.g. 2.2.8 and 3.3).
> 
> The relevant passage in Section 3.3 is this:
> 
> "Note: The redundant and grandfathered entries together are the complete 
> list of tags registered under [RFC3066]. The redundant tags are those 
> that can now be formed using the subtags defined in the registry 
> together with the rules of Section 2.2. The grandfathered entries 
> include those that can never be legal under those same provisions."
> 
> 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 think it is safe to assume that everyone at the time thought (a) and 
> (b) would be identical, and there would be no such thing as an approved 
> registration that was not in the registry.
> 

      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.

> It might be instructive to keep the timeline of events in mind:
> 
> Aug 23    Start of IESG Last Call for draft-registry and draft-initial
> Sep 06    End of IESG Last Call for draft-registry and draft-initial
> Sep 13    Luc submits RFC 3066 registration form for el-Latn
> Sep 28    Reviewer approves el-Latn and sends notice to IANA
> Nov 14    Draft-registry and draft-initial approved by IESG
> 
> Perhaps this is something that IETF and IESG need to rule on.
> 

    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.

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

    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) 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.

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

    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?


    Luc Pardon
    Belgium