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

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

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]