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

Randy Presuhn randy_presuhn at
Mon Dec 14 04:28:54 CET 2009

Hi -

----- Original Message ----- 
> From: "John Cowan" <cowan at>
> To: "Randy Presuhn" <randy_presuhn at>
> Cc: <ietf-languages at>
> Sent: Sunday, December 13, 2009 11:22 AM
> Subject: Re: Request: Add retired tag "eml" to the IANA registry

> Randy Presuhn scripsit:
> > > Only a few of the 639-3 retired codes have this problem.  Almost all
> > > of them represent either splits (multiple languages were incorrectly
> > > treated as dialects of the same language) or mergers (dialects of
> > > a single language were incorrectly treated as multiple languages).
> > 
> > This last case is, absent appropriate variant subtags, effectively a
> > case of "identical semantics", inasmuch as whatever the difference
> > was, it was felt to be insignificant for purposes of 639-3.
> Saying that two codes represent the same *language* does not mean they
> have the same *denotation*.  Consider the case of Musi 'mui', Lematang
> 'lmt', Palembang 'plm', Penesak 'pem', and Rawas 'rws'.  These are
> distinct varieties spoken along the Musi River in Sumatra, and were
> originally listed as distinct languages.
> Further evidence shows that they are reasonably mutually intelligible, so
> the codes 'lmt', 'plm', 'pem', and 'rws' were retired in favor of using
> 'mui' alone.  However, the four codes still mean what they meant before --
> "Retired code elements remain part of the code set and retain their
> identifier *and denotation*" (emphasis added).
> So 'lmt' still means Lematang, although that now counts as a dialect
> rather than a language; however, 'mui' has had its denotation widened,
> so it is not possible in 639-3 to discriminate between Musi the dialect
> and Musi the language.  (In other cases, new codes have been created,
> or a code has been promoted to macrolanguage scope.)

In this case registration requests for variant subtags would be appropriate *if*
someone needed to distinguish the various dialects.  Creating pre-deprecated
records for those dialects, with preferred-values using the (not yet and we don't
know if they ever will be requested) variant subtags seems a rather Rube
Goldberg-like approach.  Creating pre-deprecated records for those dialects
*without* preferred-values seems like an active disservice to whoever might
someday need to identify those dialects.  I think we're better off leaving them
out, and using the normal process to handle the variant subtag requests if and
when they happen.  That would be much less confusing for folks not wrapped
up in RFC 5646 aracana, and leaves open both the possibility that these
could be handled as variants, or, if further consideration tips the balance
once again, as language subtags.


More information about the Ietf-languages mailing list