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 F130C12E874 for ; Wed, 10 Jan 2018 20:59:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 t3YlvTrIDtxS for ; Wed, 10 Jan 2018 20:59:53 -0800 (PST) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACF3412E897 for ; Wed, 10 Jan 2018 20:59:52 -0800 (PST) Received: by mail-vk0-x230.google.com with SMTP id w22so802207vkw.0 for ; Wed, 10 Jan 2018 20:59:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KI14Z7XBhLeAd7r+mTkc0M3gccJ4rhv6kvPBAfApWEw=; b=mmX74wx5041zXAuyjPXcjaVW1kqTcc5wZ0Dla6xG38bxA7hRyXGIPpQPGvWVRA6UCG C//ZgFY0Tz1o1okL83gdBTx4v/KEv8xhBWmCqgJdFPOhTacdmzzGll5mN/UHaNp8kKSd LRC5jzoiRMwfaCyk73TWqJAO8u6jv9cGgWA3esrTGEyBS8mZpDw3/O5InM2STmNE6LE1 sCLtmVp53D6s0/vG/JIs6swOprjsED3dE8YGowrxFjhxaR8O8WWnjBfmJ6tUndHHFcm+ djdOL124uW9bcOA90rZF6DnlGvm5GOZsD/9fFl/N7YJFGUD9Jl1rXORgJEtdSRS328Lv nWXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KI14Z7XBhLeAd7r+mTkc0M3gccJ4rhv6kvPBAfApWEw=; b=ipU+ia7iC2pEjv8aWWPFJjLeHNlT56UV7Ow6ljuhOl48RJgm4bpO913LgF0iNs3QBB z5F7ntw7kIwTMW9ahB3B7wkBwMyHAbhcoGTBPbSJ3UC1PMUB399FpRyoTa3nMyNhfCMf 9RaPjqwWTvVHW+3I3aKGjKaHDPcDXsOgbrnqqJXyl6ifq9RL3KOJeTyXC2I08Yjc7Ciw oxEuSCDPB4sXGGLzI+fcjpogqpZSP9LNusz3TR0k3ItXBDimTv5mrz7m7YgQSdS+Cas6 w21euh6c5FAhtUDq6nBybPaN1dcuFRY7ASQKnPIGixkO968piO9txsg/TNOUq6US47aB oR6w== X-Gm-Message-State: AKwxytdiQtncTsW/lcWc18+4b7mNiofzRpYQWOkoWq4nG0ZiSyKNfYGY ZdYShdFe3JakpbQm9J4Ns0ifMq20+Lg1RLPMAPjiw4pM X-Google-Smtp-Source: ACJfBosilkV6P4Zfg0urim0f+kRkq59FV08ikMnoXhxPRaqCWdbrvlXG5wNwurxEhXGPYHpEg6YiP7eKQR8TqhUT0rg= X-Received: by 10.31.70.199 with SMTP id t190mr19757416vka.102.1515646791274; Wed, 10 Jan 2018 20:59:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.54.138 with HTTP; Wed, 10 Jan 2018 20:59:30 -0800 (PST) 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> From: Bernard Aboba Date: Wed, 10 Jan 2018 20:59:30 -0800 Message-ID: To: =?UTF-8?Q?Gunnar_Hellstr=C3=B6m?= Cc: Randall Gellens , slim@ietf.org Content-Type: multipart/alternative; boundary="001a11484ed099559805627904bb" 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 04:59:57 -0000 --001a11484ed099559805627904bb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Gunnar said: ""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."" [BA] This came from Ben Campbell, but other ADs with many years of experience in realtime communications have asked questions along similar lines. So it seems that even experienced readers could use some clarification. The reason for the language selection negotiation is to enable the right individuals and resources to be brought into the conversation so as to maximize the changes of successful communications. What happens once the call is brought up is up to the conversants. The precise meaning of the negotiation depends in part on the choice of a single language or multiple languages in the Answer. If an offer indicates the ability to receive English and French, if an Answer can only contain a single language, then an Answer indicating the ability to send English would establish that the call is expected to be conducted in English. That wouldn't necessarily preclude the use of French, but doesn't provide any indication that it could be supported as an alternative. Whereas if the Answer was allowed to include multiple languages and included both English and French, then the Answer would indicate that the conversation could use either language with a preference for English over French. That does strike me as potentially valuable in some circumstances (e.g. a visitor from Spain with an emergency offering Spanish primary and English secondary and being able to get an answer indicating English with secondary Spanish support, rather than just English). In either case, the conversants can switch languages by mutual agreement. On Wed, Jan 10, 2018 at 2:35 PM, Gunnar Hellstr=C3=B6m < gunnar.hellstrom@omnitor.se> 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 expres= s >>> 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 ca= n >> occur, by identifying language needs (which can allow endpoints to take >> potentially required additional steps, such as bridging in translation o= r >> 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 >>> 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, includin= g >> 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 mentio= n >> 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 ligh= t >>> 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 ca= n >>> 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 enou= gh >> 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 o= f >>> 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 t= o >> 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=C3=B6m > Omnitor > gunnar.hellstrom@omnitor.se > +46 708 204 288 > > --001a11484ed099559805627904bb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Gunnar said:=C2=A0

""The result of the negotiation is intended to=C2=A0guide the selection of language(s) to use= =C2=A0initially and during the session.= However,=C2=A0nothing prevents the use= rs from varying the use=C2=A0of languag= es and media by mutual agreement=C2=A0a= fter the initial exchange during the call.""

<= /div>
[BA] This came from Ben Campbell, but other ADs with many years o= f experience in realtime communications have asked questions along similar = lines.=C2=A0 So it seems that even experienced readers could use some clari= fication.

The reason for the language selection ne= gotiation is to enable the right individuals and resources to be brought in= to the conversation so as to maximize the changes of successful communicati= ons. What happens once the call is brought up is up to the conversants.=C2= =A0

The precise meaning of the negotiation depends= in part on the choice of a single language or multiple languages in the An= swer.=C2=A0

If an offer indicates the ability to r= eceive English and French, if an Answer can only contain a single language,= then an Answer indicating the ability to send English would establish that= the call is expected to be conducted in English. That wouldn't necessa= rily preclude the use of French, but doesn't provide any indication tha= t it could be supported as an alternative.=C2=A0

W= hereas if the Answer was allowed to include multiple languages and included= both English and French, then the Answer would indicate that the conversat= ion could use either language with a preference for English over French.=C2= =A0 That does strike me as potentially valuable in some circumstances (e.g.= a visitor from Spain with an emergency offering Spanish primary and Englis= h secondary and being able to get an answer indicating English with seconda= ry Spanish support, rather than just English).=C2=A0

In either case, the conversants can switch languages by mutual agree= ment.=C2=A0

On Wed, Jan 10, 2018 at 2:35 PM, Gunnar Hellstr=C3=B6m <gu= nnar.hellstrom@omnitor.se> 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 en= d of the introduction.

Proposed text:
"The result of the negotiation is intended to guide the selection of l= anguage(s) to use initially and during the session. However, nothing preven= ts the users from varying the use of languages and media by mutual agreemen= t 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:

=C2=A0I'm balloting "yes" because I think this is important w= ork, but I have some
=C2=A0comments:

=C2=A0Substantive Comments:

=C2=A0- General: It seems to be that this is as much about human behavior a= s it is
=C2=A0capabilities negotiating. Example case: I make a video call and expre= ss that I
=C2=A0would like to receive Klingon. (Is there a tag for that ? :-) The cal= lee can
=C2=A0speak Klingon and Esperanto, so we agree on Klingon. What keeps the c= allee from
=C2=A0speaking Esparanto instead?

There is a language tag for Klingon: "tlh".

The draft is not trying to even capture the full complexity of human langua= ge interaction, much less enforce it.=C2=A0 The draft provides a fairly sim= ple mechanism to make it more likely that successful communication can occu= r, by identifying language needs (which can allow endpoints to take potenti= ally required additional steps, such as bridging in translation or relay se= rvices, or having a call handled by someone who known the language(s) or ca= n use the needed media).

=C2=A0I realize we can't force people to stick to the negotiated langua= ges--but
=C2=A0should we expect that users should at least be given some sort of UI = indication
=C2=A0about the negotiated language(s)? It seems like a paragraph or two on= that
=C2=A0subject is warranted, even if it just to say it's out of scope.

I will add to the Introduction the following text:

=C2=A0=C2=A0 This document does not address user interface (UI) issues, suc= h as if
=C2=A0=C2=A0 or how a UE client informs a user about the result of language= and
=C2=A0=C2=A0 media negotiation.


=C2=A0-1, paragraph 6:=C2=A0 (related to Ekr's comments) Does the selec= tion of a single
=C2=A0tag in an answer imply=C2=A0 an assumption only one language will be = used? There are
=C2=A0communities where people tend to mix 2 or more languages freely and f= luidly. Is
=C2=A0that 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:

=C2=A0=C2=A0 (Negotiating multiple simultaneous languages within a media st= ream is
=C2=A0=C2=A0 out of scope of this document.)

There was text in a version of the draft as of February 2013 that said:

=C2=A0=C2=A0 (While it is true that a conversation among multilingual peopl= e often
=C2=A0=C2=A0 involves multiple languages, it does not seem useful enough as= a
=C2=A0=C2=A0 general facility to warrant complicating the desired semantics= of the
=C2=A0=C2=A0 SDP attribute to allow negotiation of multiple simultaneous la= nguages
=C2=A0=C2=A0 within an interactive media stream.)

I do not recall the reasons why the text was simplified, removing mention o= f multilingual people, and would have to search through minutes of the vari= ous WG sessions and email in 2013 where the draft was discussed.=C2=A0 I su= spect there was desire to have the draft merely state what it does and does= n't do, and not get into a lot of value judgment discussion.


=C2=A0- 5.1, paragraph 2:=C2=A0 Can you elaborate on the motivation to have= a separate
=C2=A0hlang-send and hlang-recv parameter vs having a single language param= eter and
=C2=A0instead setting the stream to send or receive only, especially in lig= ht of the
=C2=A0recommendation to set both directions the same for bi-directional lan= guage
=C2=A0selection? I don't mean to dispute that approach; I just think a = bit more
=C2=A0explanation of the design choice would be helpful to the reader.=C2= =A0 I can imagine
=C2=A0some use cases, for example a speech-impaired person who does not pla= n to speak
=C2=A0on a video call may still wish to send video to show facial expressio= ns, etc.
=C2=A0(I just re-read the discussion resulting from Ekr's comments, and= recognize
=C2=A0that this overlaps heavily with that.)

As you suggest, a media might be desired in both directions even though onl= y one direction is primarily intended for interactive communication.=C2=A0 = The draft currently says:

=C2=A0=C2=A0 When a media is intended for interactive communication
=C2=A0=C2=A0 using a language in one direction only (e.g., a user with diff= iculty
=C2=A0=C2=A0 speaking but able to hear who indicates a desire to send using= text
=C2=A0=C2=A0 and receive using audio), either hlang-send or hlang-recv MAY = be
=C2=A0=C2=A0 omitted.=C2=A0 When a media is not primarily intended for lang= uage (for
=C2=A0=C2=A0 example, a video or audio stream intended for background only)= both
=C2=A0=C2=A0 SHOULD be omitted.=C2=A0 Otherwise, both SHOULD have the same = value.=C2=A0 Note
=C2=A0=C2=A0 that specifying different languages for each direction (as opp= osed to
=C2=A0=C2=A0 the same or essentially the same language in different modalit= ies)
=C2=A0=C2=A0 can make it difficult to complete the call (e.g., specifying a= desire
=C2=A0=C2=A0 to send audio in Hungarian and receive audio in Portuguese).
I will add "Note that the media can still be useful in both directions= ."=C2=A0 The text thus becomes:

=C2=A0=C2=A0 When a media is intended for interactive communication
=C2=A0=C2=A0 using a language in one direction only (e.g., a user with diff= iculty
=C2=A0=C2=A0 speaking but able to hear who indicates a desire to send using= text
=C2=A0=C2=A0 and receive using audio), either hlang-send or hlang-recv MAY = be
=C2=A0=C2=A0 omitted.=C2=A0 Note that the media can still be useful in both= directions.
=C2=A0=C2=A0 When a media is not primarily intended for language (for examp= le, a
=C2=A0=C2=A0 video or audio stream intended for background only) both SHOUL= D be
=C2=A0=C2=A0 omitted.


=C2=A0-5.1, paragraph 3: "... which in most cases is one of the
=C2=A0=C2=A0=C2=A0 languages in the offer's..."
=C2=A0Are there cases where it might not?

Yes, it could happen.=C2=A0 For example, if an emergency call comes into a = PSAP and requests languages that the PSAP is unable to support, the PSAP wi= ll likely want the call to proceed anyway. It's also possible that the = callee might support a language that has some degree of mutual comprehensib= ility to those requested by the caller.=C2=A0 An example might be some Scan= dinavian languages where the caller does not include a language that is sim= ilar enough to have some comprehension but not be fluent enough to include = in the UE configuration.


=C2=A0-5.1, last paragraph: "This is not a problem."
=C2=A0Can you elaborate? That sort of statement usually takes the form &quo= t;This is not a
=C2=A0problem, because..."

The caller and callee are free to use any of the established media streams.= =C2=A0 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 st= ream and use only the video stream.

=C2=A0-5.2, last paragraph: Is there a reason to give such weak guidance on= how to
=C2=A0indicate the call is rejected?=C2=A0 (Along those lines, are non-SIP = uses of SDP in
=C2=A0scope?)

No one made a case for why mandating a particular rejection code was necess= ary, especially since the draft does not offer any suggestion as to if a ca= ll should proceed or fail when there aren't mutually supported language= s.


=C2=A0Editorial Comments and Nits:

=C2=A0-5.1, paragraph 4: The first MUST seems like a statement of fact.

You mean this sentence:

=C2=A0=C2=A0 In an offer, each value MUST be a list of one or more language= tags
=C2=A0=C2=A0 per BCP 47 [RFC5646], separated by white space.

The MUST makes sure that the values are IANA-registered language tags.


--
-----------------------------------------
Gunnar Hellstr=C3=B6m
Omnitor
gunnar.hel= lstrom@omnitor.se
+46 708 204 288


--001a11484ed099559805627904bb--