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 7B61C12EB86 for ; Thu, 11 Jan 2018 07:25:07 -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.909 X-Spam-Level: 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id He4AanCRZnAB for ; Thu, 11 Jan 2018 07:25:04 -0800 (PST) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 974D71204DA for ; Thu, 11 Jan 2018 07:25:04 -0800 (PST) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Thu, 11 Jan 2018 07:25:37 -0800 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <151555808122.21584.8379796998643581181.idtracker@ietfa.amsl.com> <2c49d430-3fb1-381f-d236-4bc5a6a38c27@omnitor.se> X-Mailer: Eudora for Mac OS X Date: Thu, 11 Jan 2018 07:24:59 -0800 To: Bernard Aboba , Gunnar =?iso-8859-1?Q?Hellstr=F6m?= From: Randall Gellens Cc: slim@ietf.org, Randall Gellens 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: Thu, 11 Jan 2018 15:25:07 -0000 At 8:59 PM -0800 1/10/18, Bernard Aboba wrote: > Gunnar said: > > ""The result of the negotiation is intended=20 > to guide the selection of language(s) to=20 > use initially and during the session.=20 > However, nothing prevents the users from=20 > varying the use of languages and media by=20 > mutual agreement after the initial exchange=20 > during the call."" > > [BA] This came from Ben Campbell, but other ADs=20 > with many years of experience in realtime=20 > communications have asked questions along=20 > similar lines. So it seems that even=20 > experienced readers could use some=20 > clarification. > > The reason for the language selection=20 > negotiation is to enable the right individuals=20 > and resources to be brought into the=20 > conversation so as to maximize the changes of=20 > successful communications. What happens once=20 > the call is brought up is up to the conversants. [RG] We can text along the lines of the above paragraph, as a clarification. > The precise meaning of the negotiation depends=20 > in part on the choice of a single language or=20 > multiple languages in the Answer. > > If an offer indicates the ability to receive=20 > English and French, if an Answer can only=20 > contain a single language, then an Answer=20 > indicating the ability to send English would=20 > establish that the call is expected to be=20 > conducted in English. That wouldn't necessarily=20 > preclude the use of French, but doesn't provide=20 > any indication that it could be supported as an=20 > alternative. > > Whereas if the Answer was allowed to include=20 > multiple languages and included both English=20 > and French, then the Answer would indicate that=20 > the conversation could use either language with=20 > a preference for English over French. That=20 > does strike me as potentially valuable in some=20 > circumstances (e.g. a visitor from Spain with=20 > an emergency offering Spanish primary and=20 > English secondary and being able to get an=20 > answer indicating English with secondary=20 > Spanish support, rather than just English). [RG] Choosing among language and modality will=20 often require trade-offs. A call may indicate=20 audio with Spanish (most preferred), Italian=20 (second choice), and English. If the call is=20 received by a PSAP that has call takers who=20 natively speak English but can bridge in Spanish=20 translation, accepting English forces the caller=20 to use a less-preferred language while accepting=20 Spanish forces the call through translation,=20 which makes the communication slower and=20 typically more difficult, as well as adding cost=20 to the PSAP. If we add modality choice into the=20 mix, it becomes more complex, with trade-offs.=20 =46urther, in the example, if the PSAP indicates=20 Spanish in the answer, then it will bridge in=20 translation services, while if if indicates=20 English, it won't; so if it indicates English, it=20 wouldn't also indicate Spanish, even if the=20 syntax permitted it. > In either case, the conversants can switch languages by mutual agreement. [RG] Conversants are always free to use any language they like. --Randall > > On Wed, Jan 10, 2018 at 2:35 PM, Gunnar=20 > Hellstr=F6m=20 > <gunnar.hellstrom@omnitor.se>=20 > 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 important work, but I have s= ome > 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=20 > 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=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 call=20 > handled by someone who known the language(s) or=20 > can use the needed media). > > I realize we can't force people to stick to the negotiated languages--bu= t > should we expect that users should at least be=20 > given some sort of UI indication > about the negotiated language(s)? It seems like a paragraph or two on th= at > 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 si= ngle > tag in an answer imply an assumption only one=20 > language will be used? There are > communities where people tend to mix 2 or more=20 > languages freely and fluidly. Is > that sort of thing out of scope? > > > Earlier versions of the draft had more explicit=20 > text that the draft did not attempt to capture=20 > the full range of human language issues,=20 > 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 in=20 > 2013 where the draft was discussed. I suspect=20 > there was desire to have the draft merely state=20 > what it does and doesn't do, and not get into a=20 > lot of value judgment discussion. > > - 5.1, paragraph 2: Can you elaborate on the motivation to have a separ= ate > hlang-send and hlang-recv parameter vs having=20 > a single language parameter and > instead setting the stream to send or receive=20 > only, especially in light of the > recommendation to set both directions the same for bi-directional langua= ge > selection? I don't mean to dispute that approach; I just think a bit mor= e > explanation of the design choice would be=20 > helpful to the reader. I can imagine > some use cases, for example a speech-impaired=20 > 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 recogn= ize > 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 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: --------------- There is hardly anything in the world that some one cannot make a little worse, and sell a little cheaper. --John Ruskin (1819-1900)