Re: Proposed resolution for Issue 13 (language tags)

I have copied the IETF LTRU (Language Tag Registry Update) WG
to make sure they can help get this right.

LTRU WG - this is a copy of a reply to a mail on the HTTP WG
mailing list about language tags. The spec being updated is
http://www.ietf.org/rfc/rfc2616.txt. See in particular
sections 3.10, Language Tags, 14.4, Accept-Language, and
14.12, Content-Language.

Please stop cross-posting for issues that don't affect both groups!
Please change the Subject if you change the subject!

At 01:02 08/04/15, Julian Reschke wrote:
>
>Hi,
>
>(see also <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/13>).
>
>So far we have delayed the resolution 13 until we're done with the ABNF conversion, but since then we have made other changes to the ABNF anyway. Therefore, I'd like to get this one resolved; there's doesn't seem to be anything holding it up...:
>
>Section 3.5., paragraph 2:
>OLD:
>
>    The syntax and registry of HTTP language tags is the same as that
>    defined by [RFC1766].  In summary, a language tag is composed of 1 or
>    more parts: A primary language tag and a possibly empty series of
>    subtags:
>
>NEW:
>
>    The syntax and registry of HTTP language tags is the same as that
>    defined by [RFC4646].  In summary, a language tag is composed of one
>    or more parts: A primary language tag and a possibly empty series of
>    subtags,

The above text gives the impression that there is a separate
concept of a "HTTP language tag". Why not just say something
like "HTTP uses language tags as defined in ...".

Also, with RFC 4646, any further (currently being worked on by the LTRU WG)
extensions (not in syntax, but in the number of languages covered) might
be excluded. People have been wondering e.g. whether they can use
RFC 3066 or RFC 4646 language tags with RFC 2616, we don't want that
to happen again. RFC 4646 (and RFC 4647, which defines matching) can
be referenced as BCP 47, which doesn't have to be updated even if
a new RFC makes more language tags available. The basic syntax
is still the same. So I strongly suggest you reference BCP 47
rather than a specific RFC.


>Section 3.5., paragraph 3:
>OLD:
>
>      language-tag  = primary-tag *( "-" subtag )
>      primary-tag   = 1*8ALPHA
>      subtag        = 1*8ALPHA
>
>NEW:
>
>      language-tag  = <Language-Tag, defined in [RFC4646], Section 2.1>

See above.

>Section 3.5., paragraph 4:
>OLD:
>
>    White space is not allowed within the tag and all tags are case-
>    insensitive.  The name space of language tags is administered by the
>    IANA.  Example tags include:
>
>NEW:
>
>    White space is not allowed within the tag and all tags are case-
>    insensitive.  The name space of language tags is administered by the
>    IANA (<http://www.iana.org/assignments/language-tags>).

As you can see on that page, the registry of full language tags is
obsolete. It has been replaced by the language subtag registry, at
http://www.iana.org/assignments/language-subtag-registry.

>    Example tags include:
>
>
>Section 3.5., paragraph 6:
>OLD:
>
>    where any two-letter primary-tag is an ISO-639 language abbreviation
>    and any two-letter initial subtag is an ISO-3166 country code.  (The
>    last three tags above are not registered tags; all but the last are
>    examples of tags which could be registered in future.)
>
>NEW:
>
>    (The last three tags above are not registered tags; all but the last
>    are examples of tags which could be registered in future.)

This has to be reworded. en-US is a tag allowed based on the current
subtag registrations. I'm not totally sure about en-cockney and i-cherokee.
The LTRU WG can provide more or different examples.

>    See RFC 4646 for further information.

Again, better use BCP 47.


For 14.4, Accept-Language, please note that BCP 47 (RFC 4647 currently)
also defines a language-range, probably the same as you have, so you
should reference that. There are also various variants for matching
predefined; you should be able to choose the one that fits your needs
best and then only have to define a few details.


>...feedback appreciated.

Great. I'm sure that with the cross-posting, you'll get some more.

Regards,   Martin.



#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:duerst@it.aoyama.ac.jp

Received on Tuesday, 15 April 2008 02:49:47 UTC