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

From: [email-masked]
Date: Mon, 29 May 2017 16:00:49 -0700

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/

There are also htmlized versions available at:
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

A diff from the previous version is available at:
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/

---

From: Gunnar Hellström <[email-masked]>
Date: Tue, 30 May 2017 22:51:16 +0200

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

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

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

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

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

--

Regards
Gunnar

Den 2017-05-30 kl. 01:00, skrev [email-masked]:
> _______________________________________________
> SLIM mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/slim

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

---

From: Randall Gellens <[email-masked]>
Date: Tue, 30 May 2017 16:56:15 -0700

At 10:51 PM +0200 5/30/17, Gunnar Hellström wrote:

>  When the draft is ready, it is no draft 
> anymore. Plus divide the aspects in two 
> sentences.
>
>  ----old text---
>

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.

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

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.

>
>  ---Change 3---
>
>  In 5.3
>
>  sharpen up the description on how to use the 
> asterisk. The current description confused most 
> reviewers.
>
>  ---old text----
>

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.

>  Note that, even though most examples show the same language

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)":

    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.

>        SP          =  1*" " ; one or more space (%x20) characters

I'll change "ASCII %" to "0x" for clarity.

>
>  --
>
>  Regards
>  Gunnar
>
>
>  Den 2017-05-30 kl. 01:00, skrev 
> <mailto:[email-masked]>[email-masked]:
>
>>
>> <https://datatracker.ietf.org/doc/draft-ietf-slim-negotiating-human-language/>https://datatracker.ietf.org/doc/draft-ietf-slim-negotiating-human-language/
>>
>> <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://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
>>
>>
>>  <ftp://ftp.ietf.org/internet-drafts/>ftp://ftp.ietf.org/internet-drafts/
>>
>>  <mailto:[email-masked]>[email-masked]
>> 
>> <https://www.ietf.org/mailman/listinfo/slim>https://www.ietf.org/mailman/listinfo/slim
>>
>
>  --
>  <mailto:[email-masked]>[email-masked]
>  +46 708 204 288
>

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Tolerance implies no lack of commitment to one's own beliefs.  Rather
it condemns the oppression or persecution of others.
                                              --John F. Kennedy (1960)

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 31 May 2017 10:58:52 +0200

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:
>>  When the draft is ready, it is no draft anymore. Plus divide the 
>> aspects in two sentences.
>>
>>  ----old text---
>>
> 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 
<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 ---
>>     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
> I don't think it's true that we're no better off than the old SDP lang 
> attribute, for multiple reasons, not least of which is that 'lang' is 
> not used for negotiating language in interactive media. Further, I 
> think the result of extra streams is that there are extra streams that 
> probably won't be used.
<GH> I just mean that it must be absolutely clear that the language 
indications for the same direction are alternatives to select from, and 
not an indication that they will be used simultaneously. (not until we 
have the extension sorted out that will indicate simultaneous use in 
specific cases).

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

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

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

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

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

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

--End of change 2.1---

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

--End of change 2.2---

---Old text 2.3 ---

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

---End of change 2.3---

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

---End of change 2.4---

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

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

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

---End of change 2.5

---Old text 2.6---

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

--End of change 2.6---

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

---New text 2.8---

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

---End of change 2.8----

>    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.)
> The text does say "(even when the modality differs)" to cover this, 
> but for clarification, I can delete "all" and add "(or essentially the 
> same)":
<GH>I think of the case when a deaf-blind person prefers to send a sign 
language and receive a written language. These languages do not have the 
same language tags even if they are used in the same geographic region.

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

Your proposed change will work for these cases.   Accepted.
---Change 5---
> I'll change "ASCII %" to "0x" for clarity.
<GH> Note also the change from "sp"   to "SP"
>>>      Filename        : 
>>> draft-ietf-slim-negotiating-human-language-10.txt
>>>      Pages           : 17
>>>      Date            : 2017-05-29
>>>
>>>  Abstract:

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 31 May 2017 15:24:40 +0200

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.

    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.  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
    even if the offer contains an asterisk.

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

---

From: Randall Gellens <[email-masked]>
Date: Wed, 31 May 2017 06:57:31 -0700

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.
>
>>  The use of "draft" was an error, I'll change 
>> it to "document." I prefer the semicolon to 
>>>  We must be clear about that the result 
>>> normally is alternative languages to use, 
>>> normally not simultaneously. Without this 
>>> alternatives to select from. Media and 
>>> language negotiation might result in more 
>>> media streams and languages being accepted 
>>> than are needed by the users
>>  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.
>
>     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.

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

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

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

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

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

>>> asterisk. The current description confused 
>>> most reviewers.
>>>
>>>  ---old text----
>>>
>  <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.

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

Thanks, fixed.

>>> <mailto:[email-masked]><mailto:[email-masked]><mailto:[email-masked]>[email-masked]:
>>>
>>>>
>>>>  This draft is a work item of the Selection 
>>>> of Language for Internet Media of the IETF.
>>>>
>>>> <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/
>>>>
>>>> <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
>>>>
>>>> <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
>>>>
>>>>
>>>> <ftp://ftp.ietf.org/internet-drafts/><ftp://ftp.ietf.org/internet-drafts/><ftp://ftp.ietf.org/internet-drafts/>ftp://ftp.ietf.org/internet-drafts/
>>>>
>>>> <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
>>>>
>>>
>>>  --
>>> <mailto:[email-masked]><mailto:[email-masked]><mailto:[email-masked]>[email-masked]
>>>  +46 708 204 288
>>>

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

---

From: Randall Gellens <[email-masked]>
Date: Wed, 31 May 2017 06:58:30 -0700

This text should go in a separate document containing advice to implementers.

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.:
>
>  In an answer, the asterisk indicates a modality 
> that is preferred by the callee to be used in 
> the session.
>
>    specified together with the asterisk should 
> be given preference to be selected for use.   
>
>     be indicated by appending an asterisk on all 
> or no humlang- values for that direction.
>
>     It is OPTIONAL for the callee to honor the 
> preference for denying the call at no match.
>     languages. The offer is likely from a 
> hearing person with knowledge in sign language:
>
>   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.
>

-------------- Randomly selected tag: ---------------
He had that rare weird electricity about him -- that extremely
wild and heavy presence that you only see in a person who has
abandoned all hope of ever behaving "normally."
        --Hunter S. Thompson, "Fear and Loathing '72"

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 31 May 2017 21:23:28 +0200

Den 2017-05-31 kl. 15:57, skrev Randall Gellens:
>>  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.
>>
>>>>  Without any further indications of preferences or requirements for 
>>>> simultaneity, the language indications should be seen as 
>>>  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 
>> 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 
>>  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.
>>
>> 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.
>>
> 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
>>     The list of alternative languages is in preference order (first 
<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---
> 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
    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.

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

>>  <GH> The important part was to change from "either" to "any", so 
>> that is good.
>>
>>  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,
>>>>
>>> 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.)
>>

Thanks,
Gunnar

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 31 May 2017 21:31:22 +0200

> This text should go in a separate document containing advice to 
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
>> 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.
>>
>>   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.
>>