Re: [Slim] New wording for the use of the asterisk in draft-ietf-slim-negotiating-human-language

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

Randall,

This is a contiuation of the discussion under topic "Issues #27 and #32 
- simultaneous languages"

Assume that I make a separate draft for indication of preferred 
modality. I would then like to use the coding with the asterisk proposed 
below.

Knowing that that is on its way, how would you describe the use of the 
asterisk in the current draft so that no interop issues appear when the 
preferred modality extension is published?

And how would you describe the use of the asterisk in the current draft 
so that it will be accepted as a media level parameter?

Right now you say that the asterisk may be attached to any hlang 
attribute for any direction.

An implementation following that advice may for an offer attach it to a 
modality that is not at all preferred. An implementation knowing the 
extension may then take very wrong decisions about how to best start the 
session.

I am afraid that in this situation the preferred modality indication 
would need to move to a new attribute or parameter, adding even more 
complexity.   E.g. a media level attribute a=modalitypref: hi    or a 
session level attribute a=modalitypref: written, spoken      (in order 
of preference). I would like to save us that added complexity. How?

Regards

Gunnar



Den 2017-05-31 kl. 21:31, skrev Gunnar Hellström:
> Den 2017-05-31 kl. 15:58, skrev Randall Gellens:
>> This text should go in a separate document containing advice to 
>> implementers.
> It adds an even better motivation than my earlier proposals for having 
> the asterisk as a parameter on media level,
> and it adds a mild recommendation about the preference between media 
> that we need to make the draft useful in reality. Therefore I suggest 
> to accept it into the current draft.  ( if issue #34 is rejected )
>
> Without this change, the confusion about the placement of the asterisk 
> and the question why the asterisk is a media parameter is still valid.
>
> Regards
> Gunnar
>>
>> At 3:24 PM +0200 5/31/17, Gunnar Hellström wrote:
>>
>>>  Regarding the many review comments about the use of the asterisk 
>>> parameter in draft-ietf-slim-negotiating-human-language, ( e.g. by 
>>> Adam Roach on 28/3/2017) I propose the following change that both 
>>> gives a meaning to the position of the asterisk and satisfies issue 
>>> #26 with media preferences.
>>>
>>>  I propose to use this solution if there is a decision to not 
>>> satisfy Issue #34, to use the Accept-Language syntax.:
>>>
>>>  --Change proposal - to draft version -10---
>>>
>>>  --First change--
>>>
>>>  in section 5.2
>>>
>>>  --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, each value MAY have an asterisk appended 
>>> as the final
>>>     parameter.  An asterisk appended to a value in an offer indicates a
>>>     that the caller has higher preference for the corresponding 
>>> modality
>>>   to be used in the specified direction than other modalities for 
>>> the indicated
>>>  direction without an asterisk. If no such preference is indicated 
>>> in any hlang-
>>>  attribute, it should be taken as a preference by the caller to get 
>>> the call denied
>>>  if no languages are in common between the caller and the callee.
>>>  In an answer, the asterisk indicates a modality that is preferred 
>>> by the callee to be used in the session.
>>>
>>>  See Section 5.3 for more information and
>>>     discussion.
>>>
>>>  --end of first change----
>>>
>>>  ---second change----
>>>  In 5.3
>>>  ----old text---
>>>
>>>
>>>  5.3.  No Language in Common
>>>
>>>     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 value of either 'hlang-recv' or 'hlang-send' 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.
>>>
>>>  ---New text ----
>>>
>>>
>>>  5.3. Preferred modality and action if no match
>>>
>>>     A user may have a clear preference to use one specific modality 
>>> in a
>>>     direction, while use of other modalities may be acceptable but 
>>> lower in
>>>     preference. This condition MAY be indicated by appending an 
>>> asterisk
>>>     as the last parameter in the corresponding humlang- value. This
>>>     indication should also be seen as a preference to not have the call
>>>     denied even if no indicated languages are in common.
>>>
>>>     When negotiating language use for a direction, languages and 
>>> modalities
>>>    specified together with the asterisk should be given preference 
>>> to be selected for use.
>>>     No specific preference between modalities in the same direction 
>>> should
>>>     be indicated by appending an asterisk on all or no humlang- 
>>> values for that direction.
>>>
>>>     If there is a preference for denying the call when no languages 
>>> match,
>>>     then it is not possible to indicate any preferred modality at 
>>> the same time.
>>>
>>>     It is OPTIONAL for the callee to honor the preference for 
>>> denying the call at no match.
>>>     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 called party MAY ignore the indication for denying the call, 
>>> 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 in case of no 
>>> matching language
>>>     even if the offer contains an asterisk.
>>>
>>>  -----end of change ------------------
>>>
>>>  ---Change in 5.5----
>>>
>>>  ---Add this text as a separate example e.g. last in 5.5---
>>>     An offer requesting the following media streams: audio for the 
>>> caller
>>>     to send using spoken English (most preferred modality) or American
>>>     Sign Language (less preferred modality),
>>>     audio for the caller to receive spoken English (most preferred 
>>> modality) or
>>>     American Sign Language (less preferred modality),
>>>     supplemental text.  The offer also requests that the
>>>     call proceed even if the callee does not support any of the
>>>     languages. The offer is likely from a hearing person with 
>>> knowledge in sign language:
>>>
>>>        m=text 45020 RTP/AVP 103 104
>>>
>>>        m=audio 49250 RTP/AVP 20
>>>        a=hlang-recv:en *
>>>        a=hlang-send:en *
>>>
>>>       m=video 51372 RTP/AVP 31 32
>>>       a=hlang-recv: ase
>>>       a=hlang-send: ase
>>>
>>>   An answer for the above offer, indicating video in which the 
>>> callee will send and receive American Sign Language, because that 
>>> callee had no capability for spoken English. The text and audio 
>>> streams are opened as supplementary streams.
>>>
>>>        m=text 45020 RTP/AVP 103 104
>>>              m=audio 49250 RTP/AVP 20
>>>
>>>
>>>        m=video 51372 RTP/AVP 31 32
>>>        a=hlang-send: ase
>>>        a=hlang-recv: ase
>>>   ---end of change---
>>>
>>>
>>>
>>>
>>>
>>>  --
>>>  -----------------------------------------
>>>  Gunnar Hellström
>>>  Omnitor
>>>  <mailto:[e-mail]>[e-mail]
>>>  [phone]
>>>
>>>  _______________________________________________
>>>  SLIM mailing list
>>>  [e-mail]
>>>  https://www.ietf.org/mailman/listinfo/slim
>>
>>
>

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