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

[Gunnar Hellström <[e-mail]>]

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:
> 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."
>>
>>
>
>
>
>
> _______________________________________________
> SLIM mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/slim

-- 
-----------------------------------------
Gunnar Hellström
Omnitor
[e-mail]
[phone]