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 12:55 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 3A00512778D for <slim@ietfa.amsl.com>; Mon, 29 May 2017 05:55:04 -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 zZ6lBnCUSTge for <slim@ietfa.amsl.com>; Mon, 29 May 2017 05:55:02 -0700 (PDT)
Received: from bin-vsp-out-03.atm.binero.net (vsp-unauthed02.binero.net [195.74.38.227]) (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 A236612956D for <slim@ietf.org>; Mon, 29 May 2017 05:55:01 -0700 (PDT)
X-Halon-ID: 03c63845-446e-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 14:54:55 +0200 (CEST)
To: slim@ietf.org
References: <p06240602d550f5367daa@[99.111.97.136]>
From: Gunnar Hellström <gunnar.hellstrom@omnitor.se>
Message-ID: <d8de2857-c2a9-5324-6df4-408974a2071b@omnitor.se>
Date: Mon, 29 May 2017 14:54:53 +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: <p06240602d550f5367daa@[99.111.97.136]>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/slim/XXPPGX3jOyslb8A-gQnV8S1M-lY>
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 12:55:04 -0000

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