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

Randall Gellens <> Tue, 09 January 2018 16:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CFA42127137 for <>; Tue, 9 Jan 2018 08:46:23 -0800 (PST)
X-Quarantine-ID: <bGT9v3mYcwmW>
X-Virus-Scanned: amavisd-new at
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -1.909
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bGT9v3mYcwmW for <>; Tue, 9 Jan 2018 08:46:21 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 6066712706D for <>; Tue, 9 Jan 2018 08:46:21 -0800 (PST)
Received: from [] ( by with ESMTP (EIMS X 3.3.9); Tue, 9 Jan 2018 08:46:53 -0800
Mime-Version: 1.0
Message-Id: <p06240602d67aa208e6a1@[]>
In-Reply-To: <>
References: <> <> <> <> <p06240601d6785f2e3ad4@> <> <p06240603d6795cbba847@> <> <p06240605d679600b6eea@[]> <p06240606d67963d25192@[]> <> <p06240608d679789e3190@[]> <> <p06240609d6799905c9c0@[]> <>
X-Mailer: Eudora for Mac OS X
Date: Tue, 09 Jan 2018 08:46:18 -0800
To: Gunnar Hellström <>, Paul Kyzivat <>, Eric Rescorla <>
From: Randall Gellens <>
Cc: "" <>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format="flowed"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [Slim] Eric Rescorla's No Objection on draft-ietf-slim-negotiating-human-language-19: (with COMMENT)
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Selection of Language for Internet Media <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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
>>>   --
>>>   -----------------------------------------
>>>   Gunnar Hellström
>>>   Omnitor
>>>   +46 708 204 288
>>>   _______________________________________________
>>>   SLIM mailing list
>  --
>  -----------------------------------------
>  Gunnar Hellström
>  Omnitor
>  +46 708 204 288
>  _______________________________________________
>  SLIM mailing list

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