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

"Ali C. Begen" <acbegen@gmail.com> Thu, 21 July 2016 02:34 UTC

Return-Path: <acbegen@gmail.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFAFA12D920 for <mmusic@ietfa.amsl.com>; Wed, 20 Jul 2016 19:34:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 N20AK_0DhWkN for <mmusic@ietfa.amsl.com>; Wed, 20 Jul 2016 19:34:49 -0700 (PDT)
Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (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 5270112D9C5 for <mmusic@ietf.org>; Wed, 20 Jul 2016 19:34:49 -0700 (PDT)
Received: by mail-oi0-x232.google.com with SMTP id j185so98578206oih.0 for <mmusic@ietf.org>; Wed, 20 Jul 2016 19:34:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cxA008+FeW974qMac8yFiEUssWy23YYxmHOVCXG8rRo=; b=gJTYqpzQjGuauzW2sDAhNQPcaISxErCxykTvfc4ZFUEsdFPCwO4Hyg7rYILgDoedv9 CBS01zQDUfpCIRDGZSsOacb4jrxXPJ1CDhgI6kQCjyC/uCXvbnqvMtkTgS/y9qIFqDOg Jv/njQRnHCy4ABQmN0v7SGw/J3VL+S4aVjeBnQ7fIWYlloez3yZOT0/yxWo7KfVJKYRT ztXonIwXjjrvxrKsimeNymfzWo2RQAqyG0TjtE2twyCScsoLpdGpDUtNymckbN2HgRcc K13Ysv7eDyPyLHAyC6VSxb4X1LiwPlGvYiwgv9bBXlEz7z+FdALKr2yvnxUjSeiQL1zP gzfg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=cxA008+FeW974qMac8yFiEUssWy23YYxmHOVCXG8rRo=; b=PK/U9cazOx9eisDRaDjO629fjxKpNtN79g985KsXieq6WIUTka848rdFj+ye20rjNB 85rctRyZe3CV0R1p+9G+q9IEBFuVF3Wp6Hu/49qF6Tp/ijZSBoy7klV7wDUlTl5zx5e8 jjB9CEPIvBfHA+38j4yREqkBRUSjYs51iz9K468qdxAr84BiR8fX2JN/EDRhHzGgP4/J Xs0iQDzpjGJJ08z7XDFXIWeRUtPO1GWUoKK8R97Iji6nDbGBGvv0wnRMgSNNbl0gMubb E8PVuFnX8C2b0iI6XoVE9b7kXWU7QUjIOKave6odhEqbgVhKOxFgfYbwOCdg3qjGgZvJ Nx9g==
X-Gm-Message-State: ALyK8tJthKltIURCeoLD8hTQ9sv2pTJcTw2YzssitY1zFVnbO9f5zMjUuyo1Aw74RPFLzNYMNHuNrNCHkEdKwA==
X-Received: by 10.202.50.139 with SMTP id y133mr23775438oiy.46.1469068488670; Wed, 20 Jul 2016 19:34:48 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.202.182.86 with HTTP; Wed, 20 Jul 2016 19:34:48 -0700 (PDT)
In-Reply-To: <ac9cb83f-1dae-870b-727e-4c37fa443092@omnitor.se>
References: <5611A155.1050303@omnitor.se> <CAG371notG+a3JQcFTU3KQ2C9-t=kq5J=fvQZN7rNGy8oWW3GMQ@mail.gmail.com> <ac9cb83f-1dae-870b-727e-4c37fa443092@omnitor.se>
From: "Ali C. Begen" <acbegen@gmail.com>
Date: Thu, 21 Jul 2016 05:34:48 +0300
Message-ID: <CAG371nqobfoVBjpbbwy_npAMqpzNJQ6kY7TVzWC9UEqRchLouw@mail.gmail.com>
To: =?UTF-8?Q?Gunnar_Hellstr=C3=B6m?= <gunnar.hellstrom@omnitor.se>
Content-Type: multipart/alternative; boundary=001a113cf21e6b04bd05381c2976
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/6aBl3ipyllDWdx4qw9sEZ-Fi1e0>
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.17
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, 21 Jul 2016 02:34:53 -0000

Hi Gunnar

I will be happy to make the change once the WG agrees with it. I am not in
Berlin this week, but if this can be discussed in the mmusic session, that
would be good.

On Wed, Jul 20, 2016 at 1:11 AM, Gunnar Hellström <
gunnar.hellstrom@omnitor.se>; wrote:

> Ali and all,
>
> The correspondence below is from a request to clarify language in
> rfc4566bis for the 'lang' attribute.
>
> The proposed modification was successfully done, so, in the current
> version, the description for the 'lang' attribute is as indicated in the
> "proposed replacement" a bit down in the earlier mail. Thanks!
>
> However, we have discussed this in SLIM and found that there may still be
> room for different interpretations. One would still be that indication of
> multiple 'lang' attributes would mean a desire to use them all during the
> session, and another interpretation that a list of 'lang' attributes mean a
> list for selection what to use during the session, and usually only one
> language will be selected and used.
>
> We have recommended to have the discussions here in mmusic, where the
> question belongs.
>
> In slim, it is in draft-ietf-slim-negotiating-human-language-01 that we
> have a section 5 discussing this topic. The discussion is supposed to be
> drastically reduced in next version. There is also more about the
> background below.
>
> So, again, a wording proposal for section 6.12 of rfc4566bis:
>
> ------------------------------Current wording of
> 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.
>
> ----------------------------------------------------------------------------
> -----------------------Proposed wording-------------------------------
>    Multiple lang attributes can be provided either at session or media
>    level if the session or media has capabilities in more than one
> language,
> 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 participants cannot be assumed, or where the session has
> capabilities in
>    languages different from the locally assumed norm.
>
>  The 'lang' attribute is supposed to be used for settling the initial
>  language(s) used in the session.
>    Events during the session may influence which language(s) are used, and
> the
>    participants are not strictly bound to only use the declared languages.
>
> Most real-time use cases start with just one language used, while other
> cases involve a range of languages, e.g. an interpreted or subtitled
> session. When more than one 'lang' attribute is specified, the 'lang'
> attribute itself does not provide any information about if multiple
> languages are intended to be used during the session, or if the intention
> is to only select one language. Other attributes or the semantics in which
> the 'lang' attributes are used may indicate such conditions. Without such
> indications of usage intent, it should be assumed that for a negotiated
> session one of the declared languages should be selected and used.
>
> --------------------------End of wording
> proposal--------------------------------
>
> I realize that the last paragraph is fuzzy, and would appreciate a
> discussion on the best way to handle this, and also the best way to ease
> the use of the 'lang' attribute already when current RFC4566 is used.
>
> Regards
> Gunnar
>
> -----------------------------------------
> Gunnar Hellström
> Omnitor
> gunnar.hellstrom@omnitor.se
>
>
>
>
>
>
> Den 2015-10-05 kl. 12:04, skrev Ali C. Begen:
>
>> 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 mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>>
>
> --
> -----------------------------------------
> Gunnar Hellström
> Omnitor
> gunnar.hellstrom@omnitor.se
> +46 708 204 288
>
>