Subject: [Slim] Ben Campbell's Yes on draft-ietf-slim-negotiating-human-language-22: (with COMMENT)

From: Ben Campbell <[email-masked]>
Date: Tue, 09 Jan 2018 20:21:21 -0800

Ben Campbell has entered the following ballot position for
draft-ietf-slim-negotiating-human-language-22: Yes

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

I'm balloting "yes" because I think this is important work, but I have some
comments:

Substantive Comments:

- General: It seems to be that this is as much about human behavior as it is
capabilities negotiating. Example case: I make a video call and express that I
would like to receive Klingon. (Is there a tag for that ? :-) The callee can
speak Klingon and Esperanto, so we agree on Klingon. What keeps the callee from
speaking Esparanto instead?

I realize we can't force people to stick to the negotiated languages--but
should we expect that users should at least be given some sort of UI indication
about the negotiated language(s)? It seems like a paragraph or two on that
subject is warranted, even if it just to say it's out of scope.

-1, paragraph 6:  (related to Ekr's comments) Does the selection of a single
tag in an answer imply  an assumption only one language will be used? There are
communities where people tend to mix 2 or more languages freely and fluidly. Is
that sort of thing out of scope?

- 5.1, paragraph 2:  Can you elaborate on the motivation to have a separate
hlang-send and hlang-recv parameter vs having a single language parameter and
instead setting the stream to send or receive only, especially in light of the
recommendation to set both directions the same for bi-directional language
selection? I don't mean to dispute that approach; I just think a bit more
explanation of the design choice would be helpful to the reader.  I can imagine
some use cases, for example a speech-impaired person who does not plan to speak
on a video call may still wish to send video to show facial expressions, etc. 
(I just re-read the discussion resulting from Ekr's comments, and recognize
that this overlaps heavily with that.)

-5.1, paragraph 3: "... which in most cases is one of the
   languages in the offer's..."
Are there cases where it might not?

-5.1, last paragraph: "This is not a problem."
Can you elaborate? That sort of statement usually takes the form "This is not a
problem, because..."

-5.2, last paragraph: Is there a reason to give such weak guidance on how to
indicate the call is rejected?  (Along those lines, are non-SIP uses of SDP in
scope?)

Editorial Comments and Nits:

-5.1, paragraph 4: The first MUST seems like a statement of fact.

---

From: Randall Gellens <[email-masked]>
Date: Wed, 10 Jan 2018 08:12:29 -0800

>  speaking Esparanto instead?

There is a language tag for Klingon: "tlh".

The draft is not trying to even capture the full complexity of human 
language interaction, much less enforce it.  The draft provides a 
fairly simple mechanism to make it more likely that successful 
communication can occur, by identifying language needs (which can 
allow endpoints to take potentially required additional steps, such 
as bridging in translation or relay services, or having a call 
handled by someone who known the language(s) or can use the needed 
media).

>  subject is warranted, even if it just to say it's out of scope.

I will add to the Introduction the following text:

    This document does not address user interface (UI) issues, such as if
    or how a UE client informs a user about the result of language and
    media negotiation.

>  that sort of thing out of scope?

Earlier versions of the draft had more explicit text that the draft 
did not attempt to capture the full range of human language issues, 
including the common practice among multilingual people of mixing 
languages.

The draft currently says:

    (Negotiating multiple simultaneous languages within a media stream is
    out of scope of this document.)

There was text in a version of the draft as of February 2013 that said:

    (While it is true that a conversation among multilingual people often
    involves multiple languages, it does not seem useful enough as a
    general facility to warrant complicating the desired semantics of the
    SDP attribute to allow negotiation of multiple simultaneous languages
    within an interactive media stream.)

I do not recall the reasons why the text was simplified, removing 
mention of multilingual people, and would have to search through 
minutes of the various WG sessions and email in 2013 where the draft 
was discussed.  I suspect there was desire to have the draft merely 
state what it does and doesn't do, and not get into a lot of value 
judgment discussion.

>  that this overlaps heavily with that.)

As you suggest, a media might be desired in both directions even 
though only one direction is primarily intended for interactive 
communication.  The draft currently says:

    When a media is intended for interactive communication
    using a language in one direction only (e.g., a user with difficulty
    speaking but able to hear who indicates a desire to send using text
    and receive using audio), either hlang-send or hlang-recv MAY be
    omitted.  When a media is not primarily intended for language (for
    example, a video or audio stream intended for background only) both
    SHOULD be omitted.  Otherwise, both SHOULD have the same value.  Note
    that specifying different languages for each direction (as opposed to
    the same or essentially the same language in different modalities)
    can make it difficult to complete the call (e.g., specifying a desire
    to send audio in Hungarian and receive audio in Portuguese).

I will add "Note that the media can still be useful in both 
directions."  The text thus becomes:

    When a media is intended for interactive communication
    using a language in one direction only (e.g., a user with difficulty
    speaking but able to hear who indicates a desire to send using text
    and receive using audio), either hlang-send or hlang-recv MAY be
    omitted.  Note that the media can still be useful in both directions.
    When a media is not primarily intended for language (for example, a
    video or audio stream intended for background only) both SHOULD be
    omitted.

>  Are there cases where it might not?

Yes, it could happen.  For example, if an emergency call comes into a 
PSAP and requests languages that the PSAP is unable to support, the 
PSAP will likely want the call to proceed anyway.  It's also possible 
that the callee might support a language that has some degree of 
mutual comprehensibility to those requested by the caller.  An 
example might be some Scandinavian languages where the caller does 
not include a language that is similar enough to have some 
comprehension but not be fluent enough to include in the UE 
configuration.

>  Can you elaborate? That sort of statement usually takes the form 

The caller and callee are free to use any of the established media 
streams.  If a caller requests audio, video (with a sign language), 
and text, and all three are established, the caller might ignore the 
text or audio stream and use only the video stream.

>  indicate the call is rejected?  (Along those lines, are non-SIP 

No one made a case for why mandating a particular rejection code was 
necessary, especially since the draft does not offer any suggestion 
as to if a call should proceed or fail when there aren't mutually 
supported languages.

>  -5.1, paragraph 4: The first MUST seems like a statement of fact.

You mean this sentence:

    In an offer, each value MUST be a list of one or more language tags
    per BCP 47 [RFC5646], separated by white space.

The MUST makes sure that the values are IANA-registered language tags.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
The first rule is, you must not fool yourself.  And you are the
easiest person to fool.                       --Richard Feynman

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 10 Jan 2018 11:15:03 -0500

> that this overlaps heavily with that.)

There are cases where what you suggest won't work. E.g., Sign language 
is embedded in video, but it isn't the sole purpose of the video. If I 
can understand sign language but not do it myself, I wouldn't want to 
indicate that by refusing to send video.

	Thanks,
	Paul

---

From: Ben Campbell <[email-masked]>
Date: Wed, 10 Jan 2018 10:39:11 -0600

> On Jan 10, 2018, at 10:15 AM, Paul Kyzivat <[email-masked]> wrote:
> 
> There are cases where what you suggest won't work. E.g., Sign language is embedded in video, but it isn't the sole purpose of the video. If I can understand sign language but not do it myself, I wouldn't want to indicate that by refusing to send video.

To be clear, all I was suggesting was a brief explanation of the design choice, not a change in that choice.

> 
> 	Thanks,
> 	Paul
> 
> _______________________________________________
> SLIM mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/slim

---

From: Ben Campbell <[email-masked]>
Date: Wed, 10 Jan 2018 10:48:34 -0600

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

I agree that UX details should be out of scope. But is it worth mentioning that there needs to be someway of communicating the language selection to the humans? Or failing that, to explicitly mention that all the selection does is determine that there is a language in common, and it’s up to the humans to figure things out from there?

> state what it does and doesn't do, and not get into a lot of value

Okay, that’s sufficient proof that people have thought about it. I don’t see a need for a change.

>    video or audio stream intended for background only) both SHOULD be

WFM.

> comprehension but not be fluent enough to include in the UE

Okay. I note to that effect might help, but I leave that to you to decide.

> text or audio stream and use only the video stream.

Would it make sense to replace “This is a not a problem” with “The participants are free to use any of the established media streams.”? Or “This is not a problem because the participants are free…”?

> as to if a call should proceed or fail when there aren't mutually

When you should fail and how to express failure are two different questions. The second can be an interoperability issue.

> The MUST makes sure that the values are IANA-registered language tags.

Ah, okay.

---

From: Randall Gellens <[email-masked]>
Date: Wed, 10 Jan 2018 09:56:12 -0800

At 10:48 AM -0600 1/10/18, Ben Campbell wrote:

>   > On Jan 10, 2018, at 10:12 AM, Randall 
> Gellens <[email-masked]> wrote:
>>
>  I agree that UX details should be out of scope. 
> But is it worth mentioning that there needs to 
> be someway of communicating the language 
> selection to the humans? Or failing that, to 
> explicitly mention that all the selection does 
> is determine that there is a language in 
> common, and it's up to the humans to figure 
> things out from there?

I don't think we need to say more; I think it's 
obvious and in this case if we say more we risk 
saying things that aren't always true or getting 
deeper into out of scope details.  For example, 
not all SIP calls are placed by UI-rich devices.

>  Okay, that's sufficient proof that people have 
> thought about it. I don't see a need for a 
> change.

Thanks.

>>     video or audio stream intended for background only) both SHOULD be

Thanks.

>  Okay. I note to that effect might help, but I leave that to you to decide.

I'd rather not try to craft language for that 
now, since doing so risks adding details that 
aren't always true or getting too deep into 
operational issues.

>  Would it make sense to replace "This is a not a 
> problem" with "The participants are free to use 
> any of the established media streams."? Or 
> "This is not a problem because the participants 
> are freeŠ"?

I'm not sure how much we need to say.  I could 
add text such as "This is not a problem because 
unused media streams are not resource-intensive" 
but I'm not sure it helps a reader understand. 
Do you think a reader would be confused if we 
don't discuss it further?  I'm open to trying to 
add clarifying text if it will help.

>  When you should fail and how to express failure 
> are two different questions. The second can be 
> an interoperability issue.

How about if I reword the text to be:

    A call that is rejected due to lack of any languages in common has
    SIP response code 488 (Not Acceptable Here) or 606 (Not Acceptable)
    [RFC3261] and a Warning header field [RFC3261] containing a warning
    code of [TBD: IANA VALUE, e.g., 308] and a warning text indicating
    that there are no mutually-supported languages in the SIP response;
    the warning text SHOULD also contain the supported languages and
    media.

>>  The MUST makes sure that the values are IANA-registered language tags.

Thanks.

-------------- Randomly selected tag: ---------------
Americans can always be counted on to do the right thing, after they
have exhausted all other possibilities. -- Winston Churchill

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 10 Jan 2018 23:35:01 +0100

I saw a question somewhere but lost track of who asked it.

It was about if the users are bound to use only the negotiated 
language(s) in the session.

I think a line about that should be inserted, probably best close to the 
end of the introduction.

Proposed text:
"The result of the negotiation is intended to guide the selection of 
language(s) to use initially and during the session. However, nothing 
prevents the users from varying the use of languages and media by mutual 
agreement after the initial exchange during the call."

Gunnar

Den 2018-01-10 kl. 17:12, skrev Randall Gellens:
> allow endpoints to take potentially required additional steps, such as 
> bridging in translation or relay services, or having a call handled by 
> someone who known the language(s) or can use the needed media).
>
> mutual comprehensibility to those requested by the caller.  An example 
> might be some Scandinavian languages where the caller does not include 
> a language that is similar enough to have some comprehension but not 
> be fluent enough to include in the UE configuration.
>
>
> necessary, especially since the draft does not offer any suggestion as 
> to if a call should proceed or fail when there aren't mutually 
> supported languages.
>
>>

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

---

From: Randall Gellens <[email-masked]>
Date: Wed, 10 Jan 2018 14:56:10 -0800

It was Ben who asked about it.  I don't think we need to add more text.

--Randall

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

>  It was about if the users are bound to use only 
> the negotiated language(s) in the session.
>
>  I think a line about that should be inserted, 
> probably best close to the end of the 
> introduction.
>
>  Proposed text:
>  "The result of the negotiation is intended to 
> guide the selection of language(s) to use 
> initially and during the session. However, 
> nothing prevents the users from varying the use 
> of languages and media by mutual agreement 
> after the initial exchange during the call."
>
>  Gunnar
>
>
>>  The draft is not trying to even capture the 
>> full complexity of human language interaction, 
>> much less enforce it.  The draft provides a 
>> fairly simple mechanism to make it more likely 
>> that successful communication can occur, by 
>> identifying language needs (which can allow 
>> endpoints to take potentially required 
>> additional steps, such as bridging in 
>> translation or relay services, or having a 
>> call handled by someone who known the 
>> language(s) or can use the needed media).
>>
>>  Earlier versions of the draft had more 
>> explicit text that the draft did not attempt 
>> to capture the full range of human language 
>> issues, including the common practice among 
>> multilingual people of mixing languages.
>>
>>  I do not recall the reasons why the text was 
>> simplified, removing mention of multilingual 
>> people, and would have to search through 
>> minutes of the various WG sessions and email 
>> in 2013 where the draft was discussed.  I 
>> suspect there was desire to have the draft 
>> merely state what it does and doesn't do, and 
>> not get into a lot of value judgment 
>> discussion.
>>
>>>   some use cases, for example a 
>>> speech-impaired person who does not plan to 
>>> speak
>>  As you suggest, a media might be desired in 
>> both directions even though only one direction 
>> is primarily intended for interactive 
>>  I will add "Note that the media can still be 
>> useful in both directions."  The text thus 
>> becomes:
>>
>>  Yes, it could happen.  For example, if an 
>> emergency call comes into a PSAP and requests 
>> languages that the PSAP is unable to support, 
>> the PSAP will likely want the call to proceed 
>> anyway. It's also possible that the callee 
>> might support a language that has some degree 
>> of mutual comprehensibility to those requested 
>> by the caller.  An example might be some 
>> Scandinavian languages where the caller does 
>> not include a language that is similar enough 
>> to have some comprehension but not be fluent 
>> enough to include in the UE configuration.
>>
>>  The caller and callee are free to use any of 
>> the established media streams.  If a caller 
>> requests audio, video (with a sign language), 
>> and text, and all three are established, the 
>> caller might ignore the text or audio stream 
>> and use only the video stream.
>>
>>  No one made a case for why mandating a 
>> particular rejection code was necessary, 
>> especially since the draft does not offer any 
>> suggestion as to if a call should proceed or 
>> fail when there aren't mutually supported 
>> languages.
>>
>>>

-------------- Randomly selected tag: ---------------
The attention span of a computer is only as long as its electrical cord
or battery life.

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 10 Jan 2018 20:59:30 -0800

Gunnar said:

""The result of the negotiation is intended to guide the selection of
language(s) to use initially and during the session. However, nothing
prevents the users from varying the use of languages and media by mutual
agreement after the initial exchange during the call.""

[BA] This came from Ben Campbell, but other ADs with many years of
experience in realtime communications have asked questions along similar
lines.  So it seems that even experienced readers could use some
clarification.

The reason for the language selection negotiation is to enable the right
individuals and resources to be brought into the conversation so as to
maximize the changes of successful communications. What happens once the
call is brought up is up to the conversants.

The precise meaning of the negotiation depends in part on the choice of a
single language or multiple languages in the Answer.

If an offer indicates the ability to receive English and French, if an
Answer can only contain a single language, then an Answer indicating the
ability to send English would establish that the call is expected to be
conducted in English. That wouldn't necessarily preclude the use of French,
but doesn't provide any indication that it could be supported as an
alternative.

Whereas if the Answer was allowed to include multiple languages and
included both English and French, then the Answer would indicate that the
conversation could use either language with a preference for English over
French.  That does strike me as potentially valuable in some circumstances
(e.g. a visitor from Spain with an emergency offering Spanish primary and
English secondary and being able to get an answer indicating English with
secondary Spanish support, rather than just English).

In either case, the conversants can switch languages by mutual agreement.

On Wed, Jan 10, 2018 at 2:35 PM, Gunnar Hellström <
[email-masked]> wrote:

> It was about if the users are bound to use only the negotiated language(s)
> in the session.
>
>> language interaction, much less enforce it.  The draft provides a fairly
>> simple mechanism to make it more likely that successful communication can
>> occur, by identifying language needs (which can allow endpoints to take
>> potentially required additional steps, such as bridging in translation or
>> relay services, or having a call handled by someone who known the
>> Earlier versions of the draft had more explicit text that the draft did
>> not attempt to capture the full range of human language issues, including
>> the common practice among multilingual people of mixing languages.
>>
>> I do not recall the reasons why the text was simplified, removing mention
>> of multilingual people, and would have to search through minutes of the
>> various WG sessions and email in 2013 where the draft was discussed.  I
>> suspect there was desire to have the draft merely state what it does and
>> doesn't do, and not get into a lot of value judgment discussion.
>>
>>
>> As you suggest, a media might be desired in both directions even though
>> only one direction is primarily intended for interactive communication.
>> I will add "Note that the media can still be useful in both directions."
>> The text thus becomes:
>>
>> PSAP and requests languages that the PSAP is unable to support, the PSAP
>> will likely want the call to proceed anyway. It's also possible that the
>> callee might support a language that has some degree of mutual
>> comprehensibility to those requested by the caller.  An example might be
>> some Scandinavian languages where the caller does not include a language
>> that is similar enough to have some comprehension but not be fluent enough
>> to include in the UE configuration.
>>
>>
>> streams.  If a caller requests audio, video (with a sign language), and
>> text, and all three are established, the caller might ignore the text or
>> audio stream and use only the video stream.
>>
>> necessary, especially since the draft does not offer any suggestion as to
>> if a call should proceed or fail when there aren't mutually supported
>> languages.
>>
>>

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 10 Jan 2018 21:06:43 -0800

Which reminds me -- what are the implications of only allowing a single
language to be indicated in an Answer with respect to re-offers?

If multiple languages were indicated in the Answer, wouldn't this make it
easier for an Offer to switch language preferences in a re-offer and
conceivably get an Answer with different preferences?

This is how codec negotiation works today - the Answer can choose the
multiple codecs among those in the Offer, but only the first choice is
expected to be used.

For example, Offer indicates ability to understand Spanish and English,
Answer includes Spanish and English sending ability in that order.

Offerer finds that he/she cannot understand the Answerer very well,
potentially due to the dialect spoken, wishes to switch to English.

This could be indicated via a re-offer with English and Spanish, likely to
be answered with English and Spanish in that order.

Whereas if only a single language were permitted in the Answer, the Offerer
does not know whether the request for a preference change can be accepted
(e.g. if the call would need to be routed to a different endpoint because
the Answerer does not speak English).

On Wed, Jan 10, 2018 at 8:59 PM, Bernard Aboba <[email-masked]>
wrote:

>>> mention of multilingual people, and would have to search through minutes of
>>> the various WG sessions and email in 2013 where the draft was discussed.  I

---

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

Den 2018-01-11 kl. 06:06, skrev Bernard Aboba:
> Which reminds me -- what are the implications of only allowing a 
> single language to be indicated in an Answer with respect to re-offers?
>
> If multiple languages were indicated in the Answer, wouldn't this make 
> it easier for an Offer to switch language preferences in a re-offer 
> and conceivably get an Answer with different preferences?
>
> For example, Offer indicates ability to understand Spanish and 
> English, Answer includes Spanish and English sending ability in that 
> order.
>
> This could be indicated via a re-offer with English and Spanish, 
> likely to be answered with English and Spanish in that order.
>
> Whereas if only a single language were permitted in the Answer, the 
> Offerer does not know whether the request for a preference change can 
> be accepted (e.g. if the call would need to be routed to a different 
> endpoint because the Answerer does not speak English).
Yes, I support that we should allow more than one language per media and 
direction in the answer.
We already have that possibility for languages in different media. With 
the current wording it is allowed to answer: I can understand sign 
language in ASL in video and spoken English in audio. For that case it 
is only the relative preference that is missing so there is a risk that 
the lower preferred alternative will be selected for initial use. But 
then at least the possibility to switch during the call is evident from 
the beginning of the call.

Why should we not open this possibility also for single media? We had it 
earlier in the syntax description.
It also reduces complexity. It can be quite hard to calculate the best 
preference between two preference ordered sets of languages, while just 
evaluating which ones are common is easy.

Assume also that it is the offeror who pulls in translating resources 
when the match is not good. Then it will be good for the offeror to have 
the full picture of the capabilities.

I also support inserting the sentence below about the possibility to 
change language by mutual agreement during the call. It can be added 
last in section 1.

Gunnar
>
> On Wed, Jan 10, 2018 at 8:59 PM, Bernard Aboba 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Gunnar said:
>
>     ""The result of the negotiation is intended to guide the selection
>     of language(s) to use initially and during the session. However,
>     nothing prevents the users from varying the use of languages and
>     media by mutual agreement after the initial exchange during the
>     call.""
>
>     experience in realtime communications have asked questions along
>     similar lines.  So it seems that even experienced readers could
>     use some clarification.
>
>     The reason for the language selection negotiation is to enable the
>     right individuals and resources to be brought into the
>     conversation so as to maximize the changes of successful
>     communications. What happens once the call is brought up is up to
>     the conversants.
>
>     The precise meaning of the negotiation depends in part on the
>     choice of a single language or multiple languages in the Answer.
>
>     If an offer indicates the ability to receive English and French,
>     if an Answer can only contain a single language, then an Answer
>     indicating the ability to send English would establish that the
>     call is expected to be conducted in English. That wouldn't
>     necessarily preclude the use of French, but doesn't provide any
>     indication that it could be supported as an alternative.
>
>     Whereas if the Answer was allowed to include multiple languages
>     and included both English and French, then the Answer would
>     indicate that the conversation could use either language with a
>     preference for English over French.  That does strike me as
>     potentially valuable in some circumstances (e.g. a visitor from
>     Spain with an emergency offering Spanish primary and English
>     secondary and being able to get an answer indicating English with
>     On Wed, Jan 10, 2018 at 2:35 PM, Gunnar Hellström
>     <[email-masked] <mailto:[email-masked]>>
>     wrote:
>
>         I think a line about that should be inserted, probably best
>         close to the end of the introduction.
>
>         Proposed text:
>         "The result of the negotiation is intended to guide the
>         selection of language(s) to use initially and during the
>         session. However, nothing prevents the users from varying the
>         use of languages and media by mutual agreement after the
>         initial exchange during the call."
>
>         Gunnar
>
>
>
>             The draft is not trying to even capture the full
>             complexity of human language interaction, much less
>             enforce it.  The draft provides a fairly simple mechanism
>             to make it more likely that successful communication can
>             occur, by identifying language needs (which can allow
>             endpoints to take potentially required additional steps,
>             such as bridging in translation or relay services, or
>             having a call handled by someone who known the language(s)
>             or can use the needed media).
>
>             Earlier versions of the draft had more explicit text that
>             the draft did not attempt to capture the full range of
>             human language issues, including the common practice among
>             I do not recall the reasons why the text was simplified,
>             removing mention of multilingual people, and would have to
>             search through minutes of the various WG sessions and
>             email in 2013 where the draft was discussed.  I suspect
>             there was desire to have the draft merely state what it
>             does and doesn't do, and not get into a lot of value
>             judgment discussion.
>
>
>             As you suggest, a media might be desired in both
>             directions even though only one direction is primarily
>             intended for interactive communication.  The draft
>             currently says:
>
>             I will add "Note that the media can still be useful in
>             both directions."  The text thus becomes:
>
>             Yes, it could happen.  For example, if an emergency call
>             comes into a PSAP and requests languages that the PSAP is
>             unable to support, the PSAP will likely want the call to
>             proceed anyway. It's also possible that the callee might
>             support a language that has some degree of mutual
>             comprehensibility to those requested by the caller.  An
>             example might be some Scandinavian languages where the
>             caller does not include a language that is similar enough
>             to have some comprehension but not be fluent enough to
>             include in the UE configuration.
>
>
>             The caller and callee are free to use any of the
>             established media streams.  If a caller requests audio,
>             video (with a sign language), and text, and all three are
>             established, the caller might ignore the text or audio
>             stream and use only the video stream.
>
>             No one made a case for why mandating a particular
>             rejection code was necessary, especially since the draft
>             does not offer any suggestion as to if a call should
>             proceed or fail when there aren't mutually supported
>             languages.
>
>
>         [email-masked] <mailto:[email-masked]>
>         +46 708 204 288 <tel:%2B46%20708%20204%20288>
>
>
>

---

From: Randall Gellens <[email-masked]>
Date: Thu, 11 Jan 2018 07:24:59 -0800

At 8:59 PM -0800 1/10/18, Bernard Aboba wrote:

>  Gunnar said:
>
>  ""The result of the negotiation is intended 
> to guide the selection of language(s) to 
> use initially and during the session. 
> However, nothing prevents the users from 
> varying the use of languages and media by 
> mutual agreement after the initial exchange 
> during the call.""
>
>  [BA] This came from Ben Campbell, but other ADs 
> with many years of experience in realtime 
> communications have asked questions along 
> similar lines.  So it seems that even 
> experienced readers could use some 
> clarification.
>
>  The reason for the language selection 
> negotiation is to enable the right individuals 
> and resources to be brought into the 
> conversation so as to maximize the changes of 
> successful communications. What happens once 
> the call is brought up is up to the conversants.

[RG] We can text along the lines of the above paragraph, as a clarification.

>  The precise meaning of the negotiation depends 
> in part on the choice of a single language or 
> multiple languages in the Answer.
>
>  If an offer indicates the ability to receive 
> English and French, if an Answer can only 
> contain a single language, then an Answer 
> indicating the ability to send English would 
> establish that the call is expected to be 
> conducted in English. That wouldn't necessarily 
> preclude the use of French, but doesn't provide 
> any indication that it could be supported as an 
> alternative.
>
>  Whereas if the Answer was allowed to include 
> multiple languages and included both English 
> and French, then the Answer would indicate that 
> the conversation could use either language with 
> a preference for English over French.  That 
> does strike me as potentially valuable in some 
> circumstances (e.g. a visitor from Spain with 
> an emergency offering Spanish primary and 
> English secondary and being able to get an 
> answer indicating English with secondary 
> Spanish support, rather than just English).

[RG] Choosing among language and modality will 
often require trade-offs.  A call may indicate 
audio with Spanish (most preferred), Italian 
(second choice), and English.  If the call is 
received by a PSAP that has call takers who 
natively speak English but can bridge in Spanish 
translation, accepting English forces the caller 
to use a less-preferred language while accepting 
Spanish forces the call through translation, 
which makes the communication slower and 
typically more difficult, as well as adding cost 
to the PSAP.  If we add modality choice into the 
mix, it becomes more complex, with trade-offs. 
Further, in the example, if the PSAP indicates 
Spanish in the answer, then it will bridge in 
translation services, while if if indicates 
English, it won't; so if it indicates English, it 
wouldn't also indicate Spanish, even if the 
syntax permitted it.

>  In either case, the conversants can switch languages by mutual agreement.

[RG] Conversants are always free to use any language they like.

--Randall

> <<mailto:[email-masked]>[email-masked]> 
> wrote:
>
> translation or relay services, or having a call 
> handled by someone who known the language(s) or 
> can use the needed media).
>
>  Earlier versions of the draft had more explicit 
> text that the draft did not attempt to capture 
> the full range of human language issues, 
> including the common practice among 
> minutes of the various WG sessions and email in 
> 2013 where the draft was discussed.  I suspect 
> there was desire to have the draft merely state 
> what it does and doesn't do, and not get into a 
> lot of value judgment discussion.
>
>  <mailto:[email-masked]>[email-masked]
>  <tel:%2B46%20708%20204%20288>+46 708 204 288
>
>
>

-------------- Randomly selected tag: ---------------
There is hardly anything in the world that some one cannot make a
little worse, and sell a little cheaper.  --John Ruskin (1819-1900)

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 11 Jan 2018 07:43:58 -0800

Randall said:

"Choosing among language and modality will often require trade-offs.  A
call may indicate audio with Spanish (most preferred), Italian (second
choice), and English.  If the call is received by a PSAP that has call
takers who natively speak English but can bridge in Spanish translation,
accepting English forces the caller to use a less-preferred language while
accepting Spanish forces the call through translation, which makes the
communication slower and typically more difficult, as well as adding cost
to the PSAP.  If we add modality choice into the mix, it becomes more
complex, with trade-offs. Further, in the example, if the PSAP indicates
Spanish in the answer, then it will bridge in translation services, while
if if indicates English, it won't; so if it indicates English, it wouldn't
also indicate Spanish, even if the syntax permitted it."

[BA] That makes sense - if putting in secondary languages would require
distinct resources to be allocated then the callee might choose not to.
But I'm wondering if there are circumstances in which it might be valuable
for the Answer to return more than one language, indicating all the
capabilities of the callee endpoint. For example, a call indicating Spanish
(most preferred) and English (second choice) might be routed to a
dispatcher who is bi-lingual in Spanish and English.The Answer could
include just Spanish, but if the callee is bi-lingual and can switch
languages on request without having to bridge in a translator, why can't
the Answer include Spanish (primary) and English (secondary)?

On Thu, Jan 11, 2018 at 7:24 AM, Randall Gellens <[email-masked]>
wrote:

> [RG] Choosing among language and modality will often require trade-offs.
> A call may indicate audio with Spanish (most preferred), Italian (second
> choice), and English.  If the call is received by a PSAP that has call
> takers who natively speak English but can bridge in Spanish translation,
> accepting English forces the caller to use a less-preferred language while
> accepting Spanish forces the call through translation, which makes the
> communication slower and typically more difficult, as well as adding cost
> to the PSAP.  If we add modality choice into the mix, it becomes more
> complex, with trade-offs. Further, in the example, if the PSAP indicates
> Spanish in the answer, then it will bridge in translation services, while
> if if indicates English, it won't; so if it indicates English, it wouldn't
> also indicate Spanish, even if the syntax permitted it.
>
>
>>  On Wed, Jan 10, 2018 at 2:35 PM, Gunnar Hellström <<mailto:
>> [email-masked]>[email-masked]> wrote:
>>

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 11 Jan 2018 19:01:10 +0100

Den 2018-01-11 kl. 16:43, skrev Bernard Aboba:
> Randall said:
>
> "Choosing among language and modality will often require trade-offs.  
> A call may indicate audio with Spanish (most preferred), Italian 
> (second choice), and English.  If the call is received by a PSAP that 
> has call takers who natively speak English but can bridge in Spanish 
> translation, accepting English forces the caller to use a 
> less-preferred language while accepting Spanish forces the call 
> through translation, which makes the communication slower and 
> typically more difficult, as well as adding cost to the PSAP.  If we 
> add modality choice into the mix, it becomes more complex, with 
> trade-offs. Further, in the example, if the PSAP indicates Spanish in 
> the answer, then it will bridge in translation services, while if if 
> indicates English, it won't; so if it indicates English, it wouldn't 
> [BA] That makes sense - if putting in secondary languages would 
> require distinct resources to be allocated then the callee might 
> choose not to.  But I'm wondering if there are circumstances in which 
> it might be valuable for the Answer to return more than one language, 
> indicating all the capabilities of the callee endpoint. For example, a 
> call indicating Spanish (most preferred) and English (second choice) 
> might be routed to a dispatcher who is bi-lingual in Spanish and 
> English.The Answer could include just Spanish, but if the callee is 
> bi-lingual and can switch languages on request without having to 
> bridge in a translator, why can't the Answer include Spanish (primary) 
> and English (secondary)?

<GH>There is one reason for the answerer to only provide one language in 
only one media for hlang-send.
-That is to better prepare the offeror exactly for the language and 
modality the offerer will receive.

But the discussion we have had now has revealed a number of reasons to 
allow more than one.
-Less complexity for the negotiation application. Decision can more 
easily be taken by the application without asking the user.
-Possibility to provide all supported alternatives when there is no 
match. That increases opportunity to find some anyway usable language.
-Prepare for feasible language switch during the call when the initial 
selection did not work well.
-Inform offeror of the options if translating resources will be brought 
in by the offeror after completed negotiation.
-Multiple languages in use.

If we just allow more than one language per media and direction in the 
answer, we do not need to have any normative wording for how the 
application handles it. Those who prefer to send just one language per 
media and direction do so, and those who see value in providing more 
info do.
OK?

>
>
> On Thu, Jan 11, 2018 at 7:24 AM, Randall Gellens 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>          ""The result of the negotiation is intended to guide the
>         initial exchange during the call.""
>
>          [BA] This came from Ben Campbell, but other ADs with many
>         years of experience in realtime communications have asked
>         questions along similar lines.  So it seems that even
>         experienced readers could use some clarification.
>
>          The reason for the language selection negotiation is to
>         enable the right individuals and resources to be brought into
>         the conversation so as to maximize the changes of successful
>         communications. What happens once the call is brought up is up
>         to the conversants.
>
>
>          If an offer indicates the ability to receive English and
>         French, if an Answer can only contain a single language, then
>         an Answer indicating the ability to send English would
>         establish that the call is expected to be conducted in
>         English. That wouldn't necessarily preclude the use of French,
>         but doesn't provide any indication that it could be supported
>         as an alternative.
>
>          Whereas if the Answer was allowed to include multiple
>         languages and included both English and French, then the
>         Answer would indicate that the conversation could use either
>         language with a preference for English over French.  That does
>         strike me as potentially valuable in some circumstances (e.g.
>         a visitor from Spain with an emergency offering Spanish
>         primary and English secondary and being able to get an answer
>         indicating English with secondary Spanish support, rather than
>         just English).
>
>
>     [RG] Choosing among language and modality will often require
>     trade-offs.  A call may indicate audio with Spanish (most
>     preferred), Italian (second choice), and English.  If the call is
>     received by a PSAP that has call takers who natively speak English
>     but can bridge in Spanish translation, accepting English forces
>     the caller to use a less-preferred language while accepting
>     Spanish forces the call through translation, which makes the
>     communication slower and typically more difficult, as well as
>     adding cost to the PSAP.  If we add modality choice into the mix,
>     it becomes more complex, with trade-offs. Further, in the example,
>     if the PSAP indicates Spanish in the answer, then it will bridge
>     in translation services, while if if indicates English, it won't;
>     so if it indicates English, it wouldn't also indicate Spanish,
>     even if the syntax permitted it.
>
>
<GH>Yes, but the whole idea of the negotiation is that the result is of 
guidance for a smooth start of the call, so it is very desirable that 
the users obey the negotiation result initially.

Gunnar
>         <<mailto:[email-masked]
>         <mailto:[email-masked]>>[email-masked]
>         <mailto:[email-masked]>> wrote:
>
>          It was about if the users are bound to use only the
>         negotiated language(s) in the session.
>
>          The draft is not trying to even capture the full complexity
>         of human language interaction, much less enforce it.  The
>         draft provides a fairly simple mechanism to make it more
>         likely that successful communication can occur, by identifying
>         language needs (which can allow endpoints to take potentially
>         required additional steps, such as bridging in translation or
>         relay services, or having a call handled by someone who known
>         the language(s) or can use the needed media).
>
>          Earlier versions of the draft had more explicit text that the
>         draft did not attempt to capture the full range of human
>         language issues, including the common practice among
>         search through minutes of the various WG sessions and email in
>         2013 where the draft was discussed.  I suspect there was
>         desire to have the draft merely state what it does and doesn't
>         do, and not get into a lot of value judgment discussion.
>
>          As you suggest, a media might be desired in both directions
>         even though only one direction is primarily intended for
>         interactive communication.  The draft currently says:
>
>         example might be some Scandinavian languages where the caller
>         does not include a language that is similar enough to have
>         some comprehension but not be fluent enough to include in the
>         UE configuration.
>
>          The caller and callee are free to use any of the established
>         media streams.  If a caller requests audio, video (with a sign
>         language), and text, and all three are established, the caller
>         might ignore the text or audio stream and use only the video
>         stream.
>
>          No one made a case for why mandating a particular rejection
>         code was necessary, especially since the draft does not offer
>         any suggestion as to if a call should proceed or fail when
>         there aren't mutually supported languages.
>
>
>          <mailto:[email-masked]
>         <mailto:[email-masked]>>[email-masked]
>         <mailto:[email-masked]>
>         <tel:%2B46%20708%20204%20288>
>
>
>
>         [email-masked] <mailto:[email-masked]>
>         <https://www.ietf.org/mailman/listinfo/slim>
>
>
>
>     -- 
>     Randall Gellens

---

From: Randall Gellens <[email-masked]>
Date: Thu, 11 Jan 2018 11:30:05 -0800

Of the two remaining open questions, one is if we need to add text to 
explicitly say that negotiation doesn't restrict what people do on a 
call.  I do not believe we need to add such text.  However, if we 
were to add text, here is a proposal to add to the Introduction:

     Language negotiation is intended to better enable interactive
     communications (e.g., by allowing needed individuals or resources
     to be part of a call); it does not attempt to describe the full
     complexity of human conversation nor restrict what conversants do
     during a call.

As I said in the email thread, I do not see any harm in leaving the 
draft as-is, but I also won't strongly object to adding the above.

-------------- Randomly selected tag: ---------------
Computers ... are not designed, as we are, for ambiguity.  --Thomas

---

From: Randall Gellens <[email-masked]>
Date: Thu, 11 Jan 2018 11:57:27 -0800

The second of the two remaining open questions is if we should allow 
an answer to contain multiple values.  I do not think this is the 
intent of the text that has been in the draft for some time; 
regardless, we could make such a change, but I question if we can do 
so now, when we've essentially passed IESG review.

I edited a version of the draft that contains all remaining 
clarifying editorial changes to also make this technical change and 
attached is a diff showing what it would look like.  However, I think 
we should not make the change since it could introduce additional 
complexities or problems that we aren't considering.  I think we 
could make such a change in a future extension or revision.  I don't 
think we'd have an interoperability problem since endpoints 
conformant with the more restrictive version will not generate such 
answers, and would regard regard receiving such answers as an error, 
but not one that would fail a call.

-------------- Randomly selected tag: ---------------
[XML] is probably the worst format ever designed...it really doesn't scale as a
file format, and it's generally a complete disaster. --Linus Torvalds, 3/6/2014

---

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

I realized an additional change was needed, to the discussion of the 
offer/answer model.  Attached is a revised diff.

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

>  The second of the two remaining open questions is if we should 
> allow an answer to contain multiple values.  I do not think this is 
> the intent of the text that has been in the draft for some time; 
> regardless, we could make such a change, but I question if we can 
> do so now, when we've essentially passed IESG review.
>
> attached is a diff showing what it would look like.  However, I 
> think we should not make the change since it could introduce 
> additional complexities or problems that we aren't considering.  I 
> think we could make such a change in a future extension or 
> revision.  I don't think we'd have an interoperability problem 
> since endpoints conformant with the more restrictive version will 
> not generate such answers, and would regard regard receiving such 
> answers as an error, but not one that would fail a call.
>
>  --
>  Randall Gellens
>  Attachment converted: TiLand:diff-with-multiple 1.pdf (    /    ) (008B9E88)

-------------- Randomly selected tag: ---------------
Those were my children being slaughtered.
        --Donald Burr, on the death of People Express.

---

From: Gunnar Hellström <[email-masked]>
Date: Fri, 12 Jan 2018 11:54:00 +0100

>> so now, when we've essentially passed IESG review.
<GH> The IESG review started on version -19, where we had normative 
language for allowing multiple languages per media and direction, and 
non-normative but quite clear wording (using "is" ) for saying that the 
intention is to have one language per media and direction intended for use.

When this difference was questioned, you changed the normative language, 
while others suggested to change the non-normative language. I still 
think that it would be better to change the non-normative language so 
that multiple languages per media and direction are allowed. I do not 
see how that would conflict the review situation, but we might need a 
judgment on that from the reviewers.

I provided one reason yesterday why it would be better to only have one 
language in the answer, but I now realize that that was false. I said 
that one language provides better opportunity for the offeror to prepare 
for receiving the selected language.  But even if the answer contains 
more than one language, the answering party should still follow the 
order of preference, and start the call using the first language in the 
hlang-send attribute in the media in the answer selected for use. So, 
all arguments point at it being better to allow more than one language 
in the answer per media and direction.

It also solves an unfair difference we have, that it is possible to list 
more than one language per direction if you include languages in 
different media, but not for a single media. I see no logical reason for 
that difference, and I do not want to give up the freedom to indicate 
support of language in multiple media for the same direction.

The offeror has the best opportunity for assessing which extra resources 
would be needed in the call after receiving the answer. I know that 
there may currently be economical and policy obstacles for making use of 
that opportunity, but it would be sad to block it by not providing the 
full view of the support in the answer.

I find the diff you sent to be good, and also version -23 solving all 
other issues in a good way. So, I vote for applying your proposed 
changes on -23 and hope that that can be the final version.

--------------------------------------------------------------------------------------------------------------------------------------------------
I also want to throw in food for thought, that I realize is too late in 
the process, but still worth thinking about:
We could just as well have defined attributes only for the directions of 
use of the media for language, and let the "lang" attribute list the 
languages. The "lang" attribute has a better definition in rfc4566bis 
than before, and the main improvement we provide is that we can indicate 
direction of use of the language. We recommend strongly against having 
different preferences and languages in the different directions of a 
media, so one language list would be sufficient per media, and the new 
attributes could be limited to use a selection of a=hlang-send  and 
a=hlang-recv per media without their own language lists.  Sorry for the 
late discovery of this condition.
---------------------------------------------------------------------------------------------------------------------------------------------------------
Gunnar

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 12 Jan 2018 07:44:34 -0800

Gunnar said:

"<GH> The IESG review started on version -19, where we had normative
language for allowing multiple languages per media and direction, and
non-normative but quite clear wording (using "is" ) for saying that the
intention is to have one language per media and direction intended for use.

When this difference was questioned, you changed the normative language,
while others suggested to change the non-normative language. I still think
that it would be better to change the non-normative language so that
multiple languages per media and direction are allowed. I do not see how
that would conflict the review situation, but we might need a judgment on
that from the reviewers. "

[BA]  Yes, -19 did not have normative language about the number of
languages in the Answer and the ABNF allowed multiple languages.  Also, -19
did not have normative language about whether the languages in the Answer
need to be present in the Offer.  The closest (from -23) is this sentence:

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

Section 5.4 includes an example Answer which includes Italian in response
to an Offer of Spanish, Basque and English.

On Fri, Jan 12, 2018 at 2:54 AM, Gunnar Hellström <
[email-masked]> wrote:

>  The second of the two remaining open questions is if we should allow an
> answer to contain multiple values.  I do not think this is the intent of
> the text that has been in the draft for some time; regardless, we could
> make such a change, but I question if we can do so now, when we've
> essentially passed IESG review.
>
> while others suggested to change the non-normative language. I still think
> that it would be better to change the non-normative language so that
> multiple languages per media and direction are allowed. I do not see how
> that would conflict the review situation, but we might need a judgment on
> that from the reviewers.
>
> language in the answer, but I now realize that that was false. I said that
> one language provides better opportunity for the offeror to prepare for
> receiving the selected language.  But even if the answer contains more than
> one language, the answering party should still follow the order of
> preference, and start the call using the first language in the hlang-send
> attribute in the media in the answer selected for use. So, all arguments
> point at it being better to allow more than one language in the answer per
> media and direction.
>
> more than one language per direction if you include languages in different
> media, but not for a single media. I see no logical reason for that
> difference, and I do not want to give up the freedom to indicate support of
> language in multiple media for the same direction.
>
> would be needed in the call after receiving the answer. I know that there
> may currently be economical and policy obstacles for making use of that
> opportunity, but it would be sad to block it by not providing the full view
> of the support in the answer.
>
> other issues in a good way. So, I vote for applying your proposed changes
> on -23 and hope that that can be the final version.
>
> ------------------------------------------------------------
> ------------------------------------------------------------
> --------------------------
> languages. The "lang" attribute has a better definition in rfc4566bis than
> before, and the main improvement we provide is that we can indicate
> different preferences and languages in the different directions of a media,
> so one language list would be sufficient per media, and the new attributes
> could be limited to use a selection of a=hlang-send  and a=hlang-recv per
> media without their own language lists.  Sorry for the late discovery of
> this condition.
> ------------------------------------------------------------
> ------------------------------------------------------------
> ---------------------------------
> Gunnar
>
>
>  I edited a version of the draft that contains all remaining clarifying
> editorial changes to also make this technical change and attached is a diff
> showing what it would look like.  However, I think we should not make the
> change since it could introduce additional complexities or problems that we
> aren't considering.  I think we could make such a change in a future
> extension or revision.  I don't think we'd have an interoperability problem
> since endpoints conformant with the more restrictive version will not
> generate such answers, and would regard regard receiving such answers as an
> error, but not one that would fail a call.
>
>
>
>  --
>  Randall Gellens
> SLIM mailing [email-masked]://www.ietf.org/mailman/listinfo/slim
>
>
> --
> [email-masked]
> +46 708 204 288
>
>

---

From: Randall Gellens <[email-masked]>
Date: Fri, 12 Jan 2018 11:51:39 -0800

Bernard: Version -23 was uploaded yesterday.  So the only issue 
remains: do we proceed with -23 or do I upload the version that 
permits multiple values in an answer (per the diff I sent)?

-------------- Randomly selected tag: ---------------
In the long-run every Government is the exact symbol of its People,
with their wisdom and unwisdom. --Thomas Carlyle, _Past and Present_