Re: [Slim] Ticket #26 Make use of the asterisk modifier on media level with session scope also for media level purposes

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

Den 2017-06-10 kl. 00:04, skrev Randall Gellens:
> At 11:29 PM +0200 6/8/17, Gunnar Hellström wrote:
>
>>  Den 2017-06-08 kl. 19:40, skrev Natasha Rooney:
>>
>>>  Hi Randall,
>>>
>>>  The additional text describing the * has not been added and myself 
>>> and Bernard are unsure of how the current text is sufficient. Can 
>>> you add some text or let us know how this is already covered? Thanks!
>>>
>>>  See comment 8 and 9 to see the request in the ticket.
>>>
>>>
>>> <https://trac.ietf.org/trac/slim/ticket/26>https://trac.ietf.org/trac/slim/ticket/26 
>>>
>>>
>>>  Thanks!
>>>
>>  I realize that a way to satisfy this request, and also prepare for a 
>> smooth extension widening the use of the asterisk is to now make the 
>> change shown below in section 5.2
>>
>>  By this, we get a firm description on where to append the asterisk. 
>> And we get no interworking problems when extending the use of the 
>> asterisk.
>>
>>  I agree that it may look odd to talk about positioning the asterisk 
>> on the attribute for the most preferred modality, when we do not 
>> describe how we use this position. But it is a fixed rule anyway that 
>> makes the asterisk a media level parameter and it would satisfy 
>> comments 8 and 9 of Ticket #26.
>>
>>  Another solution is to create a separate session level attribute for 
>> the indication of non-denial at no match.
>>  a=hlang-nomatch:deny (or keep)
>>
>>  Change proposal in section 5.3
>>
>>  ------old text----
>>     In an offer, each value MAY have an asterisk appended as the final
>>     value.  An asterisk appended to either value in an offer indicates a
>>     request by the caller to the callee to not fail the call if there is
>>     no language in common.  See Section 5.3 for more information and
>>     discussion.
>>
>>   -----new text ----
>>     In an offer or answer, the attribute value MAY have an asterisk 
>> appended as the final
>>     token. An asterisk appended to a value in an offer indicates a 
>> request by the caller to the
>>     callee to not fail the call if there is no language in common. 
>> The asterisk should be appended
>>     for at least one direction. If 'hlang-' attributes are provided 
>> for more than one media
>>     in a direction selected to have the asterisk appended, then the 
>> asterisk should be appended
>>     to the attribute for the most preferred modality in that 
>> direction. If no modality can be
>>     identified as the most preferred for that direction, then an 
>> asterisk should be appended
>>     on each 'hlang' attribute for that direction. See Section 5.3 for 
>> more information and discussion.
>>
>>     Note that separate work [draft-hellstrom-slim-modalitypref] 
>> extends the use of the
>>     asterisk.
>>
>>
>>  ---end of change-----------------
>
> This proposed text goes beyond what we've agreed to say regarding 
> preferences.
Yes, I realize that. But it does not specify any specific action 
regarding preference by the receiver of the indication.
It is just a clean way to specify the placement of the asterisk, so that 
future readers do not get as confused as our reviewers got.

And, it prepares for smooth introduction of the low comlexity addition 
of modality preference indication by the asterisk. Without this, we 
cannot really say that we are totally backwards compatible if we start 
from the current draft and add the modality preferece as an extension. 
An offering party attaching the asterisk on any modality may cause an 
answering party knowing about the extension to take the placement of the 
asterisk as a base for decision on which modality to start the call in. 
And that can be a modality that is not really the best for the offering 
party.

That makes it doubtful if we can use this simple mechanism for modality 
preference indication and instead maybe need to introduce the more 
complex one with extension parameters per language as proposed by Paul.

Or can we aim at joint IANA registration and see the reference to the 
modality-preference specification as a normative requirement for the 
implementor to consider?

/Gunnar
>
>

-- 
-----------------------------------------
Gunnar Hellström
Omnitor
[e-mail]
[phone]