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

[Paul Kyzivat <[e-mail]>]

On 6/1/17 2:10 PM, Brian Rosen wrote:
> Gunnar
> 
> And yet you persist.
> 
> We have agreed NOT to do preferences between modalities.  Any suggestion 
> that we do so is out of scope for this document.  If you want to write a 
> draft that extends the mechanism, please do and I’ll review it, but 
> PLEASE don’t keep suggesting that we handle preferences between media in 
> this document.  We agreed NOT to do it.
> 
> I would prefer the current syntax, and not Accept-Language syntax.

How about enhancing the syntax to support parameters for the values, but 
only as a future extension mechanism? Unknown parameters to be ignored. 
Then at least the hooks will be there to introduce something later if 
desired.

	Thanks,
	Paul

> Brian
> 
>> On Jun 1, 2017, at 2:01 PM, Gunnar Hellström 
>> <[e-mail] <mailto:[e-mail]>> wrote:
>>
>> Den 2017-06-01 kl. 19:17, skrev Randall Gellens:
>>> The group has repeatedly discussed q-values and priority and has 
>>> always decided to not go down that path.
>> I expect our shepherd to lead us to the decision. We had one reviewer 
>> requesting us to use the Accept-Language syntax with the q-values.
>>
>> I can accept either way, either the one-line syntax used in version 
>> -10, or the Accept-Language syntax.
>>
>> If we go with the current one-line syntax, I will propose to add the 
>> preference between modalities by giving the asterisk a preference 
>> interpretation on media level.
>> And I will propose to use the -t language subtag for simultaneous 
>> languages in other modalities.
>> This may lack some flexibility but will likely be sufficient.
>>
>> If we go with the Accept-Language syntax, then I will propose to let 
>> the q-values have scope over the whole SDP in order to assign 
>> preference between modalities,
>> and I will propose to let equal q-values or q-values within a narrow 
>> interval to indicate a preference for using simultaneous languages in 
>> different media. The first item is nice and flexible, the second, for 
>> simultaneity may be less elegant.
>>
>> I hope you will accept either solution. And do it already in the 
>> current draft.
>>
>> So we just need the decision on the Accept-Language syntax proposal 
>> and then move on.
>>
>> Regards
>>
>> Gunnar
>>
>>
>>
>>
>>
>>
>>>
>>> At 4:33 PM +0200 6/1/17, Gunnar Hellström wrote:
>>>
>>>> Den 2017-06-01 kl. 11:54, skrev Natasha Rooney:
>>>>
>>>>> This seems sufficient given our previous conversations. q-values 
>>>>> can be applied within further work (although I don't see why 
>>>>> ordering doesn't do the job, works in web).
>>>>>
>>>> It is not feasible to change syntax by adding q-values in an 
>>>> extension. That will cause interop problems, or complicated needs to 
>>>> negotiate protocol version. So, we need to decide the syntax now and 
>>>> stick closely to it.
>>>>
>>>> Ordering is not sufficient because we have a need to set preferences 
>>>> between different media.
>>>> Ordering only works within a media.
>>>>
>>>> And, a minor drawback: ordering does not allow to specify a number 
>>>> of languages in the same media with the same preference. One always 
>>>> will look as if it is more preferred than another. - but I think we 
>>>> can live with that.
>>>>
>>>> Maybe the main question is: Will our own one-line syntax really be 
>>>> less complex to parse than the Accept-Language syntax that we might 
>>>> be able to find ready library routines for?
>>>> Adam Roach had views on complexity to parse different solutions. 
>>>> Maybe you, Adam can have a view on this?
>>>>
>>>> Regards
>>>>
>>>> Gunnar
>>>>
>>>>>
>>>>> Bernard - any further thoughts?
>>>>>
>>>>>
>>>>> Natasha Rooney | Internet Engineering Director | Internet and Web 
>>>>> Team | Technology | GSMA | 
>>>>> <mailto:[e-mail]>[e-mail] <mailto:[e-mail]> 
>>>>> | [phone] | @thisNatasha | Skype: 
>>>>> <mailto:[e-mail]>[e-mail] <mailto:[e-mail]>
>>>>>
>>>>>> On 30 May 2017, at 00:04, Randall Gellens 
>>>>>> <<mailto:[e-mail]>[e-mail] 
>>>>>> <mailto:[e-mail]>> wrote:
>>>>>>
>>>>>> 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>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
>>>>>>
>>>>>>
>>>>>>
>>>>>> At 2:57 PM -0700 5/28/17, Randall Gellens 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.
>>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> SLIM mailing list
>>>>>>> <mailto:[e-mail]>[e-mail] <mailto:[e-mail]>
>>>>>>>
>>>>>>> <https://www.ietf.org/mailman/listinfo/slim>https://www.ietf.org/mailman/listinfo/slim
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Randall Gellens
>>>>>> Opinions are personal; facts are suspect; I speak for myself only
>>>>>> -------------- 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
>>>>>>
>>>>>> _______________________________________________
>>>>>> SLIM mailing list
>>>>>> <mailto:[e-mail]>[e-mail] <mailto:[e-mail]>
>>>>>>
>>>>>> <https://www.ietf.org/mailman/listinfo/slim>https://www.ietf.org/mailman/listinfo/slim
>>>>>>
>>>>>
>>>>> This email and its attachments are intended for the above named 
>>>>> only and may be confidential. If they have come to you in error you 
>>>>> must take no action based on them, nor must you copy or show them 
>>>>> to anyone; please reply to this email or call [phone] and 
>>>>> highlight the error.
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> SLIM mailing list
>>>>> <mailto:[e-mail]>[e-mail] <mailto:[e-mail]>
>>>>>
>>>>> <https://www.ietf.org/mailman/listinfo/slim>https://www.ietf.org/mailman/listinfo/slim
>>>>>
>>>>
>>>> --
>>>> -----------------------------------------
>>>> Gunnar Hellström
>>>> Omnitor
>>>> <mailto:[e-mail]>[e-mail] 
>>>> <mailto:[e-mail]>
>>>> [phone]
>>>>
>>>> _______________________________________________
>>>> SLIM mailing list
>>>> [e-mail] <mailto:[e-mail]>
>>>> https://www.ietf.org/mailman/listinfo/slim
>>>
>>>
>>
>> --
>> -----------------------------------------
>> Gunnar Hellström
>> Omnitor
>> [e-mail] <mailto:[e-mail]>
>> [phone]
>>
>> _______________________________________________
>> SLIM mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/slim
> 
> 
> 
> _______________________________________________
> SLIM mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/slim
>