Re: [Slim] I-D Action: draft-ietf-slim-negotiating-human-language-10.txt

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

Randall,

Your response on change proposal 2 caused a more thorough review of weak 
points in the reasoning in section 5.2.

So, change 2 expanded to a number of sub-proposals that, when accepted, 
should result in less risk for mis-interpretations.

See also the other comments.

Thanks,

Gunnar


Den 2017-05-31 kl. 01:56, skrev Randall Gellens:
> At 10:51 PM +0200 5/30/17, Gunnar Hellström wrote:
>
>>  Randall,
>>
>>  good to see progress.
>>
>>  I have a few edit proposals:
>>
>>  ---Change 1---
>>
>>  Last two lines of 1. Introduction
>>
>>  When the draft is ready, it is no draft anymore. Plus divide the 
>> aspects in two sentences.
>>
>>  ----old text---
>>
>>     To reduce the complexity of the solution, this draft focuses on
>>     negotiating language per media; routing is out of scope.
>>
>>  ---New text---
>>
>>     To keep the complexity of the solution low, this document focuses on
>>     negotiating language per media. Routing aspects are out of scope.
>>
>>  -- end of change 1. ----
>
> The use of "draft" was an error, I'll change it to "document."  I 
> prefer the semicolon to maintain the two parts since it has closer 
> linkage between the two than would a period.
<GH>Accepted.
>
>>
>>  ---Change 2 --
>>
>>  Last lines of 5.2
>>
>>  We must be clear about that the result normally is alternative 
>> languages to use, normally not simultaneously. Without this 
>> clarification, we are not better than the old SDP lang attribute.
>>
>>  ---Old text ---
>>     Note that media and language negotiation might result in more media
>>     streams being accepted than are needed by the users (e.g., if more
>>     preferred and less preferred combinations of media and language are
>>     all accepted).  This is not a problem.
>>
>>  ---New text ----
>>     Without any further indications of preferences or requirements 
>> for simultaneity, the language indications should be seen as 
>> alternatives to select from. Media and language negotiation might 
>> result in more media streams and languages being accepted than are 
>> needed by the users
>>   (e.g., if more preferred and less preferred combinations of media 
>> and language are
>>     all accepted).
>>
>>  ---End of change 2 ---
>
> I don't think it's true that we're no better off than the old SDP lang 
> attribute, for multiple reasons, not least of which is that 'lang' is 
> not used for negotiating language in interactive media. Further, I 
> think the result of extra streams is that there are extra streams that 
> probably won't be used.
<GH> I just mean that it must be absolutely clear that the language 
indications for the same direction are alternatives to select from, and 
not an indication that they will be used simultaneously. (not until we 
have the extension sorted out that will indicate simultaneous use in 
specific cases).

The problem we had with 'Lang' was that the intention was not absolutely 
clear if it was about alternatives or simultaneous usage. You read it 
one way and I read it another way.

In 5.2 we still have wording that can be read as if offering or 
answering with two languages in the same direction will imply that the 
user is prepared to use both simultaneously. We must be sure that the 
normal case means that the languages are alternatives to select from.

Multiple reviewers indicated that they had problems understanding our 
attributes. Some read it as if we have some pairing specified and others 
saw other relations that we have not intended. I think we need to take 
these warnings from independent readers and  sort out any risk for 
mis-interpretation of our intentions.

Making a new effort to sort this out completely in 5.2 gives us:

--Change 2.1--
--Old text 2.1--

    This document defines two media-level attributes starting with
    'hlang' (short for "human interactive language") to negotiate which
    human language is used in each interactive media stream.
--New text 2.1---
    This document defines two media-level attributes starting with
    'hlang' (short for "human interactive language") to negotiate which
    human language alternative(s) the users are prepared to use in each interactive media stream.


--End of change 2.1---

--Old text 2.2---
    Each can appear in an offer for a media
    stream.
--New text 2.2---
    Each can appear in an offer and answer for a media
    stream.


--End of change 2.2---

---Old text 2.3 ---

  In an offer, the 'hlang-send' value is a list of one or more
    language(s) the offerer is willing to use when sending using the
    media, and the 'hlang-recv' value is a list of one or more
    language(s) the offerer is willing to use when receiving using the
    media.
----New text 2.3---
  In an offer, the 'hlang-send' value is a list of one or more
    alternative language(s) the offerer is willing to use when sending using the
    media, and the 'hlang-recv' value is a list of one or more
    alternative language(s) the offerer is willing to use when receiving using the
    media.


---End of change 2.3---

---Old text 2.4 ---
    The list of languages is in preference order (first is most
    preferred).
---New text 2.4---
    The list of alternative languages is in preference order (first is most
    preferred).


---End of change 2.4---

---Change 2.5-----
Requiring exactly one language per direction in the answer requires a tight coupling between the device and the user that we have avoided to specify. It would require either that the device takes the negotiation decision and dictates to the user e.g. "SPEAK GERMAN NOW !, or that there is a user interface interaction to decide which language to answer in, e.g. "The calling part may accept French or German, indicate here which one you will answer with".

We do not want to dictate that kind of tight coupling, and therefore must allow a number of alternative languages in various media to appear in the answer.

---Old text 2.5---
  In an answer, 'hlang-send' is the language the answerer will send
    when using the media (which in most cases is one of the languages in
    the offer's 'hlang-recv'), and 'hlang-recv' is the language the
    answerer expects to receive in the media (which in most cases is one
    of the languages in the offer's 'hlang-send').
---New text 2.5---
  In an answer, 'hlang-send' may be one or a list of alternative languages the
  answerer will select from for sending if using the media for language
(which in most cases is one of the languages in the offer's 'hlang-recv'),
and 'hlang-recv' may be one or a list of alternative languages the answerer
  can accept to receive if the media is used for language (which in most cases is one
    of the languages in the offer's 'hlang-send').
   

---End of change 2.5

---Old text 2.6---

  When placing an emergency call, and in any other case where the
    language cannot be inferred from context, in an offer each media
    stream primarily intended for human language communication SHOULD
    specify both (or for asymmetrical language use, one of) the 'hlang-
    send' and 'hlang-recv' attributes.
---New text 2.6---
  When placing an emergency call, and in any other case where the
    language cannot be inferred from context, in an offer each media
    stream primarily intended as an alternative for human language communication SHOULD
    specify both (or for asymmetrical language use, one of) the 'hlang-
    send' and 'hlang-recv' attributes.


--End of change 2.6---
  

---Old text 2.7---
  Clients acting on behalf of end users are expected to set one or both
    'hlang-send' and 'hlang-recv' attributes on each media stream
    primarily intended for human communication in an offer when placing
    an outgoing session,
---New text 2.7---
  Clients acting on behalf of end users are expected to set one or both
    'hlang-send' and 'hlang-recv' attributes on each media stream
    primarily intended as an alternative for human communication in an offer when placing
    an outgoing session,


---End of change 2.7---

---Old text 2.8---

  Note that media and language negotiation might result in more media
    streams being accepted than are needed by the users (e.g., if more
    preferred and less preferred combinations of media and language are
    all accepted).  This is not a problem.

---New text 2.8---

  Media and language negotiation might result in more media
    streams and language alternatives being accepted than are needed by
    the users (e.g., if more preferred and less preferred combinations
    of media and language are all accepted).  The users are expected to
    sort out which media and language alternatives to really use in the
    session, possibly supported by using refined indications.



---End of change 2.8----


>
>>
>>  ---Change 3---
>>
>>  In 5.3
>>
>>  sharpen up the description on how to use the asterisk. The current 
>> description confused most reviewers.
>>
>>  ---old text----
>>
>>     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.
>>
>>  ---new text---
>>     The mechanism for indicating this preference is that, in an 
>> offer, if
>>     the last parameter of any 'hlang-recv' or 'hlang-send' value in 
>> the whole SDP
>>     is an asterisk, this indicates a request to not fail the call.
>>
>>  ---end of change 3---
>
> I think it's more clear to word it as so:
>
>    The mechanism for indicating this preference is that, in an offer, if
>    the last value of any 'hlang-recv' or 'hlang-send' 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.
<GH> The important part was to change from "either" to "any", so that is 
good.

But we should also be strict about what we call the parts of the 
attribute values.
I prefer to call the whole string after 'hlang-recv:" or 'hlang-send:' 
the "value", and the separate language tags or asterisk then being 
"parameters" of that value. I think it is inconsistent to say that "the 
last value of the attribute value" may be an asterisk. Better to say 
that "the last parameter of the value" may be an asterisk.

(I will return to the asterisk with a separate proposal for how to use 
its placement for something useful.)
>
>>
>>  ----Change 4---
>>
>>  In 5.5,
>>
>>  Some example shows use of sign language one way and text the other.
>>
>>  ---Old text----
>>
>>  Note that, even though the examples all show the same language
>>
>>  --New text----
>>  Note that, even though most examples show the same language
>>
>>  ---End of change 4----
>>
>
> The text does say "(even when the modality differs)" to cover this, 
> but for clarification, I can delete "all" and add "(or essentially the 
> same)":
<GH>I think of the case when a deaf-blind person prefers to send a sign 
language and receive a written language. These languages do not have the 
same language tags even if they are used in the same geographic region.

We also have the working cases when I accept to receive Norweigan but 
speak Swedish myself, or someone accepting to receive Italian, but want 
to speak Spanish themselves, and other similar language mixes. These 
cases will more likely be satisfied not by true language matching, but 
by never using the request to fail the call, and let the users sort out 
the communication with some guidance from the indications. (both seeing 
what the other party expects will prepare them for the a bit unusual 
language mix.)

Your proposed change will work for these cases.   Accepted.
>
>    Note that, even though the examples show the same (or essentially the
>    same) language being used in both directions (even when the modality
>    differs), there is no requirement that this be the case. However, in
>    practice, doing so is likely to increase the chances of successful
>    matching.
>
>
---Change 5---
>>
>>  In 6.1.
>>
>>  SDP values are UTF-8 coded, not ASCII.
>>
>>  ---Old text---
>>
>>
>>
>>        asterisk    =  "*"   ; an asterisk (ASCII %2A) character
>>
>>        sp          =  1*" " ; one or more ASCII space (%20) characters
>>
>>   ---New text---
>>
>>
>>        asterisk    =  "*"   ; an asterisk (%x2A) character
>>
>>        SP          =  1*" " ; one or more space (%x20) characters
>>
>>   --End of change 5 ----
>
> I'll change "ASCII %" to "0x" for clarity.
<GH> Note also the change from "sp"   to "SP"
>
>>
>>  --
>>
>>  Regards
>>  Gunnar
>>
>>
>>  Den 2017-05-30 kl. 01:00, skrev 
>> <mailto:[e-mail]>[e-mail]:
>>
>>>
>>>  A New Internet-Draft is available from the on-line Internet-Drafts 
>>> directories.
>>>  This draft is a work item of the Selection of Language for Internet 
>>> Media of the IETF.
>>>
>>>          Title           : Negotiating Human Language in Real-Time 
>>> Communications
>>>          Author          : Randall Gellens
>>>      Filename        : 
>>> draft-ietf-slim-negotiating-human-language-10.txt
>>>      Pages           : 17
>>>      Date            : 2017-05-29
>>>
>>>  Abstract:
>>>     Users have various human (natural) language needs, abilities, and
>>>     preferences regarding spoken, written, and signed languages.  This
>>>     document adds new SDP media-level attributes so that when
>>>     establishing interactive communication sessions ("calls"), it is
>>>     possible to negotiate (communicate and match) the caller's language
>>>     and media needs with the capabilities of the called party.  This is
>>>     especially important with emergency calls, where a call can be
>>>     handled by a call taker capable of communicating with the user, 
>>> or a
>>>     translator or relay operator can be bridged into the call during
>>>     setup, but this applies to non-emergency calls as well (as an
>>>     example, when calling a company call center).
>>>
>>>     This document describes the need and a solution using new SDP media
>>>     attributes.
>>>
>>>
>>>  The IETF datatracker status page for this draft is:
>>>
>>> <https://datatracker.ietf.org/doc/draft-ietf-slim-negotiating-human-language/>https://datatracker.ietf.org/doc/draft-ietf-slim-negotiating-human-language/ 
>>>
>>>
>>>  There are also htmlized versions available at:
>>>
>>> <https://tools.ietf.org/html/draft-ietf-slim-negotiating-human-language-10>https://tools.ietf.org/html/draft-ietf-slim-negotiating-human-language-10 
>>>
>>>
>>> <https://datatracker.ietf.org/doc/html/draft-ietf-slim-negotiating-human-language-10>https://datatracker.ietf.org/doc/html/draft-ietf-slim-negotiating-human-language-10 
>>>
>>>
>>>  A diff from the previous version is available at:
>>>
>>> <https://www.ietf.org/rfcdiff?url2=draft-ietf-slim-negotiating-human-language-10>https://www.ietf.org/rfcdiff?url2=draft-ietf-slim-negotiating-human-language-10 
>>>
>>>
>>>
>>>  Please note that it may take a couple of minutes from the time of 
>>> submission
>>>  until the htmlized version and diff are available at tools.ietf.org.
>>>
>>>  Internet-Drafts are also available by anonymous FTP at:
>>>  <ftp://ftp.ietf.org/internet-drafts/>ftp://ftp.ietf.org/internet-drafts/ 
>>>
>>>
>>>  _______________________________________________
>>>  SLIM mailing list
>>>  <mailto:[e-mail]>[e-mail]
>>>
>>> <https://www.ietf.org/mailman/listinfo/slim>https://www.ietf.org/mailman/listinfo/slim 
>>>
>>>
>>
>>  --
>>  -----------------------------------------
>>  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]