Re: [Slim] Human-language Issue 26: Asterisk modifier scope

[Randall Gellens <[e-mail]>]

I don't think there is any particular love for the asterisk.  It's 
worth keeping in mind that it is a very mild mechanism, able at most 
to express a desire by the caller to not fail a call, but either the 
presence or absence of an asterisk may be ignored by the caller.

At 9:54 AM -0700 7/17/17, Bernard Aboba wrote:

>  Issue: 
> <https://trac.ietf.org/trac/slim/ticket/26>https://trac.ietf.org/trac/slim/ticket/26
>
>  The remaining open aspect of Issue 26 relates to the scope of  the "*".
>
>  Paul Kyzivat summarized the problem in his post on February 13, 
> 2017 (see: 
> <https://www.ietf.org/mail-archive/web/slim/current/msg00737.html>https://www.ietf.org/mail-archive/web/slim/current/msg00737.html)
>
>  The text needs to be improved simply to properly explain and define 
> the syntax related to the "*" as you intend to use it.
>  the use of the "*" to indicate what it does is confusing. It is 
> using a media level attribute "parameter" to signify a session 
> level property. This has been brought up before, but simply 
> rejected without (IMO) adequate justification. There seems to be 
> some love for this particular syntax. ISTM that in part Gunnar is 
> trying to adapt this syntax so that it both makes sense as a 
> media-level attribute and simultaneously can satisfy the session 
> level need that has been identified.
>  These concerns do not appear to have been addressed in 
> <https://tools.ietf.org/html/draft-ietf-slim-negotiating-human-language-13>https://tools.ietf.org/html/draft-ietf-slim-negotiating-human-language-13
>
>  Section 5.2 states:
>
>     In an offer, a 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 
> <https://tools.ietf.org/html/draft-ietf-slim-negotiating-human-language-13#section-5.3>Section 
> 5.3 for more
>     information and discussion.
>
>  Section 5.3 states:
>     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.
>
>  Some questions that come to mind:
>
>  1. Does the inclusion of an * represent a request for the callee to 
> not fail the call based on an inability to negotiate a common 
> language only for the particular hlang-recv or hlang-send line that 
> contains the "*"?
>
>  That is, if an "*" is included on some hlang-recv/send lines but 
> not other ones, would it tell the callee that it can fail the call 
> if a common-language can't be negotiated for the lines without an 
> "*"?
>
>  -OR-
>
>
>  2. Does the inclusion of an "*" on any hlang-recv/send line imply 
> the inclusion of an "*" on other hlang-recv/send lines, either 
> within a given m-line or on other m-lines?
>
>
>  -OR-
>
>
>
>  3. To provide clarity, should the "*" merely be considered an 
> indication that the offerer will accept "any language"?  If so, 
> should it be valid only for hlang-recv lines and can an Answer 
> respond with a * in its hlang-recv line?
>
>
>
>
>
>  _______________________________________________
>  SLIM mailing list
>  [e-mail]
>  https://www.ietf.org/mailman/listinfo/slim


-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Creditors have better memories than debtors.
                                    --Benjamin Franklin