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: Gunnar Hellström <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 > >
- [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