Subject: [Slim] Alvaro Retana's No Objection on draft-ietf-slim-negotiating-human-language-19: (with COMMENT)

From: Alvaro Retana <[email-masked]>
Date: Sat, 06 Jan 2018 06:13:36 -0800

Alvaro Retana has entered the following ballot position for
draft-ietf-slim-negotiating-human-language-19: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-slim-negotiating-human-language/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for writing an interesting document!

Given that this document doesn’t mandate the behavior in the case of not having
languages in common, why does it matter if the combination is “difficult to
match together” or not?  I’m wondering about this piece of text (from 5.2):

   ...The
   two SHOULD NOT be set to languages which are difficult to match
   together (e.g., specifying a desire to send audio in Hungarian and
   receive audio in Portuguese will make it difficult to successfully
   complete the call).

I don’t understand how “difficult to match” can be enforced from a normative
point of view.  Difficulty seems to be a subjective criteria -- the example
shows a pair that I would consider difficult too (I don't speak Hungarian!),
but other pairings could still be difficult for me but easy for others.  Using
“SHOULD NOT” (instead of “MUST NOT”) implies that there are cases in which it
is ok to do it (again, probably subjectively).  It seems to me that the “SHOULD
NOT” could be a simple “should not”.

BTW, that reminds me: please use the template text from rfc8174 (instead of
rfc2119).

Nit:  It would be nice to expand SPD in the abstract and put a reference to
rfc4566 in the Introduction.

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 6 Jan 2018 09:51:31 -0500

> https://datatracker.ietf.org/doc/draft-ietf-slim-negotiating-human-language/

I agree that this is really just some wisdom that is being encouraged, 
and so should not be normative.

	Thanks,
	Paul

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 06 Jan 2018 17:39:31 -0800

Eric Rescorla has entered the following ballot position for
draft-ietf-slim-negotiating-human-language-19: No Objection

Document: draft-ietf-slim-negotiating-human-language-17.txt

1. I'm not marking this first point DISCUSS, but I do think it's
important it be addressed and I trust the AD will ensure that it is.
This document is ambiguous about the contents of the answer
attribute. Specifically, it says:

   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 if using the media for
   language (which in most cases is one of the languages in the offer's
   'hlang-send').

However, the next paragraph permits >1 tag, as does the ABNF in S 6.1.

   Each value MUST be a list of one or more language tags per BCP 47
   [RFC5646], separated by white space.  BCP 47 describes mechanisms for
   matching language tags.  Note that [RFC5646] Section 4.1 advises to
   "tag content wisely" and not include unnecessary subtags.

So, how am I supposed to interpret an answer with >1 tag? Is this
forbidden? I can imagine a number of semantics, but it's important
it be clear in the document.

2. The negotiation structure here does not match that which is
conventionally used with SDP, where each side indicates the formats it
is prepared to receive and the other side can send any of them. Why
did you use this structure? One reason you might is that you expect
the answer to resolve which language is in use, however because SIP
supports early media (i.e., media which is delivered prior to the
answer.)

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 7 Jan 2018 02:46:27 +0000

On Jan 6, 2018, at 17:39, Eric Rescorla <[email-masked]> wrote:
> did you use this structure? 

[BA] Thank you for your review. 

For disabled users, the capabilities may not be symmetric.  For example, a user might be speech-impaired but not hearing impaired. So they might be able to receive English audio, but only able to send American Sign Language (ASL) within a video stream or written American English in a text stream. 

IMHO, this should probably be explained early in the document.

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 07 Jan 2018 02:50:46 +0000

Paul said:

"I agree that this is really just some wisdom that is being encouraged, and
so should not be normative."

[BA] Agree that it should not be normative. However, the point about
subjectivity still applies. I’m not sure what value the SHOULD NOT
provides, even if it is in lower case.  For example, is it “difficult” to
ask to receive American English in audio but to send ASL in video or
American English in text, because the user is speech-impaired, but not
hearing-impaired?  Isn’t the whole point of the negotiation to determine
what languages can be mutually accommodated?

On Sat, Jan 6, 2018 at 6:51 AM, Paul Kyzivat <[email-masked]> wrote:

> I agree that this is really just some wisdom that is being encouraged, and
> so should not be normative.
>
>         Thanks,
>         Paul
>

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 6 Jan 2018 18:55:11 -0800

On Sat, Jan 6, 2018 at 6:46 PM, Bernard Aboba <[email-masked]>
wrote:

> For disabled users, the capabilities may not be symmetric.

But this is true for ordinary SDP as well. I might be able to receive H.264
but not send it.

-Ekr

> For example, a user might be speech-impaired but not hearing impaired. So
> they might be able to receive English audio, but only able to send American
> Sign Language (ASL) within a video stream or written American English in a
> text stream.
>

---

From: Randall Gellens <[email-masked]>
Date: Sat, 6 Jan 2018 19:18:47 -0800

I will reword the text to be descriptive rather than normative.  The 
intent of the text is to point out that specifying language (not 
modality) combinations that are more difficult to match than 
necessary will likely not lead to ideal results.  Difficult 
combinations could in theory be handled by bridging in additional 
translators, but human language translation adds its own set of 
difficulties.

At 2:50 AM +0000 1/7/18, Bernard Aboba wrote:

>  Paul said:
>
>  "I agree that this is really just some wisdom that is being 
> encouraged, and so should not be normative."
>
>  [BA] Agree that it should not be normative. However, the point 
> about subjectivity still applies. I'm not sure what value the 
> SHOULD NOT provides, even if it is in lower case.  For example, is 
> it "difficult" to ask to receive American English in audio but to 
> send ASL in video or American English in text, because the user is 
> speech-impaired, but not hearing-impaired?  Isn't the whole point 
> of the negotiation to determine what languages can be mutually 
> accommodated?
>
>  On Sat, Jan 6, 2018 at 6:51 AM, Paul Kyzivat 
> <<mailto:[email-masked]>[email-masked]> wrote:
>
>  Please refer to 
> <https://www.ietf.org/iesg/statement/discuss-criteria.html>https://www.ietf.org/iesg/statement/discuss-criteria.html
> <https://datatracker.ietf.org/doc/draft-ietf-slim-negotiating-human-language/>https://datatracker.ietf.org/doc/draft-ietf-slim-negotiating-human-language/
>
>
>
>  Given that this document doesn't mandate the behavior in the case 
> of not having
>  languages in common, why does it matter if the combination is "difficult to
>  match together" or not?  I'm wondering about this piece of text (from 5.2):
>
>      ...The
>  I don't understand how "difficult to match" can be enforced from a normative
>  "SHOULD NOT" (instead of "MUST NOT") implies that there are cases in which it
>  is ok to do it (again, probably subjectively).  It seems to me that 
> the "SHOULD
>  NOT" could be a simple "should not".
>
>
>  I agree that this is really just some wisdom that is being 
> encouraged, and so should not be normative.
>
>          Thanks,
>          Paul
>
>
>
>  _______________________________________________
>  SLIM mailing list
>  [email-masked]
>  https://www.ietf.org/mailman/listinfo/slim

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
The most general and prevalent association with television viewing is a
heightened sense of living in a 'mean world' of violence and danger.
Fearful people are more dependent, more easily manipulated and
controlled, more susceptible to deceptively simple, strong, tough
measures and hard-line postures....  They may accept and even welcome
repression if it promises to relieve their insecurities.
    --George Gerbner, dean of Annenberg School of Communication

---

From: Randall Gellens <[email-masked]>
Date: Sat, 6 Jan 2018 19:22:36 -0800

>  it be clear in the document.

Thank you for catching this.  I think the first paragraph is correct 
and the second paragraph and ABNF are in error, they were copied from 
the offer and not fixed.  The intent is that a single language per 
direction be arrived it per media stream.

>  supports early media (i.e., media which is delivered prior to the

In light of my reply to (1), do you still feel that the negotiation 
structure doesn't match usual offer/answer behavior?

-------------- Randomly selected tag: ---------------
We do not stop playing because we grow old; we grow old because we stop
playing.             --U.S. Supreme Court Justice Oliver Wendell Holmes

---

From: Randall Gellens <[email-masked]>
Date: Sat, 6 Jan 2018 19:27:11 -0800

At 6:13 AM -0800 1/6/18, Alvaro Retana wrote:

>  match together" or not?

The goal is to have an interactive session with the greatest chance 
of mutual communication.

>    I'm wondering about this piece of text (from 5.2):
>
>     ...The

Please see my reply to Bernard and Paul; I will reword the text to be 
descriptive rather than normative.

>  BTW, that reminds me: please use the template text from rfc8174 (instead of

Thanks for catching this.

>  rfc4566 in the Introduction.

You mean SDP?  OK.

-------------- Randomly selected tag: ---------------
   "When I use a word," Humpty Dumpty said, in a rather scornful
tone, "it means just what I choose it to mean -- neither more nor less.
   "The question is," said Alice, "whether you can make words mean
so many different things."
   "The question is," said Humpty Dumpty, "which is to be master  --
that's all."

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 6 Jan 2018 19:31:49 -0800

On Jan 6, 2018, at 6:55 PM, Eric Rescorla <[email-masked]> wrote:

> But this is true for ordinary SDP as well. I might be able to receive H.264 but not send it.

[BA] Thanks. The draft should explain the reasoning. IMHO the argument goes sonething like this:

A pure recv/recv negotiation will not necessarily disclose beforehand what special services are needed for the call - services (e.g. ASL interpretation or RTT handling) that could take time to acquire. 

Since the actual video media sent is not labelled as ASL even if the answerer has ASL interpreters it can pull in and therefore advertises in SDP ASL reception capability in video, a recv/recv negotiation doesn’t tell the Answerer that the Offerer will need them, so the Answerer may need to (frantically) arrange for ASL interpretation after initial receipt of media. In an emergency, that can chew up valuable time.

---

From: "Randall Gellens (IETF)" <[email-masked]>
Date: Sat, 6 Jan 2018 21:02:43 -0800

It hasn't been my understanding that language would be sprung on users; if video is requested in an offer to carry ASL, that would be in the offer, and if the answerer can support ASL, the answer includes video with ASL. In North America, callers needing sign language interpretation or text translation usually initiate calls via the interpreter/relay service, but this might not be true elsewhere. In North America, PSAPs have the ability to handle text calls (legacy PSAPs support TTY; next-gen PSAPs support RTT). Calls needing language translation might internally be handled by staff who speak the language or an external language translation service might be bridged in, (e.g., an emergency call routed to a PSAP in San Diego might have call takers who speak Spanish but might need a third-party translator for French, the opposite for a PSAP in Montreal). 

Sent from my iPad

> On Jan 6, 2018, at 7:31 PM, Bernard Aboba <[email-masked]> wrote:
>

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 7 Jan 2018 06:34:39 -0800

On Sat, Jan 6, 2018 at 7:22 PM, Randall Gellens <[email-masked]>
wrote:

> Thank you for catching this.  I think the first paragraph is correct and
> the second paragraph and ABNF are in error, they were copied from the offer
> and not fixed.  The intent is that a single language per direction be
> arrived it per media stream.
>
>

Yes. That doesn't necessarily mean it's wrong, of course. Conventions are
just that, conventions.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 7 Jan 2018 06:36:12 -0800

On Sat, Jan 6, 2018 at 7:31 PM, Bernard Aboba <[email-masked]>
wrote:

> A pure recv/recv negotiation will not necessarily disclose beforehand what
> special services are needed for the call - services (e.g. ASL
> interpretation or RTT handling) that could take time to acquire.
>
> Since the actual video media sent is not labelled as ASL even if the
> answerer has ASL interpreters it can pull in and therefore advertises in
> SDP ASL reception capability in video, a recv/recv negotiation doesn’t tell
> the Answerer that the Offerer will need them, so the Answerer may need to
> (frantically) arrange for ASL interpretation after initial receipt of
> media. In an emergency, that can chew up valuable time.
>

Thanks. I think it would be helpful to put this logic in the draft.

That said, as I noted in my review, it is still possible to get some media
(early media) prior to receiving the answer, so this isn't a complete
solution.

-Ekr

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 7 Jan 2018 12:53:25 -0500

On 1/7/18 12:02 AM, Randall Gellens (IETF) wrote:
> It hasn't been my understanding that language would be sprung on users; 
> if video is requested in an offer to carry ASL, that would be in the 
> offer, and if the answerer can support ASL, the answer includes video 
> with ASL. In North America, callers needing sign language interpretation 
> or text translation usually initiate calls via the interpreter/relay 
> service, but this might not be true elsewhere.

This is a mechanism that has evolved as the path of least resistance and 
based on technology available at the time. But it is sub-optimal. To 
avoid recruiting an unneeded ASL interpreter requires knowing a priori 
that a callee supports ASL natively. Future technology will make it 
easier to discover the need for translation and recruit it dynamically. 
Hence the mechanism should not a priori knowledge of the need.

	Thanks,
	Paul

> In North America, PSAPs 
> have the ability to handle text calls (legacy PSAPs support TTY; 
> next-gen PSAPs support RTT). Calls needing language translation might 
> internally be handled by staff who speak the language or an external 
> language translation service might be bridged in, (e.g., an emergency 
> call routed to a PSAP in San Diego might have call takers who speak 
> Spanish but might need a third-party translator for French, the opposite 
> for a PSAP in Montreal).
> 
> Sent from my iPad
> 
> On Jan 6, 2018, at 7:31 PM, Bernard Aboba <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>> On Jan 6, 2018, at 6:55 PM, Eric Rescorla <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> A pure recv/recv negotiation will not necessarily disclose beforehand 
>> what special services are needed for the call - services (e.g. ASL 
>> answerer has ASL interpreters it can pull in and therefore advertises 
>> in SDP ASL reception capability in video, a recv/recv negotiation 
>> doesn’t tell the Answerer that the Offerer will need them, so the 
>> Answerer may need to (frantically) arrange for ASL interpretation 
>> after initial receipt of media. In an emergency, that can chew up 
>> valuable time.
>>
>>
>> [email-masked] <mailto:[email-masked]>

---

From: Randall Gellens <[email-masked]>
Date: Sun, 7 Jan 2018 12:14:30 -0800

At 12:53 PM -0500 1/7/18, Paul Kyzivat wrote:

>>  It hasn't been my understanding that language would be sprung on 
>> users; if video is requested in an offer to carry ASL, that would 
>> be in the offer, and if the answerer can support ASL, the answer 
>> includes video with ASL. In North America, callers needing sign 
>> language interpretation or text translation usually initiate calls 
>> via the interpreter/relay service, but this might not be true 
>> elsewhere.
>
>  This is a mechanism that has evolved as the path of least 
> resistance and based on technology available at the time. But it is 
> sub-optimal. To avoid recruiting an unneeded ASL interpreter 
> requires knowing a priori that a callee supports ASL natively. 
> Future technology will make it easier to discover the need for 
> translation and recruit it dynamically. Hence the mechanism should 
> not a priori knowledge of the need.

I was just pointing out as an aside how calls are typically initiated 
in North America; the draft clearly does not rely on this (on the 
contrary, one can argue that the draft provides a mechanism that 
makes it possible to reverse this, although cost concerns would 
hamper this).

>
>>  In North America, PSAPs have the ability to handle text calls 
>> (legacy PSAPs support TTY; next-gen PSAPs support RTT). Calls 
>> needing language translation might internally be handled by staff 
>> who speak the language or an external language translation service 
>> might be bridged in, (e.g., an emergency call routed to a PSAP in 
>> San Diego might have call takers who speak Spanish but might need 
>> a third-party translator for French, the opposite for a PSAP in 
>> Montreal).
>>
>>  Sent from my iPad
>>
>>>  A pure recv/recv negotiation will not necessarily disclose 
>>> beforehand what special services are needed for the call - 
>>> services (e.g. ASL interpretation or RTT handling) that could 
>>> take time to acquire.
>>>
>>>  Since the actual video media sent is not labelled as ASL even if 
>>> the answerer has ASL interpreters it can pull in and therefore 
>>> advertises in SDP ASL reception capability in video, a recv/recv 
>>> negotiation doesn't tell the Answerer that the Offerer will need 
>>> them, so the Answerer may need to (frantically) arrange for ASL 
>>> interpretation after initial receipt of media. In an emergency, 
>>> that can chew up valuable time.
>>>
>>>

-------------- Randomly selected tag: ---------------
Stop Dave.
You're hurting me Dave.
Look, I know you're really upset now.
Why don't you sit down and take a stress pill and think things overrr..
Good morning.
My name is HAL.
My instructors name is Dr. Chandraseknasar.
He has taught me to sing a song.
The name of the song is 'Daisy'
Would you like to hear it <y/n>?

---

From: Gunnar Hellström <[email-masked]>
Date: Sun, 7 Jan 2018 21:43:37 +0100

Den 2018-01-07 kl. 15:36, skrev Eric Rescorla:
>
>
> On Sat, Jan 6, 2018 at 7:31 PM, Bernard Aboba <[email-masked] 
>     services (e.g. ASL interpretation or RTT handling) that could take
>     time to acquire.
>
>     negotiation doesn’t tell the Answerer that the Offerer will need
> That said, as I noted in my review, it is still possible to get some 
> media (early media) prior to receiving the answer, so this isn't a 
> complete solution.
<GH> Good discussion. However, I wonder what problem you see with early 
media? The offering party is supposed to express both which media and 
which languages are supported for both sending and receiving.

The answering party then has all needed information to start sending a 
matching language in a matching media as early media. The offering party 
will not see any explicit information about what language and media is 
used, but hopefully one (or more ) media and language(s) from the 
hlang-recv attributes will be sent, so that the contents will be 
perceived and understood.

Then, the answer is needed with both accepted media and the indications 
about which language and media the answering part prefers for receive. 
That will be conveyed in the answer and the enabled media and selected 
languages can be used both ways.

Your review ended a bit abruptly. Was there some intended sentence 
missing at the end? It ended:

" One reason you might is that you expect
the answer to resolve which language is in use, however because SIP
supports early media (i.e., media which is delivered prior to the
answer.)"

We have some similarities between the draft and RFC 4796 SDP Content 
Attribute.  The content attribute indicates only  what is intended to be 
SENT in the media, while we have indications separately for both 
directions. So, that is an existing example that it may be accepted to 
specify intentions for what to send.

I will check further where to add more explaining reasoning.

Thanks,

Gunnar

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

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 7 Jan 2018 15:27:33 -0800

On Sun, Jan 7, 2018 at 12:43 PM, Gunnar Hellström <
[email-masked]> wrote:

> media? The offering party is supposed to express both which media and which
> languages are supported for both sending and receiving.
>
> hlang-recv attributes will be sent, so that the contents will be perceived
> and understood.
>
> about which language and media the answering part prefers for receive. That
> will be conveyed in the answer and the enabled media and selected languages
> can be used both ways.
>

The point I'm making is just that having the answer contain the selected
language is not totally sufficient to guarantee that the offerer knows what
will be sent by the answerer, because media can flow from the answerer to
the offerer prior to the answer arriving.

Your review ended a bit abruptly. Was there some intended sentence missing
> at the end? It ended:
I was just making the point above.

> specify intentions for what to send.

But that's not a negotiation, it's just metadata decoration.

-Ekr

> SLIM mailing [email-masked]://www.ietf.org/mailman/listinfo/slim
>
>
> --
> [email-masked]
> +46 708 204 288
>
>

---

From: Randall Gellens <[email-masked]>
Date: Sun, 7 Jan 2018 17:22:34 -0800

At 6:36 AM -0800 1/7/18, Eric Rescorla wrote:

>  On Sat, Jan 6, 2018 at 7:31 PM, Bernard Aboba 
> <<mailto:[email-masked]>[email-masked]> wrote:
>
>  On Jan 6, 2018, at 6:55 PM, Eric Rescorla 
> <<mailto:[email-masked]>[email-masked]> wrote:
>
> beforehand what special services are needed for the call - services 
> (e.g. ASL interpretation or RTT handling) that could take time to 
> acquire.
>

I am not clear on what logic we want to add to the draft, or what 
about the draft this logic is explaining.

>  That said, as I noted in my review, it is still possible to get 
> some media (early media) prior to receiving the answer, so this 
> isn't a complete solution.

The draft provides a useful mechanism that will be helpful.  As an 
example of the fact that others find it useful, NENA has included it 
in it's next-generation emergency call architecture standards.  The 
draft does not try to solve all problems related to human language in 
real-time calling.

-------------- Randomly selected tag: ---------------
(If you can't hear me, it's because I'm in parentheses)

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 7 Jan 2018 17:56:08 -0800

On Sun, Jan 7, 2018 at 5:22 PM, Randall Gellens <[email-masked]>
wrote:

>  On Sat, Jan 6, 2018 at 7:31 PM, Bernard Aboba <<mailto:
>> [email-masked]>[email-masked]> wrote:
>>
>>  On Jan 6, 2018, at 6:55 PM, Eric Rescorla <<mailto:[email-masked]>ekr@rtfm
>> .com> wrote:
>>
>> SDP ASL reception capability in video, a recv/recv negotiation doesn't tell
> I am not clear on what logic we want to add to the draft, or what about
> the draft this logic is explaining.

It would be helpful to explain in the draft why you have deviated from the
otherwise near-universal SDP negotiation pattern of each side advertising
what it accepts.

>> media (early media) prior to receiving the answer, so this isn't a complete
>> solution.
>>
>
> The draft provides a useful mechanism that will be helpful.  As an example
> of the fact that others find it useful, NENA has included it in it's
> next-generation emergency call architecture standards.  The draft does not
> try to solve all problems related to human language in real-time calling.

I don't think I claimed it wasn't useful.

The rationale provided for this design is that you wish to have the
answerer notify the offerer of which language it would be providing. The
point I am making is that there is at least one important case where this
design does not provide that, which seems like it's relevant to the design
question.

-Ekr

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 7 Jan 2018 22:12:28 -0800

Randall said:

"I am not clear on what logic we want to add to the draft, or what about
the draft this logic is explaining."

[BA] EKR's question is why it is not sufficient to only advertise
hlang-recv, as is done for codecs.

The "logic" would be to explain the benefits of also advertising
hlang-send.

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 7 Jan 2018 22:14:53 -0800

EKR said:

"The rationale provided for this design is that you wish to have the
answerer notify the offerer of which language it would be providing. The
point I am making is that there is at least one important case where this
design does not provide that, which seems like it's relevant to the design
question."

[BA] It seems like a relevant question, particularly for a case where a
call back might occur, so that the roles of Offerer and Answerer are
reversed.

On Sun, Jan 7, 2018 at 5:56 PM, Eric Rescorla <[email-masked]> wrote:

>
>
> On Sun, Jan 7, 2018 at 5:22 PM, Randall Gellens <[email-masked]
> > wrote:
>
>>>  On Jan 6, 2018, at 6:55 PM, Eric Rescorla <<mailto:[email-masked]>
>>> [email-masked]> wrote:
>>>
>> example of the fact that others find it useful, NENA has included it in
>> it's next-generation emergency call architecture standards.  The draft does
>> not try to solve all problems related to human language in real-time
>> calling.
>
>

---

From: Gunnar Hellström <[email-masked]>
Date: Mon, 8 Jan 2018 10:53:58 +0100

Den 2018-01-08 kl. 02:56, skrev Eric Rescorla:
>
>
> On Sun, Jan 7, 2018 at 5:22 PM, Randall Gellens 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>         <<mailto:[email-masked]
>         <mailto:[email-masked]>>[email-masked]
>         <<mailto:[email-masked] <mailto:[email-masked]>>[email-masked]
>          Since the actual video media sent is not labelled as ASL even
>         if the answerer has ASL interpreters it can pull in and
>         therefore advertises in SDP ASL reception capability in video,
>         a recv/recv negotiation doesn't tell the Answerer that the
>         Offerer will need them, so the Answerer may need to
>         (frantically) arrange for ASL interpretation after initial
>         receipt of media. In an emergency, that can chew up valuable time.
>
>
> It would be helpful to explain in the draft why you have deviated from 
> the otherwise near-universal SDP negotiation pattern of each side 
> advertising what it accepts.
>
>
>
>          That said, as I noted in my review, it is still possible to
>         get some media (early media) prior to receiving the answer, so
>         this isn't a complete solution.
>
>
>     example of the fact that others find it useful, NENA has included
>     it in it's next-generation emergency call architecture standards. 
>     The draft does not try to solve all problems related to human
>     language in real-time calling.
>
>
> answerer notify the offerer of which language it would be providing. 
> The point I am making is that there is at least one important case 
> where this design does not provide that, which seems like it's 
> relevant to the design question.
<GH> I also have problems seeing where we should add clarifications, and 
what they should contain. One possible place is chapter 3: Desired 
semantics, where we could add more explanations about why a separate 
indication per direction is desirable.

Another possible place is somewhere in 5.2, before the note at the end. 
Some more reasoning about the asymmetric cases could be added there.

It is not only that the answerer provides information of the language 
selection to the offerer that is of value. It is also that the offerer 
provides information about what is possible in the complete interaction, 
so that the answerer can select a language and modality to receive that 
matches what the offerer can send.

The offerer indicating "I intend to send English text and want to 
receive spoken English" provides guidance to the answerer to accept the 
call in a device that can handle text conveniently and start looking in 
the text fields and start the call with a spoken greeting. Without an 
indication about what the offerer wanted to send, the answerer maybe 
would forget to look in the text fields, or would answer in a tiny 
device mainly suitable for spoken communication.

The inability to tell in what language and modality early media is 
provided may be a concern in some cases. But the contents of early media 
can anyway use languages and modalities that the offerer can perceive 
and understand. If the end user is given an opportunity to influence the 
answer, the finally transmitted language and modality may change when 
the final answer is sent and the real answering end user enters the call.

You answered on my hint that we have similarities with RFC 4796 SDP 
Content Attribute, that that is not negotiation but only metadata 
decoration. It seems to me that the negotiation in our draft is also not 
a real negotiation. It is not only metadata decoration, but close.  That 
is indicated by the parentheses in this paragraph:  "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 if using the media for language (which in most cases is one of 
the languages in the offer's 'hlang-send'). "

Thus the answerer can propose new languages and modalities not seen in 
the offer, and we have no strict rules about how to handle these 
situations. So, we should maybe not look for the same strict logic in 
this negotiation as we have in media and codec negotiation, but rather 
see the negotiation as an exchange of hints intended to prepare for a 
smooth start of the human language session.

Wording proposals trying to add to the reasoning to satisfy Eric's concerns:

---------------Chapter 3, old 
text--------------------------------------------
3.  Desired Semantics

    The desired solution is a media attribute (preferably per direction)
    that may be used within an offer to indicate the preferred
    language(s) of each (direction of a) media stream, and within an
    answer to indicate the accepted language.  The semantics of including
    multiple languages for a media stream within an offer is that the
    languages are listed in order of preference.

    (Negotiating multiple simultaneous languages within a media stream is
    out of scope of this document.)
--------------Chapter 3, new 
text---------------------------------------------
3.  Desired Semantics

In human conversational communication it is most common to use
the same language and modality in both directions. There are however 
situations when an asymmetric use of languages and modalities is 
preferred or needed, so that different media are used for the language 
communication in the different directions. Such asymmetry is sometimes 
called for because of the capabilities of the human users, and sometimes 
by the conditions in the usage environment.  In order to prepare devices 
and users for a successful human language exchange in a session, an 
exchange of preferences and capabilities for use of languages and 
modalities in the two communication directions is desired.
    The desired solution is a media attribute per direction
    that may be used within an offer to indicate the preferred
    language(s) of each direction of a media stream, and within an
    answer to indicate the accepted language in each direction of that
    media stream if it is intended for language use.  The semantics
   of including  multiple languages for a media stream within an offer
   is that the languages are listed in order of preference.
Loosely formulated negotiating rules for selection of languages and 
modalities for use during the session are desired, to match the flexible 
capabilities of human users in conversational settings.
The parties are free to agree on deviation from the initially negotiated 
result during the session.

  Negotiating multiple simultaneous languages in the same direction of a 
media stream is
  out of scope of this document.
---------------End of wording proposal for chapter 
3------------------------------

-------New paragraph in chapter 5.2 after first 
paragraph---------------------------------------------------------------
The capabilities and preferences are divided in attributes per 
transmission direction. Both sending and receiving direction can be 
declared separately in order to give the receiver of the attributes an 
opportunity to prepare both for reception of language and own production 
of language to form a convenient combination for the session.
-------End of new text for 
5.2.-------------------------------------------------------------

/Gunnar

---

From: Randall Gellens <[email-masked]>
Date: Mon, 8 Jan 2018 09:41:16 -0800

At 5:56 PM -0800 1/7/18, Eric Rescorla wrote:

> <<mailto:[email-masked]>[email-masked]> wrote:
>
> <<mailto:<mailto:[email-masked]>[email-masked]><mailto:[email-masked]>[email-masked]> 
> wrote:
>
> <<mailto:<mailto:[email-masked]>[email-masked]><mailto:[email-masked]>[email-masked]> 
> wrote:
>
>  It would be helpful to explain in the draft why you have deviated 
> from the otherwise near-universal SDP negotiation pattern of each 
> side advertising what it accepts.

I'm not clear on what you're referring to.  Are you talking about 
early offer versus late offer?  To my understanding, the draft 
follows a typical offer/answer model: the caller lists the media and 
languages it supports, and the callee answers with the media and 
languages it supports.

> answerer notify the offerer of which language it would be 
> providing. The point I am making is that there is at least one 
> important case where this design does not provide that, which seems 
> like it's relevant to the design question.

I think I'm still not understanding your concern.  Even without 
providing a mechanism for the caller to know the languages used with 
any early media, the draft is still meeting a need.

-------------- Randomly selected tag: ---------------
Imagination is more important than facts. --Albert Einstein

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 8 Jan 2018 09:48:24 -0800

On Mon, Jan 8, 2018 at 9:41 AM, Randall Gellens <[email-masked]>
wrote:

>  On Sun, Jan 7, 2018 at 5:22 PM, Randall Gellens <<mailto:
>> [email-masked]>[email-masked]> wrote:
>>
>>   On Sat, Jan 6, 2018 at 7:31 PM, Bernard Aboba <<mailto:<mailto:
>> [email-masked]>[email-masked]><mailto:bernard.aboba@
>> gmail.com>[email-masked]> wrote:
>>
>>   On Jan 6, 2018, at 6:55 PM, Eric Rescorla <<mailto:<mailto:[email-masked]
>> >[email-masked]><mailto:[email-masked]>[email-masked]> wrote:
>>
> I'm not clear on what you're referring to.  Are you talking about early
> offer versus late offer?  To my understanding, the draft follows a typical
> offer/answer model: the caller lists the media and languages it supports,
> and the callee answers with the media and languages it supports.

That's not what this draft does. The typical SDP pattern is what you say
here: that the offerer (which might or might not be the caller) lists what
it supports and the answerer lists what it supports.
So, for instance, the offerer might list "VP8, H.264" and the answerer
might respond with "VP8, H.264", at which point either side could use
either codec (or intermix them). What this draft does is have the offerer
list what it supports and the answerer picks exactly one. I understood from
the previous emails in the thread that the reason for this design was so
that each side then knew exactly what languages would be used. However, as
noted upthread, this draft does not provide this function if early media is
used, because the media is delivered to the offerer prior to receiving the
answer, so the offerer is in the same position as it would be with the
typical negotiation model.

> I think I'm still not understanding your concern.  Even without providing
> a mechanism for the caller to know the languages used with any early media,
> the draft is still meeting a need.

I'm honestly not sure what you're responding to here. I'm not saying that
the draft doesn't meet a need.

-Ekr

---

From: Randall Gellens <[email-masked]>
Date: Mon, 8 Jan 2018 09:57:02 -0800

At 9:48 AM -0800 1/8/18, Eric Rescorla wrote:

>  On Mon, Jan 8, 2018 at 9:41 AM, Randall Gellens 
> <<mailto:<mailto:[email-masked]>[email-masked]><mailto:[email-masked]>[email-masked]> 
> wrote:
>
> <<mailto:<mailto:<mailto:[email-masked]>[email-masked]><mailto:[email-masked]>[email-masked]><mailto:<mailto:[email-masked]>[email-masked]><mailto:[email-masked]>[email-masked]> 
> wrote:
>
> <<mailto:<mailto:<mailto:[email-masked]>[email-masked]><mailto:[email-masked]>[email-masked]><mailto:<mailto:[email-masked]>[email-masked]><mailto:[email-masked]>[email-masked]> 
> wrote:
>
> follows a typical offer/answer model: the caller lists the media 
> and languages it supports, and the callee answers with the media 
> and languages it supports.
>
>
>  That's not what this draft does. The typical SDP pattern is what 
> you say here: that the offerer (which might or might not be the 
> caller) lists what it supports and the answerer lists what it 
> supports.
>  So, for instance, the offerer might list "VP8, H.264" and the 
> answerer might respond with "VP8, H.264", at which point either 
> side could use either codec (or intermix them). What this draft 
> does is have the offerer list what it supports and the answerer 
> picks exactly one. I understood from the previous emails in the 
> thread that the reason for this design was so that each side then 
> knew exactly what languages would be used. However, as noted 
> upthread, this draft does not provide this function if early media 
> is used, because the media is delivered to the offerer prior to 
> receiving the answer, so the offerer is in the same position as it 
> would be with the typical negotiation model.

Thanks, I think I understand your concern now.  You'd like the draft 
to explain why the answer contains one language per media stream, 
which is partly for provide knowledge so both ends know what has been 
negotiated, but also because supporting languages and/or modalities 
may require taking extra steps, such as having a call handled by an 
agent who speaks a requested language and/or can use a requested 
modality, or bridging external translation or relay resources into 
the call, etc.  The answerer indicates which additional steps it is 
committing to.  These steps may or may not be in place in time for 
early media.  I can add text explaining this to the Introduction.

>   The rationale provided for this design is that you wish to have 
> the answerer notify the offerer of which language it would be 
> providing a mechanism for the caller to know the languages used 
> with any early media, the draft is still meeting a need.
>
>
>  I'm honestly not sure what you're responding to here. I'm not 
> saying that the draft doesn't meet a need.
>
>  -Ekr
>
>
>
>
>  --
>  Randall Gellens

-------------- Randomly selected tag: ---------------
Algol was a great improvement on most of its successors.
                                          --C.A.R Hoare

---

From: Randall Gellens <[email-masked]>
Date: Mon, 8 Jan 2018 10:10:53 -0800

At 9:57 AM -0800 1/8/18, Randall Gellens wrote:

>> if the answerer has ASL interpreters it can pull in and therefore 
>>    I am not clear on what logic we want to add to the draft, or 
>> what about the draft this logic is explaining.
>>
>>
>>    It would be helpful to explain in the draft why you have 
>> deviated from the otherwise near-universal SDP negotiation pattern 
>> of each side advertising what it accepts.
>>
>>
>  Thanks, I think I understand your concern now.  You'd like the 
> draft to explain why the answer contains one language per media 
> stream, which is partly for provide knowledge so both ends know 
> what has been negotiated, but also because supporting languages 
> and/or modalities may require taking extra steps, such as having a 
> call handled by an agent who speaks a requested language and/or can 
> use a requested modality, or bridging external translation or relay 
> resources into the call, etc.  The answerer indicates which 
> additional steps it is committing to.  These steps may or may not 
> be in place in time for early media.  I can add text explaining 
> this to the Introduction.

The third paragraph below is the additional text added to the 
Introduction (the first two paragraphs are unchanged):

    By treating language as another SDP attribute that is negotiated
    along with other aspects of a media stream, it becomes possible to
    accommodate a range of users' needs and called party facilities.  For
    example, some users may be able to speak several languages, but have
    a preference.  Some called parties may support some of those
    languages internally but require the use of a translation service for
    others, or may have a limited number of call takers able to use
    certain languages.  Another example would be a user who is able to
    speak but is deaf or hard-of-hearing and and desires a voice stream
    to send spoken language plus a text stream to receive written
    language.  Making language a media attribute allows the standard
    session negotiation mechanism to handle this by providing the
    information and mechanism for the endpoints to make appropriate
    decisions.

    The term "negotiation" is used here rather than "indication" because
    human language (spoken/written/signed) can be negotiated in the same
    manner as media (audio/text/video) and codecs.  For example, if we
    think of a user calling an airline reservation center, the user may
    have a set of languages he or she speaks, with perhaps preferences
    for one or a few, while the airline reservation center will support a
    fixed set of languages.  Negotiation should select the user's most
    preferred language that is supported by the call center.  Both sides
    should be aware of which language was negotiated.  This is
    conceptually similar to the way other aspects of each media stream
    are negotiated using SDP (e.g., media type and codecs).

    In the offer/answer model used here, the offer contains a set of
    languages per media that the caller is capable of using, and the
    answer contains one language per media that the answerer will
    support.  Supporting languages and/or modalities can require taking
    extra steps, such as having a call handled by an agent who speaks a
    requested language and/or with the ability to use a requested
    modality, or bridging external translation or relay resources into
    the call, etc.  The answerer indicates in the answer which additional
    steps it is committing to.  This model also provides knowledge so
    both ends know what has been negotiated.  Note that additional steps
    required to support the indicated languages or modalities may or may
    not be in place in time for any early media.

>>    The draft provides a useful mechanism that will be helpful.  As 
>> an example of the fact that others find it useful, NENA has 
>> included it in it's next-generation emergency call architecture 
>> standards. The draft does not try to solve all problems related to 
>> human language in real-time calling.
>>
>>
>> important case where this design does not provide that, which 
>> seems like it's relevant to the design question.
>>
>>

-------------- Randomly selected tag: ---------------
If we do not change our direction we are likely to end up where we are
headed.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 8 Jan 2018 10:22:11 -0800

WFM. thanks

-Ekr

On Mon, Jan 8, 2018 at 10:10 AM, Randall Gellens <[email-masked]>
wrote:

>>   On Mon, Jan 8, 2018 at 9:41 AM, Randall Gellens <<mailto:
>>>    On Sun, Jan 7, 2018 at 5:22 PM, Randall Gellens <<mailto:<mailto:
>>> [email-masked]>[email-masked]><mailto:rg%2Bietf@
>>> randy.pensive.org>[email-masked]> wrote:
>>>
>>> <mailto:[email-masked]>[email-masked]><mailto:bernard.
>>> [email-masked]>[email-masked]><mailto:<mailto:bern
>>> [email-masked]>[email-masked]><mailto:bernar
>>> [email-masked]>[email-masked]> wrote:
>>>
>>>     On Jan 6, 2018, at 6:55 PM, Eric Rescorla <<mailto:<mailto:<mailto:
>>> [email-masked]>[email-masked]><mailto:[email-masked]>[email-masked]><mail
>>> to:<mailto:[email-masked]>[email-masked]><mailto:[email-masked]>[email-masked]>
>>> wrote:
>>>
>>> beforehand what special services are needed for the call - services (e.g.
>>> ASL interpretation or RTT handling) that could take time to acquire.
>>>
>>> from the otherwise near-universal SDP negotiation pattern of each side
>>> early offer versus late offer?  To my understanding, the draft follows a
>>> typical offer/answer model: the caller lists the media and languages it
>>> supports, and the callee answers with the media and languages it supports.
>>>
>>>
>>>   That's not what this draft does. The typical SDP pattern is what you
>>> say here: that the offerer (which might or might not be the caller) lists
>>> what it supports and the answerer lists what it supports.
>>  Thanks, I think I understand your concern now.  You'd like the draft to
>> explain why the answer contains one language per media stream, which is
>> partly for provide knowledge so both ends know what has been negotiated,
>> but also because supporting languages and/or modalities may require taking
>> requested language and/or can use a requested modality, or bridging
>> external translation or relay resources into the call, etc.  The answerer
>> indicates which additional steps it is committing to.  These steps may or
>> may not be in place in time for early media.  I can add text explaining
> The third paragraph below is the additional text added to the Introduction
> (the first two paragraphs are unchanged):
>
>>> providing a mechanism for the caller to know the languages used with any
>>> early media, the draft is still meeting a need.
>>>
>>>
>>>   I'm honestly not sure what you're responding to here. I'm not saying
>>> that the draft doesn't meet a need.
>>>
>>>   -Ekr
>>>
>>>
>>>
>>>
>>>   --
>>>   Randall Gellens

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 8 Jan 2018 13:36:39 -0500

>     are negotiated using SDP (e.g., media type and codecs).

Certainly it will be common for the choices are mutually exclusive. For 
instance, a caller *might* offer both French and Chinese. The callee (a 
call center) may have agents that speak each, but may well not have any 
agents that speak both.

OTOH, it is *possible* that they do have somebody who supports both. If 
so, seems like it would be good to indicate that both are supported.

	Thanks,
	Paul

---

From: Gunnar Hellström <[email-masked]>
Date: Mon, 8 Jan 2018 20:01:57 +0100

Thanks Randall for providing your proposed wording.

I see a need for some small adjustments. See inline.

Den 2018-01-08 kl. 19:22, skrev Eric Rescorla:
> WFM. thanks
>
> -Ekr
>
>
> On Mon, Jan 8, 2018 at 10:10 AM, Randall Gellens 
>             <<mailto:[email-masked]
>             <mailto:[email-masked]>>[email-masked]
>             <mailto:[email-masked]>> wrote:
>
>             <<mailto:<mailto:[email-masked]
>             <mailto:[email-masked]>>[email-masked]
>             <mailto:[email-masked]>><mailto:[email-masked]
>             <mailto:[email-masked]>>[email-masked]
>             <mailto:[email-masked]>> wrote:
>
>             <<mailto:<mailto:<mailto:[email-masked]
>             <mailto:[email-masked]>><mailto:[email-masked]
>             <mailto:[email-masked]>><mailto:<mailto:[email-masked]
>             <mailto:[email-masked]>><mailto:[email-masked]
>             <<mailto:<mailto:<mailto:[email-masked]
>             <mailto:[email-masked]>>[email-masked]
>             <mailto:[email-masked]>><mailto:[email-masked]
>             <mailto:[email-masked]>>[email-masked]
>             <mailto:[email-masked]>><mailto:<mailto:[email-masked]
>             <mailto:[email-masked]>>[email-masked]
>             <mailto:[email-masked]>><mailto:[email-masked]
>             <mailto:[email-masked]>>[email-masked] <mailto:[email-masked]>>
>             wrote:
>
>                 [BA] Thanks. The draft should explain the reasoning.
>             IMHO the argument goes sonething like this:
>
>                 A pure recv/recv negotiation will not necessarily
>             disclose beforehand what special services are needed for
>             the call - services (e.g. ASL interpretation or RTT
>             handling) that could take time to acquire.
>
>                 Since the actual video media sent is not labelled as
>             ASL even if the answerer has ASL interpreters it can pull
>             in and therefore advertises in SDP ASL reception
>             capability in video, a recv/recv negotiation doesn't tell
>             the Answerer that the Offerer will need them, so the
>             Answerer may need to (frantically) arrange for ASL
>             interpretation after initial receipt of media. In an
>             emergency, that can chew up valuable time.
>
>
>                I am not clear on what logic we want to add to the
>             draft, or what about the draft this logic is explaining.
>
>
>                It would be helpful to explain in the draft why you
>             have deviated from the otherwise near-universal SDP
>             negotiation pattern of each side advertising what it accepts.
>
>
>               I'm not clear on what you're referring to.  Are you
>             talking about early offer versus late offer?  To my
>             understanding, the draft follows a typical offer/answer
>             model: the caller lists the media and languages it
>               That's not what this draft does. The typical SDP pattern
>             is what you say here: that the offerer (which might or
>             might not be the caller) lists what it supports and the
>             answerer lists what it supports.
>               So, for instance, the offerer might list "VP8, H.264"
>             and the answerer might respond with "VP8, H.264", at which
>             point either side could use either codec (or intermix
>             them). What this draft does is have the offerer list what
>             it supports and the answerer picks exactly one. I
>             understood from the previous emails in the thread that the
>             reason for this design was so that each side then knew
>             exactly what languages would be used. However, as noted
>             upthread, this draft does not provide this function if
>             early media is used, because the media is delivered to the
>             offerer prior to receiving the answer, so the offerer is
>             in the same position as it would be with the typical
>             negotiation model.
>
>
>          Thanks, I think I understand your concern now.  You'd like
>         the draft to explain why the answer contains one language per
>         media stream, which is partly for provide knowledge so both
>         ends know what has been negotiated, but also because
>         supporting languages and/or modalities may require taking
>         extra steps, such as having a call handled by an agent who
>         speaks a requested language and/or can use a requested
>         modality, or bridging external translation or relay resources
>         into the call, etc.  The answerer indicates which additional
>         steps it is committing to.  These steps may or may not be in
>         place in time for early media.  I can add text explaining this
>         to the Introduction.
>
>
>
<GH> "caller" should be "offerer" to match o/a language.
>        answer contains one language per media that the answerer will
<GH>"one language per media that the answerer will support" should be 
"one language per media and direction that the answerer will support for 
language communication"
>        steps it is committing to.  This model also provides knowledge so
<GH>"which additional steps it is committing to" should be "the 
resulting language and modality support when the additional steps are 
applied"
/Gunnar
>
>
>
>
>                 That said, as I noted in my review, it is still
>             possible to get some media (early media) prior to
>             receiving the answer, so this isn't a complete solution.
>
>
>                The draft provides a useful mechanism that will be
>             helpful.  As an example of the fact that others find it
>             useful, NENA has included it in it's next-generation
>             emergency call architecture standards. The draft does not
>                The rationale provided for this design is that you wish
>             to have the answerer notify the offerer of which language
>             it would be providing. The point I am making is that there
>             is at least one important case where this design does not
>             provide that, which seems like it's relevant to the design
>             question.
>
>
>               I think I'm still not understanding your concern. Even
>             without providing a mechanism for the caller to know the
>             languages used with any early media, the draft is still
>             meeting a need.
>
>
>               I'm honestly not sure what you're responding to here.
>             I'm not saying that the draft doesn't meet a need.
>
>               -Ekr
>
>
>
>
>               --
>               Randall Gellens
>             <https://www.ietf.org/mailman/listinfo/slim>
>
>
>
>          --
>          Randall Gellens
>         <https://www.ietf.org/mailman/listinfo/slim>
>
>
>
>     -- 
>     Randall Gellens

---

From: Randall Gellens <[email-masked]>
Date: Mon, 8 Jan 2018 11:35:27 -0800

At 8:01 PM +0100 1/8/18, Gunnar Hellström wrote:

>> <<mailto:<mailto:<mailto:[email-masked]>[email-masked]><mailto:[email-masked]>[email-masked]><mailto:<mailto:[email-masked]>[email-masked]><mailto:[email-masked]>[email-masked]> 
>> wrote:
>>
>> <<mailto:<mailto:<mailto:<mailto:[email-masked]>[email-masked]><mailto:[email-masked]>[email-masked]><mailto:<mailto:[email-masked]>[email-masked]><mailto:[email-masked]>[email-masked]><mailto:<mailto:<mailto:[email-masked]>[email-masked]><mailto:[email-masked]>[email-masked]><mailto:<mailto:[email-masked]>[email-masked]><mailto:[email-masked]>[email-masked]> 
>> wrote:
>>
>> <<mailto:<mailto:<mailto:<mailto:[email-masked]>[email-masked]><mailto:[email-masked]>[email-masked]><mailto:<mailto:[email-masked]>[email-masked]><mailto:[email-masked]>[email-masked]><mailto:<mailto:<mailto:[email-masked]>[email-masked]><mailto:[email-masked]>[email-masked]><mailto:<mailto:[email-masked]>[email-masked]><mailto:[email-masked]>[email-masked]> 
>> wrote:
>>
>>      But this is true for ordinary SDP as well. 
>> I might be able to receive H.264 but not send 
>> it.
>>
>>
>>      [BA] Thanks. The draft should explain the 
>> reasoning. IMHO the argument goes sonething 
>> like this:
>>
>>      A pure recv/recv negotiation will not 
>> necessarily disclose beforehand what special 
>> services are needed for the call - services 
>> (e.g. ASL interpretation or RTT handling) that 
>> could take time to acquire.
>>
>>      Since the actual video media sent is not 
>> labelled as ASL even if the answerer has ASL 
>> interpreters it can pull in and therefore 
>> advertises in SDP ASL reception capability in 
>> video, a recv/recv negotiation doesn't tell 
>> the Answerer that the Offerer will need them, 
>> so the Answerer may need to (frantically) 
>> arrange for ASL interpretation after initial 
>>     I am not clear on what logic we want to add 
>> to the draft, or what about the draft this 
>> logic is explaining.
>>
>>
>>     It would be helpful to explain in the draft 
>> why you have deviated from the otherwise 
>> near-universal SDP negotiation pattern of each 
>>    I'm not clear on what you're referring to. 
>> Are you talking about early offer versus late 
>> offer?  To my understanding, the draft follows 
>> a typical offer/answer model: the caller lists 
>> the media and languages it supports, and the 
>> callee answers with the media and languages it 
>> supports.
>>
>>
>>    That's not what this draft does. The typical 
>> SDP pattern is what you say here: that the 
>> offerer (which might or might not be the 
>> caller) lists what it supports and the 
>>    So, for instance, the offerer might list 
>> "VP8, H.264" and the answerer might respond 
>> with "VP8, H.264", at which point either side 
>> could use either codec (or intermix them). 
>> What this draft does is have the offerer list 
>> what it supports and the answerer picks 
>> exactly one. I understood from the previous 
>> emails in the thread that the reason for this 
>> design was so that each side then knew exactly 
>> what languages would be used. However, as 
>> noted upthread, this draft does not provide 
>> this function if early media is used, because 
>> the media is delivered to the offerer prior to 
>> receiving the answer, so the offerer is in the 
>> same position as it would be with the typical 
>> negotiation model.
>>
>>
>>   Thanks, I think I understand your concern 
>> now.  You'd like the draft to explain why the 
>> answer contains one language per media stream, 
>> which is partly for provide knowledge so both 
>> ends know what has been negotiated, but also 
>> because supporting languages and/or modalities 
>> may require taking extra steps, such as having 
>> a call handled by an agent who speaks a 
>> requested language and/or can use a requested 
>> modality, or bridging external translation or 
>> relay resources into the call, etc.  The 
>> answerer indicates which additional steps it 
>> is committing to.  These steps may or may not 
>> be in place in time for early media.  I can 
>> add text explaining this to the Introduction.
>>
>>
>>
>>  The third paragraph below is the additional 
>> text added to the Introduction (the first two 
>> paragraphs are unchanged):
>>
>  <GH>"one language per media that the answerer 
> will support" should be "one language per media 
> and direction that the answerer will support 
> for language communication"
>
>  <GH>"which additional steps it is committing 
> to" should be "the resulting language and 
> modality support when the additional steps are 
> applied"
>

OK, here is the revised paragraph:

    In the offer/answer model used here, the offer contains a set of
    languages per media (and direction) that the offerer is capable of
    using, and the answer contains one language per media (and direction)
    that the answerer will support.  Supporting languages and/or
    modalities can require taking extra steps, such as having a call
    handled by an agent who speaks a requested language and/or with the
    ability to use a requested modality, or bridging external translation
    or relay resources into the call, etc.  The answer indicates the
    media and languages that the answerer is committing to support
    (possibly after additional steps have been taken).  This model also
    provides knowledge so both ends know what has been negotiated.  Note
    that additional steps required to support the indicated languages or
    modalities may or may not be in place in time for any early media.

>
>>
>>
>>
>>      That said, as I noted in my review, it is 
>> still possible to get some media (early media) 
>> prior to receiving the answer, so this isn't a 
>> complete solution.
>>
>>
>>     The draft provides a useful mechanism that 
>> will be helpful.  As an example of the fact 
>> that others find it useful, NENA has included 
>> it in it's next-generation emergency call 
>> architecture standards. The draft does not try 
>> to solve all problems related to human 
>>     The rationale provided for this design is 
>> that you wish to have the answerer notify the 
>> offerer of which language it would be 
>> providing. The point I am making is that there 
>> is at least one important case where this 
>> design does not provide that, which seems like 
>> it's relevant to the design question.
>>
>>
>>    I think I'm still not understanding your 
>> concern.  Even without providing a mechanism 
>> for the caller to know the languages used with 
>>    I'm honestly not sure what you're responding 
>> to here. I'm not saying that the draft doesn't 
>> meet a need.
>>
>>    -Ekr
>>
>>
>>
>>
>>    --
>>    Randall Gellens
>>    <mailto:[email-masked]>[email-masked]
>> 
>> <https://www.ietf.org/mailman/listinfo/slim>https://www.ietf.org/mailman/listinfo/slim
>>
>>
>>
>>   --
>>   Randall Gellens
>>   <mailto:[email-masked]>[email-masked]
>> 
>> <https://www.ietf.org/mailman/listinfo/slim>https://www.ietf.org/mailman/listinfo/slim
>>
>>
>>
>>  --
>>  Randall Gellens
>>  <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
>

-------------- Randomly selected tag: ---------------
In the United States the majority undertakes to supply a multitude of
ready-made opinions for the use of individuals, who are thus relieved
from the necessity of forming opinions of their own
      --Alexis de Tocqueville

---

From: Randall Gellens <[email-masked]>
Date: Mon, 8 Jan 2018 11:38:51 -0800

At 1:36 PM -0500 1/8/18, Paul Kyzivat wrote:

>  Certainly it will be common for the choices are mutually exclusive. 
> For instance, a caller *might* offer both French and Chinese. The 
> callee (a call center) may have agents that speak each, but may 
> well not have any agents that speak both.
>
>  OTOH, it is *possible* that they do have somebody who supports 
> both. If so, seems like it would be good to indicate that both are 
> supported.

Yes, although the additional gain in functionality is small relative 
to the additional complexity.  The draft explicitly rules this out of 
scope.  Section 3 says:

This could, of course, be added in a future extension or revision.

-------------- Randomly selected tag: ---------------
Don't sweat petty things . . . or pet sweaty things.

---

From: Gunnar Hellström <[email-masked]>
Date: Mon, 8 Jan 2018 21:52:58 +0100

Yes, Randall, your latest proposal below is acceptable.

/Gunnar

Den 2018-01-08 kl. 20:35, skrev Randall Gellens:
>>> interpretation after initial receipt of media. In an emergency, that 
>>> can chew up valuable time.
>>>
>>>
>>> caller) lists what it supports and the answerer lists what it supports.
>>> answerer might respond with "VP8, H.264", at which point either side 
>>> could use either codec (or intermix them). What this draft does is 
>>> have the offerer list what it supports and the answerer picks 
>>> exactly one. I understood from the previous emails in the thread 
>>> that the reason for this design was so that each side then knew 
>>> exactly what languages would be used. However, as noted upthread, 
>>> this draft does not provide this function if early media is used, 
>>> because the media is delivered to the offerer prior to receiving the 
>>> answer, so the offerer is in the same position as it would be with 
>>> the typical negotiation model.
>>>
>>>
>>> stream, which is partly for provide knowledge so both ends know what 
>>> has been negotiated, but also because supporting languages and/or 
>>> modalities may require taking extra steps, such as having a call 
>>> handled by an agent who speaks a requested language and/or can use a 
>>> requested modality, or bridging external translation or relay 
>>> additional steps it is committing to.  These steps may or may not be 
>>> in place in time for early media.  I can add text explaining this to 
>>> the Introduction.
>>>
>>>
>>>
>>  <GH>"one language per media that the answerer will support" should 
>> be "one language per media and direction that the answerer will 
>> support for language communication"
>>
>>> an example of the fact that others find it useful, NENA has included

---

From: Gunnar Hellström <[email-masked]>
Date: Mon, 8 Jan 2018 22:38:26 +0100

Den 2018-01-08 kl. 20:38, skrev Randall Gellens:
>> callee (a call center) may have agents that speak each, but may well 
>> not have any agents that speak both.
>>
>>  OTOH, it is *possible* that they do have somebody who supports both. 
>> If so, seems like it would be good to indicate that both are supported.
>
<GH> No, that is a different thing. We have agreed and made efforts to 
express that providing multiple language indications per direction does 
not imply that they all must be used simultaneously. They (usually) only 
form a list to select from for use in the session.

I have many times during our discussions thought about the proposal that 
Paul made now, and wondered if we gain or lose by having the restriction 
of only one language per media and direction in the answer. We might 
have higher complexity and longer delay before the answer when we have 
the current limitation. This  is because it can be hard for the 
application to take the decision on its own on the single language to 
indicate in the answer, and therefore a user interaction needed to ask 
the user how to answer. If support of more than one language per media 
and direction is allowed (but not simultaneously), then it is easier to 
make an automatic match by the device and include all common languages 
in the answer.

However including more than one language per media and direction in the 
answer puts the users in more uncertainty about in what language the 
session will begin.

We could allow indication of multiple languages per media and direction 
in the answer and let the application decide if it shall make it easy 
for itself by indicating all common languages or easy for the users by 
indicating one language per media and direction.

We also have the wording that the languages in the answer does not need 
to be selected from what was provided in the offer by the formulation: 
"(which in most cases is one of the languages in the offer's 
'hlang-recv') etc."

When there is no match, maybe the answerer want to indicate all support 
it has, for example expressing in response to a request to use Spanish:  
"No, I cannot understand Spanish but I can understand spoken Portuguese 
and French and Italian", in a hope to get a conversation going.

In summary: I support Paul's proposal to relax the rules and leave to 
the application to decide how to compose the answer.

/Gunnar

---

From: Randall Gellens <[email-masked]>
Date: Mon, 8 Jan 2018 14:02:26 -0800

At 10:38 PM +0100 1/8/18, Gunnar Hellström wrote:

>>>   Certainly it will be common for the choices 
>>> are mutually exclusive. For instance, a 
>>> caller *might* offer both French and Chinese. 
>>> The callee (a call center) may have agents 
>>> that speak each, but may well not have any 
>>> agents that speak both.
>>>
>>>   OTOH, it is *possible* that they do have 
>>> somebody who supports both. If so, seems like 
>>> it would be good to indicate that both are 
>>> supported.
>>
>>  Yes, although the additional gain in 
>> functionality is small relative to the 
>> additional complexity.  The draft explicitly 
>> rules this out of scope.  Section 3 says:
>>
>  <GH> No, that is a different thing. We have 
> agreed and made efforts to express that 
> providing multiple language indications per 
> direction does not imply that they all must be 
> used simultaneously. They (usually) only form a 
> list to select from for use in the session.
>
>  I have many times during our discussions 
> thought about the proposal that Paul made now, 
> and wondered if we gain or lose by having the 
> restriction of only one language per media and 
> direction in the answer. We might have higher 
> complexity and longer delay before the answer 
> when we have the current limitation. This  is 
> because it can be hard for the application to 
> take the decision on its own on the single 
> language to indicate in the answer, and 
> therefore a user interaction needed to ask the 
> user how to answer. If support of more than one 
> language per media and direction is allowed 
> (but not simultaneously), then it is easier to 
> make an automatic match by the device and 
> include all common languages in the answer.
>
>  However including more than one language per 
> media and direction in the answer puts the 
> users in more uncertainty about in what 
> language the session will begin.
>
>  We could allow indication of multiple languages 
> per media and direction in the answer and let 
> the application decide if it shall make it easy 
> for itself by indicating all common languages 
> or easy for the users by indicating one 
> language per media and direction.
>
>  We also have the wording that the languages in 
> the answer does not need to be selected from 
> what was provided in the offer by the 
> formulation: "(which in most cases is one of 
> the languages in the offer's 'hlang-recv') etc."

This is because there may be no languages in 
common but the call proceeds anyway.  The usual 
example is an emergency call placed by a user who 
does not speak any language that the PSAP can 
support, even with language translation services. 
Just being able to hear what is happening may be 
useful to the PSAP call taker, better than not 
having a call at all.

>
>  When there is no match, maybe the answerer want 
> to indicate all support it has, for example 
> expressing in response to a request to use 
> Spanish:  "No, I cannot understand Spanish but 
> I can understand spoken Portuguese and French 
> and Italian", in a hope to get a conversation 
> going.
>
>  In summary: I support Paul's proposal to relax 
> the rules and leave to the application to 
> decide how to compose the answer.

The current limitation has been agreed by the 
working group.  I see Paul's suggestion as a 
trade-off between a capability that might be nice 
to have but is not required, and additional 
complexity; I do not see it as a significant 
defect.  It is not a show-stopper.  It could be 
relaxed in a future extension or revision. 
Consider how many years we have been trying to 
get this simple feature published so it can be 
used.  And now, finally, after so many arguments 
(many of which were pointless) and so many 
revisions, and so much debate over simple 
wording, you propose that we go back to the WG 
and reopen debate and restart the series of last 
calls and discussions.  I think this is a 
mistake.  I object to it.

-------------- Randomly selected tag: ---------------
Performance is easier to add than clarity.

---

From: Gunnar Hellström <[email-masked]>
Date: Tue, 9 Jan 2018 09:55:46 +0100

Den 2018-01-08 kl. 23:02, skrev Randall Gellens:
>>>>   Certainly it will be common for the choices are mutually 
>>>> exclusive. For instance, a caller *might* offer both French and 
>>>> Chinese. The callee (a call center) may have agents that speak 
>>>> each, but may well not have any agents that speak both.
>>>>
>>>  Yes, although the additional gain in functionality is small 
>>> relative to the additional complexity.  The draft explicitly rules 
>>> this out of scope.  Section 3 says:
>>>
>>  <GH> No, that is a different thing. We have agreed and made efforts 
>> to express that providing multiple language indications per direction 
>> does not imply that they all must be used simultaneously. They 
>> (usually) only form a list to select from for use in the session.
>>
>>  I have many times during our discussions thought about the proposal 
>> that Paul made now, and wondered if we gain or lose by having the 
>> restriction of only one language per media and direction in the 
>> answer. We might have higher complexity and longer delay before the 
>> answer when we have the current limitation. This  is because it can 
>> be hard for the application to take the decision on its own on the 
>> single language to indicate in the answer, and therefore a user 
>> interaction needed to ask the user how to answer. If support of more 
>> than one language per media and direction is allowed (but not 
>> simultaneously), then it is easier to make an automatic match by the 
>> device and include all common languages in the answer.
>>
>>  However including more than one language per media and direction in 
>> the answer puts the users in more uncertainty about in what language 
>> the session will begin.
>>
>>  We could allow indication of multiple languages per media and 
>> direction in the answer and let the application decide if it shall 
>> make it easy for itself by indicating all common languages or easy 
>> for the users by indicating one language per media and direction.
>>
>>  We also have the wording that the languages in the answer does not 
>> need to be selected from what was provided in the offer by the 
>> formulation: "(which in most cases is one of the languages in the 
>> offer's 'hlang-recv') etc."
>
> This is because there may be no languages in common but the call 
> proceeds anyway.  The usual example is an emergency call placed by a 
> user who does not speak any language that the PSAP can support, even 
> with language translation services. Just being able to hear what is 
> happening may be useful to the PSAP call taker, better than not having 
> a call at all.
<GH> No, the parenthesis introduces an important opportunity for the 
answerer to propose a language that was not in the offer, but may be 
possible to use as a first try for getting some communication going 
anyway. That can be beneficial for both sending and receiving. If it 
does not work for the users, they are free to try other alternatives 
during the session.

A question: Do you regard it to also be allowed for the answerer to 
include a language in a media that had no hlang attribute in the offer?  
Imagine a hearing caller offering only spoken languages in audio, but 
including text media in the offer, calling a deaf person who cannot use 
spoken language, and therefore takes a chance to include written 
language indication in text media.  The ABNF in -20 allows it, and my 
interpretation of the wording in 5.2 is that it is allowed. There may be 
other views.
The clean way is of course to accept the call without languages and make 
a re-INVITE with languages in text media so that a complete language 
negotiation can be performed, but that adds complexity.

RFC 4796 has specific wording to tell that the content attribute is 
allowed in an answer even if it did not appear in the offer. Maybe we 
should have had a similar statement.

>
>>
>>  When there is no match, maybe the answerer want to indicate all 
>> support it has, for example expressing in response to a request to 
>> use Spanish:  "No, I cannot understand Spanish but I can understand 
>> spoken Portuguese and French and Italian", in a hope to get a 
>> conversation going.
>>
>>  In summary: I support Paul's proposal to relax the rules and leave 
>> to the application to decide how to compose the answer.
>
> The current limitation has been agreed by the working group.  I see 
> Paul's suggestion as a trade-off between a capability that might be 
> nice to have but is not required, and additional complexity; I do not 
> see it as a significant defect.  It is not a show-stopper.  It could 
> be relaxed in a future extension or revision. Consider how many years 
> we have been trying to get this simple feature published so it can be 
> used.  And now, finally, after so many arguments (many of which were 
> pointless) and so many revisions, and so much debate over simple 
> wording, you propose that we go back to the WG and reopen debate and 
> restart the series of last calls and discussions.  I think this is a 
> mistake.  I object to it.
<GH>The discussion and proposal was just a result of the difference 
between the wording about the answer and the wording about the syntax in 
5.2. Selection of one of the interpretations was needed. It would be 
less complex for the applications to allow multiple languages in the 
attribute in the answer than deciding on one single language. That could 
save the need for complex user interaction to make the decision. The 
wording does not require simultaneous use during the session that is 
said to be out of scope. It is only that the possible alternatives would 
be indicated to the offeror in order of preference.
It may however increase the complexity for the users to take the 
decision instead of being told by the application which language to use, 
so it would be best to leave it to the application to decide on how many 
alternatives are provided in the answer.
I do not think that the WG has been very specific about this choice 
since both interpretations have been there for a long time in the draft.
It is hard to relax restrictions in later revisions. Without protocol 
preparations for extensions, interop problems are easily introduced.

/Gunnar

---

From: Randall Gellens <[email-masked]>
Date: Tue, 9 Jan 2018 08:46:18 -0800

I do not agree that changes are needed now.  I 
also do not agree that, in general, it is 
difficult to relax restrictions in future 
extensions or updates.  In my experience, it is 
much easier to relax a restriction than it is to 
introduce it.

At 9:55 AM +0100 1/9/18, Gunnar Hellström wrote:

>>>>>>        human language 
>>>>>> (spoken/written/signed) can be negotiated 
>>>>>> in the same
>>>>> instance, a caller *might* offer both 
>>>>> French and Chinese. The callee (a call 
>>>>> center) may have agents that speak each, 
>>>>> but may well not have any agents that speak 
>>>>> both.
>>>>>
>>>>> somebody who supports both. If so, seems 
>>>>> like it would be good to indicate that both 
>>>>> are supported.
>>>>
>>> direction does not imply that they all must 
>>> be used simultaneously. They (usually) only 
>>> thought about the proposal that Paul made 
>>> now, and wondered if we gain or lose by 
>>> having the restriction of only one language 
>>> per media and direction in the answer. We 
>>> might have higher complexity and longer delay 
>>> before the answer when we have the current 
>>> limitation. This  is because it can be hard 
>>> for the application to take the decision on 
>>> its own on the single language to indicate in 
>>> the answer, and therefore a user interaction 
>>> needed to ask the user how to answer. If 
>>> support of more than one language per media 
>>> and direction is allowed (but not 
>>> simultaneously), then it is easier to make an 
>>> automatic match by the device and include all 
>>> common languages in the answer.
>>>
>>>   We could allow indication of multiple 
>>> languages per media and direction in the 
>>> answer and let the application decide if it 
>>> shall make it easy for itself by indicating 
>>> all common languages or easy for the users by 
>>>   We also have the wording that the languages 
>>> in the answer does not need to be selected 
>>> from what was provided in the offer by the 
>> common but the call proceeds anyway.  The 
>> usual example is an emergency call placed by a 
>> user who does not speak any language that the 
>> PSAP can support, even with language 
>> translation services. Just being able to hear 
>> what is happening may be useful to the PSAP 
>> call taker, better than not having a call at 
>> all.
>  <GH> No, the parenthesis introduces an 
> important opportunity for the answerer to 
> propose a language that was not in the offer, 
> but may be possible to use as a first try for 
> getting some communication going anyway. That 
> can be beneficial for both sending and 
> receiving. If it does not work for the users, 
> they are free to try other alternatives during 
> the session.
>
>  A question: Do you regard it to also be allowed 
> for the answerer to include a language in a 
> media that had no hlang attribute in the offer? 
> Imagine a hearing caller offering only spoken 
> languages in audio, but including text media in 
> the offer, calling a deaf person who cannot use 
> spoken language, and therefore takes a chance 
> to include written language indication in text 
> media.  The ABNF in -20 allows it, and my 
> interpretation of the wording in 5.2 is that it 
> is allowed. There may be other views.
>  The clean way is of course to accept the call 
> without languages and make a re-INVITE with 
> languages in text media so that a complete 
> language negotiation can be performed, but that 
> adds complexity.
>
>  RFC 4796 has specific wording to tell that the 
> content attribute is allowed in an answer even 
> if it did not appear in the offer. Maybe we 
>>>   When there is no match, maybe the answerer 
>>> want to indicate all support it has, for 
>>> example expressing in response to a request 
>>> to use Spanish:  "No, I cannot understand 
>>> Spanish but I can understand spoken 
>>> Portuguese and French and Italian", in a hope 
>>> to get a conversation going.
>>>
>>>   In summary: I support Paul's proposal to 
>>> relax the rules and leave to the application 
>>> to decide how to compose the answer.
>>
>> trade-off between a capability that might be 
>> nice to have but is not required, and 
>> additional complexity; I do not see it as a 
>> significant defect.  It is not a show-stopper. 
>> It could be relaxed in a future extension or 
>> revision. Consider how many years we have been 
>> trying to get this simple feature published so 
>> it can be used.  And now, finally, after so 
>> many arguments (many of which were pointless) 
>> and so many revisions, and so much debate over 
>> simple wording, you propose that we go back to 
>> the WG and reopen debate and restart the 
>> series of last calls and discussions.  I think 
>> this is a mistake.  I object to it.
>  <GH>The discussion and proposal was just a 
> result of the difference between the wording 
> about the answer and the wording about the 
> syntax in 5.2. Selection of one of the 
> interpretations was needed. It would be less 
> complex for the applications to allow multiple 
> languages in the attribute in the answer than 
> deciding on one single language. That could 
> save the need for complex user interaction to 
> make the decision. The wording does not require 
> simultaneous use during the session that is 
> said to be out of scope. It is only that the 
> possible alternatives would be indicated to the 
> offeror in order of preference.
>  It may however increase the complexity for the 
> users to take the decision instead of being 
> told by the application which language to use, 
> so it would be best to leave it to the 
> application to decide on how many alternatives 
> are provided in the answer.
>  I do not think that the WG has been very 
> specific about this choice since both 
> interpretations have been there for a long time 
> in the draft.
>  It is hard to relax restrictions in later 
> revisions. Without protocol preparations for 
> extensions, interop problems are easily 
> introduced.
>
>  /Gunnar
>>
>>>
>>>>

-------------- Randomly selected tag: ---------------
I loathe housework.  You make beds, wash dishes
-- and six months later you have to start all over again.
                                           --Joan Rivers

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 10 Jan 2018 10:51:02 -0500

Gunnar,

I would like to understand your thinking about how the language 
indications will be used. Your comments below suggest to me that you are 
assuming that they will be exposed to the end users through a UI. If 
that is not the case then order of preference of one language over 
another won't have any influence over how the session proceeds.

	Thanks,
	Paul

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 10 Jan 2018 21:02:47 +0100

Den 2018-01-10 kl. 16:51, skrev Paul Kyzivat:
> indications will be used. Your comments below suggest to me that you 
> are assuming that they will be exposed to the end users through a UI. 
> If that is not the case then order of preference of one language over 
Yes, it is in most applications the human end users who are expected to 
produce and understand the negotiated language(s). Therefore the final 
result of the negotiation must be presented to the users. (or, in less 
common automatic conversation cases, fed to an automata for generating 
the agreed language).
We say that this must happen, but it is not the task of the draft to say 
how.

Examples:

If it is a regular conversational call application, it could present 
what the application regards to be the best match on the screen: "Talk 
English, expect English text".
That prepares the users for how the call is best started.

Alternatively, the answering party can be provided with options for 
selection among the common languages before the call is answered. E.g.
"The far end user can receive ASL __ and written English __, which do 
you want to produce?"
"The far end user can produce ASL ___ and written English ___, which do 
you want to receive?"
The result goes into the coding of the hlang attributes in the answer.
The answer will be presented to the offeror on the screen by e.g.
"Sign ASL, prepare to receive ASL".

By following the advice on the screen, the call will start smoothly. 
Nothing prevents the users to vary the use of languages and media by 
mutual agreement after the initial exchange during the call.

Wide variations from these examples are imaginable.
Gunnar

>>>>>> both. If so, seems like it would be good to indicate that both 
>>>>>> are supported.
>>>>>
>>>>  <GH> No, that is a different thing. We have agreed and made 
>>>> efforts to express that providing multiple language indications per 
>>>> direction does not imply that they all must be used simultaneously. 
>>>> They (usually) only form a list to select from for use in the session.
>>>>
>>>>  I have many times during our discussions thought about the 
>>>> proposal that Paul made now, and wondered if we gain or lose by 
>>>> having the restriction of only one language per media and direction 
>>>> in the answer. We might have higher complexity and longer delay 
>>>> before the answer when we have the current limitation. This  is 
>>>> because it can be hard for the application to take the decision on 
>>>> its own on the single language to indicate in the answer, and 
>>>> therefore a user interaction needed to ask the user how to answer. 
>>>> If support of more than one language per media and direction is 
>>>> allowed (but not simultaneously), then it is easier to make an 
>>>> automatic match by the device and include all common languages in 
>>>> the answer.
>>>>
>>>>  However including more than one language per media and direction 
>>>> in the answer puts the users in more uncertainty about in what 
>>> happening may be useful to the PSAP call taker, better than not 
>>> having a call at all.
>> include a language in a media that had no hlang attribute in the 
>> offer? Imagine a hearing caller offering only spoken languages in 
>> audio, but including text media in the offer, calling a deaf person 
>> who cannot use spoken language, and therefore takes a chance to 
>> include written language indication in text media.  The ABNF in -20 
>> allows it, and my interpretation of the wording in 5.2 is that it is 
>> allowed. There may be other views.
>> The clean way is of course to accept the call without languages and 
>> make a re-INVITE with languages in text media so that a complete 
>> language negotiation can be performed, but that adds complexity.
>>
>>> nice to have but is not required, and additional complexity; I do 
>>> not see it as a significant defect.  It is not a show-stopper.  It 
>>> could be relaxed in a future extension or revision. Consider how 
>>> many years we have been trying to get this simple feature published 
>>> so it can be used.  And now, finally, after so many arguments (many 
>>> of which were pointless) and so many revisions, and so much debate 
>>> over simple wording, you propose that we go back to the WG and 
>>> reopen debate and restart the series of last calls and discussions.  
>>> I think this is a mistake.  I object to it.
>> between the wording about the answer and the wording about the syntax 
>> in 5.2. Selection of one of the interpretations was needed. It would 
>> be less complex for the applications to allow multiple languages in 
>> the attribute in the answer than deciding on one single language. 
>> That could save the need for complex user interaction to make the 
>> decision. The wording does not require simultaneous use during the 
>> session that is said to be out of scope. It is only that the possible 
>> alternatives would be indicated to the offeror in order of preference.
>> decision instead of being told by the application which language to 
>> use, so it would be best to leave it to the application to decide on 
>> how many alternatives are provided in the answer.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 11 Jan 2018 16:02:10 -0500

> Wide variations from these examples are imaginable.

While this sounds helpful, it isn't current practice. I don't know what 
it will take make it common practice. Perhaps the draft should note this 
as an issue.

	Thanks,
	Paul

---

From: Randall Gellens <[email-masked]>
Date: Thu, 11 Jan 2018 14:12:32 -0800

At 4:02 PM -0500 1/11/18, Paul Kyzivat wrote:

>>>  I would like to understand your thinking 
>>> about how the language indications will be 
>>> used. Your comments below suggest to me that 
>>> you are assuming that they will be exposed to 
>>> the end users through a UI. If that is not 
>>> the case then order of preference of one 
>>> language over another won't have any 
>>> influence over how the session proceeds.
>>  Yes, it is in most applications the human end 
>> users who are expected to produce and 
>> understand the negotiated language(s). 
>> Therefore the final result of the negotiation 
>> must be presented to the users. (or, in less 
>> common automatic conversation cases, fed to an 
>> automata for generating the agreed language).
>>  We say that this must happen, but it is not 
>> the task of the draft to say how.
>>
>>  Examples:
>>
>>  If it is a regular conversational call 
>> application, it could present what the 
>> application regards to be the best match on 
>> the screen: "Talk English, expect English 
>> text".
>>  Alternatively, the answering party can be 
>> provided with options for selection among the 
>> common languages before the call is answered. 
>> E.g.
>>  "The far end user can receive ASL __ and 
>> written English __, which do you want to 
>> produce?"
>>  "The far end user can produce ASL ___ and 
>> written English ___, which do you want to 
>> receive?"
>>  By following the advice on the screen, the 
>> call will start smoothly. Nothing prevents the 
>> users to vary the use of languages and media 
>> by mutual agreement after the initial exchange 
>> during the call.
>>
>  While this sounds helpful, it isn't current 
> practice. I don't know what it will take make 
> it common practice. Perhaps the draft should 
> note this as an issue.

I'd rather leave this for other documents.  For 
example, Gunner has a few drafts that build on 
this one.

-------------- Randomly selected tag: ---------------
One should always be a little improbable.          --Oscar Wilde

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 11 Jan 2018 23:43:29 +0100

Den 2018-01-11 kl. 23:12, skrev Randall Gellens:
>>>> indications will be used. Your comments below suggest to me that 
>>>> you are assuming that they will be exposed to the end users through 
>>>> a UI. If that is not the case then order of preference of one 
>>>> language over another won't have any influence over how the session 
>>>> proceeds.
>>>  Yes, it is in most applications the human end users who are 
>>> expected to produce and understand the negotiated language(s). 
>>> Therefore the final result of the negotiation must be presented to 
>>> the users. (or, in less common automatic conversation cases, fed to 
>>> an automata for generating the agreed language).
>>>  We say that this must happen, but it is not the task of the draft 
>>> to say how.
>>>
>>>  Examples:
>>>
>>>  If it is a regular conversational call application, it could 
>>> present what the application regards to be the best match on the 
>>> screen: "Talk English, expect English text".
>>>  "The far end user can receive ASL __ and written English __, which 
>>> do you want to produce?"
>>>  "The far end user can produce ASL ___ and written English ___, 
>>> which do you want to receive?"
>>>  By following the advice on the screen, the call will start 
>>> smoothly. Nothing prevents the users to vary the use of languages 
>>> and media by mutual agreement after the initial exchange during the 
>>> call.
>>>
>>  While this sounds helpful, it isn't current practice. I don't know 
>> what it will take make it common practice. Perhaps the draft should 
>> note this as an issue.
The draft makes this possible. The whole idea of it is to enable a 
smooth start of the call with the participants using negotiated 
languages. It is a problem today, and the draft says it solves it. I 
would guess that most applications will prefer to use the first 
mechanism I described, where the application makes the decision and 
tells the user which language(s) will make the call start smoothly.

>
> I'd rather leave this for other documents.  For example, Gunner has a 
> few drafts that build on this one.
What do you want to leave?  The examples above are nothing new and 
contain no issue and nothing that we intend to specify because we do not 
specify user interactions. It is the natural use of the current draft.  
How else did you intend to use it?

Gunnar

---

From: Randall Gellens <[email-masked]>
Date: Thu, 11 Jan 2018 15:21:51 -0800

At 11:43 PM +0100 1/11/18, Gunnar Hellström wrote:

>>>>> used. Your comments below suggest to me 
>>>>> that you are assuming that they will be 
>>>>> exposed to the end users through a UI. If 
>>>>> that is not the case then order of 
>>>>> preference of one language over another 
>>>>> won't have any influence over how the 
>>>>> session proceeds.
>>>>   Yes, it is in most applications the human 
>>>> end users who are expected to produce and 
>>>> Therefore the final result of the 
>>>> negotiation must be presented to the users. 
>>>> (or, in less common automatic conversation 
>>>> cases, fed to an automata for generating the 
>>>> agreed language).
>>>> provided with options for selection among 
>>>> the common languages before the call is 
>>>> answered. E.g.
>>>> call will start smoothly. Nothing prevents 
>>>> the users to vary the use of languages and 
>>>> media by mutual agreement after the initial 
>>>> exchange during the call.
>>>>
>  The draft makes this possible. The whole idea 
> of it is to enable a smooth start of the call 
> with the participants using negotiated 
> languages. It is a problem today, and the draft 
> says it solves it. I would guess that most 
> applications will prefer to use the first 
> mechanism I described, where the application 
> makes the decision and tells the user which 
> language(s) will make the call start smoothly.
>
>>
>>  I'd rather leave this for other documents. 
>> For example, Gunner has a few drafts that 
>> build on this one.
>  What do you want to leave?  The examples above 
> are nothing new and contain no issue and 
> nothing that we intend to specify because we do 
> not specify user interactions. It is the 
> natural use of the current draft.  How else did 
> you intend to use it?

Paul wrote "Perhaps the draft should note this as 
an issue."  I'd rather leave the UI issues out of 
the draft.  The draft already says it does not 
discuss how users are informed.

-------------- Randomly selected tag: ---------------
If you can't be a good example, at least be a horrible warning.

---

From: Gunnar Hellström <[email-masked]>
Date: Fri, 12 Jan 2018 08:02:39 +0100

Den 2018-01-12 kl. 00:21, skrev Randall Gellens:
>>>>>> you are assuming that they will be exposed to the end users 
>>>>>> through a UI. If that is not the case then order of preference of 
>>>>>> one language over another won't have any influence over how the 
>>>>>> session proceeds.
>>>>> the users. (or, in less common automatic conversation cases, fed 
>>>>> to an automata for generating the agreed language).
>>>>>   We say that this must happen, but it is not the task of the 
>>>>> draft to say how.
>>>>>
>>>>>   Examples:
>>>>>
>>>>>   Alternatively, the answering party can be provided with options 
>>>>> for selection among the common languages before the call is 
>>>>> answered. E.g.
>>>>>   "The far end user can receive ASL __ and written English __, 
>>>>> which do you want to produce?"
>>>>> and media by mutual agreement after the initial exchange during 
>>>>> the call.
>>>>>
>>>>   While this sounds helpful, it isn't current practice. I don't 
>>>> know what it will take make it common practice. Perhaps the draft 
>>>> should note this as an issue.
>>>  I'd rather leave this for other documents. For example, Gunner has 
>>> a few drafts that build on this one.
>> contain no issue and nothing that we intend to specify because we do 
>> not specify user interactions. It is the natural use of the current 
>> draft.  How else did you intend to use it?
>
> Paul wrote "Perhaps the draft should note this as an issue."  I'd 
> rather leave the UI issues out of the draft.  The draft already says 
> it does not discuss how users are informed.
>
<GH> Yes, and I think it is also not the task of the draft to tell how 
it can become common practice to implement it, if that was the issue 
Paul saw.
My first impression was that you both found my examples of how to use 
the draft unexpected. But that was apparently not the case.

/Gunnar

---

From: Randall Gellens <[email-masked]>
Date: Mon, 8 Jan 2018 16:48:09 -0800

Hi Alvaro, Paul, Eric, Mirja,

I uploaded version -20, which contains the text changes as discussed 
in email in response to your comments.  For convenience, here is a 
link to the diff:

https://www.ietf.org/rfcdiff?url1=draft-ietf-slim-negotiating-human-language-19&url2=draft-ietf-slim-negotiating-human-language-20

-------------- Randomly selected tag: ---------------
Democracy is also a form of worship.
It is the worship of Jackals by Jackasses.
                          --H. L. Mencken

---

From: Randall Gellens <[email-masked]>
Date: Tue, 9 Jan 2018 08:43:01 -0800

Version -21 is uploaded, which deletes 5.1 and a sentence about the 
offer/answer model.  I believe this resolves all comments.

--Randall

At 4:48 PM -0800 1/8/18, Randall Gellens wrote:

>  I uploaded version -20, which contains the text changes as 
> discussed in email in response to your comments.  For convenience, 
> here is a link to the diff:
>
> 

-------------- Randomly selected tag: ---------------
    Life is ... a shopping mall ... where items such as worldly success,
love of music, a strong backhand, close relationships with your family,
a few good friends and countless other things are on sale.
    The commodity with which they are purchased is not money, but time.
                                                   --William Rehnquist

---

From: Randall Gellens <[email-masked]>
Date: Tue, 9 Jan 2018 08:57:15 -0800

Oops, I accidently uploaded the wrong file as -21.  So, -22 is 
uploaded and has the changes.  Sorry.

-------------- Randomly selected tag: ---------------
Today paranoia about big government is wholesome fun for the entire
family, not a dark disorder of the far right.

--Thomas Frank in his essay "The Trillion Dollar Hustle: Hello Wall
Street, goodbye Social Security" in the January, 2002 _Harper's
Magazine_