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

[Randall Gellens <[e-mail]>]

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:

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


-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- 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.