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

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

Den 2017-07-17 kl. 18:54, skrev Bernard Aboba:
> Issue: 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)
>
>
>     - 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
>
> 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 Section 5.3
> <https://tools.ietf.org/html/draft-ietf-slim-negotiating-human-language-13#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?
I think the intention is quite clearly stated in 5.2 by this statement: "

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

The idea is apparently that the position of the asterisk, and even the 
number of asterisks has no influence on the interpretation. As soon as 
there is an asterisk anywhere among the hlang-attributes in the whole 
SDP, the call should not fail because of lack of common languages.

It is a bit easier to understand the effect of the asterisk if we look 
at the logic the opposite way. "The total lack of asterisks at the end 
of all hlang-attributes in the whole SDP indicates a request by the 
offeror to the answering party to fail the call if no language match is 
found."

An interesting side effect is that if there is a language match in one 
direction, but not in the other, and no asterisk, then the call will be 
connected,  even if there will be opportunities for human language 
communication just one way.
I wonder if that was the intention by the author.

It seems not possible to invent any suitable interpretation on a true 
media level of the asterisk controlling call failure, so the comment 
from the review that it seems to be a session level parameter placed on 
a media level attribute. I think that is not good IETF quality, and 
should be corrected. I see four possible solutions:

1. Drop the idea to control if the call shall be denied.

2. Make a separate session level attribute for this purpose. e.g. 
a=hlang-disposition:keep / fail

3. Use the asterisk also for a session level purpose already in the 
current draft.

4. Accept that we propose a draft that does not fulfill good IETF 
quality standards and keep the wording as is.

Gunnar




>
>
>
> _______________________________________________
> SLIM mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/slim

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