Subject: Re: [Slim] Claim of consensus on meaning of RFC 4566 "lang" attribute

From: Gunnar Hellström <[email-masked]>
Date: Thu, 19 May 2016 08:09:55 +0200

Bernard,

I got the impression that you wanted to collect earlier discussions on 
the intentions and interpretations of the 'lang' attribute in RFC 4566 
in order to get to a conclusion for the reference of it in the work in 
SLIM (or MMUSIC).

Was that the intention? Did you get to any conclusion?

I think the reasoning about RFC 4566 lang attribute in the current 
humintlang-01 draft expresses the wrong conclusion and thereby increases 
the confusion around its usage. It is sufficient in our draft to say 
that the lang attribute cannot express directionality and therefore we 
need to introduce something new.
As stated in the mail below, the lang attribute was introduced in the 
sdp specification as a response to requirements for language negotiation 
in a draft that became RFC 2277. The section in RFC 2277 that talks 
about it is:
"

4.4.  Considerations for language negotiation

    Protocols where users have text presented to them in response to user
    actions MUST provide for support of multiple languages.

    How this is done will vary between protocols; for instance, in some
    cases, a negotiation where the client proposes a set of languages and
    the server replies with one is appropriate; in other cases, a server
    may choose to send multiple variants of a text and let the client
    pick which one to display.

    Negotiation is useful in the case where one side of the protocol
    exchange is able to present text in multiple languages to the other
    side, and the other side has a preference for one of these; the most
    common example is the text part of error responses, or Web pages that
    are available in multiple languages.

    Negotiating a language should be regarded as a permanent requirement
    of the protocol that will not go away at any time in the future.

    In many cases, it should be possible to include it as part of the
    connection establishment, together with authentication and other
    preferences negotiation."

Here it is only talk about selecting*_a_*  single language. According to the mail sent when the attribute was introduced in the SDP specification, the wording in RFC 4566 was intended to match this requirement. The interpretation in our SLIM draft that the lang attribute always aims at usage of ALL specified languages together in a session is therefore wrong. It is about selection of the single initial language in the call.

This conclusion leaves the RFC 4566 lang attribute without a way to require use of multiple languages together in a session. That is a valid case, but more seldom needed than selecting a single initial language.

But, since RFC 4566 lang is not sufficient, we do not need to go deeper in the analysis of it but just to say that it does not handle directionality.

/Gunnar

Den 2016-04-10 kl. 21:44, skrev Gunnar Hellström:
> The very origin of the 'lang' sdp attribute is its announcement last 
> in this e-mail from 1997-11-23
> https://mailarchive.ietf.org/arch/msg/mmusic/hEU4yCmc31ib4Vk23aCQPfm5QvQ
>
> It is said to fulfill a requirement from a draft that later became RFC 
> 2277.
>
> /Gunnar
>
>
>
>
>
> Den 2016-04-08 kl. 00:58, skrev Gunnar Hellström:
>> Bernard,
>> Also the discussion we had in SLIM in October explains the history of 
>> the 'lang' attribute.
>> Starting with mail with subject "The use of multiple lang attributes 
>> in SDP" on 2015-10-04.
>>
>> Linking it back to a need to describe language negotiation in RFC 2277.
>>
>> This background makes it clear that the intention was for selection 
>> and negotiation.
>>
>> /Gunnar
>>
>>
>>
>> Den 2016-04-07 kl. 23:11, skrev Gunnar Hellström:
>>> I had a discussion in mmusic in October 2015 under the subject:
>>> "Clarification for multiple lang attributes in rfc4566bis"
>>> Starting at:
>>> https://mailarchive.ietf.org/arch/search/?email_list=mmusic&qdr=y&q=rfc4566bis
>>>
>>> /Gunnar
>>>
>>>
>>>
>>> Den 2016-04-07 kl. 22:08, skrev Bernard Aboba:
>>>> Here is what we have in RFC 4566bis 
>>>> (https://tools.ietf.org/html/draft-ietf-mmusic-rfc4566bis-16#page-36):
>>>>
>>>>     Multiple lang attributes can be provided either at session or media
>>>>     level if the session or media has capabilities to use multiple
>>>>     languages, in which case the order of the attributes indicates the
>>>>     order of preference of the various languages in the session or media,
>>>>     from most preferred to least preferred.
>>>>
>>>>     As a session-level attribute, lang specifies a language capability
>>>>     for the session being described.  As a media-level attribute, it
>>>>     specifies a language capability for that media, overriding any
>>>>     session-level language(s) specified.
>>>>     The "lang" attribute value must be a single [RFC5646 <https://tools.ietf.org/html/rfc5646>] language tag in
>>>>     US-ASCII.  A "lang" attribute SHOULD be specified when a session is
>>>>     of sufficient scope to cross geographic boundaries where the language
>>>>     of recipients cannot be assumed, or where the session has
>>>>     capabilities in languages different from the locally assumed norm.
>>>>
>>>>     Events during the session can influence which language(s) are used,
>>>>     and the participants are not strictly bound to only use the declared
>>>>     languages.
>>>>
>>>>
>>>> On Thu, Apr 7, 2016 at 1:03 PM, Bernard Aboba 
>>>> <[email-masked]> wrote:
>>>>
>>>>     In today's meeting, we had folks pointing to discussions of the
>>>>     meaning of the "lang" attribute in previous meetings (in
>>>>     MMUSIC).  Can people post pointers to those previous discussions?
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> SLIM mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/slim
>>>
>>> -- 
>>> -----------------------------------------
>>> Gunnar Hellström
>>> Omnitor
>>> [email-masked]
>>> +46 708 204 288
>>>
>>>
>>> _______________________________________________
>>> SLIM mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/slim
>>
>> -- 
>> -----------------------------------------
>> Gunnar Hellström
>> Omnitor
>> [email-masked]
>> +46 708 204 288
>>
>>
>> _______________________________________________
>> SLIM mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/slim
>
> -- 
> -----------------------------------------
> Gunnar Hellström
> Omnitor
> [email-masked]
> +46 708 204 288
>
>
> _______________________________________________
> SLIM mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/slim

-- 
-----------------------------------------
Gunnar Hellström
Omnitor
[email-masked]
+46 708 204 288