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 17: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 D6DEB1243FE; Wed, 10 Jan 2018 09:56:19 -0800 (PST)
X-Quarantine-ID: <QWxO8qLKFSX7>
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 QWxO8qLKFSX7; Wed, 10 Jan 2018 09:56:17 -0800 (PST)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 4351212DA4A; Wed, 10 Jan 2018 09:56:17 -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 09:56:48 -0800
Mime-Version: 1.0
Message-Id: <p06240605d67c0026f619@[99.111.97.136]>
In-Reply-To: <A08111A3-D877-4F65-964B-BBE1832CAB0A@nostrum.com>
References: <151555808122.21584.8379796998643581181.idtracker@ietfa.amsl.com> <p06240602d67be148b9db@[99.111.97.136]> <A08111A3-D877-4F65-964B-BBE1832CAB0A@nostrum.com>
X-Mailer: Eudora for Mac OS X
Date: Wed, 10 Jan 2018 09:56:12 -0800
To: Ben Campbell <ben@nostrum.com>
From: Randall Gellens <rg+ietf@randy.pensive.org>
Cc: slim@ietf.org, draft-ietf-slim-negotiating-human-language@ietf.org, The IESG <iesg@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/eXTzeqWOs0ce3qvBZSZyxKVEiiI>
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 17:56:20 -0000
At 10:48 AM -0600 1/10/18, Ben Campbell wrote: > > On Jan 10, 2018, at 10:12 AM, Randall > Gellens <rg+ietf@randy.pensive.org> wrote: >> >> 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. > > I agree that UX details should be out of scope. > But is it worth mentioning that there needs to > be someway of communicating the language > selection to the humans? Or failing that, to > explicitly mention that all the selection does > is determine that there is a language in > common, and it's up to the humans to figure > things out from there? I don't think we need to say more; I think it's obvious and in this case if we say more we risk saying things that aren't always true or getting deeper into out of scope details. For example, not all SIP calls are placed by UI-rich devices. > >> -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. > > Okay, that's sufficient proof that people have > thought about it. I don't see a need for a > change. Thanks. > >> - 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. > > WFM. Thanks. > >> -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. > > Okay. I note to that effect might help, but I leave that to you to decide. I'd rather not try to craft language for that now, since doing so risks adding details that aren't always true or getting too deep into operational issues. > >> -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. > > Would it make sense to replace "This is a not a > problem" with "The participants are free to use > any of the established media streams."? Or > "This is not a problem because the participants > are free"? I'm not sure how much we need to say. I could add text such as "This is not a problem because unused media streams are not resource-intensive" but I'm not sure it helps a reader understand. Do you think a reader would be confused if we don't discuss it further? I'm open to trying to add clarifying text if it will help. > >> -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. > > When you should fail and how to express failure > are two different questions. The second can be > an interoperability issue. How about if I reword the text to be: A call that is rejected due to lack of any languages in common has SIP response code 488 (Not Acceptable Here) or 606 (Not Acceptable) [RFC3261] and a Warning header field [RFC3261] containing a warning code of [TBD: IANA VALUE, e.g., 308] and a warning text indicating that there are no mutually-supported languages in the SIP response; the warning text SHOULD also contain the supported languages and media. > >> 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. > > Ah, okay. Thanks. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Americans can always be counted on to do the right thing, after they have exhausted all other possibilities. -- Winston Churchill
- [Slim] Ben Campbell's Yes on draft-ietf-slim-nego… Ben Campbell
- Re: [Slim] Ben Campbell's Yes on draft-ietf-slim-… Randall Gellens
- Re: [Slim] Ben Campbell's Yes on draft-ietf-slim-… Paul Kyzivat
- Re: [Slim] Ben Campbell's Yes on draft-ietf-slim-… Ben Campbell
- Re: [Slim] Ben Campbell's Yes on draft-ietf-slim-… Ben Campbell
- Re: [Slim] Ben Campbell's Yes on draft-ietf-slim-… Randall Gellens
- Re: [Slim] Ben Campbell's Yes on draft-ietf-slim-… Gunnar Hellström
- Re: [Slim] Ben Campbell's Yes on draft-ietf-slim-… Randall Gellens
- Re: [Slim] Ben Campbell's Yes on draft-ietf-slim-… Bernard Aboba
- Re: [Slim] Ben Campbell's Yes on draft-ietf-slim-… Bernard Aboba
- Re: [Slim] Ben Campbell's Yes on draft-ietf-slim-… Gunnar Hellström
- Re: [Slim] Ben Campbell's Yes on draft-ietf-slim-… Randall Gellens
- Re: [Slim] Ben Campbell's Yes on draft-ietf-slim-… Bernard Aboba
- Re: [Slim] Ben Campbell's Yes on draft-ietf-slim-… Gunnar Hellström
- [Slim] Text stating that negotiation isn't restri… Randall Gellens
- [Slim] Allowing multiple values in an answer Randall Gellens
- Re: [Slim] Allowing multiple values in an answer Randall Gellens
- Re: [Slim] Allowing multiple values in an answer Gunnar Hellström
- Re: [Slim] Allowing multiple values in an answer Bernard Aboba
- [Slim] Action or not on multiple values in an ans… Randall Gellens
- Re: [Slim] Allowing multiple values in an answer Bernard Aboba
- Re: [Slim] Allowing multiple values in an answer Randall Gellens