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

From: Bernard Aboba <[email-masked]>
Date: Mon, 17 Jul 2017 09:54:00 -0700

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?

---

From: Gunnar Hellström <[email-masked]>
Date: Sun, 23 Jul 2017 00:06:17 +0200

> only for hlang-recv lines and can an Answer respond with a * in its
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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/slim

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

---

From: Randall Gellens <[email-masked]>
Date: Tue, 25 Jul 2017 08:42:33 -0700

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
>
> <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 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 
> <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:
>
>     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
>  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?
>
>
>
>
>

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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 25 Jul 2017 12:04:46 -0400

> quality standards and keep the wording as is.

+1

(And I don't find #4 to be a reasonable choice.)

	Thanks,
	Paul

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 25 Jul 2017 10:09:44 -0700

Paul Kyzivat said:

"(And I don't find #4 to be a reasonable choice.)"

[BA] Is there another choice/solution that you would prefer?

On Tue, Jul 25, 2017 at 9:04 AM, Paul Kyzivat <[email-masked]> wrote:

>> 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:
>>
>> 4. Accept that we propose a draft that does not fulfill good IETF quality
>> standards and keep the wording as is.
>>
>
> +1
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 25 Jul 2017 13:42:38 -0400

> [BA] Is there another choice/solution that you would prefer?

Since this is really a session-level feature I would prefer to see it 
controlled by a session-level attribute.

	Thanks,
	Paul

> On Tue, Jul 25, 2017 at 9:04 AM, Paul Kyzivat <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>         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:
> 
>         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.
> 
> 
>     +1
> 
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/slim>
> 
> 
> 
>

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 26 Jul 2017 14:14:33 +0200

I see now that I made a mistake in formulating alternative 3 - see below.

> controlled by a session-level attribute.
<GH> That would mean alternative 2. I also find that most appropriate.
>>         3. Use the asterisk also for a session level purpose already in
<GH> Mistake, it should read:
3. "Use the asterisk also for a media level purpose already in the 
current draft."
     This alternative of course aims at my earlier efforts to specify 
also relative modality preference with the asterisk.
    But it has problems. 1) It is not logically clean to merge two 
meanings of the asterisk, even if it looks possible. 2) In order to not 
create interop problems, this meaning should be specified in the same 
draft, and not be done as a separate addition. The wg has opposed to do so.
The decision would be easier to take if we got some comments on the 
draft about using sdp grouping for modality preference and simultaneous 
modality indication. draft-hellstrom-slim-modality-grouping

>>     (And I don't find #4 to be a reasonable choice.)
<GH>  #2 seems to be the right way.
Gunnar

---

From: Randall Gellens <[email-masked]>
Date: Wed, 26 Jul 2017 11:35:05 -0700

Why don't we just take out of the current draft the asterisk and the 
ability to indicate a caller preference to not fail the call?  Then 
Gunnar's draft(s) are free to use the asterisk.

-------------- Randomly selected tag: ---------------
Law of Probability Dispersal:  Whatever it is that hits the fan will
not be evenly distributed.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 26 Jul 2017 16:46:16 -0400

> Gunnar's draft(s) are free to use the asterisk.

Then what is the expectation regarding whether to accept a call with no 
matching language?

I guess it would make the most sense for the callee to accept the call 
unless he doesn't want a call without matching language. Then if the 
callee does accept the call without the matching language the caller can 
still terminate the call once he realizes that is the situation.

That seems reasonable to me.

	Thanks,
	Paul

---

From: Brian Rosen <[email-masked]>
Date: Wed, 26 Jul 2017 14:14:44 -0700

I think it’s up to the called party, right?  “Reject” a call after you have an offer has to be done by the UAS.  So the asterisk is advice to the UAS on whether to accept the call or reject it.
The callee, after it gets the answer, can always send BYE, of course but that’s not a “reject”. 

The asterisk was just a way to indicated the caller’s preference on the matter.

I really think we’ve blown this up way, way beyond what we intended, which was to send an advisory note from the UAC to the UAS that suggests what the caller would prefer.  It wasn’t supposed to be media specific - it’s just a suggestion as to what to do when faced with no common language.  It’s advisory.  It doesn’t suggest what media or language that will be used.  It’s just a notion of what the caller would like the called party to do in this case.

Brian

> On Jul 26, 2017, at 1:46 PM, Paul Kyzivat <[email-masked]> wrote:
> 
>> Why don't we just take out of the current draft the asterisk and the ability to indicate a caller preference to not fail the call?  Then Gunnar's draft(s) are free to use the asterisk.
> 
> Then what is the expectation regarding whether to accept a call with no matching language?
> 
> I guess it would make the most sense for the callee to accept the call unless he doesn't want a call without matching language. Then if the callee does accept the call without the matching language the caller can still terminate the call once he realizes that is the situation.
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 26 Jul 2017 17:26:39 -0400

> I really think we’ve blown this up way, way beyond what we intended, which was to send an advisory note from the UAC to the UAS that suggests what the caller would prefer.  It wasn’t supposed to be…

Sure, I get that. It is effectively a callerpref. Maybe the right thing 
to do is to define it as such.

If we want to keep it, and if it must be in SDP, then I think it ought 
to be a session-level attribute. The easiest way out is just to drop it.

	Thanks,
	Paul

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 26 Jul 2017 14:35:26 -0700

Paul said:

"Then what is the expectation regarding whether to accept a call with no
matching language?"

I guess it would make the most sense for the callee to accept the call
unless he doesn't want a call without matching language. Then if the callee
does accept the call without the matching language the caller can still
terminate the call once he realizes that is the situation.

That seems reasonable to me."

[BA] The inability to negotiate a matching language is different from other
SDP negotiation failures such as the inability to negotiate a matching
codec, since even without a matching language, it still may be useful to
successfully negotiate media characteristics and bring up the call.
Therefore it is not clear to me how much value the "*" has in the current
draft, regardless of how it is defined.

For example, if the callee has policy that dictates that it will always
accept the call (e.g. a PSAP), the callee might always ignore the "*".
This might be frustrating to the caller, but the caller may still choose
not to terminate the call.

Even if the callee cares deeply about a matching language (e.g. a voice
recognition or chat bot system that is only supports a subset of
languages), the callee might still choose to ignore the "*".

For example, the callee might accept the call in order to provide
information to the caller (e.g. a pre-recorded voice or text message
indicating that the caller's languages are not supported).

On Wed, Jul 26, 2017 at 1:46 PM, Paul Kyzivat <[email-masked]>
wrote:

> unless he doesn't want a call without matching language. Then if the callee
> does accept the call without the matching language the caller can still
> terminate the call once he realizes that is the situation.
>

---

From: Randall Gellens <[email-masked]>
Date: Wed, 26 Jul 2017 15:12:09 -0700

At 2:35 PM -0700 7/26/17, Bernard Aboba wrote:

>  Paul said:
>
>  "Then what is the expectation regarding whether to accept a call 
> with no matching language?"
>
>  I guess it would make the most sense for the callee to accept the 
> call unless he doesn't want a call without matching language. Then 
> if the callee does accept the call without the matching language 
> the caller can still terminate the call once he realizes that is 
> the situation.
>
>  [BA] The inability to negotiate a matching language is different 
> from other SDP negotiation failures such as the inability to 
> negotiate a matching codec, since even without a matching language, 
> it still may be useful to successfully negotiate media 
> characteristics and bring up the call.  Therefore it is not clear 
> to me how much value the "*" has in the current draft, regardless 
> of how it is defined.
>
>  For example, if the callee has policy that dictates that it will 
> always accept the call (e.g. a PSAP), the callee might always 
> ignore the "*".  This might be frustrating to the caller, but the 
> caller may still choose not to terminate the call.
>
>  Even if the callee cares deeply about a matching language (e.g. a 
> voice recognition or chat bot system that is only supports a subset 
> of languages), the callee might still choose to ignore the "*".
>
> information to the caller (e.g. a pre-recorded voice or text 
> message indicating that the caller's languages are not supported).

The draft has said for some time that the asterisk is nothing more 
than advisory, and has explicitly said that the callee is free to 
ignore either the presence or absence of an asterisk:

Therefore, if the asterisk is causing heartburn, we can remove it 
without technical impact.

--Randy

>
>  On Wed, Jul 26, 2017 at 1:46 PM, Paul Kyzivat 
> <<mailto:[email-masked]>[email-masked]> wrote:
>
>  Why don't we just take out of the current draft the asterisk and 
> the ability to indicate a caller preference to not fail the call? 
> Then Gunnar's draft(s) are free to use the asterisk.
>
>
>  I guess it would make the most sense for the callee to accept the 
> call unless he doesn't want a call without matching language. Then 
> if the callee does accept the call without the matching language 
> the caller can still terminate the call once he realizes that is 
> the situation.
>
>  <mailto:[email-masked]>[email-masked]
> 
> <https://www.ietf.org/mailman/listinfo/slim>https://www.ietf.org/mailman/listinfo/slim
>
>
>

-------------- Randomly selected tag: ---------------
It isn't pollution that's harming the environment.  It's the
impurities in our air and water that are doing it.
                 --Dan Quayle (then-U.S. Vice-President)

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 26 Jul 2017 15:20:56 -0700

Randy said:

"Therefore, if the asterisk is causing heartburn, we can remove it without
technical impact."

[BA] Unless there is some compelling reason to keep it, removing the "*"
might be the simplest way to resolve Issue 26.

On Wed, Jul 26, 2017 at 3:12 PM, Randall Gellens <[email-masked]>
wrote:

>>  [BA] The inability to negotiate a matching language is different from
>> other SDP negotiation failures such as the inability to negotiate a
>> matching codec, since even without a matching language, it still may be
>> useful to successfully negotiate media characteristics and bring up the
>> call.  Therefore it is not clear to me how much value the "*" has in the
>> current draft, regardless of how it is defined.
>>
> The draft has said for some time that the asterisk is nothing more than
> advisory, and has explicitly said that the callee is free to ignore either
> the presence or absence of an asterisk:
>
> Therefore, if the asterisk is causing heartburn, we can remove it without
> technical impact.
>
> --Randy
>
>
>>  On Wed, Jul 26, 2017 at 1:46 PM, Paul Kyzivat <<mailto:
>> [email-masked]>[email-masked]> wrote:
>>
>> ability to indicate a caller preference to not fail the call? Then Gunnar's
>> draft(s) are free to use the asterisk.
>>
>>

---

From: Randall Gellens <[email-masked]>
Date: Wed, 26 Jul 2017 16:11:05 -0700

At 3:20 PM -0700 7/26/17, Bernard Aboba wrote:

>  Randy said:
>
>  "Therefore, if the asterisk is causing heartburn, we can remove it 
> without technical impact."
>
>  [BA] Unless there is some compelling reason to keep it, removing 
> the "*" might be the simplest way to resolve Issue 26.

There is no compelling reason to keep it, especially since it's 
purely advisory.

I suggest we delete it, revise the draft, and advance it.  In my 
view, we've spent far too much time on the asterisk, which is a 
supremely trivial aspect of the draft.

--Randy

>
>  On Wed, Jul 26, 2017 at 3:12 PM, Randall Gellens 
> <<mailto:[email-masked]>[email-masked]> wrote:
>
> <<mailto:<mailto:[email-masked]>[email-masked]><mailto:[email-masked]>[email-masked]> 
> wrote:
>
> <mailto:<mailto:[email-masked]>[email-masked]><mailto:[email-masked]>[email-masked]
>
> 
> <<https://www.ietf.org/mailman/listinfo/slim>https://www.ietf.org/mailman/listinfo/slim><https://www.ietf.org/mailman/listinfo/slim>https://www.ietf.org/mailman/listinfo/slim
>
>
>

-------------- Randomly selected tag: ---------------
I base my fashion taste on what doesn't itch.
    --Gilda Radner