Request: Add retired tag "eml" to the IANA registry
mike at w3.org
Fri Dec 11 05:09:11 CET 2009
This is a request to add the retired tag "eml" to the IANA
language-subtag registry as a grandfathered tag. I realize this is
an odd request; for the rationale, see "6. Any other relevant
1. Name of requester: Michael(tm) Smith
2. E-mail address of requester: mike at w3.org
3. Record Requested:
Preferred-Value: egl or rgn
4. Intended meaning of the tag: Emiliano-Romagnolo
5. Reference to published description of the language:
6. Any other relevant information:
My understanding about "eml" is:
- is has never been in the registry nor was it in the set of
tags that were grandfathered into the registry
- its status is "retired", a state that doesn't exactly correspond
to any existing field values in the registry but that based on
what I have read means that it remains valid but deprecated
 message from Peter Constable on LTRU list, stating
'"Retired" means it's no longer recommended -- basically
the same as deprecated.'
The fact that it is not in the registry makes it impossible,
using the registry alone, to distinguish a use of "eml" from being
an instance of a invalid tag. If it is in fact still valid but
deprecated, it seems that it should be included in the registry
and marked as such, so that its actual status is clear.
- Grandfathered vs. retired. I recognize that the semantics of
the "grandfathered" type are different from the semantics of
"retired", but the only other solution would seem to be to add
"retired" as a new documented value for the type field, and it
would seem like there would not be enough benefit to justify
- Syntax of the Preferred-Value field. I don't know what
documented constraints there are on the syntax of the
Preferred-Value field, nor what expectations/ assumptions any
current parsers of the registry have about the value of the
field. But for this case, if "eml" is added, it would seem to
require that the field be able to contain multiple values.
If/when it does, I don't know what would be the best way to
separate the values should be -- just space-separated or
comma-separated, or what -- but it seems like just putting
"or" between might be good as far as trying to keep backward
compatibility with existing tools (which I would guess are
just reading in the whole value as a string).
- "Added" date. Not sure what the Added date would best be for
this case. Though I can see it being odd to have a record with
an Added date that is after its Deprecated date, it seems like
it'd best need to be the date of if/when this actually does
get added to the registry.
That's it in a nutshell. The rest of the info below is just about
the particular context/use-case underlying my making this request.
More details about the context for this request
The context for this request is that I contribute to development
of a markup validation tool, Validator.nu that includes a feature
for checking the conformance of the values of HTML lang and XML
xml:lang attributes. The feature is enabled through a backend
parser that reads and parses the IANA language-subtag registry.
We recently got a report from an admin at Wikipedia about some of
the error messages that tool emits. The context for the report is
that the http://wikipedia.org home page includes links to all
Wikipedias available in any language that one has been created for.
One of those existing Wikipedias is http://eml.wikipedia.org
(As far as why Wikipedia has a eml.wikipedia.org site instead of
having separate egl.wikipedia.org and rgn.wikipedia.org sites, I
dunno. But they do, and it would seem that as long as it exists,
it is reasonable for eml to be the tag to uniquely identify it.)
When I run Validator.nu on the Wikipedia.org home page, I get:
Notice the error "Bad value eml for attribute lang on element a:
Bad ISO language part in language tag".
What it seem like should be reported for this case is a warning:
"Bad value eml for attribute lang on element a: The language tag
eml is deprecated. Use egl or rgn instead.
But because "eml" is not in the registry, I currently have no way
of having the application correctly report for that problem --
except to special-case "eml" in the application code (which I can
do easily enough but would prefer first to try getting it into the
registry so that other developers don't also end up having to
special-casing it in the code too).
More information about the Ietf-languages