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

[Randall Gellens <[e-mail]>]

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.

>
>
>
>  --End of change 2.1---
>
>  --Old text 2.2---
>     Each can appear in an offer for a media
>     stream.
>  --New text 2.2---
>     Each can appear in an offer and answer for a media
>     stream.
>
>
>  --End of change 2.2---
>
>  ---Old text 2.3 ---
>
>   In an offer, the 'hlang-send' value is a list of one or more
>     language(s) the offerer is willing to use when sending using the
>     media, and the 'hlang-recv' value is a list of one or more
>     language(s) the offerer is willing to use when receiving using the
>     media.
>  ----New text 2.3---
>   In an offer, the 'hlang-send' value is a list of one or more
>     alternative language(s) the offerer is 
> willing to use when sending using the
>     media, and the 'hlang-recv' value is a list of one or more
>     alternative language(s) the offerer is 
> willing to use when receiving using the
>     media.
>
>
>  ---End of change 2.3---
>
>  ---Old text 2.4 ---
>     The list of languages is in preference order (first is most
>     preferred).
>  ---New text 2.4---
>     The list of alternative languages is in preference order (first is most
>     preferred).
>
>
>  ---End of change 2.4---
>
>  ---Change 2.5-----
>  Requiring exactly one language per direction in 
> the answer requires a tight coupling between 
> the device and the user that we have avoided to 
> specify. It would require either that the 
> device takes the negotiation decision and 
> dictates to the user e.g. "SPEAK GERMAN NOW !, 
> or that there is a user interface interaction 
> to decide which language to answer in, e.g. 
> "The calling part may accept French or German, 
> indicate here which one you will answer with".
>
>  We do not want to dictate that kind of tight 
> coupling, and therefore must allow a number of 
> alternative languages in various media to 
> appear in the answer.
>
>  ---Old text 2.5---
>   In an answer, 'hlang-send' is the language the answerer will send
>     when using the media (which in most cases is one of the languages in
>     the offer's 'hlang-recv'), and 'hlang-recv' is the language the
>     answerer expects to receive in the media (which in most cases is one
>     of the languages in the offer's 'hlang-send').
>  ---New text 2.5---
>   In an answer, 'hlang-send' may be one or a list of alternative languages the
>   answerer will select from for sending if using the media for language
>  (which in most cases is one of the languages in the offer's 'hlang-recv'),
>  and 'hlang-recv' may be one or a list of alternative languages the answerer
>   can accept to receive if the media is used for 
> language (which in most cases is one
>     of the languages in the offer's 'hlang-send').

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.)

>
>
>  ---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.

>
>
>  --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.


>
>
>  ---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.

>
>
>  ---End of change 2.8----
>
>>
>>>
>>>  ---Change 3---
>>>
>>>  In 5.3
>>>
>>>  sharpen up the description on how to use the 
>>> asterisk. The current description confused 
>>> most reviewers.
>>>
>>>  ---old text----
>>>
>>>  The mechanism for indicating this preference is that, in an offer, if
>>>  the last value of either 'hlang-recv' or 'hlang-send' is an asterisk,
>>>  this indicates a request to not fail the call.
>>>
>>>  ---new text---
>>>  The mechanism for indicating this preference is that, in an offer, if
>>>  the last parameter of any 'hlang-recv' or 
>>> 'hlang-send' value in the whole SDP
>>>  is an asterisk, this indicates a request to not fail the call.
>>>
>>>  ---end of change 3---
>>>
>>
>>  I think it's more clear to word it as so:
>>
>>  The mechanism for indicating this preference is that, in an offer, if
>>  the last value of any 'hlang-recv' or 'hlang-send' for any media is
>>  an asterisk, this indicates a request to not fail the call. The
>>  called party MAY ignore the indication, e.g., for the emergency
>>  services use case, regardless of the absence of an asterisk, a PSAP
>>  will likely not fail the call; some call centers might reject a call
>>  even if the offer contains an asterisk.
>>
>  <GH> The important part was to change from 
> "either" to "any", so that is good.
>
>  But we should also be strict about what we call 
> the parts of the attribute values.
>  I prefer to call the whole string after 
> 'hlang-recv:" or 'hlang-send:' the "value", and 
> the separate language tags or asterisk then 
> being "parameters" of that value. I think it is 
> inconsistent to say that "the last value of the 
> attribute value" may be an asterisk. Better to 
> say that "the last parameter of the value" may 
> be an asterisk.
>
>  (I will return to the asterisk with a separate 
> proposal for how to use its placement for 
> something useful.)

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?

>
>  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.

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


-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
When bad men combine, the good must associate; else they will fall, one
by one, an unpitied sacrifice in a contemptible struggle.
                                             --Edmund Burke (1729-1797)