Re: [Ltru] Proposed resolution for Issue 13 (language tags)

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