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

[Randall Gellens <[e-mail]>]

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 
> applicability section 1.1 as follows:



>
>  1.	Introduction
>
>  A mutually comprehensive language is helpful for human communication.

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


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

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

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

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

>
>
>  On Wed, Jul 12, 2017 at 10:11 AM, Bernard Aboba 
> <<mailto:[e-mail]>[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


-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Beware of programmers who carry screwdrivers.  --Leonard Brandwein