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]>]

I like Brian's wording for the note about reuse of the asterisk in 5.2, 
and think that that can be sufficient for allowing reuse of the asterisk.

"Note that separate work  [I-D.hellstrom-slim-modalitypref] extends the 
use of the asterisk to convey additional information about language 
preferences among multiple media sessions."

If this is acceptable, and also the use of the "t" extension to indicate 
simultaneous modalities, then I do not see any urgent need to complicate 
syntax with extension possibilities.  But these two conditions need to 
be checked.

Gunnar


Den 2017-06-10 kl. 11:08, skrev Gunnar Hellström:
> 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]