Return-Path: 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: 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: In-Reply-To: References: <151555808122.21584.8379796998643581181.idtracker@ietfa.amsl.com> X-Mailer: Eudora for Mac OS X Date: Wed, 10 Jan 2018 09:56:12 -0800 To: Ben Campbell From: Randall Gellens Cc: slim@ietf.org, draft-ietf-slim-negotiating-human-language@ietf.org, The IESG , 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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=20 > Gellens 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=20 >>> 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=20 >>> 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--b= ut >>> 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 t= hat >>> 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.=20 > But is it worth mentioning that there needs to=20 > be someway of communicating the language=20 > selection to the humans? Or failing that, to=20 > explicitly mention that all the selection does=20 > is determine that there is a language in=20 > common, and it's up to the humans to figure=20 > things out from there? I don't think we need to say more; I think it's=20 obvious and in this case if we say more we risk=20 saying things that aren't always true or getting=20 deeper into out of scope details. For example,=20 not all SIP calls are placed by UI-rich devices. > >> -1, paragraph 6: (related to Ekr's=20 > 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=20 > thought about it. I don't see a need for a=20 > change. Thanks. > >> - 5.1, paragraph 2: Can you elaborate on=20 > the motivation to have a separate >>> hlang-send and hlang-recv parameter vs having=20 >>> 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 langu= age >>> selection? I don't mean to dispute that approach; I just think a bit mo= re >>> 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=20 >>> to show facial expressions, etc. >>> (I just re-read the discussion resulting from Ekr's comments, and recog= nize >>> 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= =2E I'd rather not try to craft language for that=20 now, since doing so risks adding details that=20 aren't always true or getting too deep into=20 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=20 > problem" with "The participants are free to use=20 > any of the established media streams."? Or=20 > "This is not a problem because the participants=20 > are free=8A"? I'm not sure how much we need to say. I could=20 add text such as "This is not a problem because=20 unused media streams are not resource-intensive"=20 but I'm not sure it helps a reader understand.=20 Do you think a reader would be confused if we=20 don't discuss it further? I'm open to trying to=20 add clarifying text if it will help. > >> -5.2, last paragraph: Is there a reason to=20 > 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=20 > are two different questions. The second can be=20 > 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