Re: [Slim] Ben Campbell's Yes on draft-ietf-slim-negotiating-human-language-22: (with COMMENT)

Randall Gellens <rg+ietf@randy.pensive.org> Wed, 10 January 2018 22:56 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 2BD28129C51; Wed, 10 Jan 2018 14:56:15 -0800 (PST)
X-Quarantine-ID: <FdrPtcFqTdgs>
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.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 FdrPtcFqTdgs; Wed, 10 Jan 2018 14:56:13 -0800 (PST)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id B9B051241FC; Wed, 10 Jan 2018 14:56:12 -0800 (PST)
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Wed, 10 Jan 2018 14:56:45 -0800
Mime-Version: 1.0
Message-Id: <p06240609d67c4a3651cc@[99.111.97.136]>
In-Reply-To: <2c49d430-3fb1-381f-d236-4bc5a6a38c27@omnitor.se>
References: <151555808122.21584.8379796998643581181.idtracker@ietfa.amsl.com> <p06240602d67be148b9db@[99.111.97.136]> <2c49d430-3fb1-381f-d236-4bc5a6a38c27@omnitor.se>
X-Mailer: Eudora for Mac OS X
Date: Wed, 10 Jan 2018 14:56:10 -0800
To: Gunnar =?iso-8859-1?Q?Hellstr=F6m?= <gunnar.hellstrom@omnitor.se>, Ben Campbell <ben@nostrum.com>, The IESG <iesg@ietf.org>
From: Randall Gellens <rg+ietf@randy.pensive.org>
Cc: slim@ietf.org, draft-ietf-slim-negotiating-human-language@ietf.org, slim-chairs@ietf.org, bernard.aboba@gmail.com
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/OAGj3XHUTZRWLf0hKcHK2DBTX6s>
Subject: Re: [Slim] Ben Campbell's Yes on draft-ietf-slim-negotiating-human-language-22: (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: Wed, 10 Jan 2018 22:56:15 -0000

It was Ben who asked about it.  I don't think we need to add more text.

--Randall

At 11:35 PM +0100 1/10/18, Gunnar Hellström wrote:

>  I saw a question somewhere but lost track of who asked it.
>
>  It was about if the users are bound to use only 
> the negotiated language(s) in the session.
>
>  I think a line about that should be inserted, 
> probably best close to the end of the 
> introduction.
>
>  Proposed text:
>  "The result of the negotiation is intended to 
> guide the selection of language(s) to use 
> initially and during the session. However, 
> nothing prevents the users from varying the use 
> of languages and media by mutual agreement 
> after the initial exchange during the call."
>
>  Gunnar
>
>
>  Den 2018-01-10 kl. 17:12, skrev Randall Gellens:
>>  At 8:21 PM -0800 1/9/18, Ben Campbell wrote:
>>
>>>   I'm balloting "yes" because I think this is 
>>> important work, but I have some
>>>   comments:
>>>
>>>   Substantive Comments:
>>>
>>>   - General: It seems to be that this is as 
>>> much about human behavior as it is
>>>   capabilities negotiating. Example case: I 
>>> make a video call and express that I
>>>   would like to receive Klingon. (Is there a 
>>> tag for that ? :-) The callee can
>>>   speak Klingon and Esperanto, so we agree on 
>>> Klingon. What keeps the callee from
>>>   speaking Esparanto instead?
>>
>>  There is a language tag for Klingon: "tlh".
>>
>>  The draft is not trying to even capture the 
>> full complexity of human language interaction, 
>> much less enforce it.  The draft provides a 
>> fairly simple mechanism to make it more likely 
>> that successful communication can occur, by 
>> identifying language needs (which can allow 
>> endpoints to take potentially required 
>> additional steps, such as bridging in 
>> translation or relay services, or having a 
>> call handled by someone who known the 
>> language(s) or can use the needed media).
>>
>>>   I realize we can't force people to stick to the negotiated languages--but
>>>   should we expect that users should at least 
>>> be given some sort of UI indication
>>>   about the negotiated language(s)? It seems like a paragraph or two on that
>>>   subject is warranted, even if it just to say it's out of scope.
>>
>>  I will add to the Introduction the following text:
>>
>>     This document does not address user interface (UI) issues, such as if
>>     or how a UE client informs a user about the result of language and
>>     media negotiation.
>>
>>>   -1, paragraph 6:  (related to Ekr's 
>>> comments) Does the selection of a single
>>>   tag in an answer imply  an assumption only 
>>> one language will be used? There are
>>>   communities where people tend to mix 2 or 
>>> more languages freely and fluidly. Is
>>>   that sort of thing out of scope?
>>
>>  Earlier versions of the draft had more 
>> explicit text that the draft did not attempt 
>> to capture the full range of human language 
>> issues, including the common practice among 
>> multilingual people of mixing languages.
>>
>>  The draft currently says:
>>
>>     (Negotiating multiple simultaneous languages within a media stream is
>>     out of scope of this document.)
>>
>>  There was text in a version of the draft as of February 2013 that said:
>>
>>     (While it is true that a conversation among multilingual people often
>>     involves multiple languages, it does not seem useful enough as a
>>     general facility to warrant complicating the desired semantics of the
>>     SDP attribute to allow negotiation of multiple simultaneous languages
>>     within an interactive media stream.)
>>
>>  I do not recall the reasons why the text was 
>> simplified, removing mention of multilingual 
>> people, and would have to search through 
>> minutes of the various WG sessions and email 
>> in 2013 where the draft was discussed.  I 
>> suspect there was desire to have the draft 
>> merely state what it does and doesn't do, and 
>> not get into a lot of value judgment 
>> discussion.
>>
>>>   - 5.1, paragraph 2:  Can you elaborate on 
>>> the motivation to have a separate
>>>   hlang-send and hlang-recv parameter vs 
>>> having a single language parameter and
>>>   instead setting the stream to send or 
>>> receive only, especially in light of the
>>>   recommendation to set both directions the same for bi-directional language
>>>   selection? I don't mean to dispute that approach; I just think a bit more
>>>   explanation of the design choice would be 
>>> helpful to the reader.  I can imagine
>>>   some use cases, for example a 
>>> speech-impaired person who does not plan to 
>>> speak
>>>   on a video call may still wish to send video 
>>> to show facial expressions, etc.
>>>   (I just re-read the discussion resulting 
>>> from Ekr's comments, and recognize
>>>   that this overlaps heavily with that.)
>>
>>  As you suggest, a media might be desired in 
>> both directions even though only one direction 
>> is primarily intended for interactive 
>> communication.  The draft currently says:
>>
>>     When a media is intended for interactive communication
>>     using a language in one direction only (e.g., a user with difficulty
>>     speaking but able to hear who indicates a desire to send using text
>>     and receive using audio), either hlang-send or hlang-recv MAY be
>>     omitted.  When a media is not primarily intended for language (for
>>     example, a video or audio stream intended for background only) both
>>     SHOULD be omitted.  Otherwise, both SHOULD have the same value.  Note
>>     that specifying different languages for each direction (as opposed to
>>     the same or essentially the same language in different modalities)
>>     can make it difficult to complete the call (e.g., specifying a desire
>>     to send audio in Hungarian and receive audio in Portuguese).
>>
>>  I will add "Note that the media can still be 
>> useful in both directions."  The text thus 
>> becomes:
>>
>>     When a media is intended for interactive communication
>>     using a language in one direction only (e.g., a user with difficulty
>>     speaking but able to hear who indicates a desire to send using text
>>     and receive using audio), either hlang-send or hlang-recv MAY be
>>     omitted.  Note that the media can still be useful in both directions.
>>     When a media is not primarily intended for language (for example, a
>>     video or audio stream intended for background only) both SHOULD be
>>     omitted.
>>
>>>   -5.1, paragraph 3: "... which in most cases is one of the
>>>      languages in the offer's..."
>>>   Are there cases where it might not?
>>
>>  Yes, it could happen.  For example, if an 
>> emergency call comes into a PSAP and requests 
>> languages that the PSAP is unable to support, 
>> the PSAP will likely want the call to proceed 
>> anyway. It's also possible that the callee 
>> might support a language that has some degree 
>> of mutual comprehensibility to those requested 
>> by the caller.  An example might be some 
>> Scandinavian languages where the caller does 
>> not include a language that is similar enough 
>> to have some comprehension but not be fluent 
>> enough to include in the UE configuration.
>>
>>>   -5.1, last paragraph: "This is not a problem."
>>>   Can you elaborate? That sort of statement 
>>> usually takes the form "This is not a
>>>   problem, because..."
>>
>>  The caller and callee are free to use any of 
>> the established media streams.  If a caller 
>> requests audio, video (with a sign language), 
>> and text, and all three are established, the 
>> caller might ignore the text or audio stream 
>> and use only the video stream.
>>
>>>   -5.2, last paragraph: Is there a reason to 
>>> give such weak guidance on how to
>>>   indicate the call is rejected?  (Along those 
>>> lines, are non-SIP uses of SDP in
>>>   scope?)
>>
>>  No one made a case for why mandating a 
>> particular rejection code was necessary, 
>> especially since the draft does not offer any 
>> suggestion as to if a call should proceed or 
>> fail when there aren't mutually supported 
>> languages.
>>
>>>
>>>   Editorial Comments and Nits:
>>>
>>>   -5.1, paragraph 4: The first MUST seems like a statement of fact.
>>
>>  You mean this sentence:
>>
>>     In an offer, each value MUST be a list of one or more language tags
>>     per BCP 47 [RFC5646], separated by white space.
>>
>>  The MUST makes sure that the values are IANA-registered language tags.
>>
>
>  --
>  -----------------------------------------
>  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: ---------------
The attention span of a computer is only as long as its electrical cord
or battery life.