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 2BD28129C51; Wed, 10 Jan 2018 14:56:15 -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 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: In-Reply-To: <2c49d430-3fb1-381f-d236-4bc5a6a38c27@omnitor.se> References: <151555808122.21584.8379796998643581181.idtracker@ietfa.amsl.com> <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?= , Ben Campbell , The IESG From: Randall Gellens 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: 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 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=F6m wrote: > I saw a question somewhere but lost track of who asked it. > > It was about if the users are bound to use only=20 > the negotiated language(s) in the session. > > I think a line about that should be inserted,=20 > probably best close to the end of the=20 > introduction. > > Proposed text: > "The result of the negotiation is intended to=20 > guide the selection of language(s) to use=20 > initially and during the session. However,=20 > nothing prevents the users from varying the use=20 > of languages and media by mutual agreement=20 > 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=20 >>> 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=20 >>> 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=20 >>> 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=20 >> full complexity of human language interaction,=20 >> much less enforce it. The draft provides a=20 >> fairly simple mechanism to make it more likely=20 >> that successful communication can occur, by=20 >> identifying language needs (which can allow=20 >> endpoints to take potentially required=20 >> additional steps, such as bridging in=20 >> translation or relay services, or having a=20 >> call handled by someone who known the=20 >> 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=20 >>> 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=20 >>> comments) Does the selection of a single >>> tag in an answer imply an assumption only=20 >>> one language will be used? There are >>> communities where people tend to mix 2 or=20 >>> more languages freely and fluidly. Is >>> that sort of thing out of scope? >> >> Earlier versions of the draft had more=20 >> explicit text that the draft did not attempt=20 >> to capture the full range of human language=20 >> issues, including the common practice among=20 >> 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=20 >> simplified, removing mention of multilingual=20 >> people, and would have to search through=20 >> minutes of the various WG sessions and email=20 >> in 2013 where the draft was discussed. I=20 >> suspect there was desire to have the draft=20 >> merely state what it does and doesn't do, and=20 >> not get into a lot of value judgment=20 >> discussion. >> >>> - 5.1, paragraph 2: Can you elaborate on=20 >>> the motivation to have a separate >>> hlang-send and hlang-recv parameter vs=20 >>> having a single language parameter and >>> instead setting the stream to send or=20 >>> receive only, especially in light of the >>> recommendation to set both directions the same for bi-directional lang= uage >>> selection? I don't mean to dispute that approach; I just think a bit m= ore >>> explanation of the design choice would be=20 >>> helpful to the reader. I can imagine >>> some use cases, for example a=20 >>> speech-impaired person who does not plan to=20 >>> speak >>> on a video call may still wish to send video=20 >>> to show facial expressions, etc. >>> (I just re-read the discussion resulting=20 >>> from Ekr's comments, and recognize >>> that this overlaps heavily with that.) >> >> As you suggest, a media might be desired in=20 >> both directions even though only one direction=20 >> is primarily intended for interactive=20 >> 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=20 >> useful in both directions." The text thus=20 >> 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=20 >> emergency call comes into a PSAP and requests=20 >> languages that the PSAP is unable to support,=20 >> the PSAP will likely want the call to proceed=20 >> anyway. It's also possible that the callee=20 >> might support a language that has some degree=20 >> of mutual comprehensibility to those requested=20 >> by the caller. An example might be some=20 >> Scandinavian languages where the caller does=20 >> not include a language that is similar enough=20 >> to have some comprehension but not be fluent=20 >> enough to include in the UE configuration. >> >>> -5.1, last paragraph: "This is not a problem." >>> Can you elaborate? That sort of statement=20 >>> usually takes the form "This is not a >>> problem, because..." >> >> The caller and callee are free to use any of=20 >> the established media streams. If a caller=20 >> requests audio, video (with a sign language),=20 >> and text, and all three are established, the=20 >> caller might ignore the text or audio stream=20 >> and use only the video stream. >> >>> -5.2, last paragraph: Is there a reason to=20 >>> give such weak guidance on how to >>> indicate the call is rejected? (Along those=20 >>> lines, are non-SIP uses of SDP in >>> scope?) >> >> No one made a case for why mandating a=20 >> particular rejection code was necessary,=20 >> especially since the draft does not offer any=20 >> suggestion as to if a call should proceed or=20 >> fail when there aren't mutually supported=20 >> 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=F6m > 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.