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 >>
- [MMUSIC] Clarification for multiple lang attribut… Gunnar Hellström
- Re: [MMUSIC] Clarification for multiple lang attr… Ali C. Begen
- Re: [MMUSIC] Clarification for multiple lang attr… Peter Saint-Andre - &yet
- Re: [MMUSIC] Clarification for multiple lang attr… Ali C. Begen
- Re: [MMUSIC] Clarification for multiple lang attr… Gunnar Hellström