Request: Add retired tag "eml" to the IANA registry

[Phillips, Addison]

> >
> > Since we do not AFAICT have limiting language in RFC 5646 that
> says we
> > can only register 639-3 codes in active status, it seems to me
> that we
> > SHOULD and perhaps MUST register the retired codes, since they
> have the
> > same denotations they had before their retirement.
> 
> Definitely not "MUST" - that sort of language is only appropriate
> when something
> is necessary in order for things to work.  Since no one could ever
> have legitimately
> used these as language subtags, that's clearly not the case.

I think we must entertain the possibility of MUST here. We *are* required to insert all codes that are assigned going forward by ISO 639 (with some elaborate restrictions that do not apply here). The question is whether the retired codes are assigned in a manner consistent with putting them into the registry. The codes were not withdrawn. RFC 5645 describes what the registry was "supposed to" contain at inception and it says in Section 2.2:

--
   For each language in [ISO639-3] that was not already represented by a
   language subtag in the Language Subtag Registry, a new language
   subtag was added to the registry, using the [ISO639-3] code element
   as the value for the Subtag field and using each of the non-inverted
   [ISO639-3] names as a separate Description field.  The [ISO639-3]
   reference name is represented by the first Description field.
--

Nowhere do we discuss (because we weren't aware of them) the already-retired codes. If LTRU has finished as originally intended, before ISO 639-3 was final, we would have included all of these codes (Section 3.4 item 12.B) and later deprecated them using our normal process (Section 3.4 item 14). Since we don't say whether the retired codes should be handled exceptionally or not, one could argue that we "MUST" include them because they are, in fact, assigned.

We face similar issues with ISO 3166-1 codes. There we faced the problem that some codes had actually been withdrawn in the past (and these values had actually been potentially valid for use). Indeed, some were even reassigned. We solved this by choosing gating dates. The "gating date" for ISO 639-3 was *intended* but not actually "ab initio ISO 639-3".

I do agree with you that the codes in question have never been valid in language tags. If we were to register them, then any such subtags would be deprecated at birth and SHOULD never be used. That would avoid having 159 codes that are assigned by ISO 639-3 but which don't appear anywhere in the registry.

The downside of "completing the set" is that it would allow users to construct (BCP 47) 'valid' language tags with these subtags. I hate to encourage such bogus usages. There is no interoperability goal that is served by doing this that I can see. Because the text is silent, I think it may be up to the subtag reviewer. However, if any *one* of these is accepted, I think it creates a "MUST" condition for all of the others. That is, the only way to register an alpha3 primary language subtag is if ISO 639-3 assigns it. If you accept one, then you must mean they are all eligible... and the text is clear that all eligible ISO 639-3 codes must be registered as soon as practical.

> 
> > I hesitate only
> > in the case of the Group 1 (nonexistent language) codes, since
> their
> > denotations are empty: still, there are only eight of them, and
> adding
> > a comment would probably do the trick.
> 
> We should also keep in mind the RFC 5646 section 3.4 (13) principle
> of not adding a new subtag with semantics identical  to something already
> in the registry.
> 
That is a (Very good) objection. But I think it might apply on a case-by-case basis, if any of these are eligible.

Addison