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

[Adam Roach <[e-mail]>]

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
>
>     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] <mailto:[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
>     <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."
>
>