Proposed resolution for Issue 13 (language tags)

[Julian Reschke]

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,


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>


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>).

    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.)

    See RFC 4646 for further information.


...feedback appreciated.

Julian

[Frank Ellermann]

Julian Reschke wrote:

> language-tag  = <Language-Tag, defined in [RFC4646], Section 2.1>

+1, but keep in mind that LTRU might replace 4646 by 4646bis before
    2616bis is ready.

> Example tags include:

RFC 2616 has:  en, en-US, en-cockney, i-cherokee, x-pig-latin

Please replace en-cockney by say es-419, and i-cherokee by say
az-Arab.  Rationale:  

* en-cockney doesn't exist,
* es-419 shows a new 4646-feature (UN region number),
* i-cherokee doesn't exist,
* az-Arab shows a new 4646-feature (script subtags).

> (The last three tags above are not registered tags; all but the
>  last are examples of tags which could be registered in future.)

That misses the point of RFC 4646, apart from some grandfathered
tags, and primary subtags like "en" that can be used as tags, the
registry conains *subtags*.  

And "en", "US", "es", "419", "az", and "Arab" are all registered
*subtags*.

> ...feedback appreciated.

I missed that above, the link is wrong:

| The name space of language tags is administered by the
| IANA (<http://www.iana.org/assignments/language-tags>).

That is the *obsolete* RFC 3066 tag registry, please write:

| The name spaces of language subtags are administered by the
| IANA, <http://www.iana.org/assignments/language-subtag-registry>.

Actually three namespaces (languages, scripts, regions) in
essence copy standards by third parties, but these details
are explained in RFC 4646.

 Frank

[Brian Smith-19]

Julian Reschke wrote:
> 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>).

This is already specified by RFC 4646. Just delete the old text without
replacing it with anything.

- Brian

[David Morris-4]

A small typo ... if you keep the sentence ....

On Mon, 14 Apr 2008, Julian Reschke wrote:

>
> NEW:
>
>     (The last three tags above are not registered tags; all but the last
>     are examples of tags which could be registered in future.)
                                      in the future<<---------

["Martin J. Dürst"]

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@...    

[Frank Ellermann]

Martin Duerst wrote:

> I'm not totally sure about en-cockney and i-cherokee.

i-cherokee cannot be registered because the language
already has another subtag, and besides RFC 4646 does
not permit i-whatever registrations.  "en-cockney" is
in theory possible, but no compelling example, "en"
and "en-US" are already enough "en".

>>    See RFC 4646 for further information.
> Again, better use BCP 47.

The normative reference is RFC 4646 at the moment, not
some moving target.  A successor of RFC 4646 can do
whatever it needs to do, e.g., dump the subtag syntax
in favour of ISO 639-6, trash the extlang-syntax if it
turned out to be unnecessary, reintroduce i-whatever
tags, or invent a new concept for region codes.  Two
of these four points are far from only hypothetical.

2616bis has to fix the RFC 2616 1*8ALPHA bug without
introducing new bugs, and for that it needs a precise
reference.  Whatever is state of the art in a year.
 
 Frank

[Stephane Bortzmeyer]

On Mon, Apr 14, 2008 at 09:49:22PM +0200,
 Frank Ellermann <nobody@...> wrote
 a message of 46 lines which said:

> RFC 2616 has:  en, en-US, en-cockney, i-cherokee, x-pig-latin
>
> Please replace en-cockney by say es-419, and i-cherokee by say
> az-Arab.  Rationale:  

+1

I suggest also a man-Nkoo-GN to show both the use of >1 subtags and a
three-letter language subtag.

[Stephane Bortzmeyer]

On Mon, Apr 14, 2008 at 01:15:55PM -0700,
 Brian Smith <brian@...> wrote
 a message of 14 lines which said:

> >     White space is not allowed within the tag and all tags are case-
> >     insensitive.
>
> This is already specified by RFC 4646. Just delete the old text without
> replacing it with anything.

-1

Repeating the case-insensitivity rule of RFC 4646 increases the
probability it will be noticed by developers.

[Frank Ellermann]

Stephane Bortzmeyer wrote:

>> Please replace en-cockney by say es-419, and i-cherokee
>> by say az-Arab.
 
> +1
 
> I suggest also a man-Nkoo-GN to show both the use of >1
> subtags and a three-letter language subtag.

ACK, readers familiar with RFC 2616 won't necessarily know
new tricks introduced after RFC 1766.  But I'm not sure if
using an ISO 639-3 "macrolanguage" is a good idea, or how
plausible man-Nkoo-GN is.  For i-cherokee fans chr-Cher-US
might do, but then US is unnecessary (against 4646 rules).

 Frank

[Stephane Bortzmeyer]

On Tue, Apr 15, 2008 at 11:13:06AM +0200,
 Frank Ellermann <nobody@...> wrote
 a message of 17 lines which said:

> But I'm not sure if using an ISO 639-3 "macrolanguage" is a good
> idea,

It already existed in 639-2, long before the concept of macrolanguage
was invented. Anyway, 4646bis will not treat the macrolanguages
differently from other languages...

> or how plausible man-Nkoo-GN is.

Plausible and in real use in Guinea.

[Julian Reschke]

Frank Ellermann wrote:
> Julian Reschke wrote:
>
>> language-tag  = <Language-Tag, defined in [RFC4646], Section 2.1>
>
> +1, but keep in mind that LTRU might replace 4646 by 4646bis before
>     2616bis is ready.

Optimally, we'll just have to bump up the reference then, right?

>> Example tags include:
>
> RFC 2616 has:  en, en-US, en-cockney, i-cherokee, x-pig-latin
>
> Please replace en-cockney by say es-419, and i-cherokee by say
> az-Arab.  Rationale:  
>
> * en-cockney doesn't exist,
> * es-419 shows a new 4646-feature (UN region number),
> * i-cherokee doesn't exist,
> * az-Arab shows a new 4646-feature (script subtags).

Ack.

>> (The last three tags above are not registered tags; all but the
>>  last are examples of tags which could be registered in future.)
>
> That misses the point of RFC 4646, apart from some grandfathered
> tags, and primary subtags like "en" that can be used as tags, the
> registry conains *subtags*.  
>
> And "en", "US", "es", "419", "az", and "Arab" are all registered
> *subtags*.

I'm tempted to drop the statement, or even go further to drop the
example as well.

>> ...feedback appreciated.
>
> I missed that above, the link is wrong:
>
> | The name space of language tags is administered by the
> | IANA (<http://www.iana.org/assignments/language-tags>).
>
> That is the *obsolete* RFC 3066 tag registry, please write:
>
> | The name spaces of language subtags are administered by the
> | IANA, <http://www.iana.org/assignments/language-subtag-registry>.

Ack.

> Actually three namespaces (languages, scripts, regions) in
> essence copy standards by third parties, but these details
> are explained in RFC 4646.
>
>  Frank


BR, Julian

[Julian Reschke]

Martin Duerst wrote:
> 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 ...".

Ack.

> 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.

As we're including the Language-Tag ABNF production by reference, I'd
prefer to stick with a fixed reference.

> 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.

ACK.

>> 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.

I think the simplest fix is just to remove the statement.

> 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.

Good catch; I'd prefer to deal with this separately.

> ...

BR, Julian

[Julian Reschke]

OK,

thanks for all the feedback so far. I (hopefully) have addressed many of
the issues; here's the new proposed text for 3.5:

------
3.5.  Language Tags

    A language tag, as defined in [RFC4646], identifies a natural
    language spoken, written, or otherwise conveyed by human beings for
    communication of information to other human beings.  Computer
    languages are explicitly excluded.  HTTP uses language tags within
    the Accept-Language and Content-Language fields.

    In summary, a language tag is composed of one or more parts: A
    primary language tag and a possibly empty series of subtags:

      language-tag  = <Language-Tag, defined in [RFC4646], Section 2.1>

    White space is not allowed within the tag and all tags are case-
    insensitive.  The name space of language subtags is administered by
    the IANA (see
    <http://www.iana.org/assignments/language-subtag-registry>).

    Example tags include:

      en, en-US, es-419, az-Arab, x-pig-latin, man-Nkoo-GN

    See RFC 4646 for further information.
------

(see also <http://www.tools.ietf.org/wg/httpbis/trac/ticket/13>).


BR, Julian

[Phillips, Addison]

Hi,

I have a number of thoughts on the proposed changes, which appear below my signature.

I would suggest that HTTPbis wait in order to reference 4646bis, which is in WG last call, if at all possible. I mention this for two reasons:

1. It would be better to reference the update than the soon-to-be-obsolete version, even though the differences are minor.

2. The new version includes an ABNF production of value to HTTPbis (obs-language).

Best Regards,

Addison

Addison Phillips
Globalization Architect -- Lab126 (Amazon)
Chair -- W3C Internationalization Core WG

Internationalization is not a feature.
It is an architecture.

>
> Martin Dürst wrote comments on Julian's email which said in part:
> >
> >(see also <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/13>).
> >
> >

>
> 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 ...".

I agree with Martin here. However, it may be useful to reference the RFC 3066 Language-Tag production in Section 2.2.9, for compatibility with existing RFC 2616 implementations, and to specify "well-formed" conformance.
>
>
So I strongly suggest you reference BCP 47
> rather than a specific RFC.

+1

>
>
> >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.

It may be better to reference Language-Tag as defined in 2.2.9 for compatibility. While it would be good to adopt the modern language tag ABNF, that would suggest that receivers reject tags that were well-formed but no longer are.

>
> 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.

"en-cockney" is not valid, nor is "i-cherokee". "i-cherokee" can NEVER be registered. The "cockney" subtag could be registered. However, there is no need to use artificial examples (as there was when RFC 2616 was written). It would be better to use examples from RFC 4646/4646bis.

Note: Cherokee is in the registry with the subtag 'chr'.


>
> 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.

Actually, Accept-Language is an example of a "language priority list" in RFC 4647. However, RFC 4647 doesn't define the exact syntax for a language priority list. The "language-range" production *is* defined by RFC 4647, as a "Basic Language Range".

The text about matching of language ranges and tags in RFC 2616 is the same as the Basic Filtering algorithm--in fact, the latter was designed to be identical. However, I think that choosing this algorithm explicitly would be a Bad Thing. Sometimes the Lookup algorithm is the right choice for an application (as when selecting user interface language for an application), while at other times one of the Filtering algorithms makes more sense (as when selecting search results).

Note that the text in RFC 2616 should have been superseded by RFC 3282. Ultimately, I think that 2616bis should define Accept-Language using the existing ABNF but adopting the terminology in RFC 4647. It should then guide users to BCP 47 (RFC 4647) regarding the selection of matching algorithms.

[Phillips, Addison]

"No sooner do I push send..."

This text would work for me.

Addison

Addison Phillips
Globalization Architect -- Lab126 (Amazon)
Chair -- W3C Internationalization Core WG

Internationalization is not a feature.
It is an architecture.

> -----Original Message-----
> From: ltru-bounces@... [mailto:ltru-bounces@...] On Behalf Of
> Julian Reschke
> Sent: mardi 15 avril 2008 04:33
> To: HTTP Working Group; LTRU Working Group
> Subject: Re: [Ltru] Proposed resolution for Issue 13 (language tags)
>
> OK,
>
> thanks for all the feedback so far. I (hopefully) have addressed many
> of
> the issues; here's the new proposed text for 3.5:
>
> ------
> 3.5.  Language Tags
>
>     A language tag, as defined in [RFC4646], identifies a natural
>     language spoken, written, or otherwise conveyed by human beings for
>     communication of information to other human beings.  Computer
>     languages are explicitly excluded.  HTTP uses language tags within
>     the Accept-Language and Content-Language fields.
>
>     In summary, a language tag is composed of one or more parts: A
>     primary language tag and a possibly empty series of subtags:
>
>       language-tag  = <Language-Tag, defined in [RFC4646], Section 2.1>
>
>     White space is not allowed within the tag and all tags are case-
>     insensitive.  The name space of language subtags is administered by
>     the IANA (see
>     <http://www.iana.org/assignments/language-subtag-registry>).
>
>     Example tags include:
>
>       en, en-US, es-419, az-Arab, x-pig-latin, man-Nkoo-GN
>
>     See RFC 4646 for further information.
> ------
>
> (see also <http://www.tools.ietf.org/wg/httpbis/trac/ticket/13>).
>
>
> BR, Julian
> _______________________________________________
> Ltru mailing list
> Ltru@...
> https://www.ietf.org/mailman/listinfo/ltru

[Frank Ellermann]

Julian Reschke wrote:

> Optimally, we'll just have to bump up the reference then, right?

Almost certainly, yes.  Just don't *copy* RFC 4646 syntax details.

> I'm tempted to drop the statement, or even go further to drop
> the example as well.

An updated example would be nice.  For readers not familar with
new 4646-features it could get them to read RFC 4646, figure out
what es-419 is, lookup man-Nkoo-GN, or simply see that az-Arab
is something that wasn't possible before.  Admittedly a case of
RFC-spamvertizing, not necessary to get HTTP technically right.

 Frank

["Martin J. Dürst"]

At 20:33 08/04/15, Julian Reschke wrote:

>
>OK,
>
>thanks for all the feedback so far. I (hopefully) have addressed many of the issues; here's the new proposed text for 3.5:
>
>------
>3.5.  Language Tags
>
>    A language tag, as defined in [RFC4646], identifies a natural
>    language spoken, written, or otherwise conveyed by human beings for
>    communication of information to other human beings.  Computer
>    languages are explicitly excluded.  HTTP uses language tags within
>    the Accept-Language and Content-Language fields.
>
>    In summary, a language tag is composed of one or more parts: A
>    primary language tag and a possibly empty series of subtags:
>
>      language-tag  = <Language-Tag, defined in [RFC4646], Section 2.1>
>
>    White space is not allowed within the tag and all tags are case-
>    insensitive.  The name space of language subtags is administered by
>    the IANA (see
>    <http://www.iana.org/assignments/language-subtag-registry>).

This is going very much in the right direction, but there
is some confusion about what a subtag means. Where it says
"A primary language tag and a possibly empty series of subtags",
the first tag (e.g. 'en' in 'en-US') seems to not be a subtag,
but the subtag registry clearly also includes that as a subtag,
and RFC 4646 is using terminology consistent with that.

Regards,   Martin.

>    Example tags include:
>
>      en, en-US, es-419, az-Arab, x-pig-latin, man-Nkoo-GN
>
>    See RFC 4646 for further information.
>------
>
>(see also <http://www.tools.ietf.org/wg/httpbis/trac/ticket/13>).
>
>
>BR, Julian
>

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

[Debbie Garside]

I would agree with Martin and propose the following changes:

From:
---
> >    In summary, a language tag is composed of one or more parts: A
> >    primary language tag and a possibly empty series of subtags:

To:
---

In summary, a language tag is composed of one or more parts: A
primary language subtag followed by a, possibly empty, series of subtags:

---

best regards

Debbie Garside

> -----Original Message-----
> From: ltru-bounces@... [mailto:ltru-bounces@...] On
> Behalf Of Martin Duerst
> Sent: 16 April 2008 08:02
> To: Julian Reschke; HTTP Working Group; LTRU Working Group
> Subject: Re: [Ltru] Proposed resolution for Issue 13 (language tags)
>
> At 20:33 08/04/15, Julian Reschke wrote:
> >
> >OK,
> >
> >thanks for all the feedback so far. I (hopefully) have
> addressed many of the issues; here's the new proposed text for 3.5:
> >
> >------
> >3.5.  Language Tags
> >
> >    A language tag, as defined in [RFC4646], identifies a natural
> >    language spoken, written, or otherwise conveyed by human
> beings for
> >    communication of information to other human beings.  Computer
> >    languages are explicitly excluded.  HTTP uses language
> tags within
> >    the Accept-Language and Content-Language fields.
> >
> >    In summary, a language tag is composed of one or more parts: A
> >    primary language tag and a possibly empty series of subtags:
> >
> >      language-tag  = <Language-Tag, defined in [RFC4646],
> Section 2.1>
> >
> >    White space is not allowed within the tag and all tags are case-
> >    insensitive.  The name space of language subtags is
> administered by
> >    the IANA (see
> >    <http://www.iana.org/assignments/language-subtag-registry>).
>
> This is going very much in the right direction, but there is
> some confusion about what a subtag means. Where it says "A
> primary language tag and a possibly empty series of subtags",
> the first tag (e.g. 'en' in 'en-US') seems to not be a
> subtag, but the subtag registry clearly also includes that as
> a subtag, and RFC 4646 is using terminology consistent with that.
>
> Regards,   Martin.
>
> >    Example tags include:
> >
> >      en, en-US, es-419, az-Arab, x-pig-latin, man-Nkoo-GN
> >
> >    See RFC 4646 for further information.
> >------
> >
> >(see also <http://www.tools.ietf.org/wg/httpbis/trac/ticket/13>).
> >
> >
> >BR, Julian
> >
>
>
> #-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
> #-#-#  http://www.sw.it.aoyama.ac.jp
> mailto:duerst@...
>
> _______________________________________________
> Ltru mailing list
> Ltru@...
> https://www.ietf.org/mailman/listinfo/ltru
>
>
>
>

[Julian Reschke]

Debbie Garside wrote:

> I would agree with Martin and propose the following changes:
>
> From:
> ---
>>>    In summary, a language tag is composed of one or more parts: A
>>>    primary language tag and a possibly empty series of subtags:
>
> To:
> ---
>
> In summary, a language tag is composed of one or more parts: A
> primary language subtag followed by a, possibly empty, series of subtags:
>
> ---
>
> best regards
>
> Debbie Garside

Hi Debbie,

thanks for the proposed text (which I'll include).

BR, Julian

[Julian Reschke]

Phillips, Addison wrote:
> Hi,
>
> I have a number of thoughts on the proposed changes, which appear below my signature.
>
> I would suggest that HTTPbis wait in order to reference 4646bis, which is in WG last call, if at all possible. I mention this for two reasons:
>
> 1. It would be better to reference the update than the soon-to-be-obsolete version, even though the differences are minor.
>
> 2. The new version includes an ABNF production of value to HTTPbis (obs-language).

Now that would be a good reason.

Are you saying that HTTP should use that production (obs-language,
<http://www.tools.ietf.org/html/draft-ietf-ltru-4646bis-12#section-2.2.9>),
instead of Language-Tag
(<http://www.tools.ietf.org/html/draft-ietf-ltru-4646bis-12#section-2.1>)?

I'm no expert on that matter... do we have consensus on this among those
who are?

>> Martin Dürst wrote comments on Julian's email which said in part:
>>> (see also <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/13>).
>>>
>>>
>
>> 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 ...".
>
> I agree with Martin here. However, it may be useful to reference the RFC 3066 Language-Tag production in Section 2.2.9, for compatibility with existing RFC 2616 implementations, and to specify "well-formed" conformance.

In which case it may be simpler to just align the definition in HTTPbis
with that production (instead of referring directly to RFC3066).

> So I strongly suggest you reference BCP 47
>> rather than a specific RFC.
>
> +1

I don't see how, as long as we want to include a specific ABNF production.

>>> 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.
>
> It may be better to reference Language-Tag as defined in 2.2.9 for compatibility. While it would be good to adopt the modern language tag ABNF, that would suggest that receivers reject tags that were well-formed but no longer are.

For the record: that's in RFC4646bis, but not in RFC4646, right?

 > ...

BR, Julian