Re: [Slim] Eric Rescorla's No Objection on draft-ietf-slim-negotiating-human-language-19: (with COMMENT)

Randall Gellens <rg+ietf@randy.pensive.org> Tue, 09 January 2018 16:46 UTC

Return-Path: <rg+ietf@randy.pensive.org>
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFA42127137 for <slim@ietfa.amsl.com>; Tue, 9 Jan 2018 08:46:23 -0800 (PST)
X-Quarantine-ID: <bGT9v3mYcwmW>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bGT9v3mYcwmW for <slim@ietfa.amsl.com>; Tue, 9 Jan 2018 08:46:21 -0800 (PST)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 6066712706D for <slim@ietf.org>; Tue, 9 Jan 2018 08:46:21 -0800 (PST)
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Tue, 9 Jan 2018 08:46:53 -0800
Mime-Version: 1.0
Message-Id: <p06240602d67aa208e6a1@[99.111.97.136]>
In-Reply-To: <d556fd95-991a-635c-d513-265135b75b11@omnitor.se>
References: <151528917109.10947.12045320996364596931.idtracker@ietfa.amsl.com> <CABcZeBNQLuaMLa3=gWqaYHL_ynQ1t+HRtsgEebCRORm+OUA0iw@mail.gmail.com> <ECD0168D-9C53-4ACA-BF28-C631DAE38A4D@gmail.com> <CABcZeBPwb5LzCEpaOMbR9CeETHSZiigovkTMhKm_3K=hsWZckA@mail.gmail.com> <p06240601d6785f2e3ad4@99.111.97.136> <CABcZeBNX4iTuvuqvvqjAQEgnhkV4f5Z1e8Ac2ebWOf=prAcPKg@mail.gmail.com> <p06240603d6795cbba847@99.111.97.136> <CABcZeBPsXfPGBRMTRJSNZiHaXA8dT1MYXsU+3GdPsmLyQHZigg@mail.gmail.com> <p06240605d679600b6eea@[99.111.97.136]> <p06240606d67963d25192@[99.111.97.136]> <2d4be9b6-08d0-236e-4230-6ebc12b4167b@alum.mit.edu> <p06240608d679789e3190@[99.111.97.136]> <4a2b52ff-3853-b159-6563-018e4080eb53@omnitor.se> <p06240609d6799905c9c0@[99.111.97.136]> <d556fd95-991a-635c-d513-265135b75b11@omnitor.se>
X-Mailer: Eudora for Mac OS X
Date: Tue, 9 Jan 2018 08:46:18 -0800
To: Gunnar =?iso-8859-1?Q?Hellstr=F6m?= <gunnar.hellstrom@omnitor.se>, Paul Kyzivat <pkyzivat@alum.mit.edu>, Eric Rescorla <ekr@rtfm.com>
From: Randall Gellens <rg+ietf@randy.pensive.org>
Cc: "slim@ietf.org" <slim@ietf.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/slim/eOALt4S3_ZpvkdGSIoUJJPARbGw>
Subject: Re: [Slim] Eric Rescorla's No Objection on draft-ietf-slim-negotiating-human-language-19: (with COMMENT)
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Selection of Language for Internet Media <slim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/slim>, <mailto:slim-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/slim/>
List-Post: <mailto:slim@ietf.org>
List-Help: <mailto:slim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/slim>, <mailto:slim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Jan 2018 16:46:24 -0000

I do not agree that changes are needed now.  I 
also do not agree that, in general, it is 
difficult to relax restrictions in future 
extensions or updates.  In my experience, it is 
much easier to relax a restriction than it is to 
introduce it.

At 9:55 AM +0100 1/9/18, Gunnar Hellström wrote:

>  Den 2018-01-08 kl. 23:02, skrev Randall Gellens:
>>  At 10:38 PM +0100 1/8/18, Gunnar Hellström wrote:
>>
>>>   Den 2018-01-08 kl. 20:38, skrev Randall Gellens:
>>>>   At 1:36 PM -0500 1/8/18, Paul Kyzivat wrote:
>>>>
>>>>>    On 1/8/18 1:10 PM, Randall Gellens wrote:
>>>>>
>>>>>>        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).
>>>>>
>>>>>    Certainly it will be common for the 
>>>>> choices are mutually exclusive. For 
>>>>> instance, a caller *might* offer both 
>>>>> French and Chinese. The callee (a call 
>>>>> center) may have agents that speak each, 
>>>>> but may well not have any agents that speak 
>>>>> both.
>>>>>
>>>>>    OTOH, it is *possible* that they do have 
>>>>> somebody who supports both. If so, seems 
>>>>> like it would be good to indicate that both 
>>>>> are supported.
>>>>
>>>>   Yes, although the additional gain in 
>>>> functionality is small relative to the 
>>>> additional complexity.  The draft explicitly 
>>>> rules this out of scope.  Section 3 says:
>>>>
>>>>      (Negotiating multiple simultaneous languages within a media stream is
>>>>      out of scope of this document.)
>>>   <GH> No, that is a different thing. We have 
>>> agreed and made efforts to express that 
>>> providing multiple language indications per 
>>> direction does not imply that they all must 
>>> be used simultaneously. They (usually) only 
>>> form a list to select from for use in the 
>>> session.
>>>
>>>   I have many times during our discussions 
>>> thought about the proposal that Paul made 
>>> now, and wondered if we gain or lose by 
>>> having the restriction of only one language 
>>> per media and direction in the answer. We 
>>> might have higher complexity and longer delay 
>>> before the answer when we have the current 
>>> limitation. This  is because it can be hard 
>>> for the application to take the decision on 
>>> its own on the single language to indicate in 
>>> the answer, and therefore a user interaction 
>>> needed to ask the user how to answer. If 
>>> support of more than one language per media 
>>> and direction is allowed (but not 
>>> simultaneously), then it is easier to make an 
>>> automatic match by the device and include all 
>>> common languages in the answer.
>>>
>>>   However including more than one language per 
>>> media and direction in the answer puts the 
>>> users in more uncertainty about in what 
>>> language the session will begin.
>>>
>>>   We could allow indication of multiple 
>>> languages per media and direction in the 
>>> answer and let the application decide if it 
>>> shall make it easy for itself by indicating 
>>> all common languages or easy for the users by 
>>> indicating one language per media and 
>>> direction.
>>>
>>>   We also have the wording that the languages 
>>> in the answer does not need to be selected 
>>> from what was provided in the offer by the 
>>> formulation: "(which in most cases is one of 
>>> the languages in the offer's 'hlang-recv') 
>>> etc."
>>
>>  This is because there may be no languages in 
>> common but the call proceeds anyway.  The 
>> usual example is an emergency call placed by a 
>> user who does not speak any language that the 
>> PSAP can support, even with language 
>> translation services. Just being able to hear 
>> what is happening may be useful to the PSAP 
>> call taker, better than not having a call at 
>> all.
>  <GH> No, the parenthesis introduces an 
> important opportunity for the answerer to 
> propose a language that was not in the offer, 
> but may be possible to use as a first try for 
> getting some communication going anyway. That 
> can be beneficial for both sending and 
> receiving. If it does not work for the users, 
> they are free to try other alternatives during 
> the session.
>
>  A question: Do you regard it to also be allowed 
> for the answerer to include a language in a 
> media that had no hlang attribute in the offer? 
> Imagine a hearing caller offering only spoken 
> languages in audio, but including text media in 
> the offer, calling a deaf person who cannot use 
> spoken language, and therefore takes a chance 
> to include written language indication in text 
> media.  The ABNF in -20 allows it, and my 
> interpretation of the wording in 5.2 is that it 
> is allowed. There may be other views.
>  The clean way is of course to accept the call 
> without languages and make a re-INVITE with 
> languages in text media so that a complete 
> language negotiation can be performed, but that 
> adds complexity.
>
>  RFC 4796 has specific wording to tell that the 
> content attribute is allowed in an answer even 
> if it did not appear in the offer. Maybe we 
> should have had a similar statement.
>
>>
>>>
>>>   When there is no match, maybe the answerer 
>>> want to indicate all support it has, for 
>>> example expressing in response to a request 
>>> to use Spanish:  "No, I cannot understand 
>>> Spanish but I can understand spoken 
>>> Portuguese and French and Italian", in a hope 
>>> to get a conversation going.
>>>
>>>   In summary: I support Paul's proposal to 
>>> relax the rules and leave to the application 
>>> to decide how to compose the answer.
>>
>>  The current limitation has been agreed by the 
>> working group.  I see Paul's suggestion as a 
>> trade-off between a capability that might be 
>> nice to have but is not required, and 
>> additional complexity; I do not see it as a 
>> significant defect.  It is not a show-stopper. 
>> It could be relaxed in a future extension or 
>> revision. Consider how many years we have been 
>> trying to get this simple feature published so 
>> it can be used.  And now, finally, after so 
>> many arguments (many of which were pointless) 
>> and so many revisions, and so much debate over 
>> simple wording, you propose that we go back to 
>> the WG and reopen debate and restart the 
>> series of last calls and discussions.  I think 
>> this is a mistake.  I object to it.
>  <GH>The discussion and proposal was just a 
> result of the difference between the wording 
> about the answer and the wording about the 
> syntax in 5.2. Selection of one of the 
> interpretations was needed. It would be less 
> complex for the applications to allow multiple 
> languages in the attribute in the answer than 
> deciding on one single language. That could 
> save the need for complex user interaction to 
> make the decision. The wording does not require 
> simultaneous use during the session that is 
> said to be out of scope. It is only that the 
> possible alternatives would be indicated to the 
> offeror in order of preference.
>  It may however increase the complexity for the 
> users to take the decision instead of being 
> told by the application which language to use, 
> so it would be best to leave it to the 
> application to decide on how many alternatives 
> are provided in the answer.
>  I do not think that the WG has been very 
> specific about this choice since both 
> interpretations have been there for a long time 
> in the draft.
>  It is hard to relax restrictions in later 
> revisions. Without protocol preparations for 
> extensions, interop problems are easily 
> introduced.
>
>  /Gunnar
>>
>>>
>>>>
>>>>   This could, of course, be added in a future extension or revision.
>>>>
>>>>>
>>>>>        Thanks,
>>>>>        Paul
>>>>>
>>>>>    _______________________________________________
>>>>>    SLIM mailing list
>>>>>    SLIM@ietf.org
>>>>>    https://www.ietf.org/mailman/listinfo/slim
>>>>
>>>>
>>>
>>>   --
>>>   -----------------------------------------
>>>   Gunnar Hellström
>>>   Omnitor
>>>   gunnar.hellstrom@omnitor.se
>>>   +46 708 204 288
>>>
>>>   _______________________________________________
>>>   SLIM mailing list
>>>   SLIM@ietf.org
>>>   https://www.ietf.org/mailman/listinfo/slim
>>
>>
>
>  --
>  -----------------------------------------
>  Gunnar Hellström
>  Omnitor
>  gunnar.hellstrom@omnitor.se
>  +46 708 204 288
>
>  _______________________________________________
>  SLIM mailing list
>  SLIM@ietf.org
>  https://www.ietf.org/mailman/listinfo/slim


-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
I loathe housework.  You make beds, wash dishes
-- and six months later you have to start all over again.
                                           --Joan Rivers