Re: [MMUSIC] Clarification for multiple lang attributes in rfc4566bis

Peter Saint-Andre - &yet <peter@andyet.net> Thu, 08 October 2015 19:06 UTC

Return-Path: <peter@andyet.net>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1C841ABD3C for <mmusic@ietfa.amsl.com>; Thu, 8 Oct 2015 12:06:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.299
X-Spam-Level:
X-Spam-Status: No, score=0.299 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, J_CHICKENPOX_12=0.6, J_CHICKENPOX_17=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bgaa_rNoqm_B for <mmusic@ietfa.amsl.com>; Thu, 8 Oct 2015 12:06:18 -0700 (PDT)
Received: from mail-yk0-f175.google.com (mail-yk0-f175.google.com [209.85.160.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B93011AC3A0 for <mmusic@ietf.org>; Thu, 8 Oct 2015 12:06:17 -0700 (PDT)
Received: by ykdg206 with SMTP id g206so58036771ykd.1 for <mmusic@ietf.org>; Thu, 08 Oct 2015 12:06:17 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=D59vKF6WCTn2OJFGnNZ0GU+2IpxpSA/4aGlKejUkPSw=; b=BhYSvsxNvwWg94MQuh2tLI81qy5TqOP7rKqO5fuIMqFssbnWoNb2ropskLopW6LGdm NlF29z9Hk48kp+Y65gxaoktoAa4KCPVlpyHCIdI1W4D2nEFugZSeSkSoQWr021v3eu12 zwX6klu2jjwxGMEb4Y2DSknuqTEpBAdGU+t2ad65wYck5I6q6R7giABIcjvDEXOb1fuP G5ZNVErpXIk0WpKGUVoNYyIp1TSr496rnSpEZc9US45Uo9SELmEL75IJKyg21tFI+Lg3 +wf7Cw2W4HK6uz3TvncCP4Qlwz7RQpEbPdmUNkQ5pFxfUQle1byuR1cG6dqh+yTpkRxP pG4A==
X-Gm-Message-State: ALoCoQnRpAy3rx+5mBghU18r613RMCawO+VKcbK3NvgQfTMkK5aATz3xhb/jPnr/mtDzJw5EyPVG
X-Received: by 10.129.106.4 with SMTP id f4mr6987395ywc.21.1444331176883; Thu, 08 Oct 2015 12:06:16 -0700 (PDT)
Received: from aither.local (71-94-211-114.static.knwc.wa.charter.com. [71.94.211.114]) by smtp.googlemail.com with ESMTPSA id f133sm31409699ywa.27.2015.10.08.12.06.13 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Oct 2015 12:06:15 -0700 (PDT)
To: "Ali C. Begen" <acbegen@gmail.com>, Gunnar Hellström <gunnar.hellstrom@omnitor.se>
References: <5611A155.1050303@omnitor.se> <CAG371notG+a3JQcFTU3KQ2C9-t=kq5J=fvQZN7rNGy8oWW3GMQ@mail.gmail.com>
From: Peter Saint-Andre - &yet <peter@andyet.net>
Message-ID: <5616BEA5.3050407@andyet.net>
Date: Thu, 08 Oct 2015 12:06:13 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <CAG371notG+a3JQcFTU3KQ2C9-t=kq5J=fvQZN7rNGy8oWW3GMQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/25AM6ydbpnbMeTThgooyn3QXRoY>
Cc: "mmusic (E-mail)" <mmusic@ietf.org>
Subject: Re: [MMUSIC] Clarification for multiple lang attributes in rfc4566bis
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Oct 2015 19:06:19 -0000

On 10/5/15 3:04 AM, Ali C. Begen wrote:
> Hi Gunnar
>
> Thanks for bringing this up. I am not against your wording and I dont
> think this change causes issues with recorded material, which could
> support a single or multiple languages and in that case, you can use
> this attribute in the declarative mode.
>
> if there are no objections, I can implement this change in the next cycle.

I support this change.

We had some examples like this (but removed them because of 
incompatibility with RFC 4566) in what became RFC 7573, for instance 
this example in draft-ietf-stox-chat-02...

OFFER

| INVITE sip:romeo@example.net SIP/2.0
| To: <sip:romeo@example.net>
| From: <sip:juliet@example.com>
| Contact: <sip:juliet@example.com>;gr=balcony
| Subject: Open chat with Juliet?
| Call-ID: 29377446-0CBB-4296-8958-590D79094C50
| Content-Type: application/sdp
|
| c=IN IP4 x2s.example.com
| m=message 7654 TCP/MSRP *
| a=accept-types:text/plain
| a=lang:en
| a=lang:it
| a=path:msrp://x2s.example.com:7654/jshA7weztas;tcp

ANSWER

| SIP/2.0 200 OK
| To: <sip:juliet@example.com>;gr=balcony
| From: <sip:romeo@example.net>
| Contact: <sip:romeo@example.net>;gr=orchard
| Call-ID: 29377446-0CBB-4296-8958-590D79094C50
| Content-Type: application/sdp
|
| c=IN IP4 s2x.example.net
| m=message 12763 TCP/MSRP *
| a=accept-types:text/plain
| a=lang:it
| a=path:msrp://s2x.example.net:12763/kjhd37s2s20w2a;tcp

To my mind, it is natural for the lang to specify capabilities.

Peter

>
> -acbegen
>
> On Mon, Oct 5, 2015 at 12:59 AM, Gunnar Hellström
> <gunnar.hellstrom@omnitor.se> wrote:
>> There is some uncertainty about interpretation of multiple lang attributes
>> in RFC 4566 that would need to be sorted out in rfc4566bis.
>> The uncertainty has caused stox to select another mechanism and now also
>> slim is hesitating. (see slim and its real-time draft for a deeper
>> discussion)
>>
>> The current text in section 6.12 of rfc4566bis is:
>>
>> -----------------------------current text from
>> 6.12--------------------------------
>>
>> Multiple lang attributes can be provided either at session or media
>>     level if the session or media use multiple languages, in which case
>>     the order of the attributes indicates the order of importance of the
>>     various languages in the session or media, from most important to
>>     least important.
>>
>>     As a session-level attribute, it specifies the default language for
>>     the session being described.  As a media-level attribute, it
>>     specifies the language for that media, overriding any session-level
>>     languages specified.
>>
>>     The "lang" attribute value must be a single [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 is in a
>>     different language from the locally assumed norm.
>>
>> -----------------------------------------------------------------------------------------------
>>
>> The uncertainty has been around what the wording "use multiple languages"
>> means.
>> It can mean that all are provided simultaneously, but it can also mean that
>> it is a list of capabilities and
>> that events during the session can decide which languages will really be
>> used. There is also uncertainty
>> about if a negotiation can take place to agree on one or a set of common
>> languages to select from as default language(s).
>>
>> In order to bring some clarity, I suggest to change to the following:
>>
>> -----------------------------proposed replacement text for
>> 6.12--------------------------------
>>
>>     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] 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 may influence which language(s) are used, and
>> the
>>     participants are not strictly bound to only use the declared languages.
>>
>>
>>
>> -----------------------------------------------------------------------------------------------
>>
>> My conclusion from looking at the background of the wording for lang in RFC
>> 4566 is that we can safely assume that for real-time sessions, the meaning
>> of multiple lang specifications is a range of capabilities, and not a
>> requirement to use all languages.
>> By that interpretation, we can also assume that an offer/answer exchange can
>> negotiate the language(s) to be suitable for use in a session to be a subset
>> of what the offer contained.
>>
>> I traced the introduction of the wording from an announcement in mmusic on
>> 1997-11-23, and then the wording appeared in draft-ietf-mmusic-sdp-05 on
>> 1997-12-23. There was no further discussion and the wording has stayed like
>> that with merely a swap of the paragraphs in rfc4566bis.
>>
>> In the mail announcing the introduction it was said that the intention was
>> to fulfill requirements from a draft that then became RFC 2277.
>>
>> A relevant section in RFC 2277 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. "
>>
>> So it is apparent that the intention for real-time conversational cases is a
>> negotiation with
>>   an offer and a selection, either in an answer or by human agreement in the
>> session.
>>
>> The central word creating the hesitation in interpretation is that all
>> languages must be used is "use" in this phrase:
>> "if the session description or media use multiple languages".
>>
>> It is hard to believe that it was the intention that all must be used. The
>> proposed wording is made to make the
>> interpretation clear that it is a set of capabilities..
>>
>> There are multiple reasons for that interpretation:
>>
>> 1. It aligns with the requirement for language negotiation in RFC 2277 that
>> was said to be
>>     the requirement behind the wording.
>> 2. It is usually unrealistic to use multiple languages at the same time in a
>> medium.
>>     It is more in line at least with real-time conversation that events
>> during the conversation causes decision to use
>>     just one language.
>> 3. The discussion in the original wording of importance of languages lose
>> its meaning if all must be used. "the
>> order of the attributes indicates the order of importance of the various
>> languages in the session or media".
>> There is no use of knowing how important a language is if they all must be
>> presented. It is more likely that
>> this relates to a possibility to select languages and that the "importance"
>> is a grading of preference.
>>
>> This would mean that we can safely assume that the use of multiple lang
>> attributes in SDP were and are intended as
>> a selection and that negotiation through offer/answer is possible.
>>
>>
>> I realize that the language about capabilities in my proposal does not match
>> an sdp that belongs to a
>> static session with recorded material equally well as it does for a
>> real-time session between human participants,
>> but I want anyway propose the wording.
>>
>> /Gunnar Hellström
>>