Subject: [Slim] [slim] #7 (negotiating-human-language): The notation for Advisory vs Required is not logical and needs revision

From: "slim issue tracker" <[email-masked]>
Date: Tue, 02 Aug 2016 08:02:53 -0000

#7: The notation for Advisory vs Required is not logical and needs revision

 In section 6.3 of version -04, the Advisory vs required feature is
 described. The description indicates that it is a session level feature
 influencing the acceptance or rejection of the call depending on outcome
 of the language negotiation. The proposed notation in the draft is however
 hooked on to any media level attribute. This is not logical.
 Here is instead a session level attribute proposed.

 Also, the description indicates that the most common result should be to
 connect the call even if the language negotiation fails, but the notation
 in the draft has failing the call as default value. This is proposed to be
 reverted.

 Change 1: Replace the last paragraph in section 6.3, that currently is:
 ---------------------------------------------------------------
   The mechanism for indicating this preference is that, in an offer, if
    the last character of any of the 'humintlang-recv' or 'humintlang-
    send' values is an asterisk, this indicates a request to not fail the
    call (similar to SIP Accept-Language syntax).  Either way, the called
    party MAY ignore this, e.g., for the emergency services use case, a
    PSAP will likely not fail the call.
 -------------------------------------------------------------------
 replace with:
 -------------------------------------------------------------------
   The mechanism for indicating this preference is a session level
 attribute "humintlang-disposition", with "reject" and "connect" as
 possible values and "connect" as default.

 Example:
 humintlang-disposition: reject

 The called party MAY ignore this, e.g., for the emergency services use
 case, a PSAP will likely not fail the call.

 -------------------------------------------------------------------

 Change 2:
 --------------------------------------------------------------------
 In section 6.2, delete this paragraph since the feature is no longer tied
 to the humintlang-send or humintlang-recv attributes.
 -----------------------------------------
   In an offer, each language tag value MAY have an asterisk appended as
    the last character (after the registry value).  The asterisk
    indicates a request by the caller to not fail the call if there is no
    language in common.  See Section 6.3 for more information and
    discussion.
 ---------------------------------------------------------------

     Change 3:
 Include the syntax of the "humintlang-disposition" in the syntax chapter
 and examples.   - will be submitted separately.

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |      Owner:  draft-ietf-slim-
  [email-masked]        |  [email-masked]
     Type:  defect                   |     Status:  new
 Priority:  major                    |  Milestone:
Component:  negotiating-human-       |    Version:
  language                           |   Keywords:  reject
 Severity:  In WG Last Call          |
-------------------------------------+-------------------------------------

Ticket URL: <https://trac.tools.ietf.org/wg/slim/trac/ticket/7>
slim <https://tools.ietf.org/slim/>

---

From: "slim issue tracker" <[email-masked]>
Date: Tue, 09 Aug 2016 06:50:36 -0000

Comment (by [email-masked]):

 Modify the text in change 1 to:

 The mechanism for indicating this preference is a session level attribute
 "humintlang-disposition", with "reject", "improve" and "connect" as
 possible values and "connect" as default.

 Example:
 a=humintlang-disposition: reject

 The called party MAY ignore the "reject" value, e.g., for the emergency
 services use case, a PSAP will likely not fail the call.

  language                           |  Resolution:
 Keywords:  reject                   |

Ticket URL: <https://trac.tools.ietf.org/wg/slim/trac/ticket/7#comment:1>
slim <https://tools.ietf.org/slim/>

---

From: Brian Rosen <[email-masked]>
Date: Tue, 9 Aug 2016 09:01:29 -0400

I am not in favor of this change.  I think the existing text is fine.

Brian

> On Aug 9, 2016, at 2:50 AM, slim issue tracker <[email-masked]> wrote:
> 
> _______________________________________________
> SLIM mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/slim

---

From: "slim issue tracker" <[email-masked]>
Date: Mon, 15 Aug 2016 16:54:26 -0000

Comment (by [email-masked]):

 Chairs: Randall - can you respond to this when you have a chance? It seems
 like there are some interesting points here which should be discussed on-
 list (e.g. the default value perhaps should change).

Ticket URL: <https://trac.tools.ietf.org/wg/slim/trac/ticket/7#comment:2>
slim <https://tools.ietf.org/slim/>

---

From: "Randall Gellens (IETF)" <[email-masked]>
Date: Mon, 15 Aug 2016 19:49:27 +0100

Since we're talking about a flag to indicate the origination's preference to the answerer, which is advisory in all cases, I don't see that it makes any difference which is the default.

--Randall

Sent from my iPad

> On Aug 15, 2016, at 5:54 PM, slim issue tracker <[email-masked]> wrote:
>

---

From: Brian Rosen <[email-masked]>
Date: Mon, 15 Aug 2016 15:14:20 -0400

I agree, and think the asterisk naturally means “all” and thus the suggested default is correct.

As was noted, we should probably just drop the reference to Accept-Language, since it uses an entirely different syntax.

Brian

> On Aug 15, 2016, at 2:49 PM, Randall Gellens (IETF) <[email-masked]> wrote:
>

---

From: Randall Gellens <[email-masked]>
Date: Mon, 15 Aug 2016 12:31:04 -0700

Yes, deleting the mention of Accept-Language is good.

At 3:14 PM -0400 8/15/16, Brian Rosen wrote:

>  I agree, and think the asterisk naturally means "all" and thus the 
> suggested default is correct.
>
>  As was noted, we should probably just drop the reference to 
> Accept-Language, since it uses an entirely different syntax.
>
>  Brian
>
>>  Since we're talking about a flag to indicate the origination's 
>> preference to the answerer, which is advisory in all cases, I 
>> don't see that it makes any difference which is the default.
>>
>>  --Randall
>>
>>  Sent from my iPad
>>

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Deregulation will be the greatest thing to happen to the airlines
since the jet engine.   -- Richard Ferris, CEO United Airlines, 1976

---

From: "slim issue tracker" <[email-masked]>
Date: Mon, 15 Aug 2016 22:24:46 -0000

By having the default value to be to reject the call, that is very seldom
 desired, the usage very often will be that the user (= sdp encoder )  will
 need to remember to insert the notation for "do not reject" in most SDPs.
 That seems awkward and a bit risky.

Ticket URL: <https://trac.tools.ietf.org/wg/slim/trac/ticket/7#comment:3>
slim <https://tools.ietf.org/slim/>

---

From: Brian Rosen <[email-masked]>
Date: Mon, 15 Aug 2016 20:05:45 -0400

You say “very seldom desired”, but I’m not convinced that is the case.  It might be true, but for a whole lot of cases, if you can’t communicate, then you either need to change your request, or try a different service.

Brian
> On Aug 15, 2016, at 6:24 PM, slim issue tracker <[email-masked]> wrote:
>

---

From: Gunnar Hellström <[email-masked]>
Date: Tue, 16 Aug 2016 09:45:57 +0200

> You say “very seldom desired”, but I’m not convinced that is the case.  It might be true, but for a whole lot of cases, if you can’t communicate, then you either need to change your request, or try…
Yes,
I agree that it is hard to say how the "reject if no match" parameter 
will be used.
In recent discussions it was said that there was risk for the users 
having common ways to communicate that they had not bothered configuring 
in their devices and therefore getting calls rejected that could have 
been performed.
E.g. neighbour languages.

But the other way around is also annoying and frustrating;  to get a 
call accepted, and then after some efforts to find a way to communicate, 
you need to give up without even being able to say "sorry, we cannot 
understand each other, so bye".

So, yes, both values of this parameter has its values and risks and it 
is hard to know how it will be used.
It is a session level parameter and with good definition and syntax, the 
default could be either way. I have a slight preference for "don't 
reject" as the default because it has a lower risk for wanted calls to 
be rejected.

/Gunnar

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

---

From: Gunnar Hellström <[email-masked]>
Date: Tue, 16 Aug 2016 23:19:04 +0200

> I am not in favor of this change.  I think the existing text is fine.
The described function for advisory vs required in the draft is a 
session level function. That makes the coding very unusual when it is 
said that it can be attached to any media level language indication. I 
do not think that that kind of logic behind the coding is acceptable in 
an IETF document.

If you are really eager to keep the current syntax, we would need to add 
some media level semantics to the "don't reject" parameter. That is to 
give a specific meaning of which media, language and direction the 
parameter is tacked on to.

A possible coding would be to let the tacked on character indicate that 
the language it is tacked on to is the most favoured language. There are 
two possible characters indicating two proposed dispositions in case of 
no match in the whole sdp.

"*" marks a most favoured language and that the call should be connected 
even if no language match was found in the whole sdp.
"+" marks a most favoured language and that the call should be rejected 
if no language match was found in the whole sdp.
It is most common to only have one most favoured language per direction, 
but it is allowed to use the indication for two languages in different 
modalities for the same direction if the user is favouring using two 
languages simultaneously in the same direction.

I am not convinced that the coding with a character tacked on directly 
to the language tag is an acceptable coding, but want to test the 
reaction on this compromise proposal.

---------------------------------------------------------------------------------------------------

The existing text is clearly not fine. It has a contradiction.
In 6 it says:  "

The attribute value should be a language tag perRFC 5646 <https://tools.ietf.org/html/rfc5646>  [RFC5646 <https://tools.ietf.org/html/rfc5646>]"
In 6.2 it says:
"
The attribute value should be a language tag perRFC 5646 <https://tools.ietf.org/html/rfc5646>  [RFC5646 <https://tools.ietf.org/html/rfc5646>]"

But also
  "In an offer, each language tag value MAY have an asterisk appended as
    the last character (after the registry value)."

And in 6.3:
"The mechanism for indicating this preference is that, in an offer, if
    the last character of any of the 'humintlang-recv' or 'humintlang-
    send' values is an asterisk, this indicates a request to not fail the
    call."

This indicates that the attribute value is both just a language tag and a language tag with a possibly attached *. That is not logical.

The syntax description needs to be clearer. With the current coding it needs to indicate that the attribute value is composed of a language tag combined with an optional call disposition indication character.

--------------------

/Gunnar

----------------------------------------

---

From: Brian Rosen <[email-masked]>
Date: Tue, 16 Aug 2016 17:33:57 -0400

I really don’t think there is any confusion whatsoever in the current language.

I could see adding “with an optional asterisk appended” after "per RFC 5446”, but I don’t think it’s necessary.

Brian

Brian
> On Aug 16, 2016, at 5:19 PM, Gunnar Hellström <[email-masked]> wrote:
> 
> The described function for advisory vs required in the draft is a session level function. That makes the coding very unusual when it is said that it can be attached to any media level language indication. I do not think that that kind of logic behind the coding is acceptable in an IETF document.
> 
> If you are really eager to keep the current syntax, we would need to add some media level semantics to the "don't reject" parameter. That is to give a specific meaning of which media, language and direction the parameter is tacked on to.
> 
> A possible coding would be to let the tacked on character indicate that the language it is tacked on to is the most favoured language.  There are two possible characters indicating two proposed dispositions in case of no match in the whole sdp. 
> 
> "*" marks a most favoured language and that the call should be connected even if no language match was found in the whole sdp.
> "+" marks a most favoured language and that the call should be rejected if no language match was found in the whole sdp.
> It is most common to only have one most favoured language per direction, but it is allowed to use the indication for two languages in different modalities for the same direction if the user is favouring using two languages simultaneously in the same direction.
> 
> I am not convinced that the coding with a character tacked on directly to the language tag is an acceptable coding, but want to test the reaction on this compromise proposal.
> 
> The attribute value should be a language tag per RFC 5646 <https://tools.ietf.org/html/rfc5646> [RFC5646 <https://tools.ietf.org/html/rfc5646>]"
> In 6.2 it says:
> "
> The attribute value should be a language tag per RFC 5646 <https://tools.ietf.org/html/rfc5646> [RFC5646 <https://tools.ietf.org/html/rfc5646>]"
> 
> But also 
>>> On Aug 9, 2016, at 2:50 AM, slim issue tracker <[email-masked]> <mailto:[email-masked]> wrote:
>>> 
>>> Comment (by [email-masked] <mailto:[email-masked]>):
>>> 
>>>  [email-masked] <mailto:[email-masked]>        |  [email-masked] <mailto:[email-masked]>
>>> Ticket URL: <https://trac.tools.ietf.org/wg/slim/trac/ticket/7#comment:1> <https://trac.tools.ietf.org/wg/slim/trac/ticket/7#comment:1>
>>> slim <https://tools.ietf.org/slim/> <https://tools.ietf.org/slim/>
>>> 
>>> [email-masked] <mailto:[email-masked]>
>>> https://www.ietf.org/mailman/listinfo/slim <https://www.ietf.org/mailman/listinfo/slim>
> 
> -- 
> [email-masked] <mailto:[email-masked]>
> +46 708 204 288