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

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

Den 2017-05-31 kl. 15:57, skrev Randall Gellens:
> At 10:58 AM +0200 5/31/17, Gunnar Hellström wrote:
>
>>  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.
>
> I think the editorial clarifications have resolved any potential 
> confusion noted by the previous reviewers.  Further, the current 
> wording only discusses language per media, while the text in 5.2 
> explicitly says that it's possible that some media might not be used.  
> I think the combination makes it clear that there is absolutely no 
> expectation that users use all languages since it clearly says they 
> might not use all media.  I do not think the wording "language 
> alternative(s)" is good; I think it introduces more confusion.  
> However, I can change "language is used" to "language is selected for 
> use" for clarity.
<GH>Accepted
>
>>
>>
>>
>>  --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---
<GH>Did you accept 2.2, 2.3, 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').
>
> Having one language per media in the answer has been part of the draft 
> all along.  I don't recall seeing an objection to this before.  
> Further, Section 3 has said all along that attempting to negotiate 
> multiple languages per media is out of scope:
>
>    (Negotiating multiple simultaneous languages within a media stream is
>    out of scope of this document.)
<GH>Yes, the user will only use one language. But have you thought about 
the consequences for how to accomplish a negotiation result of just one 
language in a media, and just that language will also be used by the 
answering human?

It will require tight coupling in the user interface of a kind that you 
do not want to discuss. If the UA decides that the answering part will 
send spoken german, then that needs to be conveyed to the user.  If the 
UA instead lets the user decide, then there must be a question-answer 
exchange between the UA and the user to enable the UA to have just one 
language for the media in the answer.

We have agreed that some kind of such coupling is needed, and we do not 
specify how. But the requirements on the operation will be much less 
strict if we allow a list of languages per media to be the result of the 
negotiation.

The paranthesis "   (Negotiating multiple simultaneous languages within 
a media stream is
    out of scope of this document.) " will then apply to the user.


This is a quite new finding from when trying to think through a real 
negotiation, so I am prepared to discuss how strict we should be.


>
>>
>>
>>  ---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.
>
> I don't think this text is needed.  A stream can be negotiated as 
> being intended for human interactive communication but the text says 
> the stream might not be used.
<GH>I think "primarily intended for human language communication" is a 
quite strong indication that the purpose is to use it. I wanted to 
reduce that impression by inserting the "as an alternative".
>
>>
>>
>>  --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,
>
> I don't think this text is needed.  A stream can be negotiated as 
> being intended for human interactive communication but the text says 
> the stream might not be used.
<GH>Again - "intended" is strong and may need to be weakened to indicate 
that it might not be used.
>
>
>>
>>
>>  ---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.
>
> If you think such text is needed, I suggest putting in a separate 
> document containing advice to implementers, where you can go into 
> detail on how the indications function.
<GH> You may delete the last phrase after the comma. The remaining part 
describes better the real situation than the current text.
We take the discussion about refined indications separately.


>
>>
>>
>>  ---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.
<GH>Did you accept to call the language tags and the asterisk 
"parameters" of the value, instead of values in the value?
>>
>>  (I will return to the asterisk with a separate proposal for how to 
>> use its placement for something useful.)
>
> Such proposal should go in a separate document containing advice to 
> implementers.
>
>>
>>>
>>>>
>>>>  ----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.
>
> Yes, the language tags are different between the spoken/written form 
> of a language and the signed form.  That's what the "essentially the 
> same" means.  Can you suggest a better description of the commonality 
> between these forms?
<GH>I think "essentially the same" will do. It can mean "in most cases 
the same" as well as "close to the same".

>
>>
>>  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"
>
> Thanks, fixed.

Thanks,
Gunnar
>
>>
>>>
>>>>
>>>>  --
>>>>
>>>>  Regards
>>>>  Gunnar
>>>>
>>>>
>>>>  Den 2017-05-30 kl. 01:00, skrev 
>>>> <mailto:[e-mail]><mailto:[e-mail]><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/><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://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><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><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/><ftp://ftp.ietf.org/internet-drafts/>ftp://ftp.ietf.org/internet-drafts/ 
>>>>>
>>>>>
>>>>>  _______________________________________________
>>>>>  SLIM mailing list
>>>>>
>>>>> <mailto:[e-mail]><mailto:[e-mail]><mailto:[e-mail]>[e-mail] 
>>>>>
>>>>>
>>>>>
>>>>> <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 
>>>>>
>>>>>
>>>>
>>>>  --
>>>>  -----------------------------------------
>>>>  Gunnar Hellström
>>>>  Omnitor
>>>>
>>>> <mailto:[e-mail]><mailto:[e-mail]><mailto:[e-mail]>[e-mail] 
>>>>
>>>>  [phone]
>>>>
>>>>  _______________________________________________
>>>>  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]