Re: [Slim] Collapse attribute syntax to one line in draft-ietf-slim-negotiating-human-language

Gunnar Hellström <gunnar.hellstrom@omnitor.se> Mon, 29 May 2017 20:37 UTC

Return-Path: <gunnar.hellstrom@omnitor.se>
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 053D4129437 for <slim@ietfa.amsl.com>; Mon, 29 May 2017 13:37:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 kcO2tRnFIujG for <slim@ietfa.amsl.com>; Mon, 29 May 2017 13:37:28 -0700 (PDT)
Received: from bin-vsp-out-03.atm.binero.net (bin-mail-out-06.binero.net [195.74.38.229]) (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 A3DA61205D3 for <slim@ietf.org>; Mon, 29 May 2017 13:37:27 -0700 (PDT)
X-Halon-ID: 9d1be29b-44ae-11e7-bca7-0050569116f7
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [77.53.231.21]) by bin-vsp-out-03.atm.binero.net (Halon Mail Gateway) with ESMTPSA for <slim@ietf.org>; Mon, 29 May 2017 22:37:20 +0200 (CEST)
To: slim@ietf.org
References: <p06240602d550f5367daa@[99.111.97.136]> <d8de2857-c2a9-5324-6df4-408974a2071b@omnitor.se> <8f8fb511-420b-9cdd-5de0-a0d7be27766a@omnitor.se>
From: Gunnar Hellström <gunnar.hellstrom@omnitor.se>
Message-ID: <f9294ebb-572e-c7be-d618-ca9aced5d15f@omnitor.se>
Date: Mon, 29 May 2017 22:37:19 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <8f8fb511-420b-9cdd-5de0-a0d7be27766a@omnitor.se>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/slim/ZZT9JVYiDPpEYAGfTGsuE8mwqmc>
Subject: Re: [Slim] Collapse attribute syntax to one line in draft-ietf-slim-negotiating-human-language
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Selection of Language for Internet Media <slim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/slim>, <mailto:slim-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/slim/>
List-Post: <mailto:slim@ietf.org>
List-Help: <mailto:slim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/slim>, <mailto:slim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 May 2017 20:37:31 -0000

By accepting Issue #34, the extensions needed for the two missing 
functions could be adding the following to chapter 5:

----------------an introduction of the q-values in section 5.2 by 
something like this------------------------------

  The values  constitute a list of languages in order of preference 
according to the q-value optionally provided with each language.  If the 
q-value is omitted, the value 1 is assumed.

-----------------Explanation of the q-value use in separate 
sections-------------------------

5.x Preference indication and evaluation
    Each language may be assigned a preference by a q-value parameter 
with value between 0 and 1.
    The value is valid for preference assignment between all languages 
indicated for the same direction
    among all media. The higher value, the higher preference.
    The language to use is decided by matching the languages and 
preferences in an incoming indication
    with the preferences and capabilities of the receiving party. The 
best matching language(s) per direction are
    indicated in the response and used initially in the session.

    This kind of indication is intended for indication of relative 
preference between language in different alternative media, such as a 
high preference for written language but an acceptance to use spoken 
language.

5.y Indication of preference for simultaneous use of more than one 
medium in a direction
    There are situations when it is required or strongly desired to use 
two languages in different media simultaneously in the same direction. 
This is indicated by assigning q-values less than one, and with a value 
less or equal to 0.1 apart for such languages. Indication of the same 
q-value means that the languages are required together. Indication of 
different q-values not more than 0.1 apart means that the lower valued 
language is desired simultaneously but may be omitted.
    The possibilities by the answering part to respond to the expressed 
preferences should be indicated in the answer.

     This kind of indication is intended for indication of need or 
capability to provide simultaneous subtitling in text of what is said in 
audio or video, or need or capability to provide a view of the speaker.

------------------------------------------------

And the following to the examples,  incurrent section 5.5:

----------------------------------------------------------------------------------------------

An offer for written English both ways as highest priority, and American 
Sign language both ways as second preference alternative.

       m=video 51372 RTP/AVP 34
       a=hlang-send: ase; q=0.4, *
       a=hlang-recv: ase; q=0.4, *

       m=text 45020 RTP/AVP 103 104
       a=hlang-recv: en; q=0.6, *
       a=hlang-send: en; q=0.6, *

An answer, accepting only the written English:

       m=video 51372 RTP/AVP 34

       m=text 45020 RTP/AVP 103 104
       a=hlang-recv: en; q=0.6, *
       a=hlang-send: en; q=0.6, *


An offer for reception of written English as highest priority, and a 
preference for also receiving speech. And an offer to send speech at 
highest priority but an acceptance to send text as an alternative.

       m=audio 51372 RTP/AVP 0
       a=hlang-send: en; q=0.4, *
       a=hlang-recv: en; q=0.4, *

       m=text 45020 RTP/AVP 103 104
       a=hlang-recv: en; q=0.41, *
       a=hlang-send: en; q=0.1, *

An answer, accepting to send both English audio and text, and receive 
only spoken English:

       m=audio 51372 RTP/AVP 0
       a=hlang-send: en; q=0.4, *
       a=hlang-recv; en; q=0.4

       m=text 45020 RTP/AVP 103 104
       a=hlang-send: en; q=0.4, *
-----------------------------------------------------------------------------------------------

There are other places in need of changes as well, this was the main items.

This would of course be easiest to introduce now. If done as a later 
extension, we will have some mild interop issues, as well as a need to 
prepare wording in the current draft so that it does not contradict the 
extension.


Regards


Gunnar





Den 2017-05-29 kl. 20:14, skrev Gunnar Hellström:
> It should be noted that the syntax according to the Accept-Language 
> does not need to include the q-values until the user want to be 
> specific about the relative preferences.
>
> So, as long as the preferences are not of specific interest, the 
> example would be:
>
>  m=audio 49250 RTP/AVP 20
>  a=hlang-send: es, eu, en, *
>  a=hlang-recv:es, eu, en,  *
>
> Which is very similar to the syntax just proposed by Randall.
>
> /Gunnar
>
>
>
> Den 2017-05-29 kl. 14:54, skrev Gunnar Hellström:
>> Den 2017-05-28 kl. 23:57, skrev Randall Gellens:
>>> In response to Adam Roach's comments as well as other comments, I 
>>> intend to update the draft to collapse the attribute syntax to one 
>>> line; each attribute can occur at most once per media, with all 
>>> languages on the same line.  This will further reduce the size of 
>>> the SDP block.
>>>
>>> If you object to this, please reply.
>> I am glad to see a one-line syntax, but I would as well as Dale 
>> Worley expressed in issue #34, prefer to use the full Accept-Language 
>> syntax including the q-values.
>>
>> Thus a syntax according to this example:
>>
>>  m=audio 49250 RTP/AVP 20
>>  a=hlang-send: es; q=0.5, eu; q=0.3, en;q=0.1, *
>>  a=hlang-recv:es; q=0.5, eu; q=0.3, en;q=0.1,  *
>>
>> This format provides the following benefits
>>
>> 1. Satisfies both Dales and Adam's and other's review proposals
>>
>> 2. Is a good base for the extensions I am asked to propose, to enable 
>> preference between languages in different media, and preference for 
>> simultaneous languages in different media in the same direction. 
>> These two extensions are essential for making the draft useful in 
>> real cases.
>> We can introduce cross-media validity of the q-values, and a rule for 
>> how preference for simultaneous media should be expressed. With other 
>> syntax proposals, such extensions will be much less clean.
>>
>> 3. Solves a problem for persons who want to express equal preference 
>> for a set of languages, e.g. a proffessional call center. Other 
>> syntaxes require a preference grading even when the user does not 
>> want to express any preference.
>>
>> 4. Makes it possible to satisfy Bernard's request for a way to 
>> specify subtitling, issue #34. (also included in 2 above)
>>
>> 5. May possibly open for a motivation to keep the asterisk as a media 
>> and directional parameter.
>> But I have problems to define how we can motivate the placement of 
>> the asterisk.
>> Can it be:
>> "An asterisk included in an attribute value means that the call 
>> should not be denied because of lack of language matching in that 
>> media and direction. An asterisk included in each attribute value in 
>> the sdp means that the call should not be denied because of no 
>> language matching at all.
>> The lack of an asterisk in an attribute value means a desire to get 
>> the call denied if no language match is found for the corresponding 
>> media and direction."
>> I do not think that this differentiation betwen reasons to deny the 
>> call is useful, but the description motivates the placement of the 
>> asterisk on media and direction level, and gives us a possiblity to 
>> keep the asterisk parameter.
>>
>> I have not seen us reject issue #34, so I see the above as the 
>> appropriate solution on issues #34 and #39.
>>
>> Regards
>>
>> Gunnar
>>
>>
>>>
>>> Here is the section of Adam's review:
>>>
>>> At 8:31 PM +0000 3/28/17, Sabrina Tanamal via RT wrote:
>>>>  I'll note that much of this can be fixed if the syntax is 
>>>> collapsed so
>>>>  that each media section can have at most one hlang-send and one
>>>>  hlang-receive, each of which contain a list of one or more languages
>>>>  that can be sent or received. This is also much more consistent 
>>>> with the
>>>>  way SDP attributes are used in general. The presence of a "*" 
>>>> token on
>>>>  that line would indicate the "call should happen even without 
>>>> matching
>>>>  languages" characteristic; since there is only one place to add this
>>>>  indicator, the ambiguity of some lines indicating it and others not
>>>>  disappears. The preceding example would collapse to:
>>>>
>>>>  m=audio 49250 RTP/AVP 20
>>>>  a=hlang-send:es eu en *
>>>>  a=hlang-recv:es eu en *
>>>>
>>>>  ...and the example text would be revised to remove the implication 
>>>> that
>>>>  *sending* "es" necessarily implies *receiving* "es".
>>>>
>>>>  I'll further note that the majority of SDP libraries I've worked with
>>>>  would make accessing the all-on-one-line format easier than
>>>>  one-line-per-language as well.
>>>
>>> Here is the proposed ABNF:
>>>
>>>    Attribute Syntax:
>>>
>>>       hlang-value =  Language-Tag *( SP Language-tag ) [ SP asterisk ]
>>>
>>>                            ; Language-Tag as defined in BCP 47
>>>
>>>       asterisk    =  "*"   ; an asterisk (ASCII %2A) character
>>>
>>>       sp          =  1*" " ; one or more ASCII space (%20) characters
>>>
>>
>

-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288