Request for variant subtag fr 16th-c 17th-c Resubmitted!

Randy Presuhn randy_presuhn at mindspring.com
Tue Dec 19 02:26:09 CET 2006


Hi -

> From: "CE Whitehead" <cewcathar at hotmail.com>
> To: <petercon at microsoft.com>
> Cc: <ietf-languages at iana.org>
> Sent: Monday, December 18, 2006 11:00 AM
> Subject: RE: Request for variant subtag fr 16th-c 17th-c Resubmitted!
>
> >So, at the very least, if these two prefix fields are part of the
> >registration for "1606Nict" then it is necessary to explain what is the
> >intended semantic distinction between "fr-1606Nict" and "frm-1606Nict".
> 
> Hi, it would depend on the exact language in the document; to have two tags 
> allows the content authors to use judgement.
...

RFC 4646 section 3.5 says:

   Requests to add a prefix to a variant subtag that imply a different
   semantic meaning will probably be rejected.  For example, a request
   to add the prefix "de" to the subtag 'nedis' so that the tag
   "de-nedis" represented some German dialect would be rejected.  The
   'nedis' subtag represents a particular Slovenian dialect and the
   additional registration would change the semantic meaning assigned to
   the subtag.  A separate subtag SHOULD be proposed instead.

How we procede here hinges on whether someone can nail down the difference
between "fr-1606Nict" and "frm-1606Nict".  If they are *indistinguishable*,
then the registration request would be in line with what RFC 4646
has to say about multiple prefixes for variant subtags.

If there really is a difference between "fr-1606Nict" and "frm-1606Nict",
and I understand CE Whitehead's earlier postings to suggest that there is,
then it seems that distinct subtags should be used, again based on what
RFC 4646 has to say about multiple prefixes for variant subtags.

The only other path I see is to dig into just what is intended by
"semantic meaning assigned to the subtag", which is probably a
clarification question for the ltru at ietf.org list.

I think the "search engine" question is irrelevant to this discussion,
since the RFC 4647 mechanisms adequately cover all of the alternatives
discussed so far.

Randy



More information about the Ietf-languages mailing list