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

[Bernard Aboba <[e-mail]>]

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 <[e-mail]>
wrote:

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