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, 5 Oct 2015 13:04:53 +0300
Message-ID: <CAG371notG+a3JQcFTU3KQ2C9-t=kq5J=fvQZN7rNGy8oWW3GMQ@mail.gmail.com>
From: "Ali C. Begen" <acbegen@gmail.com>
To: =?UTF-8?Q?Gunnar_Hellstr=C3=B6m?= <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
>