Subject: [Slim] draft-ietf-slim-negotiating-human-language: Issue 38

From: Bernard Aboba <[email-masked]>
Date: Wed, 12 Jul 2017 10:11:11 -0700

In reviewing open tickets
against draft-ietf-slim-negotiating-human-language, it appears to me that
Issue 38 remains unresolved.

This issue was raised by ART AD Adam Roach in his review: ​
https://mailarchive.ietf.org/arch/msg/slim/fZmbXKtwn1771DoZhh1Kt_kUWf4

" Aside -- I have a concern that negotiating language in SDP rather

than SIP makes it necessary for proxies to look into SDP to make
routing decisions, which is a pretty substantial layer violation
(keep in mind, for example, that SIP was originally envisioned to
contain S/MIME encrypted bodies, which would render the SDP
unreadable by proxies). However, I note that section 5.1 indicates
that this has issue been litigated in the working group already, and
that it chose to do things in the way documented in the current draft."

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 12 Jul 2017 10:12:36 -0700

To resolve Issue 38 which arose from Adam Roach's review, I would like to
suggest the following revision for Section 1 and introduction of a new
applicability section 1.1 as follows:

   1. Introduction

A mutually comprehensive language is helpful for human communication.
This document addresses the negotiation of human (natural) language
and media modality (spoken, signed, written) in real-time communications.
A companion document [I-D.ietf-slim-multilangcontent] addresses
language selection in email.

Unless the caller and callee know each other or there is contextual or
out-of-
band information from which the language(s) and media modalities can
be determined, there is a need for spoken, signed, or written languages
to be negotiated based on the caller's needs and the callee's capabilities.
This need applies to both emergency and non-emergency calls.
For example, it is helpful for a caller to a company call center
or a Public Safety Answering Point (PSAP) to be able to indicate
preferred signed, written, and/or spoken languages, and for the callee
to be able to indicate its capabilities in this area, allowing
the call to proceed using the language(s) and media forms supported by both.

For various reasons, including the ability to
establish multiple streams using different media (e.g., voice, text,
video), it makes sense to use a per-stream negotiation mechanism known
as the Session Description Protocol (SDP). Utilizing SDP enables
the solution described in this document to be applied to all
interactive communications negotiated using SDP, in emergency as well
as non-emergency scenarios.

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 requires a voice stream plus
a text stream. 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).

Since this is a protocol mechanism, the user equipment (UE client)
needs to know the user's preferred languages; a reasonable technique
could include a configuration mechanism with a default of the
language of the user interface. In some cases, a UE could tie
language and media preferences, such as a preference for a video
stream using a signed language and/or a text or audio stream using a
written/spoken language.

1.1 Applicability

Within this document, it is assumed that the negotiating endpoints
have already been determined, so that a per-stream negotiation
based on the Session Description Protocol (SDP) can proceed.

However, when setting up interactive communications sessions it
is first necessary to route signaling messages to the appropriate
endpoint(s). This document does not address the problem of
language-based routing. In order to enable intermediaries to make
make routing decisions based on language and media capabilities,
future documents may define extensions to the Session Initiation
Protocol (SIP).

On Wed, Jul 12, 2017 at 10:11 AM, Bernard Aboba <[email-masked]>
wrote:

> In reviewing open tickets against draft-ietf-slim-negotiating-human-language,
> it appears to me that Issue 38 remains unresolved.
>

---

From: Adam Roach <[email-masked]>
Date: Wed, 12 Jul 2017 12:21:24 -0500

Thanks. The text in 1.1, in particular, addresses my concern. The rest 
of the revisions look good as well.

/a

On 7/12/17 12:12, Bernard Aboba wrote:
>
> To resolve Issue 38 which arose from Adam Roach's review, I would like 
> to suggest the following revision for Section 1 and introduction of a 
> new applicability section 1.1 as follows:
>
>  1. Introduction
>
>     Unless the caller and callee know each other or there is
>     contextual or out-of-
> On Wed, Jul 12, 2017 at 10:11 AM, Bernard Aboba 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     against draft-ietf-slim-negotiating-human-language, it appears to
>     me that Issue 38 remains unresolved.
>
>     This issue was raised by ART AD Adam Roach in his review:
>     ​https://mailarchive.ietf.org/arch/msg/slim/fZmbXKtwn1771DoZhh1Kt_kUWf4
>     <https://mailarchive.ietf.org/arch/msg/slim/fZmbXKtwn1771DoZhh1Kt_kUWf4>
>

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 13 Jul 2017 09:41:51 +0200

Bernard,

I do not like the last sentence of 1.1. A long time ago, I stopped 
arguing for a SIP based solution when I realized that SDP is more often 
used than SIP in the WebRTC environment. Basing it on SDP makes it 
easier to convey the language and modality needs across the SIP / WebRTC 
border. (There is a complication that real-time text is an RTP stream on 
the SIP side and a multiplexed data channel on the WebRTC side, but 
there are solutions defined for handling SDP attribute conveyance for 
such situations. )

Indicating that a SIP solution may follow kind of invalidates the whole 
work we have done. I prefer to just leave out the last sentence in 1.1. 
Saying that routing is out-of-scope for this document is sufficient.

Gunnar

Den 2017-07-12 kl. 19:21, skrev Adam Roach:
>> To resolve Issue 38 which arose from Adam Roach's review, I would 
>> like to suggest the following revision for Section 1 and introduction 
>> of a new applicability section 1.1 as follows:
>>
>>  1. Introduction
>>
> _______________________________________________
> SLIM mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/slim

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

---

From: Randall Gellens <[email-masked]>
Date: Thu, 13 Jul 2017 09:12:08 -0700

At 10:11 AM -0700 7/12/17, Bernard Aboba wrote:

> against draft-ietf-slim-negotiating-human-language, 
>  This issue was raised by ART AD Adam Roach in 
> his 
> review: <https://mailarchive.ietf.org/arch/msg/slim/fZmbXKtwn1771DoZhh1Kt_kUWf4>Ðhttps://mailarchive.ietf.org/arch/msg/slim/fZmbXKtwn1771DoZhh1Kt_kUWf4
>

The group explicitly decided to keep routing out 
of scope of this draft.  Section 1 says:

    To reduce the complexity of the solution, this document focuses on
    negotiating language per media; routing is out of scope.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
When I was younger, I could remember anything, whether it had
happened or not.                                --Mark Twain

---

From: Randall Gellens <[email-masked]>
Date: Thu, 13 Jul 2017 09:25:18 -0700

At 10:12 AM -0700 7/12/17, Bernard Aboba wrote:

>  To resolve Issue 38 which arose from Adam Roach's review,

I am not clear on why we need to say more than 
what we already say, which is that routing is out 
of scope.

>   I would like to suggest the following revision 
> for Section 1 and introduction of a new 

>  A mutually comprehensive language is helpful for human communication.

Why do you want to change "comprehensible" to "comprehensive"?

>  Unless the caller and callee know each other or 
> there is contextual or out-of-

Aside from "comprehensive," the rest of this text looks fine.

>  future documents may define extensions to the Session Initiation

I'd suggest deleting the last sentence, as I 
don't see the benefit of speculating in this 
draft on what future drafts might do.

--Randy

> <<mailto:[email-masked]>[email-masked]> 
> wrote:
>

-------------- Randomly selected tag: ---------------
Beware of programmers who carry screwdrivers.  --Leonard Brandwein

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 13 Jul 2017 10:09:25 -0700

Gunnar said:

" A long time ago, I stopped arguing for a SIP based solution when I
realized that SDP is more often used than SIP in the WebRTC environment.
Basing it on SDP makes it easier to convey the language and modality needs
across the SIP / WebRTC border. (There is a complication that real-time
text is an RTP stream on the SIP side and a multiplexed data channel on the
WebRTC side, but there are solutions defined for handling SDP attribute
conveyance for such situations. ). Indicating that a SIP solution may
follow kind of invalidates the whole work we have done."

[BA]  The group did indeed converge on SDP as the mechanism to negotiate
language and media modality (the subject of the draft).  As I read it, the
SDP Directorate review is not a request to reconsider that decision, but
rather a request for the document to more clearly indicate that SDP is not
being proposed as a solution to the routing problem.

"I prefer to just leave out the last sentence in 1.1. Saying that routing
is out-of-scope for this document is sufficient."

[BA]  Adam and Gunnar - Would the following work?

1.1 Applicability

However, when setting up interactive communications sessions it
is first necessary to route signaling messages to the appropriate
endpoint(s). This document does not address the problem of
routing based on language and media capabilities.

On Thu, Jul 13, 2017 at 12:41 AM, Gunnar Hellström <
[email-masked]> wrote:

> Bernard,
>
> I do not like the last sentence of 1.1. A long time ago, I stopped arguing
> for a SIP based solution when I realized that SDP is more often used than
> SIP in the WebRTC environment. Basing it on SDP makes it easier to convey
> the language and modality needs across the SIP / WebRTC border. (There is a
> complication that real-time text is an RTP stream on the SIP side and a
> multiplexed data channel on the WebRTC side, but there are solutions
> defined for handling SDP attribute conveyance for such situations. )
>
> Thanks. The text in 1.1, in particular, addresses my concern. The rest of
> the revisions look good as well.
>
> /a
>
> On Wed, Jul 12, 2017 at 10:11 AM, Bernard Aboba <[email-masked]
> <mailto:[email-masked]> <[email-masked]>> wrote:
>
> SLIM mailing [email-masked]://www.ietf.org/mailman/listinfo/slim
>
>
> --
> [email-masked]
> +46 708 204 288
>
>

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 13 Jul 2017 22:33:55 +0200

> [BA]  Adam and Gunnar - Would the following work?
Yes it works, and it is better than the wording in version 0.12

/Gunnar

---

From: Adam Roach <[email-masked]>
Date: Thu, 13 Jul 2017 16:34:39 -0500

I'm okay with this formulation. 

/a

> On Jul 13, 2017, at 12:09, Bernard Aboba <[email-masked]> wrote:
> 
> Gunnar said: 
> 
> " A long time ago, I stopped arguing for a SIP based solution when I realized that SDP is more often used than SIP in the WebRTC environment. Basing it on SDP makes it easier to convey the language and modality needs across the SIP / WebRTC border. (There is a complication that real-time text is an RTP stream on the SIP side and a multiplexed data channel on the WebRTC side, but there are solutions defined for handling SDP attribute conveyance for such situations. ). Indicating that a SIP solution may follow kind of invalidates the whole work we have done."
> 
> [BA]  The group did indeed converge on SDP as the mechanism to negotiate language and media modality (the subject of the draft).  As I read it, the SDP Directorate review is not a request to reconsider that decision, but rather a request for the document to more clearly indicate that SDP is not being proposed as a solution to the routing problem. 
> 
> "I prefer to just leave out the last sentence in 1.1. Saying that routing is out-of-scope for this document is sufficient."
> 
>> On Thu, Jul 13, 2017 at 12:41 AM, Gunnar Hellström <[email-masked]> wrote:
>> Bernard,
>> 
>> I do not like the last sentence of 1.1. A long time ago, I stopped arguing for a SIP based solution when I realized that SDP is more often used than SIP in the WebRTC environment. Basing it on SDP makes it easier to convey the language and modality needs across the SIP / WebRTC border. (There is a complication that real-time text is an RTP stream on the SIP side and a multiplexed data channel on the WebRTC side, but there are solutions defined for handling SDP attribute conveyance for such situations. )
>> Indicating that a SIP solution may follow kind of invalidates the whole work we have done. I prefer to just leave out the last sentence in 1.1. Saying that routing is out-of-scope for this document is sufficient.
>> 
>> Gunnar
>> 
>> 
>>> Thanks. The text in 1.1, in particular, addresses my concern. The rest of the revisions look good as well. 
>>> 
>>> /a 
>>> 
>>>> To resolve Issue 38 which arose from Adam Roach's review, I would like to suggest the following revision for Section 1 and introduction of a new applicability section 1.1 as follows: 
>>>> 
>>>>  1. Introduction 
>>>> 
>>>> On Wed, Jul 12, 2017 at 10:11 AM, Bernard Aboba <[email-masked] <mailto:[email-masked]>> wrote: 
>>>>

---

From: Adam Roach <[email-masked]>
Date: Thu, 13 Jul 2017 16:34:39 -0500

/a