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

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

New info on 2.5 below


Den 2017-05-31 kl. 21:23, skrev Gunnar Hellström:
> 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.
<GH>After the exercise with the negotiation today, I see that I can 
relax this requirement.
But it needs to be clear that the negotiated language in a media just 
maybe used for language.
So that it is clear that no simultaneous use is normally required.

That leads to
--New text 2.5 ---
   In an answer, 'hlang-send' is the language the answerer will send
     if using the media for language (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').

  ---end of 2.5 -------------------------

Gunnar
>
>
>>
>>>
>>>
>>>  ---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]

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