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

[Gunnar Hellström <[e-mail]>]

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
[e-mail]
[phone]