Fixing the lost el-Latn
lucp at skopos.be
Sun Mar 26 08:40:39 CEST 2006
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
> (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
Therefore only the process was approved and frozen, not the list of
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
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
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
More information about the Ietf-languages