Request: Add retired tag "eml" to the IANA registry
addison at amazon.com
Fri Dec 11 06:45:26 CET 2009
There are two problems with your request:
1. You cannot request a grandfathered subtag. That category exists for subtags already extant in the old RFC 3066 registry at the time RFC 4646 came into being. The list is fixed in a number of difficult-to-undo ways. You can request a primary language subtag based on ISO 639-3 RA action (this isn't one) or a longer-than-three-letter code to replace 'eml' (this isn't what you're looking for).
My reasoning is that 2009-01-16 predates RFC 5646, which incorporated ISO 639-3 into the registry. 'eml' could not have been registered under RFC 4646. Since the code should not have been used at any time as a valid primary language subtag and since ISO 639-3 has a reasonably large number of "retired" codes, it probably would be a bad idea to take this particular one in. There doesn't seem to be a basis in the RFC for doing so.
2. I don't believe that your requested Preferred-Value is valid. Each Preferred-Value must contain exactly one subtag and there can be only one P-V field per record. It is permissible to omit the Preferred-Value. You could include a Comments field explaining preferred values, as deprecation of a record is permitted without having a single preferred mapping. For example, see region subtag YU:
Comments: see BA, HR, ME, MK, RS, or SI
Globalization Architect -- Lab126
Internationalization is not a feature.
It is an architecture.
> -----Original Message-----
> From: ietf-languages-bounces at alvestrand.no [mailto:ietf-languages-
> bounces at alvestrand.no] On Behalf Of Michael(tm) Smith
> Sent: Thursday, December 10, 2009 8:09 PM
> To: ietf-languages at alvestrand.no
> Subject: Request: Add retired tag "eml" to the IANA registry
> 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
> information" below.
> 1. Name of requester: Michael(tm) Smith
> 2. E-mail address of requester: mike at w3.org
> 3. Record Requested:
> Type: grandfathered
> Tag: eml
> Description: Emiliano-Romagnolo
> Added: 2010-XX-XX
> Deprecated: 2009-01-16
> 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
> 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
> doing that.
> - 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).
> Michael(tm) Smith
> Ietf-languages mailing list
> Ietf-languages at alvestrand.no
More information about the Ietf-languages