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

From: Randall Gellens <[email-masked]>
Date: Sun, 28 May 2017 14:57:09 -0700

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.

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

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
If forced to travel on an airplane, try and get in the cabin with
the Captain, so you can keep an eye on him and nudge him if he
falls asleep or point out any mountains looming up ahead ...
        --Mike Harding, The Armchair Anarchist's Almanac.

---

From: Gunnar Hellström <[email-masked]>
Date: Mon, 29 May 2017 14:54:53 +0200

> 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

-- 
-----------------------------------------
Gunnar Hellström
Omnitor
[email-masked]
+46 708 204 288

---

From: Gunnar Hellström <[email-masked]>
Date: Mon, 29 May 2017 20:14:59 +0200

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:
> 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.
>
> 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.
>

---

From: Gunnar Hellström <[email-masked]>
Date: Mon, 29 May 2017 22:37:19 +0200

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
>>> languages on the same line.  This will further reduce the size of 
>>> the SDP block.
>>>
>> 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.
>>
>> simultaneous languages in different media in the same direction. 
>> These two extensions are essential for making the draft useful in 
>> real cases.
>> 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)
>>
>> 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.

---

From: Randall Gellens <[email-masked]>
Date: Mon, 29 May 2017 15:23:16 -0700

The use of q-values has been proposed before but 
we have always decided to maintain a simple 
syntax and solution.

At 2:54 PM +0200 5/29/17, Gunnar Hellström wrote:

>>  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.
>>
>  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.
>
>  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 
>  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
>
>>
>  _______________________________________________
>  SLIM mailing list
>  [email-masked]
>  https://www.ietf.org/mailman/listinfo/slim

-------------- Randomly selected tag: ---------------
In my own view, it was not merely uncomfortable, it was intolerable.
It might perhaps have been endurable for a two-hour flight but an
eight-hour flight is a totally different matter.
    --Judge Gareth Edwards QC, regards JMC's 29-inch seat pitch.
    The judge upheld a compensation award made to Brian Horan after
    he suffered deep-vein thrombosis (DVT) on his journey Manchester,
    England, to the Canadian ski resort of Calgary. Chester County
    Court, 17 April 2002.

---

From: Randall Gellens <[email-masked]>
Date: Mon, 29 May 2017 16:04:28 -0700

I uploaded version -10, which includes the syntax change to single 
line, along with a few editorial clarifications.  (Version -09 
accidently omitted an editorial clarification.)

You can see a diff of the changes from 08 to 10 here:
https://www.ietf.org/rfcdiff?url1=draft-ietf-slim-negotiating-human-language-08&url2=draft-ietf-slim-negotiating-human-language-10

If there objections to the change from multi-line to single-line, 
this can be reverted.

--Randy

-------------- Randomly selected tag: ---------------
Knowledge always desires increase; it is like fire, which must
first be kindled by some external agent, but which will afterwards
propagate itself.                       --Dr. Samuel Johnson