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

Gunnar Hellström <gunnar.hellstrom@omnitor.se> Tue, 19 July 2016 22:11 UTC

Return-Path: <gunnar.hellstrom@omnitor.se>
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 4D92A12D95C for <mmusic@ietfa.amsl.com>; Tue, 19 Jul 2016 15:11:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level:
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 X5NdPSyhVjf2 for <mmusic@ietfa.amsl.com>; Tue, 19 Jul 2016 15:11:40 -0700 (PDT)
Received: from bin-vsp-out-05.atm.binero.net (bin-mail-out-05.binero.net [195.74.38.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E497012D97F for <mmusic@ietf.org>; Tue, 19 Jul 2016 15:11:39 -0700 (PDT)
X-Halon-ID: c46d9efd-4dfd-11e6-81a1-005056913f0f
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [83.209.156.58]) by bin-vsp-out-05.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Wed, 20 Jul 2016 00:11:39 +0200 (CEST)
To: "Ali C. Begen" <acbegen@gmail.com>
References: <5611A155.1050303@omnitor.se> <CAG371notG+a3JQcFTU3KQ2C9-t=kq5J=fvQZN7rNGy8oWW3GMQ@mail.gmail.com>
From: Gunnar Hellström <gunnar.hellstrom@omnitor.se>
Message-ID: <ac9cb83f-1dae-870b-727e-4c37fa443092@omnitor.se>
Date: Wed, 20 Jul 2016 00:11:32 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.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: <https://mailarchive.ietf.org/arch/msg/mmusic/hYzFvxjCTvC7sGTYXJ5wcLUXPac>
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: Tue, 19 Jul 2016 22:11:44 -0000

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