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

From: Natasha Rooney <[email-masked]>
Date: Thu, 8 Jun 2017 17:40:13 +0000

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

Thanks!

Natasha Rooney | Internet Engineering Director | Internet and Web Team | Technology | GSMA | [email-masked]<mailto:[email-masked]> | +44 (0) 7730 219 765 | @thisNatasha | Skype: [email-masked]<mailto:[email-masked]>

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 +44 207 356 0600 and highlight the error.

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 8 Jun 2017 23:29:29 +0200

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

Gunnar

>
> Natasha Rooney | Internet Engineering Director | Internet and Web Team 
> | Technology | GSMA | [email-masked] <mailto:[email-masked]> | +44 
> (0) 7730 219 765 | @thisNatasha | Skype: [email-masked] 
> <mailto:[email-masked]>
>
> 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 +44 207 356 0600 and 
> highlight the error.
>
>
>
> _______________________________________________
> SLIM mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/slim

-- 
-----------------------------------------
Gunnar Hellström
Omnitor
[email-masked]
+46 708 204 288

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 8 Jun 2017 23:31:37 +0200

This mail replaces the one I just sent. There was an error in the 
section number for the change proposal. Corrected now.

Change proposal in section 5.2

---end of change-----------------

Gunnar

---

From: Randall Gellens <[email-masked]>
Date: Fri, 9 Jun 2017 15:01:55 -0700

At 5:40 PM +0000 6/8/17, Natasha Rooney wrote:

>  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!
>
> <https://trac.ietf.org/trac/slim/ticket/26>https://trac.ietf.org/trac/slim/ticket/26

The text describing the use of asterisk was modified in the more 
recent updates of the draft.  I am not aware of any remaining 
ambiguity.

Specifically, Section 5.2 contains:

    In an offer, each list of language tags MAY have an asterisk appended
    at the end.  An asterisk appended to any value in any media 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.

While Section 5.3 contains:

    A consideration with the ability to negotiate language is if the call
    proceeds or fails if the callee does not support any of the languages
    requested by the caller.  This document does not mandate either
    behavior, although it does provide a way for the caller to indicate a
    preference for the call succeeding when there is no language in
    common.  It is OPTIONAL for the callee to honor this preference.  For
    example, a PSAP is likely to attempt the call even without an
    indicated preference when there is no language in common, while a
    call center might choose to fail the call.

    The mechanism for indicating this preference is that, in an offer, if
    the last token of any 'hlang-recv' or 'hlang-send' value for any
    media is an asterisk, this indicates a request to not fail the call.
    The called party MAY ignore the indication, e.g., for the emergency
    services use case, regardless of the absence of an asterisk, a PSAP
    will likely not fail the call; some call centers might reject a call
    even if the offer contains an asterisk.

The examples in Section 5.5 show an asterisk used in some cases.

Additionally, Section 6.1 contains:

    Attribute Syntax:

       hlang-value =  Language-Tag *( SP Language-tag ) [ SP asterisk ]

                            ; Language-Tag as defined in BCP 47

       asterisk    =  "*"   ; an asterisk (0x2A) character

       SP          =  1*" " ; one or more space (0x20) characters

Which makes it clear that an asterisk may be appended to the list of 
language tags, and that it can only appear at the end.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Virtue has never been as respectable as money.      --Mark Twain

---

From: Randall Gellens <[email-masked]>
Date: Fri, 9 Jun 2017 15:04:02 -0700

At 11:29 PM +0200 6/8/17, Gunnar Hellström wrote:

>>  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!
>>
>  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.
>     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.
>
>

This proposed text goes beyond what we've agreed to say regarding preferences.

-------------- Randomly selected tag: ---------------
A fail-safe circuit will destroy others.  A transistor protected by a
fast-acting fuse will protect the fuse by blowing first.  After the
last of 16 mounting screws has been removed from an access cover, it
will be discovered that the wrong access cover has been removed.

---

From: Gunnar Hellström <[email-masked]>
Date: Sat, 10 Jun 2017 11:08:37 +0200

Den 2017-06-10 kl. 00:04, skrev Randall Gellens:
>>> you add some text or let us know how this is already covered? Thanks!
>>>
>>  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 
>>  Another solution is to create a separate session level attribute for 
>> the indication of non-denial at no match.
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

---

From: Gunnar Hellström <[email-masked]>
Date: Sat, 10 Jun 2017 19:58:06 +0200

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:
>>>  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 
>>> 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 
>>>  Another solution is to create a separate session level attribute 
>>> for the indication of non-denial at no match.
> 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.
>
> 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.
>