Re: [MMUSIC] Clarification for multiple lang attributes in rfc4566bis
"Ali C. Begen" <acbegen@gmail.com> Mon, 05 October 2015 10:04 UTC
Return-Path: <acbegen@gmail.com>
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 219B21B4EFE for <mmusic@ietfa.amsl.com>; Mon, 5 Oct 2015 03:04:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level:
X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, 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 L5P653qCdklA for <mmusic@ietfa.amsl.com>; Mon, 5 Oct 2015 03:04:54 -0700 (PDT)
Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (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 C61571B4EFA for <mmusic@ietf.org>; Mon, 5 Oct 2015 03:04:53 -0700 (PDT)
Received: by oibi136 with SMTP id i136so88124237oib.3 for <mmusic@ietf.org>; Mon, 05 Oct 2015 03:04:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=h3TKUjat5eThipwKq8H0BUkkDzyQKP94QarrVpXCDFI=; b=bxDR08UkfCfv6SpNyVhBKOAR5zmQbJJY2ZwF/1n2++pF5I77znfjva7wyS1aNj8qLb cCrqbcBFp+jcOwX+U0DQLKSAocFt+SJDWDa0WHjbbsLWa7rwPhhp+R2hPMr6LlnQVTdy 35yCEo8fVmOSGeuL94oGFG41KW0AQgVMAmrl/2DbmBU7ZRYo3LIZt7GbDq1zyOafl17c IUzZJ2jRS2Fcqp+BD748ZJ+3MPh1knHpAHMA+ehwkt7uIsXgjm8d33HFNjruutHtjHBA kQeJ+KShYm5AZ90zQ6h+KPzNcycer7CIWOUTE/N6iEyGbCqlmOUR1X8C8DUgdtBm2AOF Rr4g==
MIME-Version: 1.0
X-Received: by 10.202.181.198 with SMTP id e189mr15609572oif.6.1444039493199; Mon, 05 Oct 2015 03:04:53 -0700 (PDT)
Received: by 10.202.213.83 with HTTP; Mon, 5 Oct 2015 03:04:53 -0700 (PDT)
In-Reply-To: <5611A155.1050303@omnitor.se>
References: <5611A155.1050303@omnitor.se>
Date: Mon, 05 Oct 2015 13:04:53 +0300
Message-ID: <CAG371notG+a3JQcFTU3KQ2C9-t=kq5J=fvQZN7rNGy8oWW3GMQ@mail.gmail.com>
From: "Ali C. Begen" <acbegen@gmail.com>
To: Gunnar Hellström <gunnar.hellstrom@omnitor.se>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/eCSTjDeiXFiMczUHUIbAnZ-3HhA>
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: Mon, 05 Oct 2015 10:04:56 -0000
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. -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 mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic >
- [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