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

From: Gunnar Hellström <[email-masked]>
Date: Thu, 1 Jun 2017 20:16:43 +0200

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:[email-masked]><mailto:[email-masked]><mailto:[email-masked]>[email-masked]:
>>>>>
>>>>>>
>>>>>>  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:[email-masked]><mailto:[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 
>>>>>>
>>>>>>
>>>>>
>>>>>  --
>>>>>  -----------------------------------------
>>>>>  Gunnar Hellström
>>>>>  Omnitor
>>>>>
>>>>> <mailto:[email-masked]><mailto:[email-masked]><mailto:[email-masked]>[email-masked] 
>>>>>
>>>>>  +46 708 204 288
>>>>>
>>>>>  _______________________________________________
>>>>>  SLIM mailing list
>>>>> <mailto:[email-masked]>[email-masked]
>>>>>
>>>>> <https://www.ietf.org/mailman/listinfo/slim>https://www.ietf.org/mailman/listinfo/slim 
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>  --
>>>  -----------------------------------------
>>>  Gunnar Hellström
>>>  Omnitor
>>> <mailto:[email-masked]>[email-masked]
>>>  +46 708 204 288
>>>
>>>  _______________________________________________
>>>  SLIM mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/slim
>>
>>
>
> -- 
> -----------------------------------------
> Gunnar Hellström
> Omnitor
> [email-masked]
> +46 708 204 288

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

---

From: Randall Gellens <[email-masked]>
Date: Thu, 1 Jun 2017 11:28:01 -0700

Edited down for clarity.

At 8:16 PM +0200 6/1/17, Gunnar Hellström wrote:

>>>>
>>>>  ---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---
>>>>  when using the media (which in most cases is one of the languages in
>>>>  In an answer, 'hlang-send' may be one or a 
>>>> list of alternative languages the
>>>>  (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
>>>  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:
>>>
>>  <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
>>  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.
>  if using the media for language (which in most 
> cases is one of the languages in

Your request is to change "when using the media" 
to "if using the media for language".  I can live 
with this.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
There are two ways to write error-free programs;
only the third one works.

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 1 Jun 2017 20:35:02 +0200

Den 2017-06-01 kl. 20:28, skrev Randall Gellens:
>>>>>  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".
>>>>>
>>>>>  and 'hlang-recv' may be one or a list of alternative languages 
>>>>> the answerer
>>> just one language in a media, and just that language will also be 
>>> used by the answering human?
>>>
>>> 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.
>>>
>>> less strict if we allow a list of languages per media to be the 
>>> result of the negotiation.
>>>
>>>  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.
>>>
>>  But it needs to be clear that the negotiated language in a media 
>> just maybe used for language.
> Your request is to change "when using the media" to "if using the 
> media for language".  I can live with this.
>
<GH>Good, accepted.

---

From: Gunnar Hellström <[email-masked]>
Date: Sun, 4 Jun 2017 09:09:16 +0200

Randall,

This is a contiuation of the discussion under topic "Issues #27 and #32 
- simultaneous languages"

Assume that I make a separate draft for indication of preferred 
modality. I would then like to use the coding with the asterisk proposed 
below.

Knowing that that is on its way, how would you describe the use of the 
asterisk in the current draft so that no interop issues appear when the 
preferred modality extension is published?

And how would you describe the use of the asterisk in the current draft 
so that it will be accepted as a media level parameter?

Right now you say that the asterisk may be attached to any hlang 
attribute for any direction.

An implementation following that advice may for an offer attach it to a 
modality that is not at all preferred. An implementation knowing the 
extension may then take very wrong decisions about how to best start the 
session.

I am afraid that in this situation the preferred modality indication 
would need to move to a new attribute or parameter, adding even more 
complexity.   E.g. a media level attribute a=modalitypref: hi    or a 
session level attribute a=modalitypref: written, spoken      (in order 
of preference). I would like to save us that added complexity. How?

Regards

Gunnar

Den 2017-05-31 kl. 21:31, skrev Gunnar Hellström:
> Den 2017-05-31 kl. 15:58, skrev Randall Gellens:
>> This text should go in a separate document containing advice to 
>> implementers.
> It adds an even better motivation than my earlier proposals for having 
> the asterisk as a parameter on media level,
> and it adds a mild recommendation about the preference between media 
> that we need to make the draft useful in reality. Therefore I suggest 
> to accept it into the current draft.  ( if issue #34 is rejected )
>
> Without this change, the confusion about the placement of the asterisk 
> and the question why the asterisk is a media parameter is still valid.
>
> Regards
> Gunnar
>>
>> At 3:24 PM +0200 5/31/17, Gunnar Hellström wrote:
>>
>>>  Regarding the many review comments about the use of the asterisk 
>>> parameter in draft-ietf-slim-negotiating-human-language, ( e.g. by 
>>> Adam Roach on 28/3/2017) I propose the following change that both 
>>> gives a meaning to the position of the asterisk and satisfies issue 
>>> #26 with media preferences.
>>>
>>>  I propose to use this solution if there is a decision to not 
>>> satisfy Issue #34, to use the Accept-Language syntax.:
>>>
>>>  --Change proposal - to draft version -10---
>>>
>>>  --First change--
>>>
>>>  in section 5.2
>>>
>>>  --old text-
>>>
>>>     In an offer, each value MAY have an asterisk appended as the final
>>>     value.  An asterisk appended to either value 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 for more information and
>>>     discussion.
>>>
>>>  -new text
>>>
>>>     In an offer or answer, each value MAY have an asterisk appended 
>>> as the final
>>>     parameter.  An asterisk appended to a value in an offer indicates a
>>>     that the caller has higher preference for the corresponding 
>>> modality
>>>   to be used in the specified direction than other modalities for 
>>> the indicated
>>>  direction without an asterisk. If no such preference is indicated 
>>> in any hlang-
>>>  attribute, it should be taken as a preference by the caller to get 
>>> the call denied
>>>  if no languages are in common between the caller and the callee.
>>>  In an answer, the asterisk indicates a modality that is preferred 
>>> by the callee to be used in the session.
>>>
>>>  See Section 5.3 for more information and
>>>     discussion.
>>>
>>>  --end of first change----
>>>
>>>  ---second change----
>>>  In 5.3
>>>  ----old text---
>>>
>>>
>>>  5.3.  No Language in Common
>>>
>>>     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.
>>>
>>>     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.
>>>
>>>  ---New text ----
>>>
>>>
>>>  5.3. Preferred modality and action if no match
>>>
>>>     A user may have a clear preference to use one specific modality 
>>> in a
>>>     direction, while use of other modalities may be acceptable but 
>>> lower in
>>>     preference. This condition MAY be indicated by appending an 
>>> asterisk
>>>     as the last parameter in the corresponding humlang- value. This
>>>     indication should also be seen as a preference to not have the call
>>>     denied even if no indicated languages are in common.
>>>
>>>     When negotiating language use for a direction, languages and 
>>> modalities
>>>    specified together with the asterisk should be given preference 
>>> to be selected for use.
>>>     No specific preference between modalities in the same direction 
>>> should
>>>     be indicated by appending an asterisk on all or no humlang- 
>>> values for that direction.
>>>
>>>     If there is a preference for denying the call when no languages 
>>> match,
>>>     then it is not possible to indicate any preferred modality at 
>>> the same time.
>>>
>>>     It is OPTIONAL for the callee to honor the preference for 
>>> denying the call at no match.
>>>     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 called party MAY ignore the indication for denying the call, 
>>> 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 in case of no 
>>> matching language
>>>  -----end of change ------------------
>>>
>>>  ---Change in 5.5----
>>>
>>>  ---Add this text as a separate example e.g. last in 5.5---
>>>     An offer requesting the following media streams: audio for the 
>>> caller
>>>     to send using spoken English (most preferred modality) or American
>>>     Sign Language (less preferred modality),
>>>     audio for the caller to receive spoken English (most preferred 
>>> modality) or
>>>     American Sign Language (less preferred modality),
>>>     supplemental text.  The offer also requests that the
>>>     call proceed even if the callee does not support any of the
>>>     languages. The offer is likely from a hearing person with 
>>> knowledge in sign language:
>>>
>>>        m=text 45020 RTP/AVP 103 104
>>>
>>>        m=audio 49250 RTP/AVP 20
>>>        a=hlang-recv:en *
>>>        a=hlang-send:en *
>>>
>>>       m=video 51372 RTP/AVP 31 32
>>>       a=hlang-recv: ase
>>>       a=hlang-send: ase
>>>
>>>   An answer for the above offer, indicating video in which the 
>>> callee will send and receive American Sign Language, because that 
>>> callee had no capability for spoken English. The text and audio 
>>> streams are opened as supplementary streams.
>>>
>>>        m=text 45020 RTP/AVP 103 104
>>>              m=audio 49250 RTP/AVP 20
>>>
>>>
>>>        m=video 51372 RTP/AVP 31 32
>>>        a=hlang-send: ase
>>>        a=hlang-recv: ase
>>>   ---end of change---
>>>
>>>
>>>
>>>
>>>
>>>  --

---

From: Randall Gellens <[email-masked]>
Date: Sun, 4 Jun 2017 14:51:48 -0700

Hi Gunnar,

What I'd suggest is that we include an informational reference to the 
draft, although that requires that at least an initial version of the 
draft be published pretty quickly.  So, my suggestion is that you 
publish at least a skeleton draft right away (which you can revise 
and extend quickly), and we add text along the lines of the 
following, perhaps after the second paragraph of Section 5.3:

    Note that separate work [draft-xxx] proposes to use the asterisk (or
    lack thereof) to convey information between endpoints.

This alerts implementers to the other draft.

-------------- Randomly selected tag: ---------------
Weiner's Law of Libraries:
    There are no answers, only cross references.

---

From: Gunnar Hellström <[email-masked]>
Date: Mon, 5 Jun 2017 22:21:41 +0200

Den 2017-06-04 kl. 23:51, skrev Randall Gellens:
> publish at least a skeleton draft right away (which you can revise and 
> extend quickly), and we add text along the lines of the following, 
> perhaps after the second paragraph of Section 5.3:
>
This might be a possible way ahead, if others also think it is feasible.

The wording and placement of the text requires more tuning. E.g. it 
should not say "proposes", but rather "specifies".

Gunnar

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 7 Jun 2017 20:20:55 +0200

Den 2017-06-06 kl. 03:00, skrev Randall Gellens:
> At 10:21 PM +0200 6/5/17, Gunnar Hellström wrote:
>
>>>  What I'd suggest is that we include an informational reference to 
>>> the draft, although that requires that at least an initial version 
>>> of the draft be published pretty quickly. So, my suggestion is that 
>>> you publish at least a skeleton draft right away (which you can 
>>> revise and extend quickly), and we add text along the lines of the 
> Gunnar, please upload at least a skeleton version of the draft right 
> away, and let me know the title.  If you need help with that, I can 
> create one.
>
> I was reluctant to say "specifies" until we have a more solid draft 
> (we don't yet have anything). How about if the text says "uses" rather 
> than "proposes to use"?  I think that covers it.
Yes, the drafts for the two functionality extensions are uploaded.

I would think that it would be more logical to insert the note about the 
added meaning of the asterisk in section 5.2, because 5.3 is for the 
current interpretation case only.

I propose a change to this current text in 5.2

------old text----

    In an offer, each value MAY have an asterisk appended as the final
    value.  An asterisk appended to either value 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 for more information and
    discussion.

-----new text could be----

    In an offer or answer, each value MAY have an asterisk appended as the final
    token.  An asterisk appended to either value 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 for more information and
    discussion.

    Note that separate work [draft-hellstrom-slim-modalitypref] extends the use of the
    asterisk with a media level indication.

---end of change-----------------

The other draft, about simultaneous modality may also need to be announced.
I suggest this change:

----old text in 5.2------

  BCP 47 describes mechanisms for
    matching language tags.  Note that [RFC5646] Section 4.1 advises to
    "tag content wisely" and not include unnecessary subtags.

  ----new text-----

  BCP 47 describes mechanisms for
    matching language tags.  Note that [RFC5646] Section 4.1 advises to
    "tag content wisely" and not include unnecessary subtags.

  Note also that separate work in [draft-hellstrom-slim-simultaneous-modality] uses a
  notation with a subtag for extended functionality. It is therefore of importance to
  use the mechanisms from BCP 47 for matching languages correctly.

----end of change-----

This all builds on that we can at least get WG draft status soon on the 
new drafts.

Gunnar

---

From: Randall Gellens <[email-masked]>
Date: Fri, 9 Jun 2017 11:28:32 -0700

At 8:20 PM +0200 6/7/17, Gunnar Hellström wrote:

>>>>  What I'd suggest is that we include an 
>>>> informational reference to the draft, 
>>>> although that requires that at least an 
>>>> initial version of the draft be published 
>>>> pretty quickly. So, my suggestion is that 
>>>> you publish at least a skeleton draft right 
>>>> away (which you can revise and extend 
>>>> quickly), and we add text along the lines of 
>>>> the following, perhaps after the second 
>>>> paragraph of Section 5.3:
>>>>
>>  Gunnar, please upload at least a skeleton 
>> version of the draft right away, and let me 
>> know the title. If you need help with that, I 
>> can create one.
>>
>>>  The wording and placement of the text 
>>> requires more tuning. E.g. it should not say 
>>> "proposes", but rather "specifies".
>>>
>>
>>  I was reluctant to say "specifies" until we 
>> have a more solid draft (we don't yet have 
>> anything). How about if the text says "uses" 
>> rather than "proposes to use"? I think that 
>> covers it.
>>
>  I would think that it would be more logical to 
> insert the note about the added meaning of the 
> asterisk in section 5.2, because 5.3 is for the 
>     Note that separate work 
> [draft-hellstrom-slim-modalitypref] extends the 
> use of the

I moved the note from 5.3 to 5.2 and reworded to 
say "extends the use of the asterisk to convey 
information between endpoints":

    In an offer, each 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 for more
    information and discussion.  Note that separate work
    [I-D.hellstrom-slim-modalitypref] extends the use of the asterisk to
    convey information between endpoints.

>   Note also that separate work in 
> [draft-hellstrom-slim-simultaneous-modality] 
> uses a
>   notation with a subtag for extended 
> functionality. It is therefore of importance to

I am not sure we need to reference the other 
draft, since it doesn't directly affect the usage 
of this draft.

>
>   This all builds on that we can at least get WG 
> draft status soon on the new drafts.

-------------- Randomly selected tag: ---------------
"SFPD Homicide: Our Day Begins when Yours End" --Slogan seen on back of
San Francisco Police Jacket, as reported by Herb Caen in SF Chronicle

---

From: Brian Rosen <[email-masked]>
Date: Fri, 9 Jun 2017 14:48:52 -0400

Generally, I like the wording here.  I’d make a minor suggestion to change "extends the use of the asterisk with a media level indication” to “extends the use of the asterisk convey additional information”  or even "extends the use of the asterisk convey additional information about languages preferences among multiple media sessions”

Brian

> On Jun 9, 2017, at 2:28 PM, Randall Gellens <[email-masked]> wrote:
> 
>>>>> What I'd suggest is that we include an informational reference to the draft, although that requires that at least an initial version of the draft be published pretty quickly. So, my suggestion is that you publish at least a skeleton draft right away (which you can revise and extend quickly), and we add text along the lines of the following, perhaps after the second paragraph of Section 5.3:
>>>>> 
>>> Gunnar, please upload at least a skeleton version of the draft right away, and let me know the title. If you need help with that, I can create one.
>>> 
>>>> The wording and placement of the text requires more tuning. E.g. it should not say "proposes", but rather "specifies".
>>>> 
>>> 
>>> I was reluctant to say "specifies" until we have a more solid draft (we don't yet have anything). How about if the text says "uses" rather than "proposes to use"? I think that covers it.
>>> 
>> I would think that it would be more logical to insert the note about the added meaning of the asterisk in section 5.2, because 5.3 is for the current interpretation case only.
>> 
> I moved the note from 5.3 to 5.2 and reworded to say "extends the use of the asterisk to convey information between endpoints":
> 
> I am not sure we need to reference the other draft, since it doesn't directly affect the usage of this draft.
> 
>> 
>>  This all builds on that we can at least get WG draft status soon on the new drafts.
> 
> -- 
> Randall Gellens
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/slim <https://www.ietf.org/mailman/listinfo/slim>

---

From: Gunnar Hellström <[email-masked]>
Date: Fri, 9 Jun 2017 21:03:08 +0200

Den 2017-06-09 kl. 20:48, skrev Brian Rosen:
> Generally, I like the wording here.  I’d make a minor suggestion to 
> change "extends the use of the asterisk with a media level indication” 
> to “extends the use of the asterisk convey additional information”  or 
> even "extends the use of the asterisk convey additional information 
> about languages preferences among multiple media sessions”
>
I like the last one best.
(I think 'to' is missing after 'asterisk')

/Gunnar
> Brian
>
>> On Jun 9, 2017, at 2:28 PM, Randall Gellens 
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>>>>> the draft, although that requires that at least an initial 
>>>>>> version of the draft be published pretty quickly. So, my 
>>>>>> suggestion is that you publish at least a skeleton draft right 
>>>>>> away (which you can revise and extend quickly), and we add text 
>>>>>> along the lines of the following, perhaps after the second 
>>>> Gunnar, please upload at least a skeleton version of the draft 
>>>> right away, and let me know the title. If you need help with that, 
>>>> I can create one.
>>>>
>>>>> The wording and placement of the text requires more tuning. E.g. 
>>>>> it should not say "proposes", but rather "specifies".
>>>>>
>>>>
>>>> (we don't yet have anything). How about if the text says "uses" 
>>>> rather than "proposes to use"? I think that covers it.
>>>>
>>> I would think that it would be more logical to insert the note about 
>>> the added meaning of the asterisk in section 5.2, because 5.3 is for 
>>> the current interpretation case only.
>>>
>> I moved the note from 5.3 to 5.2 and reworded to say "extends the use 
>> of the asterisk to convey information between endpoints":
>>
>>> [draft-hellstrom-slim-simultaneous-modality] uses a

---

From: Randall Gellens <[email-masked]>
Date: Fri, 9 Jun 2017 14:42:02 -0700

The wording I proposed earlier today is "extends 
the use of the asterisk to convey information 
between endpoints" but I like adding "additional" 
to "information".

At 2:48 PM -0400 6/9/17, Brian Rosen wrote:

>  Generally, I like the wording here.  I'd make a 
> minor suggestion to change "extends the use of 
> the asterisk with a media level indication" to 
> "extends the use of the asterisk convey 
> additional information"  or even "extends the 
> use of the asterisk convey additional 
> information about languages preferences among 
> multiple media sessions"
>
>  Brian
>
>> <<mailto:[email-masked]>[email-masked]> 
>> wrote:
>>
>>>>>> you publish at least a skeleton draft 
>>>>>> right away (which you can revise and 
>>>>>> extend quickly), and we add text along the 
>>>>>> lines of the following, perhaps after the 
>>>>>> second paragraph of Section 5.3:
>>>>>>
>>>> know the title. If you need help with that, 
>>>> I can create one.
>>>>
>>>>> requires more tuning. E.g. it should not 
>>>>> say "proposes", but rather "specifies".
>>>>>
>>>>
>>>  I would think that it would be more logical 
>>> to insert the note about the added meaning of 
>>> the asterisk in section 5.2, because 5.3 is 
>>> for the current interpretation case only.
>>>
>>> [draft-hellstrom-slim-modalitypref] extends 
>>> the use of the
>>  I moved the note from 5.3 to 5.2 and reworded 
>> to say "extends the use of the asterisk to 
>> convey information between endpoints":
>>
>> draft, since it doesn't directly affect the 
>> usage of this draft.
>>
>>>

-------------- Randomly selected tag: ---------------
Anarchy may not be the best form of government, but it's better
than no government at all.