From nobody Thu Feb 15 04:53:55 2018 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 EF6091273B1 for ; Thu, 15 Feb 2018 04:53:53 -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 a5oG_BoBL50U for ; Thu, 15 Feb 2018 04:53:52 -0800 (PST) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (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 16CE5126CBF for ; Thu, 15 Feb 2018 04:53:52 -0800 (PST) Received: by mail-vk0-x233.google.com with SMTP id k196so1606942vke.4 for ; Thu, 15 Feb 2018 04:53:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=GnmAUVnM6XLRqfS/jjmi9rOj26Lccmpypj3yXMjiocQ=; b=Y4DJGNOs3HGehUatnoRo3NVu3gtLG4Lu/CT838UriTkN2E6ic0quNtE4Qlijo8b2s8 RO2FWbKm9w/i/3GfjrSSFkh81c9OEz6bdL+gfY95vRkdin4svVCht+WGEsyFwOxqyB7D /JC+74aHiQlJF+7GjjRVbzwH0LIV0PQbitMFg0ajC1ce8YROhXt6P211goo+C5eGw+R1 ePJixSJLQGBK20m6jICC9ZijqLKyioD/1XEdITtH7wpHDpK3PCA9ZBL+qQBJsNP5hf/T X9h8gvk3W3FBynS6AJfwFwRznlfnCh2H1SZoPD/GN9kzdTygIaYTJZIgZJsnosk9704a Byrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=GnmAUVnM6XLRqfS/jjmi9rOj26Lccmpypj3yXMjiocQ=; b=HYquhRACNMuY8VT2rHo5gji8+EjbiSj/ibL91+vk5+W24t1BIPEaLuI1D1hUkfOCPH lt68L3Ocy/9wT6KYqxISfduCAwPutIW/ii2wRQLpzjd+ZxTY5saGJ4eVo8BLZ98fDaVF abZklH19hgYM22fPowq+nksQiv/3zio+2Sn3xOKplWJ35ViCqUoT+5ncc3TVlxKphmqG aNq9XWaqSaKUNqLNWXqghmMS8G3s9TuuoSOb9Kii0mOUn3S4vPW3YaBgpa62cvfx9dvK euuK8npdwQ/yvUPyTrvcAL37OMTeRSYTGB4j+7R0cJq66SHj51thuMWm0bLdRJJflX61 I0+w== X-Gm-Message-State: APf1xPAT/pMUEJ6l4DJxzj6H9r0n+K3FAmZziUr/glYfWaB44+J92KYg CUxBFgiFiEOdlCzITwIuYg8on5hc3gQbMnqvKSRAfErE X-Google-Smtp-Source: AH8x2261V0Ht0ueacSS5HyuI1b2qitFqhlCEYU63gekzBGpL6hSovrcsisCz9n6el4vX/u2glJ2KTmStzoTEEGxOw2w= X-Received: by 10.31.125.205 with SMTP id y196mr589749vkc.57.1518699230465; Thu, 15 Feb 2018 04:53:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.92.200 with HTTP; Thu, 15 Feb 2018 04:53:30 -0800 (PST) From: Bernard Aboba Date: Thu, 15 Feb 2018 07:53:30 -0500 Message-ID: To: slim@ietf.org Content-Type: multipart/alternative; boundary="94eb2c1494962712d205653fb8f4" Archived-At: Subject: [Slim] Negotiation issue in draft-ietf-slim-negotiating-human-language 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, 15 Feb 2018 12:53:54 -0000 --94eb2c1494962712d205653fb8f4 Content-Type: text/plain; charset="UTF-8" As noted in the below thread, multiple ambiguities need to be resolved in draft-ietf-slim-negotiating-human-language: https://www.ietf.org/mail-archive/web/slim/current/msg01300.html In the SDP codec negotiation, multiple codecs are offered, and the answerer selects among them, with the first codec being the preferred one. Codecs not present in the Offer cannot be included in the Answer. The model proposed in draft-ietf-slim-negotiating-human-language does not conform to this paradigm, allowing languages not present in the Offer to be presented in the Answer, and also (previously) having an ambiguity about whether a single language or multiple languages can be included in an Answer. Gunnar has proposed language to address this. Any reason not to accept his proposal? --94eb2c1494962712d205653fb8f4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As noted in the below thread, multiple ambiguities need to= be resolved in draft-ietf-slim-negotiating-human-language:=C2=A0=

In the SDP codec negotiation, multiple codecs are offer= ed, and the answerer selects among them, with the first codec being the pre= ferred one.=C2=A0 Codecs not present in the Offer cannot be included in the= Answer.=C2=A0

The model proposed in draft-ietf-sl= im-negotiating-human-language does not conform to this paradigm, allowing l= anguages not present in the Offer to be presented in the Answer, and also (= previously) having an ambiguity about whether a single language or multiple= languages can be included in an Answer.=C2=A0

Gun= nar has proposed language to address this.=C2=A0 Any reason not to accept h= is proposal?
--94eb2c1494962712d205653fb8f4-- From nobody Thu Feb 15 14:37:02 2018 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 CF6E612704A for ; Thu, 15 Feb 2018 14:37:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 WCZKc3U38KUU for ; Thu, 15 Feb 2018 14:36:53 -0800 (PST) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 1987F12DB6B for ; Thu, 15 Feb 2018 14:36:53 -0800 (PST) Received: from [99.111.97.174] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Thu, 15 Feb 2018 14:37:45 -0800 From: "Randall Gellens" To: "Bernard Aboba" Cc: "Gunnar =?utf-8?q?Hellstr=C3=B6m?=" , slim@ietf.org Date: Thu, 15 Feb 2018 14:36:49 -0800 X-Mailer: MailMate Trial (1.10r5443) Message-ID: <64A8A716-9AB6-4CF6-AE76-1E92AD6454F4@randy.pensive.org> In-Reply-To: References: <151555808122.21584.8379796998643581181.idtracker@ietfa.amsl.com> <2c49d430-3fb1-381f-d236-4bc5a6a38c27@omnitor.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_E4F8F9B0-0CB6-473F-9C70-C2CFC437C0DE_=" Content-Transfer-Encoding: 8bit Embedded-HTML: [{"HTML":[1628, 9824], "plain":[1183, 7133], "uuid":"A3FFF17B-623A-414E-8012-96B116F5C91F"}] Archived-At: Subject: Re: [Slim] Allowing multiple values in an answer 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, 15 Feb 2018 22:37:01 -0000 --=_MailMate_E4F8F9B0-0CB6-473F-9C70-C2CFC437C0DE_= Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I checked older versions of the draft, and the text seems to clearly indicate that one language per media is negotiated. This is why I resolved the ambiguity between the text and the ABNF in favor of the text. That said, I don’t personally mind if we were to resolve it the other way, and proposed an edit that would do so, but I do feel that the intent of the text has been clear for some time. For example, here is the text in a version from November 2014: In an offer, the 'humintlang-send' values constitute a list in preference order (first is most preferred) of the languages the offerer wishes to send using the media, and the 'humintlang-recv' values constitute a list in preference order of the languages the offerer wishes to receive using the media. … In an answer, 'humintlang-send' is the accepted language the answerer will send (which in most cases is one of the languages in the offer's 'humintlang-recv'), and 'humintlang-recv' is the accepted language the answerer expects to receive (which in most cases is one of the languages in the offer's 'humintlang-send'). —Randall On 12 Jan 2018, at 7:44, Bernard Aboba wrote: > Gunnar said: > > " The IESG review started on version -19, where we had normative > language for allowing multiple languages per media and direction, and > non-normative but quite clear wording (using "is" ) for saying that > the > intention is to have one language per media and direction intended for > use. > > When this difference was questioned, you changed the normative > language, > while others suggested to change the non-normative language. I still > think > that it would be better to change the non-normative language so that > multiple languages per media and direction are allowed. I do not see > how > that would conflict the review situation, but we might need a judgment > on > that from the reviewers. " > > [BA] Yes, -19 did not have normative language about the number of > languages in the Answer and the ABNF allowed multiple languages. > Also, -19 > did not have normative language about whether the languages in the > Answer > need to be present in the Offer. The closest (from -23) is this > sentence: > > In an answer, 'hlang-send' is the language the answerer will send > if > using the media for language (which in most cases is one of the > languages in the offer's 'hlang-recv'), and 'hlang-recv' is the > language the answerer expects to receive if using the media for > language (which in most cases is one of the languages in the > offer's > 'hlang-send'). > > > Section 5.4 includes an example Answer which includes Italian in > response > to an Offer of Spanish, Basque and English. > > > > > > On Fri, Jan 12, 2018 at 2:54 AM, Gunnar Hellström < > gunnar.hellstrom@omnitor.se> wrote: > >> Den 2018-01-11 kl. 23:04, skrev Randall Gellens: >> >> I realized an additional change was needed, to the discussion of the >> offer/answer model. Attached is a revised diff. >> >> At 11:57 AM -0800 1/11/18, Randall Gellens wrote: >> >> The second of the two remaining open questions is if we should allow >> an >> answer to contain multiple values. I do not think this is the intent >> of >> the text that has been in the draft for some time; regardless, we >> could >> make such a change, but I question if we can do so now, when we've >> essentially passed IESG review. >> >> The IESG review started on version -19, where we had normative >> language for allowing multiple languages per media and direction, and >> non-normative but quite clear wording (using "is" ) for saying that >> the >> intention is to have one language per media and direction intended >> for use. >> >> When this difference was questioned, you changed the normative >> language, >> while others suggested to change the non-normative language. I still >> think >> that it would be better to change the non-normative language so that >> multiple languages per media and direction are allowed. I do not see >> how >> that would conflict the review situation, but we might need a >> judgment on >> that from the reviewers. >> >> I provided one reason yesterday why it would be better to only have >> one >> language in the answer, but I now realize that that was false. I said >> that >> one language provides better opportunity for the offeror to prepare >> for >> receiving the selected language. But even if the answer contains >> more than >> one language, the answering party should still follow the order of >> preference, and start the call using the first language in the >> hlang-send >> attribute in the media in the answer selected for use. So, all >> arguments >> point at it being better to allow more than one language in the >> answer per >> media and direction. >> >> It also solves an unfair difference we have, that it is possible to >> list >> more than one language per direction if you include languages in >> different >> media, but not for a single media. I see no logical reason for that >> difference, and I do not want to give up the freedom to indicate >> support of >> language in multiple media for the same direction. >> >> The offeror has the best opportunity for assessing which extra >> resources >> would be needed in the call after receiving the answer. I know that >> there >> may currently be economical and policy obstacles for making use of >> that >> opportunity, but it would be sad to block it by not providing the >> full view >> of the support in the answer. >> >> I find the diff you sent to be good, and also version -23 solving all >> other issues in a good way. So, I vote for applying your proposed >> changes >> on -23 and hope that that can be the final version. >> >> ------------------------------------------------------------ >> ------------------------------------------------------------ >> -------------------------- >> I also want to throw in food for thought, that I realize is too late >> in >> the process, but still worth thinking about: >> We could just as well have defined attributes only for the directions >> of >> use of the media for language, and let the "lang" attribute list the >> languages. The "lang" attribute has a better definition in rfc4566bis >> than >> before, and the main improvement we provide is that we can indicate >> direction of use of the language. We recommend strongly against >> having >> different preferences and languages in the different directions of a >> media, >> so one language list would be sufficient per media, and the new >> attributes >> could be limited to use a selection of a=hlang-send and a=hlang-recv >> per >> media without their own language lists. Sorry for the late discovery >> of >> this condition. >> ------------------------------------------------------------ >> ------------------------------------------------------------ >> --------------------------------- >> Gunnar >> >> >> I edited a version of the draft that contains all remaining >> clarifying >> editorial changes to also make this technical change and attached is >> a diff >> showing what it would look like. However, I think we should not make >> the >> change since it could introduce additional complexities or problems >> that we >> aren't considering. I think we could make such a change in a future >> extension or revision. I don't think we'd have an interoperability >> problem >> since endpoints conformant with the more restrictive version will not >> generate such answers, and would regard regard receiving such answers >> as an >> error, but not one that would fail a call. >> >> >> >> -- >> Randall Gellens >> Opinions are personal; facts are suspect; I speak for myself >> only >> -------------- Randomly selected tag: --------------- >> [XML] is probably the worst format ever designed...it really doesn't >> scale as a >> file format, and it's generally a complete disaster. --Linus >> Torvalds, >> 3/6/2014 >> >> >> Attachment converted: TiLand:diff-with-multiple 1.pdf ( / ) >> (008B9E88) >> _______________________________________________ >> SLIM mailing list >> SLIM@ietf.org >> https://www.ietf.org/mailman/listinfo/slim >> >> >> >> >> >> _______________________________________________ >> SLIM mailing >> listSLIM@ietf.orghttps://www.ietf.org/mailman/listinfo/slim >> >> >> -- >> ----------------------------------------- >> Gunnar Hellström >> Omnitorgunnar.hellstrom@omnitor.se >> +46 708 204 288 >> >> > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim --Randall --=_MailMate_E4F8F9B0-0CB6-473F-9C70-C2CFC437C0DE_= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">I checked older versions of the draft, and the text seems = to clearly indicate that one language per media is negotiated. This is w= hy I resolved the ambiguity between the text and the ABNF in favor of the= text. That said, I don=E2=80=99t personally mind if we were to resolve = it the other way, and proposed an edit that would do so, but I do feel th= at the intent of the text has been clear for some time. For example, her= e is the text in a version from November 2014:

In an offer, the 'humintlang-send' values constitute a= list in
preference order (first is most preferred) of the languages the
offerer wishes to send using the media, and the 'humintlang-recv'
values constitute a list in preference order of the languages the
offerer wishes to receive using the media. =E2=80=A6

In an answer, 'humintlang-send' is the accepted langua= ge the answerer
will send (which in most cases is one of the languages in the offer's<= br> 'humintlang-recv'), and 'humintlang-recv' is the accepted language
= the answerer expects to receive (which in most cases is one of the
= languages in the offer's 'humintlang-send').

=E2=80=94Randall

On 12 Jan 2018, at 7:44, Bernard Aboba wrote:

Gunnar said:=C2=A0

"<GH> The IESG review started on version -19, whe= re we had normative language for allowing multiple languages per media an= d direction, and non-normative but quite clear wording (using "is&qu= ot; ) for saying that the intention is to have one language per media and= direction intended for use.=C2=A0=

When this difference was questioned, you changed the normative langua= ge, while others suggested to change the non-normative language. I still = think that it would be better to change the non-normative language so tha= t multiple languages per media and direction are allowed. I do not see ho= w that would conflict the review situation, but we might need a judgment = on that from the reviewers.=C2=A0"

[BA]=C2= =A0 Yes, -19 did not have normative language about the number of language= s in the Answer and the ABNF allowed multiple languages.=C2=A0 Also, -19 = did not have normative language about whether the languages in the Answer= need to be present in the Offer.=C2=A0 The closest (from -23) is this se= ntence:=C2=A0

   In an answer, 'hlang-send' is the language the answerer will=
 send if
   using the media for language (which in most cases is one of the
   languages in the offer's 'hlang-recv'), and 'hlang-rec=
v' is the
   language the answerer expects to receive if using the media for
   language (which in most cases is one of the languages in the offer'=
;s
   'hlang-send').

Section 5.4 incl= udes an example Answer which includes Italian in response to an Offer of = Spanish, Basque and English.=C2=A0





On Fri, Jan 12, 2018 at 2:54 AM, Gunnar Hellstr=C3=B6m = <gunnar.hellstrom@omnitor.se> wrote:
= = =
Den 2018-01-11 kl. 23:04, skrev Randall Gellens:
I realized an additional change was needed, to the discussion of the offer/answer model.=C2=A0 Attached is a revised diff.

At 11:57 AM -0800 1/11/18, Randall Gellens wrote:

=C2=A0The second of the two remaining ope= n questions is if we should allow an answer to contain multiple values.=C2=A0 I do not think this is the intent of the text that = has been in the draft for some time; regardless, we could make such a change, but I question if we can do so now, when we've essentially passed IESG review.
<GH> The IESG review started on version -19, where we had normative language for allowing multiple languages per media and direction, and non-normative but quite clear wording (using "is&= quot; ) for saying that the intention is to have one language per media and direction intended for use.

When this difference was questioned, you changed the normative language, while others suggested to change the non-normative language. I still think that it would be better to change the non-normative language so that multiple languages per media and direction are allowed. I do not see how that would conflict the review situation, but we might need a judgment on that from the reviewers.

I provided one reason yesterday why it would be better to only have one language in the answer, but I now realize that that was false. I said that one language provides better opportunity for the offeror to prepare for receiving the selected language.=C2=A0 But even if the= answer contains more than one language, the answering party should still follow the order of preference, and start the call using the first language in the hlang-send attribute in the media in the answer selected for use. So, all arguments point at it being better to allow more than one language in the answer per media and direction.=C2=A0

It also solves an unfair difference we have, that it is possible to list more than one language per direction if you include languages in different media, but not for a single media. I see no logical reason for that difference, and I do not want to give up the freedom to indicate support of language in multiple media for the same direction.

The offeror has the best opportunity for assessing which extra resources would be needed in the call after receiving the answer. I know that there may currently be economical and policy obstacles for making use of that opportunity, but it would be sad to block it by not providing the full view of the support in the answer.

I find the diff you sent to be good, and also version -23 solving all other issues in a good way. So, I vote for applying your proposed changes on -23 and hope that that can be the final version.<= br>
---------------------------------------------------------------= ---------------------------------------------------------------= --------------------
I also want to throw in food for thought, that I realize is too late in the process, but still worth thinking about:
We could just as well have defined attributes only for the directions of use of the media for language, and let the "lang&q= uot; attribute list the languages. The "lang" attribute has a be= tter definition in rfc4566bis than before, and the main improvement we provide is that we can indicate direction of use of the language. We recommend strongly against having different preferences and languages in the different directions of a media, so one language list would be sufficient per media, and the new attributes could be limited to use a selection of a=3Dhlang-send=C2=A0 and a=3Dhlang-recv= per media without their own language lists.=C2=A0 Sorry for the late discovery of this condition.
---------------------------------------------------------------= ---------------------------------------------------------------= ---------------------------
Gunnar

=C2=A0I edited a version of the draft that contains all remaining= clarifying editorial changes to also make this technical change and attached is a diff showing what it would look like.=C2=A0 However, I think we should not make the change since it could introduce additional complexities or problems that we aren't considering.=C2=A0 I think we could make such a change in a futur= e extension or revision.=C2=A0 I don't think we'd have an interoperability problem since endpoints conformant with the more restrictive version will not generate such answers, and would regard regard receiving such answers as an error, but not one that would fail a call.


=C2=A0--
=C2=A0Randall Gellens
=C2=A0Opinions are personal;=C2=A0=C2=A0=C2=A0 facts are suspect;= =C2=A0=C2=A0=C2=A0 I speak for myself only
=C2=A0-------------- Randomly selected tag: ---------------
=C2=A0[XML] is probably the worst format ever designed...it reall= y doesn't scale as a
=C2=A0file format, and it's generally a complete disaster. --= Linus Torvalds, 3/6/2014


=C2=A0Attachment converted: TiLand:diff-with-multiple 1.pdf (=C2=A0= =C2=A0=C2=A0 /=C2=A0=C2=A0=C2=A0 ) (008B9E88)
=C2=A0_______________________________________________
=C2=A0SLIM mailing list
=C2=A0SLIM@ietf.org
=C2=A0https:= //www.ietf.org/mailman/listinfo/slim 




_______________________________________________
SLIM mailing list
SLIM@ietf.org
https://www.ietf.org=
/mailman/listinfo/slim


-- =

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

______________________= _________________________
SLIM mailing list
SLIM@ietf.org
https://www.ietf.org/mailman/listinfo/slim


--Randall

--=_MailMate_E4F8F9B0-0CB6-473F-9C70-C2CFC437C0DE_=-- From nobody Thu Feb 15 14:44:17 2018 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 7FEA712D7EB for ; Thu, 15 Feb 2018 14:44:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 I2YNpXwSsbsX for ; Thu, 15 Feb 2018 14:44:14 -0800 (PST) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id E9B8D127871 for ; Thu, 15 Feb 2018 14:44:13 -0800 (PST) Received: from [99.111.97.174] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Thu, 15 Feb 2018 14:45:06 -0800 From: "Randall Gellens" To: "Bernard Aboba" Cc: slim@ietf.org Date: Thu, 15 Feb 2018 14:44:09 -0800 X-Mailer: MailMate Trial (1.10r5443) Message-ID: <6754134E-63FD-4212-90D5-D07293EFE36B@randy.pensive.org> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed Archived-At: Subject: Re: [Slim] Negotiation issue in draft-ietf-slim-negotiating-human-language 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, 15 Feb 2018 22:44:16 -0000 On 15 Feb 2018, at 4:53, Bernard Aboba wrote: > As noted in the below thread, multiple ambiguities need to be resolved > in > draft-ietf-slim-negotiating-human-language: > https://www.ietf.org/mail-archive/web/slim/current/msg01300.html > > In the SDP codec negotiation, multiple codecs are offered, and the > answerer > selects among them, with the first codec being the preferred one. > Codecs > not present in the Offer cannot be included in the Answer. > > The model proposed in draft-ietf-slim-negotiating-human-language does > not > conform to this paradigm, allowing languages not present in the Offer > to be > presented in the Answer, and also (previously) having an ambiguity > about > whether a single language or multiple languages can be included in an > Answer. There are important reasons why we need to permit an answer to potentially select a language that was not included in the offer, e.g., in an emergency services case, if the PSAP does not support any of the languages in the offer, it still wants the call to proceed, and will indicate the language it supports. (In some cases this is likely to result in a more or less comprehensible communication stream, e.g., in some Scandinavian countries where cross-border languages may be different enough not to be included in an offer but mutually comprehensible to an extent, while in some cases it may result in incomprehensible communication that is still of value to the PSAP in responding to the emergency.) > Gunnar has proposed language to address this. Any reason not to > accept his > proposal? Which language is this? Can you copy the text or point to the message? --Randall From nobody Thu Feb 15 23:39:44 2018 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 A2ADD12D7E9 for ; Thu, 15 Feb 2018 23:39:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-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 NhpgypXgcvL2 for ; Thu, 15 Feb 2018 23:39:41 -0800 (PST) Received: from bin-vsp-out-03.atm.binero.net (vsp-unauthed02.binero.net [195.74.38.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99B6B124217 for ; Thu, 15 Feb 2018 23:39:40 -0800 (PST) X-Halon-ID: 869d0f9c-12ec-11e8-875e-0050569116f7 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [87.96.161.61]) by bin-vsp-out-03.atm.binero.net (Halon) with ESMTPSA id 869d0f9c-12ec-11e8-875e-0050569116f7; Fri, 16 Feb 2018 08:39:32 +0100 (CET) To: Randall Gellens , Bernard Aboba Cc: slim@ietf.org References: <6754134E-63FD-4212-90D5-D07293EFE36B@randy.pensive.org> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <09dcffcc-a65d-65d8-614d-fa12b790dd4f@omnitor.se> Date: Fri, 16 Feb 2018 08:39:32 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <6754134E-63FD-4212-90D5-D07293EFE36B@randy.pensive.org> Content-Type: multipart/alternative; boundary="------------7F3E392A67360619D9391341" Content-Language: en-US Archived-At: Subject: Re: [Slim] Negotiation issue in draft-ietf-slim-negotiating-human-language 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: Fri, 16 Feb 2018 07:39:44 -0000 This is a multi-part message in MIME format. --------------7F3E392A67360619D9391341 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Den 2018-02-15 kl. 23:44, skrev Randall Gellens: > On 15 Feb 2018, at 4:53, Bernard Aboba wrote: > >> As noted in the below thread, multiple ambiguities need to be >> resolved in >> draft-ietf-slim-negotiating-human-language: >> https://www.ietf.org/mail-archive/web/slim/current/msg01300.html >> >> In the SDP codec negotiation, multiple codecs are offered, and the >> answerer >> selects among them, with the first codec being the preferred one. >> Codecs >> not present in the Offer cannot be included in the Answer. >> >> The model proposed in draft-ietf-slim-negotiating-human-language does >> not >> conform to this paradigm, allowing languages not present in the Offer >> to be >> presented in the Answer, and also (previously) having an ambiguity about >> whether a single language or multiple languages can be included in an >> Answer. > > There are important reasons why we need to permit an answer to > potentially select a language that was not included in the offer, > e.g., in an emergency services case, if the PSAP does not support any > of the languages in the offer, it still wants the call to proceed, and > will indicate the language it supports. (In some cases this is likely > to result in a more or less comprehensible communication stream, e.g., > in some Scandinavian countries where cross-border languages may be > different enough not to be included in an offer but mutually > comprehensible to an extent, while in some cases it may result in > incomprehensible communication that is still of value to the PSAP in > responding to the emergency.) > >> Gunnar has proposed language to address this. Any reason not to >> accept his >> proposal? > > Which language is this? Can you copy the text or point to the message? I find that the changes to version -23 prepared by Randall and provided in this archive mail are good: https://www.ietf.org/mail-archive/web/slim/current/msg01289.html That version allows answers to contain languages not contained in the offer (that was already allowed and well specified in version -23), and allows multiple languages per media and direction in the answer. I think both of these conditions are good and important for successful use of the draft. We need to imagine all kinds of feasible applications, e.g. the decision on including interpreting resources taken by the offeror after receiving the answer. That calls for providing the full and true picture about the supported languages in the answer. So, I repeat my comment from https://www.ietf.org/mail-archive/web/slim/current/msg01297.html "I find the diff you sent to be good, and also version -23 solving all other issues in a good way. So, I vote for applying your proposed changes on -23 and hope that that can be the final version." Gunnar > > > --Randall > > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim -- ----------------------------------------- Gunnar Hellstrm Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 --------------7F3E392A67360619D9391341 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit



Den 2018-02-15 kl. 23:44, skrev Randall Gellens:
On 15 Feb 2018, at 4:53, Bernard Aboba wrote:

As noted in the below thread, multiple ambiguities need to be resolved in
draft-ietf-slim-negotiating-human-language:
https://www.ietf.org/mail-archive/web/slim/current/msg01300.html

In the SDP codec negotiation, multiple codecs are offered, and the answerer
selects among them, with the first codec being the preferred one. Codecs
not present in the Offer cannot be included in the Answer.

The model proposed in draft-ietf-slim-negotiating-human-language does not
conform to this paradigm, allowing languages not present in the Offer to be
presented in the Answer, and also (previously) having an ambiguity about
whether a single language or multiple languages can be included in an
Answer.

There are important reasons why we need to permit an answer to potentially select a language that was not included in the offer, e.g., in an emergency services case, if the PSAP does not support any of the languages in the offer, it still wants the call to proceed, and will indicate the language it supports. (In some cases this is likely to result in a more or less comprehensible communication stream, e.g., in some Scandinavian countries where cross-border languages may be different enough not to be included in an offer but mutually comprehensible to an extent, while in some cases it may result in incomprehensible communication that is still of value to the PSAP in responding to the emergency.)

Gunnar has proposed language to address this. Any reason not to accept his
proposal?

Which language is this? Can you copy the text or point to the message?
I find that the changes to version -23 prepared by Randall and provided in this archive mail are good:
https://www.ietf.org/mail-archive/web/slim/current/msg01289.html

That version allows answers to contain languages not contained in the offer (that was already allowed and well specified in version -23),
and allows multiple languages per media and direction in the answer.

I think both of these conditions are good and important for successful use of the draft.
We need to imagine all kinds of feasible applications, e.g. the decision on including interpreting resources taken by the offeror after receiving the answer. That calls for providing the full and true picture about the supported languages in the answer.

So, I repeat my comment from https://www.ietf.org/mail-archive/web/slim/current/msg01297.html
"I find the diff you sent to be good, and also version -23 solving all other issues in a good way. So, I vote for applying your proposed changes on -23 and hope that that can be the final version."

Gunnar


--Randall

_______________________________________________
SLIM mailing list
SLIM@ietf.org
https://www.ietf.org/mailman/listinfo/slim 

-- 
-----------------------------------------
Gunnar Hellstrm
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288
--------------7F3E392A67360619D9391341-- From nobody Fri Feb 16 19:37:14 2018 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 DB02612426E for ; Fri, 16 Feb 2018 19:37:11 -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 aezKfHar6rUE for ; Fri, 16 Feb 2018 19:37:09 -0800 (PST) Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::22d]) (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 6FF5A124235 for ; Fri, 16 Feb 2018 19:37:09 -0800 (PST) Received: by mail-ua0-x22d.google.com with SMTP id e25so3138153uan.5 for ; Fri, 16 Feb 2018 19:37:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CnzW7lAqmHdoWJ5OYVQt0oSkB27T2UwsKluvbpyzBdY=; b=OIvDUY8Kb4GryJZKr9aPaDw7D7gxN6nWw1u69KMoRa9DvLx28WOKI4LG1iJQPoYEzs CfTGm3q9igTONLkYPXvKtcTRdVU/+eJo8XIMo1WcLna5+TdZ6/hCGLvZiSvKwPJSoXat BwYggGfJrkwOzpARHb9c6cRSf9RLByjnOc5V1PprrDf9CuH8DBti8CHjwubeMAoI5ZR0 X1n203eSPHsosadX7NJLaTuLxuqTu3QHKncnDYu778yPRgS2uBrqjzRi8MQXoT1uyELz 4OAYyk1G8XwAl8xXiMgef04G95kJ6tJwt7eFErQQ80tUW6wanBxQG/1TaxWJfDybYcGB VxnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CnzW7lAqmHdoWJ5OYVQt0oSkB27T2UwsKluvbpyzBdY=; b=HchAfGqYaKMZcrak0To3BUeymWVncIKXvF9/qB/dzHNya+50qm1ha0MRdv+eHitUBl Q2GoThDCyb/9lBLuy+KnL/sGuM/KXFY6FI+Jp0e329vBZbb3MLyZ5QW1Q2blDn7HvDwm x/1CD2FO7uGHzJugWuwRmjEsiWGXwdDxqdquZM4hEO0p3Vklx2xt1khE3cRjgJd6chdi SQFO5HealzX8AXdlHgftb/K0z5tYLeM1HzChTC2b0euwx0+Paj8dfF9G6Xo8SwYuuQaC P0HSe76nL5mpYSO/e3bT5zzpZxLTYQHOVeBUM8MZJ6aTpwEWpy0S+kp7DiY4l9JOM3ye auoA== X-Gm-Message-State: APf1xPDMKaL7QGYQK7/2UtYVv05xuN74+dqGDM9HUMVJfTd50Zo9oVS4 vAvnUa5XwsOw0VKAwrzVySbVsOU8kuDCa82agwaN2Q== X-Google-Smtp-Source: AH8x226MrquNWkh5jgO12Ss9GVXGAwjjy37oNVFsu4TyP+3e8b6qjWhejDX5tJ96H8qJIRV2LPzRmEDtwkU3FBmCZbo= X-Received: by 10.176.18.220 with SMTP id o28mr6431540uac.41.1518838628045; Fri, 16 Feb 2018 19:37:08 -0800 (PST) MIME-Version: 1.0 References: <6754134E-63FD-4212-90D5-D07293EFE36B@randy.pensive.org> <09dcffcc-a65d-65d8-614d-fa12b790dd4f@omnitor.se> In-Reply-To: <09dcffcc-a65d-65d8-614d-fa12b790dd4f@omnitor.se> From: Bernard Aboba Date: Sat, 17 Feb 2018 03:36:57 +0000 Message-ID: To: =?UTF-8?Q?Gunnar_Hellstr=C3=B6m?= Cc: Randall Gellens , slim@ietf.org Content-Type: multipart/alternative; boundary="f403043613c2e55bb00565602c3e" Archived-At: Subject: Re: [Slim] Negotiation issue in draft-ietf-slim-negotiating-human-language 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: Sat, 17 Feb 2018 03:37:12 -0000 --f403043613c2e55bb00565602c3e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yes, the proposed changes seem good. One question: is there enough normative language about adding languages to an Answer that were not in the Offer? For example, can this only occur if the Answerer has no languages in common with the Offerer? Or can an Answerer add any languages(s) they would put into an Offer if roles were reversed? On Fri, Feb 16, 2018 at 02:39 Gunnar Hellstr=C3=B6m wrote: > I find that the changes to version -23 prepared by Randall and provided i= n > this archive mail are good: > https://www.ietf.org/mail-archive/web/slim/current/msg01289.html > > That version allows answers to contain languages not contained in the > offer (that was already allowed and well specified in version -23), > and allows multiple languages per media and direction in the answer. > > I think both of these conditions are good and important for successful us= e > of the draft. > We need to imagine all kinds of feasible applications, e.g. the decision > on including interpreting resources taken by the offeror after receiving > the answer. That calls for providing the full and true picture about the > supported languages in the answer. > > So, I repeat my comment from > https://www.ietf.org/mail-archive/web/slim/current/msg01297.html > "I find the diff you sent to be good, and also version -23 solving all > other issues in a good way. So, I vote for applying your proposed changes > on -23 and hope that that can be the final version." > > Gunnar > > > > --Randall > > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim > > > -- > ----------------------------------------- > Gunnar Hellstr=C3=B6m > Omnitorgunnar.hellstrom@omnitor.se > +46 708 204 288 > > --f403043613c2e55bb00565602c3e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes, the proposed changes seem good. One question: i= s there enough normative language about adding languages to an Answer that = were not in the Offer? For example, can this only occur if the Answerer has= no languages in common with the Offerer? Or can an Answerer add any langua= ges(s) they would put into an Offer if roles were reversed?

On Fri, Feb 16, 2018 at 02:39 Gunnar Hellstr=C3= =B6m <gunnar.hellstrom@om= nitor.se> wrote:
I find that the changes to version -23 prepared by Randall and provided in this archive mail are good:
https://www.ietf.org/mail-archive/web/slim/current/msg01289.html

That version allows answers to contain languages not contained in the offer (that was already allowed and well specified in version -23),
and allows multiple languages per media and direction in the answer.
I think both of these conditions are good and important for successful use of the draft.
We need to imagine all kinds of feasible applications, e.g. the decision on including interpreting resources taken by the offeror after receiving the answer. That calls for providing the full and true picture about the supported languages in the answer.=C2=A0

So, I repeat my comment from https://www.ietf.org/mail-archive/web/slim/current/msg01297.html
"I find the diff you sent to be good, and also version -23 solving all other issues in a good way. So, I vote for applying your proposed changes on -23 and hope that that can be the final version."

Gunnar


--Randall

_______________________________________________
SLIM mailing list
SLIM@ietf.org
https://www.ietf.o= rg/mailman/listinfo/slim 

--=20
-----------------------------------------
Gunnar Hellstr=C3=B6m
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288
--f403043613c2e55bb00565602c3e-- From nobody Sat Feb 17 01:52:10 2018 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 12FD3124217 for ; Sat, 17 Feb 2018 01:52:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 JYtxd-c81nWf for ; Sat, 17 Feb 2018 01:52:06 -0800 (PST) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 5884B120724 for ; Sat, 17 Feb 2018 01:52:06 -0800 (PST) Received: from [163.47.54.3] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Sat, 17 Feb 2018 01:52:59 -0800 From: "Randall Gellens" To: "Bernard Aboba" Cc: "Gunnar =?utf-8?q?Hellstr=C3=B6m?=" , slim@ietf.org Date: Sat, 17 Feb 2018 01:52:02 -0800 X-Mailer: MailMate Trial (1.10r5443) Message-ID: In-Reply-To: References: <6754134E-63FD-4212-90D5-D07293EFE36B@randy.pensive.org> <09dcffcc-a65d-65d8-614d-fa12b790dd4f@omnitor.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_6FE2E0AE-13BB-4C7F-97D9-8E744E59E0A5_=" Content-Transfer-Encoding: 8bit Embedded-HTML: [{"HTML":[648, 3523], "plain":[252, 1822], "uuid":"7F242985-85CB-4614-93DC-E50DE623900E"}] Archived-At: Subject: Re: [Slim] Negotiation issue in draft-ietf-slim-negotiating-human-language 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: Sat, 17 Feb 2018 09:52:08 -0000 --=_MailMate_6FE2E0AE-13BB-4C7F-97D9-8E744E59E0A5_= Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Bernard, Putting a language in an answer that was not in the offer is an unusual case (as the text says). I don’t think we need to add more text (normative or descriptive) about it. —Randall On 16 Feb 2018, at 19:36, Bernard Aboba wrote: > Yes, the proposed changes seem good. One question: is there enough > normative language about adding languages to an Answer that were not > in the > Offer? For example, can this only occur if the Answerer has no > languages in > common with the Offerer? Or can an Answerer add any languages(s) they > would > put into an Offer if roles were reversed? > > On Fri, Feb 16, 2018 at 02:39 Gunnar Hellström > > wrote: > >> I find that the changes to version -23 prepared by Randall and >> provided in >> this archive mail are good: >> https://www.ietf.org/mail-archive/web/slim/current/msg01289.html >> >> That version allows answers to contain languages not contained in the >> offer (that was already allowed and well specified in version -23), >> and allows multiple languages per media and direction in the answer. >> >> I think both of these conditions are good and important for >> successful use >> of the draft. >> We need to imagine all kinds of feasible applications, e.g. the >> decision >> on including interpreting resources taken by the offeror after >> receiving >> the answer. That calls for providing the full and true picture about >> the >> supported languages in the answer. >> >> So, I repeat my comment from >> https://www.ietf.org/mail-archive/web/slim/current/msg01297.html >> "I find the diff you sent to be good, and also version -23 solving >> all >> other issues in a good way. So, I vote for applying your proposed >> changes >> on -23 and hope that that can be the final version." >> >> Gunnar >> >> >> >> --Randall >> >> _______________________________________________ >> SLIM mailing list >> SLIM@ietf.org >> https://www.ietf.org/mailman/listinfo/slim >> >> >> -- >> ----------------------------------------- >> Gunnar Hellström >> Omnitorgunnar.hellstrom@omnitor.se >> +46 708 204 288 >> >> --Randall --=_MailMate_6FE2E0AE-13BB-4C7F-97D9-8E744E59E0A5_= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">Hi Bernard,

Putting a language in an answer that was not in the offer= is an unusual case (as the text says). I don=E2=80=99t think we need to= add more text (normative or descriptive) about it.

=E2=80=94Randall

On 16 Feb 2018, at 19:36, Bernard Aboba wrote:

Yes, the proposed changes seem good. One question: i= s there enough normative language about adding languages to an Answer tha= t were not in the Offer? For example, can this only occur if the Answerer= has no languages in common with the Offerer? Or can an Answerer add any = languages(s) they would put into an Offer if roles were reversed?
<= div text=3D"#000000" bgcolor=3D"#FFFFFF"> I find that the changes to version -23 prepared by Randall and provided in this archive mail are good:
https://www.ietf.org/mail-archive/web/slim/current/msg01289.html

That version allows answers to contain languages not contained in the offer (that was already allowed and well specified in version -23),
and allows multiple languages per media and direction in the answer.<= br>
I think both of these conditions are good and important for successful use of the draft.
We need to imagine all kinds of feasible applications, e.g. the decision on including interpreting resources taken by the offeror after receiving the answer. That calls for providing the full and true picture about the supported languages in the answer.=C2=A0

So, I repeat my comment from https://www.ietf.org/mail-archive/web/slim/current/msg01297.html
"I find the diff you sent to be good, and also version -23 solving all other issues in a good way. So, I vote for applying your proposed changes on -23 and hope that that can be the final version."

Gunnar


--Randall

_______________________________________________
SLIM mailing list
SLIM@ietf.org
https://www.ie= tf.org/mailman/listinfo/slim 

-- =

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


--Randall

--=_MailMate_6FE2E0AE-13BB-4C7F-97D9-8E744E59E0A5_=-- From nobody Sat Feb 17 14:21:14 2018 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 228C112D72F for ; Sat, 17 Feb 2018 14:21:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.699 X-Spam-Level: X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, 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 slkIvQG23xLD for ; Sat, 17 Feb 2018 14:21:08 -0800 (PST) Received: from bin-vsp-out-01.atm.binero.net (bin-mail-out-05.binero.net [195.74.38.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 673AE1250B8 for ; Sat, 17 Feb 2018 14:21:07 -0800 (PST) X-Halon-ID: d1f9ff2e-1430-11e8-93ce-005056917a89 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [87.96.161.61]) by bin-vsp-out-01.atm.binero.net (Halon) with ESMTPSA id d1f9ff2e-1430-11e8-93ce-005056917a89; Sat, 17 Feb 2018 23:20:55 +0100 (CET) To: Randall Gellens , Bernard Aboba Cc: slim@ietf.org References: <6754134E-63FD-4212-90D5-D07293EFE36B@randy.pensive.org> <09dcffcc-a65d-65d8-614d-fa12b790dd4f@omnitor.se> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <5c33acfd-8853-4254-c6b1-fa05ea4901fd@omnitor.se> Date: Sat, 17 Feb 2018 23:20:58 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------E3880CF47DFCEA9CA9BB52FB" Content-Language: en-US Archived-At: Subject: Re: [Slim] Negotiation issue in draft-ietf-slim-negotiating-human-language 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: Sat, 17 Feb 2018 22:21:12 -0000 This is a multi-part message in MIME format. --------------E3880CF47DFCEA9CA9BB52FB Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I agree with Randall. No more normative or descriptive language is needed. There is already a warning against providing language indications that will be hard to match. That will happen if you decide to answer with a language that was not in the offer. But it is better than answering with no language indication and it indicates how you might answer the call. There is however one small adjustment to do. The sentence about having the languages in preference order in the lists should be included also in the paragraph about the answer in 5.2.  Or it could be pulled out from the paragraph about the offer and put in a common paragraph below both paragraphs about the offer and the answer. And the lists should be in plural in the sentence. Here the sentence is attached last in the paragraph about the answer: -----------------------------5.2 paragraph about the answer, with new sentence attached last------------------------------------------ In an answer, 'hlang-send' is a list of one or more languages the answerer might send if using the media for language (which in most cases contains one or more of the languages in the offer's 'hlang-recv'), and 'hlang-recv' is a list of one or more of the languages the answerer is prepared to receive if using the media for language (which in most cases contains one or more of the languages in the offer's 'hlang-send'). The lists of languages are in preference order (first is most preferred). ---------------------------------------------------------------------------------------------------------------------------------------------------------- /Gunnar Den 2018-02-17 kl. 10:52, skrev Randall Gellens: > > Hi Bernard, > > Putting a language in an answer that was not in the offer is an > unusual case (as the text says). I don’t think we need to add more > text (normative or descriptive) about it. > > —Randall > > On 16 Feb 2018, at 19:36, Bernard Aboba wrote: > > Yes, the proposed changes seem good. One question: is there enough > normative language about adding languages to an Answer that were > not in the Offer? For example, can this only occur if the Answerer > has no languages in common with the Offerer? Or can an Answerer > add any languages(s) they would put into an Offer if roles were > reversed? > > On Fri, Feb 16, 2018 at 02:39 Gunnar Hellström > > > wrote: > > I find that the changes to version -23 prepared by Randall and > provided in this archive mail are good: > https://www.ietf.org/mail-archive/web/slim/current/msg01289.html > > That version allows answers to contain languages not contained > in the offer (that was already allowed and well specified in > version -23), > and allows multiple languages per media and direction in the > answer. > > I think both of these conditions are good and important for > successful use of the draft. > We need to imagine all kinds of feasible applications, e.g. > the decision on including interpreting resources taken by the > offeror after receiving the answer. That calls for providing > the full and true picture about the supported languages in the > answer. > > So, I repeat my comment from > https://www.ietf.org/mail-archive/web/slim/current/msg01297.html > "I find the diff you sent to be good, and also version -23 > solving all other issues in a good way. So, I vote for > applying your proposed changes on -23 and hope that that can > be the final version." > > Gunnar >> >> >> --Randall >> >> _______________________________________________ >> SLIM mailing list >> SLIM@ietf.org >> https://www.ietf.org/mailman/listinfo/slim > > -- > ----------------------------------------- > Gunnar Hellström > Omnitor > gunnar.hellstrom@omnitor.se > +46 708 204 288 > > > > --Randall > > > > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 --------------E3880CF47DFCEA9CA9BB52FB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit I agree with Randall. No more normative or descriptive language is needed. There is already a warning against providing language indications that will be hard to match. That will happen if you decide to answer with a language that was not in the offer. But it is better than answering with no language indication and it indicates how you might answer the call. 

There is however one small adjustment to do. The sentence about having the languages in preference order in the lists should be included also in the paragraph about the answer in 5.2.  Or it could be pulled out from the paragraph about the offer and put in a common paragraph below both paragraphs about the offer and the answer. And the lists should be in plural in the sentence.
Here the sentence is attached last in the paragraph about the answer:
-----------------------------5.2 paragraph about the answer, with new sentence attached last------------------------------------------
 In an answer, 'hlang-send' is a list of one or more languages the answerer might send if
   using the media for language (which in most cases contains one or more of the
   languages in the offer's 'hlang-recv'), and 'hlang-recv' is a list of one or more of the
   languages the answerer is prepared to receive if using the media for
   language (which in most cases contains one or more of the languages in the offer's
   'hlang-send'). The lists of languages are in preference order (first is most
   preferred).
----------------------------------------------------------------------------------------------------------------------------------------------------------
/Gunnar





Den 2018-02-17 kl. 10:52, skrev Randall Gellens:

Hi Bernard,

Putting a language in an answer that was not in the offer is an unusual case (as the text says). I don’t think we need to add more text (normative or descriptive) about it.

—Randall

On 16 Feb 2018, at 19:36, Bernard Aboba wrote:

Yes, the proposed changes seem good. One question: is there enough normative language about adding languages to an Answer that were not in the Offer? For example, can this only occur if the Answerer has no languages in common with the Offerer? Or can an Answerer add any languages(s) they would put into an Offer if roles were reversed?

On Fri, Feb 16, 2018 at 02:39 Gunnar Hellström <gunnar.hellstrom@omnitor.se> wrote:
I find that the changes to version -23 prepared by Randall and provided in this archive mail are good:
https://www.ietf.org/mail-archive/web/slim/current/msg01289.html

That version allows answers to contain languages not contained in the offer (that was already allowed and well specified in version -23),
and allows multiple languages per media and direction in the answer.

I think both of these conditions are good and important for successful use of the draft.
We need to imagine all kinds of feasible applications, e.g. the decision on including interpreting resources taken by the offeror after receiving the answer. That calls for providing the full and true picture about the supported languages in the answer. 

So, I repeat my comment from https://www.ietf.org/mail-archive/web/slim/current/msg01297.html
"I find the diff you sent to be good, and also version -23 solving all other issues in a good way. So, I vote for applying your proposed changes on -23 and hope that that can be the final version."

Gunnar


--Randall

_______________________________________________
SLIM mailing list
SLIM@ietf.org
https://www.ietf.org/mailman/listinfo/slim 

-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288


--Randall



_______________________________________________
SLIM mailing list
SLIM@ietf.org
https://www.ietf.org/mailman/listinfo/slim


-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288
--------------E3880CF47DFCEA9CA9BB52FB-- From nobody Sun Feb 18 07:28:11 2018 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 8C7EB1205F0 for ; Sun, 18 Feb 2018 07:28:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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] 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 W3TT7HTFBD48 for ; Sun, 18 Feb 2018 07:28:06 -0800 (PST) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (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 704941201F8 for ; Sun, 18 Feb 2018 07:28:06 -0800 (PST) Received: by mail-vk0-x234.google.com with SMTP id t201so4379033vke.8 for ; Sun, 18 Feb 2018 07:28:06 -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=XyQfeiQisxuXakMWxAedizamAcCaQEL1LhJCoCr/p7g=; b=pRNnmOZyKNryONl6fnwjHCv4U0svIcrikeDoqVEUXK3wR1tkUtsSGIgLAMeNk3HLvr elfW7FZKDONp66IcFBGevS6YB1HEyGyor6d1IcQN1IGkyRR2zmSC86bF7PFxtsbI6bQu 62so0JtFbT6WIvf1xogPwDDtl8Cx5cTg1t04p9jELw9AYKzf51Yta4oYEIt2d5o70uQg EeAVGsyVWuDZkpQ8ZNF2fsNW0RMxNmnSyIa8VuhYldIbjJKfdkez2N0DoXKfjOqOGQel bwKWPEdcNzmxz9qXmiExu4E0NJPssJMxfZauz/4g4rvqphsc42d8OaW/sDnGeONivKZW 7iUA== 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=XyQfeiQisxuXakMWxAedizamAcCaQEL1LhJCoCr/p7g=; b=d6MTbLU73KyeUOUIdafk9ng91gA5t14/ySQYW4hOB1I5xfWtvgIchzKy22tkF5DLHy s8oYuV7qoBzKZbhxFRsU9Q/4P3ZFNbbUNn18AD3xsG1C+W3/d41wuqWoDiN+/PZ1DxBT bn4ez7IGYEPNW2YhWT+GE5lvo93AbEAx3dPnN5cwxHocyEK4hjgfrTxZuHgIOnOItXym 63nZcjSHDldh6OMsND/dXeEQPJsh7OBGekeZRDyaaWXu6eHrDeEU60wjgpsJuRPrgaV4 iZ7TavwRvE8GfiNo9msRS3qviEtLCC31o31pww//tLlQ3sxbts6wJkT2LMUTD1JHwTtL xhGw== X-Gm-Message-State: APf1xPCAP3NdbwYabraPzqF1qNE7rOTXa8zuM6SIduHhtVBHOkiep3HP sSzRT0Q/MuLm7OQIIVVf4pyn40GhORV/gTHFbjY= X-Google-Smtp-Source: AH8x225mXMrcGlFxC/A/g6scJsOn748l1IZJfWjUq5olvWG8RdJV1uXTmKWBRm0/piAgxvDsdpCrXRL+9mgv2c1ZcuA= X-Received: by 10.31.171.5 with SMTP id u5mr4177352vke.120.1518967685037; Sun, 18 Feb 2018 07:28:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.10.24 with HTTP; Sun, 18 Feb 2018 07:27:44 -0800 (PST) In-Reply-To: <5c33acfd-8853-4254-c6b1-fa05ea4901fd@omnitor.se> References: <6754134E-63FD-4212-90D5-D07293EFE36B@randy.pensive.org> <09dcffcc-a65d-65d8-614d-fa12b790dd4f@omnitor.se> <5c33acfd-8853-4254-c6b1-fa05ea4901fd@omnitor.se> From: Bernard Aboba Date: Sun, 18 Feb 2018 10:27:44 -0500 Message-ID: To: =?UTF-8?Q?Gunnar_Hellstr=C3=B6m?= Cc: Randall Gellens , slim@ietf.org Content-Type: multipart/alternative; boundary="001a114408424ac4e505657e3952" Archived-At: Subject: Re: [Slim] Negotiation issue in draft-ietf-slim-negotiating-human-language 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: Sun, 18 Feb 2018 15:28:09 -0000 --001a114408424ac4e505657e3952 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Gunnar said: "That will happen if you decide to answer with a language that was not in the offer. But it is better than answering with no language indication and it indicates how you might answer the call." [BA] I understand how an Answerer could respond only with language(s) not in the Offer. But if the Answerer can support some of the offered languages, what are the restrictions on non-offered languages? Can an Answerer put a non-offered language first in the preference list and an offered language in a less preferred position? Should it be able to include a non-offered language at all? If you offer English and Swedish and receive an Answer with Swahili and Swedish, that could result in confusion at best. On Sat, Feb 17, 2018 at 5:20 PM, Gunnar Hellstr=C3=B6m < gunnar.hellstrom@omnitor.se> wrote: > I agree with Randall. No more normative or descriptive language is needed= . > There is already a warning against providing language indications that wi= ll > be hard to match. That will happen if you decide to answer with a languag= e > that was not in the offer. But it is better than answering with no langua= ge > indication and it indicates how you might answer the call. > > There is however one small adjustment to do. The sentence about having th= e > languages in preference order in the lists should be included also in the > paragraph about the answer in 5.2. Or it could be pulled out from the > paragraph about the offer and put in a common paragraph below both > paragraphs about the offer and the answer. And the lists should be in > plural in the sentence. > Here the sentence is attached last in the paragraph about the answer: > -----------------------------5.2 paragraph about the answer, with new > sentence attached last------------------------------------------ > > In an answer, 'hlang-send' is a list of one or more languages the answer= er might send if > using the media for language (which in most cases contains one or more= of the > languages in the offer's 'hlang-recv'), and 'hlang-recv' is a list of = one or more of the > languages the answerer is prepared to receive if using the media for > language (which in most cases contains one or more of the languages in= the offer's > 'hlang-send'). The lists of languages are in preference order (first i= s most > preferred). > > ------------------------------------------------------------ > ------------------------------------------------------------ > ---------------------------------- > /Gunnar > > > > > > > Den 2018-02-17 kl. 10:52, skrev Randall Gellens: > > Hi Bernard, > > Putting a language in an answer that was not in the offer is an unusual > case (as the text says). I don=E2=80=99t think we need to add more text (= normative > or descriptive) about it. > > =E2=80=94Randall > > On 16 Feb 2018, at 19:36, Bernard Aboba wrote: > > Yes, the proposed changes seem good. One question: is there enough > normative language about adding languages to an Answer that were not in t= he > Offer? For example, can this only occur if the Answerer has no languages = in > common with the Offerer? Or can an Answerer add any languages(s) they wou= ld > put into an Offer if roles were reversed? > > On Fri, Feb 16, 2018 at 02:39 Gunnar Hellstr=C3=B6m < > gunnar.hellstrom@omnitor.se> wrote: > >> I find that the changes to version -23 prepared by Randall and provided >> in this archive mail are good: >> https://www.ietf.org/mail-archive/web/slim/current/msg01289.html >> >> That version allows answers to contain languages not contained in the >> offer (that was already allowed and well specified in version -23), >> and allows multiple languages per media and direction in the answer. >> >> I think both of these conditions are good and important for successful >> use of the draft. >> We need to imagine all kinds of feasible applications, e.g. the decision >> on including interpreting resources taken by the offeror after receiving >> the answer. That calls for providing the full and true picture about the >> supported languages in the answer. >> >> So, I repeat my comment from https://www.ietf.org/mail- >> archive/web/slim/current/msg01297.html >> "I find the diff you sent to be good, and also version -23 solving all >> other issues in a good way. So, I vote for applying your proposed change= s >> on -23 and hope that that can be the final version." >> >> Gunnar >> >> >> >> --Randall >> >> _______________________________________________ >> SLIM mailing list >> SLIM@ietf.org >> https://www.ietf.org/mailman/listinfo/slim >> >> >> -- >> ----------------------------------------- >> Gunnar Hellstr=C3=B6m >> Omnitorgunnar.hellstrom@omnitor.se >> +46 708 204 288 >> >> > > --Randall > > > _______________________________________________ > SLIM mailing listSLIM@ietf.orghttps://www.ietf.org/mailman/listinfo/slim > > > -- > ----------------------------------------- > Gunnar Hellstr=C3=B6m > Omnitorgunnar.hellstrom@omnitor.se > +46 708 204 288 > > --001a114408424ac4e505657e3952 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Gunnar said:=C2=A0

"That will happen if you decide to answer with a language that = was not in the offer. But it is better than answering with no language indi= cation and it indicates how you might answer the call."

[BA] I understand how an Answerer could respond only with= language(s) not in the Offer.=C2=A0 But if the Answerer can support some o= f the offered languages, what are the restrictions on non-offered languages= ?=C2=A0
Can an Answerer put a non-offered language first in the p= reference list and an offered language in a less preferred position?=C2=A0 = Should it be able to include a non-offered language at all?=C2=A0 If you of= fer English and
Swedish and receive an Answer with Swahili and Sw= edish, that could result in confusion at best.

On Sat, Feb 17, 2018 at 5:20 PM, G= unnar Hellstr=C3=B6m <gunnar.hellstrom@omnitor.se>= wrote:
=20 =20 =20
I agree with Randall. No more normative or descriptive language is needed. There is already a warning against providing language indications that will be hard to match. That will happen if you decide to answer with a language that was not in the offer. But it is better than answering with no language indication and it indicates how you might answer the call.=C2=A0

There is however one small adjustment to do. The sentence about having the languages in preference order in the lists should be included also in the paragraph about the answer in 5.2.=C2=A0 Or it cou= ld be pulled out from the paragraph about the offer and put in a common paragraph below both paragraphs about the offer and the answer. And the lists should be in plural in the sentence.
Here the sentence is attached last in the paragraph about the answer:
-----------------------------5.2 paragraph about the answer, with new sentence attached last----------------------------------------= --
 In an answer, 'hlang-se=
nd' is a list of one or more languages the answerer might send if
   using the media for language (which in most cases contains one or more o=
f the
   languages in the offer's 'hlang-recv'), and 'hlang-recv&=
#39; is a list of one or more of the
   languages the answerer is prepared to receive if using the media for
   language (which in most cases contains one or more of the languages in t=
he offer's
   'hlang-send'). The lists of languages are in preference order (f=
irst is most
   preferred).
-----------------------------------------------------------------= -----------------------------------------------------------------= ------------------------
/Gunnar






Den 2018-02-17 kl. = 10:52, skrev Randall Gellens:
=20

Hi Bernard,

Putting a language in an answer that was not in the offer is an unusual case (as the text says). I don=E2=80=99= t think we need to add more text (normative or descriptive) about it.

=E2=80=94Randall

On 16 Feb 2018, at 19:36, Bernard Aboba wrote:

Yes, the proposed changes seem good. One question: is there enough normative language about adding languages to an Answer that were not in the Offer? For example, can this only occur if the Answerer has no languages in common with the Offerer? Or can an Answerer add any languages(s) they would put into an Offer if roles were reversed?

On Fri, Feb 16, 2018 at 02:39 Gunnar Hellstr=C3=B6m &l= t;gunnar.h= ellstrom@omnitor.se> wrote:
I find that th= e changes to version -23 prepared by Randall and provided in this archive mail are good:
https://www.ietf.org/mail-archi= ve/web/slim/current/msg01289.html

That version allows answers to contain languages not contained in the offer (that was already allowed and well specified in version -23),
and allows multiple languages per media and direction in the answer.

I think both of these conditions are good and important for successful use of the draft.
We need to imagine all kinds of feasible applications, e.g. the decision on including interpreting resources taken by the offeror after receiving the answer. That calls for providing the full and true picture about the supported languages in the answer.=C2=A0

So, I repeat my comment from https:/= /www.ietf.org/mail-archive/web/slim/current/msg01297.html
"I find the diff you sent to be good, and al= so version -23 solving all other issues in a good way. So, I vote for applying your proposed changes on -23 and hope that that can be the final version."

Gunnar


--Randall

_______________________________________________ =
SLIM mailing list
= SLIM@ietf.org
https://www.ietf.org/mailman/listinfo/slim 

--=20
-----------------------------------------
Gunnar Hellstr=C3=B6m
Omnitor
gunnar.h=
ellstrom@omnitor.se
+46 708 204 288


--Randall



_______________________________________________
SLIM mailing list
SLIM@ietf.org
https://www.ietf.org/mai=
lman/listinfo/slim


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

--001a114408424ac4e505657e3952-- From nobody Sun Feb 18 08:14:08 2018 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 8E016126C19 for ; Sun, 18 Feb 2018 08:14:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, 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 3s8BH1y52xo0 for ; Sun, 18 Feb 2018 08:14:04 -0800 (PST) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id BEDA7124319 for ; Sun, 18 Feb 2018 08:14:03 -0800 (PST) Received: from [10.252.7.122] (127.0.0.1) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Sun, 18 Feb 2018 08:14:55 -0800 Content-Type: multipart/alternative; boundary=Apple-Mail-3064AA30-5DC8-4C11-9DF2-D7F6DE2DFB98 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) From: Randall Gellens In-Reply-To: Date: Sun, 18 Feb 2018 23:40:32 +0800 Cc: =?utf-8?Q?Gunnar_Hellstr=C3=B6m?= , slim@ietf.org Message-Id: <608E5933-9EB0-489D-A845-39018CF68127@randy.pensive.org> References: <6754134E-63FD-4212-90D5-D07293EFE36B@randy.pensive.org> <09dcffcc-a65d-65d8-614d-fa12b790dd4f@omnitor.se> <5c33acfd-8853-4254-c6b1-fa05ea4901fd@omnitor.se> To: Bernard Aboba X-Mailer: iPhone Mail (14G60) Archived-At: Subject: Re: [Slim] Negotiation issue in draft-ietf-slim-negotiating-human-language 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: Sun, 18 Feb 2018 16:14:06 -0000 --Apple-Mail-3064AA30-5DC8-4C11-9DF2-D7F6DE2DFB98 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable We don't expect an answer to contain a non-offered language except in unusua= l cases. What's in an answer is decided by policies at the answerer. I don't= think we need to get into an exercise of trying to describe what is permitt= ed vs forbidden for such edge cases. I think we can assume that the people w= ho create the policies want to enable communication and not sow pointless co= nfusion.=20 Sent from my iPhone > On Feb 18, 2018, at 11:27 PM, Bernard Aboba wrot= e: >=20 > Gunnar said:=20 >=20 > "That will happen if you decide to answer with a language that was not in t= he offer. But it is better than answering with no language indication and it= indicates how you might answer the call." >=20 > [BA] I understand how an Answerer could respond only with language(s) not i= n the Offer. But if the Answerer can support some of the offered languages,= what are the restrictions on non-offered languages?=20 > Can an Answerer put a non-offered language first in the preference list an= d an offered language in a less preferred position? Should it be able to in= clude a non-offered language at all? If you offer English and > Swedish and receive an Answer with Swahili and Swedish, that could result i= n confusion at best. >=20 >> On Sat, Feb 17, 2018 at 5:20 PM, Gunnar Hellstr=C3=B6m wrote: >> I agree with Randall. No more normative or descriptive language is needed= . There is already a warning against providing language indications that wil= l be hard to match. That will happen if you decide to answer with a language= that was not in the offer. But it is better than answering with no language= indication and it indicates how you might answer the call. =20 >>=20 >> There is however one small adjustment to do. The sentence about having th= e languages in preference order in the lists should be included also in the p= aragraph about the answer in 5.2. Or it could be pulled out from the paragr= aph about the offer and put in a common paragraph below both paragraphs abou= t the offer and the answer. And the lists should be in plural in the sentenc= e. >> Here the sentence is attached last in the paragraph about the answer: >> -----------------------------5.2 paragraph about the answer, with new sen= tence attached last------------------------------------------ >> In an answer, 'hlang-send' is a list of one or more languages the answer= er might send if >> using the media for language (which in most cases contains one or more= of the >> languages in the offer's 'hlang-recv'), and 'hlang-recv' is a list of o= ne or more of the >> languages the answerer is prepared to receive if using the media for >> language (which in most cases contains one or more of the languages in= the offer's >> 'hlang-send'). The lists of languages are in preference order (first i= s most >> preferred). >> -------------------------------------------------------------------------= ----------------------------------------------------------------------------= ----- >> /Gunnar >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>> Den 2018-02-17 kl. 10:52, skrev Randall Gellens: >>> Hi Bernard, >>>=20 >>> Putting a language in an answer that was not in the offer is an unusual c= ase (as the text says). I don=E2=80=99t think we need to add more text (norm= ative or descriptive) about it. >>>=20 >>> =E2=80=94Randall >>>=20 >>> On 16 Feb 2018, at 19:36, Bernard Aboba wrote: >>>=20 >>> Yes, the proposed changes seem good. One question: is there enough norma= tive language about adding languages to an Answer that were not in the Offer= ? For example, can this only occur if the Answerer has no languages in commo= n with the Offerer? Or can an Answerer add any languages(s) they would put i= nto an Offer if roles were reversed? >>>=20 >>>> On Fri, Feb 16, 2018 at 02:39 Gunnar Hellstr=C3=B6m wrote: >>>> I find that the changes to version -23 prepared by Randall and provided= in this archive mail are good: >>>> https://www.ietf.org/mail-archive/web/slim/current/msg01289.html >>>>=20 >>>> That version allows answers to contain languages not contained in the o= ffer (that was already allowed and well specified in version -23), >>>> and allows multiple languages per media and direction in the answer. >>>>=20 >>>> I think both of these conditions are good and important for successful u= se of the draft.=20 >>>> We need to imagine all kinds of feasible applications, e.g. the decisio= n on including interpreting resources taken by the offeror after receiving t= he answer. That calls for providing the full and true picture about the supp= orted languages in the answer. =20 >>>>=20 >>>> So, I repeat my comment from https://www.ietf.org/mail-archive/web/slim= /current/msg01297.html >>>> "I find the diff you sent to be good, and also version -23 solving all o= ther issues in a good way. So, I vote for applying your proposed changes on -= 23 and hope that that can be the final version." >>>>=20 >>>> Gunnar=20 >>>>>=20 >>>>>=20 >>>>> --Randall=20 >>>>>=20 >>>>> _______________________________________________=20 >>>>> SLIM mailing list=20 >>>>> SLIM@ietf.org=20 >>>>> https://www.ietf.org/mailman/listinfo/slim=20 >>>>=20 >>>>=20 >>>> --=20 >>>> ----------------------------------------- >>>> Gunnar Hellstr=C3=B6m >>>> Omnitor >>>> gunnar.hellstrom@omnitor.se >>>> +46 708 204 288 >>>=20 >>>=20 >>>=20 >>> --Randall >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> SLIM mailing list >>> SLIM@ietf.org >>> https://www.ietf.org/mailman/listinfo/slim >>=20 >> --=20 >> ----------------------------------------- >> Gunnar Hellstr=C3=B6m >> Omnitor >> gunnar.hellstrom@omnitor.se >> +46 708 204 288 >=20 --Apple-Mail-3064AA30-5DC8-4C11-9DF2-D7F6DE2DFB98 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
We don't expect an answer to contain a= non-offered language except in unusual cases. What's in an answer is decide= d by policies at the answerer. I don't think we need to get into an exercise= of trying to describe what is permitted vs forbidden for such edge cases. I= think we can assume that the people who create the policies want to enable c= ommunication and not sow pointless confusion. 

Sent from my iPhone
Gunnar said: 

"That= will happen if you decide to answer with a language that was not in the off= er. But it is better than answering with no language indication and it indic= ates how you might answer the call."

[BA] I u= nderstand how an Answerer could respond only with language(s) not in the Off= er.  But if the Answerer can support some of the offered languages, wha= t are the restrictions on non-offered languages? 
Can an Answ= erer put a non-offered language first in the preference list and an offered l= anguage in a less preferred position?  Should it be able to include a n= on-offered language at all?  If you offer English and
Swedish= and receive an Answer with Swahili and Swedish, that could result in confus= ion at best.

On Sat, Feb 17, 2018 at 5:20 PM, Gunnar Hellstr=C3=B6m <gunn= ar.hellstrom@omnitor.se> wrote:
=20 =20 =20
I agree with Randall. No more normative or descriptive language is needed. There is already a warning against providing language indications that will be hard to match. That will happen if you decide to answer with a language that was not in the offer. But it is better than answering with no language indication and it indicates how you might answer the call. 

There is however one small adjustment to do. The sentence about having the languages in preference order in the lists should be included also in the paragraph about the answer in 5.2.  Or it coul= d be pulled out from the paragraph about the offer and put in a common paragraph below both paragraphs about the offer and the answer. And the lists should be in plural in the sentence.
Here the sentence is attached last in the paragraph about the answer:
-----------------------------5.2 paragraph about the answer, with new sentence attached last-----------------------------------------= -
 In an answer, 'hlang-send' is a lis=
t of one or more languages the answerer might send if
   using the media for language (which in most cases contains one or more of=
 the
   languages in the offer's 'hlang-recv'), and 'hlang-recv' is a list of one=
 or more of the
   languages the answerer is prepared to receive if using the media for
   language (which in most cases contains one or more of the languages in th=
e offer's
   'hlang-send'). The lists of languages are in preference order (first is m=
ost
   preferred).
------------------------------------------------------------------= ------------------------------------------------------------------= ----------------------
/Gunnar






Den 2018-02-17 kl. 1= 0:52, skrev Randall Gellens:
=20

Hi Bernard,

Putting a language in an answer that was not in the offer is an unusual case (as the text says). I don=E2=80=99t= think we need to add more text (normative or descriptive) about it.

=E2=80=94Randall

On 16 Feb 2018, at 19:36, Bernard Aboba wrote:

=
Yes, the proposed changes seem good. One question: is there enough normative language about adding languages to an Answer that were not in the Offer? For example, can this only occur if the Answerer has no languages in common with the Offerer? Or can an Answerer add any languages(s) they would put into an Offer if roles were reversed?

On Fri, Feb 16, 2018 at 02:39 Gunnar Hellstr=C3=B6m <= ;gunnar.hel= lstrom@omnitor.se> wrote:
I find that the= changes to version -23 prepared by Randall and provided in this archive mail are good:
https://www.ietf.org/mail-archive/= web/slim/current/msg01289.html

That version allows answers to contain languages not contained in the offer (that was already allowed and well specified in version -23),
and allows multiple languages per media and direction in the answer.

I think both of these conditions are good and important for successful use of the draft.
We need to imagine all kinds of feasible applications, e.g. the decision on including interpreting resources taken by the offeror after receiving the answer. That calls for providing the full and true picture about the supported languages in the answer. 

So, I repeat my comment from https://ww= w.ietf.org/mail-archive/web/slim/current/msg01297.html
"I find the diff you sent to be good, and also version -23 solving all other issues in a good way. So, I vote for applying your proposed changes on -23 and hope that that can be the final version."

Gunnar


--Randall

_______________________________________________ <= br> SLIM mailing list
SL= IM@ietf.org
https://www.ietf.org/mailman/listinfo/slim 

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


--Randall



_______________________________________________
SLIM mailing list
SLIM@ietf.org
https://www.ietf.org/mailm=
an/listinfo/slim


--=20
-----------------------------------------
Gunnar Hellstr=C3=B6m
Omnitor
gunnar.hellstrom@omnitor.se=

+46 708 204 288

= --Apple-Mail-3064AA30-5DC8-4C11-9DF2-D7F6DE2DFB98-- From nobody Sun Feb 18 11:55:00 2018 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 4B7DF126BFD for ; Sun, 18 Feb 2018 11:54:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 gBOm1QCyHID2 for ; Sun, 18 Feb 2018 11:54:56 -0800 (PST) Received: from bin-vsp-out-02.atm.binero.net (bin-mail-out-05.binero.net [195.74.38.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED839126BF6 for ; Sun, 18 Feb 2018 11:54:55 -0800 (PST) X-Halon-ID: 92312e42-14e5-11e8-9bc4-005056917f90 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [87.96.161.61]) by bin-vsp-out-02.atm.binero.net (Halon) with ESMTPSA id 92312e42-14e5-11e8-9bc4-005056917f90; Sun, 18 Feb 2018 20:54:47 +0100 (CET) To: Randall Gellens , Bernard Aboba Cc: slim@ietf.org References: <6754134E-63FD-4212-90D5-D07293EFE36B@randy.pensive.org> <09dcffcc-a65d-65d8-614d-fa12b790dd4f@omnitor.se> <5c33acfd-8853-4254-c6b1-fa05ea4901fd@omnitor.se> <608E5933-9EB0-489D-A845-39018CF68127@randy.pensive.org> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <3deaecbf-cf9a-a1aa-1974-63b1bd338c95@omnitor.se> Date: Sun, 18 Feb 2018 20:54:50 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <608E5933-9EB0-489D-A845-39018CF68127@randy.pensive.org> Content-Type: multipart/alternative; boundary="------------74B8D641159C191B6B4C95F0" Content-Language: en-US Archived-At: Subject: Re: [Slim] Negotiation issue in draft-ietf-slim-negotiating-human-language 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: Sun, 18 Feb 2018 19:54:59 -0000 This is a multi-part message in MIME format. --------------74B8D641159C191B6B4C95F0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Again, I agree with Randall. We do not need to complicate this with more rules. It will be a matter for the unspecified user interface to express the result of the negotiation to the users so that they rapidly can grasp the situation and know how to start the conversation smoothly. It is much more important to complement the draft with ways to express relative preference between languages in different media (in another draft) than to detail the rules about the mix of offered and un-offered languages in the answer in each media. Gunnar Den 2018-02-18 kl. 16:40, skrev Randall Gellens: > We don't expect an answer to contain a non-offered language except in > unusual cases. What's in an answer is decided by policies at the > answerer. I don't think we need to get into an exercise of trying to > describe what is permitted vs forbidden for such edge cases. I think > we can assume that the people who create the policies want to enable > communication and not sow pointless confusion. > > Sent from my iPhone > > On Feb 18, 2018, at 11:27 PM, Bernard Aboba > wrote: > >> Gunnar said: >> >> "That will happen if you decide to answer with a language that was >> not in the offer. But it is better than answering with no language >> indication and it indicates how you might answer the call." >> >> [BA] I understand how an Answerer could respond only with language(s) >> not in the Offer.  But if the Answerer can support some of the >> offered languages, what are the restrictions on non-offered languages? >> Can an Answerer put a non-offered language first in the preference >> list and an offered language in a less preferred position?  Should it >> be able to include a non-offered language at all?  If you offer >> English and >> Swedish and receive an Answer with Swahili and Swedish, that could >> result in confusion at best. >> >> On Sat, Feb 17, 2018 at 5:20 PM, Gunnar Hellström >> > wrote: >> >> I agree with Randall. No more normative or descriptive language >> is needed. There is already a warning against providing language >> indications that will be hard to match. That will happen if you >> decide to answer with a language that was not in the offer. But >> it is better than answering with no language indication and it >> indicates how you might answer the call. >> >> There is however one small adjustment to do. The sentence about >> having the languages in preference order in the lists should be >> included also in the paragraph about the answer in 5.2.  Or it >> could be pulled out from the paragraph about the offer and put in >> a common paragraph below both paragraphs about the offer and the >> answer. And the lists should be in plural in the sentence. >> Here the sentence is attached last in the paragraph about the answer: >> -----------------------------5.2 paragraph about the answer, with >> new sentence attached last------------------------------------------ >> >> In an answer, 'hlang-send' is a list of one or more languages the answerer might send if >> using the media for language (which in most cases contains one or more of the >> languages in the offer's 'hlang-recv'), and 'hlang-recv' is a list of one or more of the >> languages the answerer is prepared to receive if using the media for >> language (which in most cases contains one or more of the languages in the offer's >> 'hlang-send'). The lists of languages are in preference order (first is most >> preferred). >> >> ---------------------------------------------------------------------------------------------------------------------------------------------------------- >> /Gunnar >> >> >> >> >> >> >> Den 2018-02-17 kl. 10:52, skrev Randall Gellens: >>> >>> Hi Bernard, >>> >>> Putting a language in an answer that was not in the offer is an >>> unusual case (as the text says). I don’t think we need to add >>> more text (normative or descriptive) about it. >>> >>> —Randall >>> >>> On 16 Feb 2018, at 19:36, Bernard Aboba wrote: >>> >>> Yes, the proposed changes seem good. One question: is there >>> enough normative language about adding languages to an >>> Answer that were not in the Offer? For example, can this >>> only occur if the Answerer has no languages in common with >>> the Offerer? Or can an Answerer add any languages(s) they >>> would put into an Offer if roles were reversed? >>> >>> On Fri, Feb 16, 2018 at 02:39 Gunnar Hellström >>> >> > wrote: >>> >>> I find that the changes to version -23 prepared by >>> Randall and provided in this archive mail are good: >>> https://www.ietf.org/mail-archive/web/slim/current/msg01289.html >>> >>> >>> That version allows answers to contain languages not >>> contained in the offer (that was already allowed and >>> well specified in version -23), >>> and allows multiple languages per media and direction in >>> the answer. >>> >>> I think both of these conditions are good and important >>> for successful use of the draft. >>> We need to imagine all kinds of feasible applications, >>> e.g. the decision on including interpreting resources >>> taken by the offeror after receiving the answer. That >>> calls for providing the full and true picture about the >>> supported languages in the answer. >>> >>> So, I repeat my comment from >>> https://www.ietf.org/mail-archive/web/slim/current/msg01297.html >>> >>> "I find the diff you sent to be good, and also version >>> -23 solving all other issues in a good way. So, I vote >>> for applying your proposed changes on -23 and hope that >>> that can be the final version." >>> >>> Gunnar >>>> >>>> >>>> --Randall >>>> >>>> _______________________________________________ >>>> SLIM mailing list >>>> SLIM@ietf.org >>>> https://www.ietf.org/mailman/listinfo/slim >>>> >>> >>> -- >>> ----------------------------------------- >>> Gunnar Hellström >>> Omnitor >>> gunnar.hellstrom@omnitor.se >>> >>> +46 708 204 288 >>> >>> >>> >>> --Randall >>> >>> >>> >>> _______________________________________________ >>> SLIM mailing list >>> SLIM@ietf.org >>> https://www.ietf.org/mailman/listinfo/slim >>> >> >> -- >> ----------------------------------------- >> Gunnar Hellström >> Omnitor >> gunnar.hellstrom@omnitor.se >> +46 708 204 288 >> >> -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 --------------74B8D641159C191B6B4C95F0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Again, I agree with Randall. We do not need to complicate this with more rules. It will be a matter for the unspecified user interface to express the result of the negotiation to the users so that they rapidly can grasp the situation and know how to start the conversation smoothly. It is much more important to complement the draft with ways to express relative preference between languages in different media (in another draft) than to detail the rules about the mix of offered and un-offered languages in the answer in each media.

Gunnar



Den 2018-02-18 kl. 16:40, skrev Randall Gellens:
We don't expect an answer to contain a non-offered language except in unusual cases. What's in an answer is decided by policies at the answerer. I don't think we need to get into an exercise of trying to describe what is permitted vs forbidden for such edge cases. I think we can assume that the people who create the policies want to enable communication and not sow pointless confusion. 

Sent from my iPhone

On Feb 18, 2018, at 11:27 PM, Bernard Aboba <bernard.aboba@gmail.com> wrote:

Gunnar said: 

"That will happen if you decide to answer with a language that was not in the offer. But it is better than answering with no language indication and it indicates how you might answer the call."

[BA] I understand how an Answerer could respond only with language(s) not in the Offer.  But if the Answerer can support some of the offered languages, what are the restrictions on non-offered languages? 
Can an Answerer put a non-offered language first in the preference list and an offered language in a less preferred position?  Should it be able to include a non-offered language at all?  If you offer English and
Swedish and receive an Answer with Swahili and Swedish, that could result in confusion at best.

On Sat, Feb 17, 2018 at 5:20 PM, Gunnar Hellström <gunnar.hellstrom@omnitor.se> wrote:
I agree with Randall. No more normative or descriptive language is needed. There is already a warning against providing language indications that will be hard to match. That will happen if you decide to answer with a language that was not in the offer. But it is better than answering with no language indication and it indicates how you might answer the call. 

There is however one small adjustment to do. The sentence about having the languages in preference order in the lists should be included also in the paragraph about the answer in 5.2.  Or it could be pulled out from the paragraph about the offer and put in a common paragraph below both paragraphs about the offer and the answer. And the lists should be in plural in the sentence.
Here the sentence is attached last in the paragraph about the answer:
-----------------------------5.2 paragraph about the answer, with new sentence attached last------------------------------------------
 In an answer, 'hlang-send' is a list of one or more languages the answerer might send if
   using the media for language (which in most cases contains one or more of the
   languages in the offer's 'hlang-recv'), and 'hlang-recv' is a list of one or more of the
   languages the answerer is prepared to receive if using the media for
   language (which in most cases contains one or more of the languages in the offer's
   'hlang-send'). The lists of languages are in preference order (first is most
   preferred).
----------------------------------------------------------------------------------------------------------------------------------------------------------
/Gunnar






Den 2018-02-17 kl. 10:52, skrev Randall Gellens:

Hi Bernard,

Putting a language in an answer that was not in the offer is an unusual case (as the text says). I don’t think we need to add more text (normative or descriptive) about it.

—Randall

On 16 Feb 2018, at 19:36, Bernard Aboba wrote:

Yes, the proposed changes seem good. One question: is there enough normative language about adding languages to an Answer that were not in the Offer? For example, can this only occur if the Answerer has no languages in common with the Offerer? Or can an Answerer add any languages(s) they would put into an Offer if roles were reversed?

On Fri, Feb 16, 2018 at 02:39 Gunnar Hellström <gunnar.hellstrom@omnitor.se> wrote:
I find that the changes to version -23 prepared by Randall and provided in this archive mail are good:
https://www.ietf.org/mail-archive/web/slim/current/msg01289.html

That version allows answers to contain languages not contained in the offer (that was already allowed and well specified in version -23),
and allows multiple languages per media and direction in the answer.

I think both of these conditions are good and important for successful use of the draft.
We need to imagine all kinds of feasible applications, e.g. the decision on including interpreting resources taken by the offeror after receiving the answer. That calls for providing the full and true picture about the supported languages in the answer. 

So, I repeat my comment from https://www.ietf.org/mail-archive/web/slim/current/msg01297.html
"I find the diff you sent to be good, and also version -23 solving all other issues in a good way. So, I vote for applying your proposed changes on -23 and hope that that can be the final version."

Gunnar


--Randall

_______________________________________________
SLIM mailing list
SLIM@ietf.org
https://www.ietf.org/mailman/listinfo/slim 

-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288


--Randall



_______________________________________________
SLIM mailing list
SLIM@ietf.org
https://www.ietf.org/mailman/listinfo/slim


-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288


-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288
--------------74B8D641159C191B6B4C95F0-- From nobody Sun Feb 18 11:56:46 2018 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 55FCB126BF6 for ; Sun, 18 Feb 2018 11:56:45 -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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 UxsAg6bW3nBh for ; Sun, 18 Feb 2018 11:56:43 -0800 (PST) Received: from mail-yb0-x22a.google.com (mail-yb0-x22a.google.com [IPv6:2607:f8b0:4002:c09::22a]) (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 F1B4112422F for ; Sun, 18 Feb 2018 11:56:42 -0800 (PST) Received: by mail-yb0-x22a.google.com with SMTP id i13-v6so2221735ybl.9 for ; Sun, 18 Feb 2018 11:56:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=h3ip3lPaJG8MWYNLT6XRxhwGSJoqY5/pPdqA5I9tHzw=; b=raioouTNX5uVMOqU5Wh8DD/zVzVULKEoMbZyJZlMT1x3Wf0Hou+kzDecEoiM0/1z70 5GdYd5aOKExoK+jEt4R/zUVqvyBgvOpRqULdUrQ4Vdosh4kBRlQ+fvUuMpz6XRr4cr5Q Dzsaql082uxnM4P5ML5tjHEgX4WGhMOitY+MLN+Ccv6ZliamwbAiIrx3pmOrSrBHVz51 WbcYOUcAUaL+tFUhuVcaMWIeSceXnFRBMfeeaeJVEKuHXcQDo57lO6DwWmn0LRkz4Uyp qrirCIFrzNbFkDk/ZmD43yhL+ztYBMZLsNkODrZDg7F+8c4eLHGR4T2qsE16NOVVbFbM XzoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=h3ip3lPaJG8MWYNLT6XRxhwGSJoqY5/pPdqA5I9tHzw=; b=jtay+M4ARGoXxnoT3kCnRRhu3cB9V5wZc+uQbY8T1mqyytxBvf/gV4hxr1DgAZOh+5 PubHrRLhxLkq0k1EytHKbplq8Ci6eBNa++FNmqKHZRaEkdfDANIBQ1+ZSHVRhnbCHXk+ oik5L86tSwyc8QZljqFkUV/tJj5/9FXNbWDA1R3+gRch5qSDeutPd002lvD9xp0ZTlQQ o0553WJpwWEJtMc2EQhrbjLeviBgxKQFMLLNCGhGb6FLewWI9mixEkX+bn1SIa16Z0yH EZUWnq1ZZOgLScHpcp4GuUOZoBcAWFHyGQr06W1XHI9UWg3/Sewt0G6EJny6GX+SM5Lx a2cw== X-Gm-Message-State: APf1xPAq5kz4I5b/azUHKl+pLqZfFxbI1hSHjW5e9raYdBxYS8yw8I7u 7TPcwvbPkmit35IqTyChqkfAlVdO X-Google-Smtp-Source: AH8x226lyfCZ5T6pkibj+knjZ4VeBBVh3KEtPKNf8iJxksMygh+9td2zowf3/IsVMW9DeB7ct+XQaw== X-Received: by 10.37.63.1 with SMTP id m1mr8860649yba.489.1518983801723; Sun, 18 Feb 2018 11:56:41 -0800 (PST) Received: from [10.187.41.197] (mobile-166-172-190-31.mycingular.net. [166.172.190.31]) by smtp.gmail.com with ESMTPSA id t4sm3045820ywh.9.2018.02.18.11.56.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 18 Feb 2018 11:56:41 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-BA5C1FC7-C7DB-4281-A7A4-A5B6E32C9BED Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPhone Mail (15D60) In-Reply-To: <608E5933-9EB0-489D-A845-39018CF68127@randy.pensive.org> Date: Sun, 18 Feb 2018 14:56:40 -0500 Cc: slim@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <9B27941C-CAE7-4162-8E8B-3BFA60921578@gmail.com> References: <6754134E-63FD-4212-90D5-D07293EFE36B@randy.pensive.org> <09dcffcc-a65d-65d8-614d-fa12b790dd4f@omnitor.se> <5c33acfd-8853-4254-c6b1-fa05ea4901fd@omnitor.se> <608E5933-9EB0-489D-A845-39018CF68127@randy.pensive.org> To: Randall Gellens , =?utf-8?Q?Gunnar_Hellstr=C3=B6m?= Archived-At: Subject: Re: [Slim] Negotiation issue in draft-ietf-slim-negotiating-human-language 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: Sun, 18 Feb 2018 19:56:45 -0000 --Apple-Mail-BA5C1FC7-C7DB-4281-A7A4-A5B6E32C9BED Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable The fact that Answers containing =E2=80=9Cpointless confusion=E2=80=9D are a= llowed means that implementations need to be prepared to handle these edge c= ases. I see no benefit arising from this. Why not require that an Answer place mutually supported language(s) before l= anguages only supported by the Answerer? In what situations would it be nece= ssary to do something else? > On Feb 18, 2018, at 10:40 AM, Randall Gellens w= rote: >=20 > We don't expect an answer to contain a non-offered language except in unus= ual cases. What's in an answer is decided by policies at the answerer. I don= 't think we need to get into an exercise of trying to describe what is permi= tted vs forbidden for such edge cases. I think we can assume that the people= who create the policies want to enable communication and not sow pointless c= onfusion.=20 >=20 > Sent from my iPhone >=20 >> On Feb 18, 2018, at 11:27 PM, Bernard Aboba wro= te: >>=20 >> Gunnar said:=20 >>=20 >> "That will happen if you decide to answer with a language that was not in= the offer. But it is better than answering with no language indication and i= t indicates how you might answer the call." >>=20 >> [BA] I understand how an Answerer could respond only with language(s) not= in the Offer. But if the Answerer can support some of the offered language= s, what are the restrictions on non-offered languages?=20 >> Can an Answerer put a non-offered language first in the preference list a= nd an offered language in a less preferred position? Should it be able to i= nclude a non-offered language at all? If you offer English and >> Swedish and receive an Answer with Swahili and Swedish, that could result= in confusion at best. >>=20 >>> On Sat, Feb 17, 2018 at 5:20 PM, Gunnar Hellstr=C3=B6m wrote: >>> I agree with Randall. No more normative or descriptive language is neede= d. There is already a warning against providing language indications that wi= ll be hard to match. That will happen if you decide to answer with a languag= e that was not in the offer. But it is better than answering with no languag= e indication and it indicates how you might answer the call. =20 >>>=20 >>> There is however one small adjustment to do. The sentence about having t= he languages in preference order in the lists should be included also in the= paragraph about the answer in 5.2. Or it could be pulled out from the para= graph about the offer and put in a common paragraph below both paragraphs ab= out the offer and the answer. And the lists should be in plural in the sente= nce. >>> Here the sentence is attached last in the paragraph about the answer: >>> -----------------------------5.2 paragraph about the answer, with new se= ntence attached last------------------------------------------ >>> In an answer, 'hlang-send' is a list of one or more languages the answe= rer might send if >>> using the media for language (which in most cases contains one or mor= e of the >>> languages in the offer's 'hlang-recv'), and 'hlang-recv' is a list of= one or more of the >>> languages the answerer is prepared to receive if using the media for >>> language (which in most cases contains one or more of the languages i= n the offer's >>> 'hlang-send'). The lists of languages are in preference order (first i= s most >>> preferred). >>> ------------------------------------------------------------------------= ----------------------------------------------------------------------------= ------ >>> /Gunnar >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>> Den 2018-02-17 kl. 10:52, skrev Randall Gellens: >>>> Hi Bernard, >>>>=20 >>>> Putting a language in an answer that was not in the offer is an unusual= case (as the text says). I don=E2=80=99t think we need to add more text (no= rmative or descriptive) about it. >>>>=20 >>>> =E2=80=94Randall >>>>=20 >>>> On 16 Feb 2018, at 19:36, Bernard Aboba wrote: >>>>=20 >>>> Yes, the proposed changes seem good. One question: is there enough norm= ative language about adding languages to an Answer that were not in the Offe= r? For example, can this only occur if the Answerer has no languages in comm= on with the Offerer? Or can an Answerer add any languages(s) they would put i= nto an Offer if roles were reversed? >>>>=20 >>>>> On Fri, Feb 16, 2018 at 02:39 Gunnar Hellstr=C3=B6m wrote: >>>>> I find that the changes to version -23 prepared by Randall and provide= d in this archive mail are good: >>>>> https://www.ietf.org/mail-archive/web/slim/current/msg01289.html >>>>>=20 >>>>> That version allows answers to contain languages not contained in the o= ffer (that was already allowed and well specified in version -23), >>>>> and allows multiple languages per media and direction in the answer. >>>>>=20 >>>>> I think both of these conditions are good and impo= rtant for successful use of the draft.=20 >>>>> We need to imagine all kinds of feasible applications, e.g. the decisi= on on including interpreting resources taken by the offeror after receiving t= he answer. That calls for providing the full and true picture about the supp= orted languages in the answer. =20 >>>>>=20 >>>>> So, I repeat my comment from https://www.ietf.org/mail-archive/web/sli= m/current/msg01297.html >>>>> "I find the diff you sent to be good, and also version -23 solving all= other issues in a good way. So, I vote for applying y= our proposed changes on -23 and hope that that can be the final version." >>>>>=20 >>>>> Gunnar=20 >>>>>>=20 >>>>>>=20 >>>>>> --Randall=20 >>>>>>=20 >>>>>> _______________________________________________=20 >>>>>> SLIM mailing list=20 >>>>>> SLIM@ietf.org=20 >>>>>> https://www.ietf.org/mailman/listinfo/slim=20 >>>>>=20 >>>>>=20 >>>>> --=20 >>>>> ----------------------------------------- >>>>> Gunnar Hellstr=C3=B6m >>>>> Omnitor >>>>> gunnar.hellstrom@omnitor.se >>>>> +46 708 204 288 >>>>=20 >>>>=20 >>>>=20 >>>> --Randall >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> SLIM mailing list >>>> SLIM@ietf.org >>>> https://www.ietf.org/mailman/listinfo/slim >>>=20 >>> --=20 >>> ----------------------------------------- >>> Gunnar Hellstr=C3=B6m >>> Omnitor >>> gunnar.hellstrom@omnitor.se >>> +46 708 204 288 >>=20 --Apple-Mail-BA5C1FC7-C7DB-4281-A7A4-A5B6E32C9BED Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
The fact that Answers conta= ining =E2=80=9Cpointless confusion=E2=80=9D are allowed means that implement= ations need to be prepared to handle these edge cases. I see no benefit aris= ing from this.

Why not require that an Answer place= mutually supported language(s) before languages only supported by the Answe= rer? In what situations would it be necessary to do something else?

On Feb 18, 2018, at 10:40 AM, Randall Gellens <rg+ietf@randy.pensive.org> wrote:

We don't expect an answer to contain a non= -offered language except in unusual cases. What's in an answer is decided by= policies at the answerer. I don't think we need to get into an exercise of t= rying to describe what is permitted vs forbidden for such edge cases. I thin= k we can assume that the people who create the policies want to enable commu= nication and not sow pointless confusion. 

Sent from my iPhone

On Feb 18, 2018, at 11:27 PM, B= ernard Aboba <bernard.aboba@gm= ail.com> wrote:

Gunnar said: 

"That will= happen if you decide to answer with a language that was not in the offer. B= ut it is better than answering with no language indication and it indicates h= ow you might answer the call."

[BA] I unders= tand how an Answerer could respond only with language(s) not in the Offer.&n= bsp; But if the Answerer can support some of the offered languages, what are= the restrictions on non-offered languages? 
Can an Answerer p= ut a non-offered language first in the preference list and an offered langua= ge in a less preferred position?  Should it be able to include a non-of= fered language at all?  If you offer English and
Swedish and r= eceive an Answer with Swahili and Swedish, that could result in confusion at= best.

= On Sat, Feb 17, 2018 at 5:20 PM, Gunnar Hellstr=C3=B6m <= ;gunnar.hel= lstrom@omnitor.se> wrote:
=20 =20 =20
I agree with Randall. No more normative or descriptive language is needed. There is already a warning against providing language indications that will be hard to match. That will happen if you decide to answer with a language that was not in the offer. But it is better than answering with no language indication and it indicates how you might answer the call. 

There is however one small adjustment to do. The sentence about having the languages in preference order in the lists should be included also in the paragraph about the answer in 5.2.  Or it coul= d be pulled out from the paragraph about the offer and put in a common paragraph below both paragraphs about the offer and the answer. And the lists should be in plural in the sentence.
Here the sentence is attached last in the paragraph about the answer:
-----------------------------5.2 paragraph about the answer, with new sentence attached last-----------------------------------------= -
 In an answer, 'hlang-send' is a lis=
t of one or more languages the answerer might send if
   using the media for language (which in most cases contains one or more of=
 the
   languages in the offer's 'hlang-recv'), and 'hlang-recv' is a list of one=
 or more of the
   languages the answerer is prepared to receive if using the media for
   language (which in most cases contains one or more of the languages in th=
e offer's
   'hlang-send'). The lists of languages are in preference order (first is m=
ost
   preferred).
------------------------------------------------------------------= ------------------------------------------------------------------= ----------------------
/Gunnar






Den 2018-02-17 kl. 1= 0:52, skrev Randall Gellens:
=20

Hi Bernard,

Putting a language in an answer that was not in the offer is an unusual case (as the text says). I don=E2=80=99t= think we need to add more text (normative or descriptive) about it.

=E2=80=94Randall

On 16 Feb 2018, at 19:36, Bernard Aboba wrote:

=
Yes, the proposed changes seem good. One question: is there enough normative language about adding languages to an Answer that were not in the Offer? For example, can this only occur if the Answerer has no languages in common with the Offerer? Or can an Answerer add any languages(s) they would put into an Offer if roles were reversed?

On Fri, Feb 16, 2018 at 02:39 Gunnar Hellstr=C3=B6m <= ;gunnar.hel= lstrom@omnitor.se> wrote:
I find that the= changes to version -23 prepared by Randall and provided in this archive mail are good:
https://www.ietf.org/mail-archive/= web/slim/current/msg01289.html

That version allows answers to contain languages not contained in the offer (that was already allowed and well specified in version -23),
and allows multiple languages per media and direction in the answer.

I think both of these conditions are good and important for successful use of the draft.
We need to imagine all kinds of feasible applications, e.g. the decision on including interpreting resources taken by the offeror after receiving the answer. That calls for providing the full and true picture about the supported languages in the answer. 

So, I repeat my comment from https://ww= w.ietf.org/mail-archive/web/slim/current/msg01297.html
"I find the diff you sent to be good, and also version -23 solving all other issues in a good way. So, I vote for applying your proposed changes on -23 and hope that that can be the final version."

Gunnar


--Randall

_______________________________________________ <= br> SLIM mailing list
SL= IM@ietf.org
https://www.ietf.org/mailman/listinfo/slim 

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


--Randall



_______________________________________________
SLIM mailing list
SLIM@ietf.org
https://www.ietf.org/mailm=
an/listinfo/slim


--=20
-----------------------------------------
Gunnar Hellstr=C3=B6m
Omnitor
gunnar.hellstrom@omnitor.se=

+46 708 204 288

= --Apple-Mail-BA5C1FC7-C7DB-4281-A7A4-A5B6E32C9BED-- From nobody Sun Feb 18 12:20:19 2018 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 1C7D51242EA for ; Sun, 18 Feb 2018 12:20:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-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 DODoUKHfufaL for ; Sun, 18 Feb 2018 12:20:09 -0800 (PST) Received: from bin-vsp-out-03.atm.binero.net (vsp-unauthed02.binero.net [195.74.38.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0108A12422F for ; Sun, 18 Feb 2018 12:20:08 -0800 (PST) X-Halon-ID: 197911de-14e9-11e8-8760-0050569116f7 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [87.96.161.61]) by bin-vsp-out-03.atm.binero.net (Halon) with ESMTPSA id 197911de-14e9-11e8-8760-0050569116f7; Sun, 18 Feb 2018 21:20:02 +0100 (CET) To: Bernard Aboba , Randall Gellens Cc: slim@ietf.org References: <6754134E-63FD-4212-90D5-D07293EFE36B@randy.pensive.org> <09dcffcc-a65d-65d8-614d-fa12b790dd4f@omnitor.se> <5c33acfd-8853-4254-c6b1-fa05ea4901fd@omnitor.se> <608E5933-9EB0-489D-A845-39018CF68127@randy.pensive.org> <9B27941C-CAE7-4162-8E8B-3BFA60921578@gmail.com> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <5551ded6-5bc4-7bc9-54e4-559d17955802@omnitor.se> Date: Sun, 18 Feb 2018 21:20:02 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <9B27941C-CAE7-4162-8E8B-3BFA60921578@gmail.com> Content-Type: multipart/alternative; boundary="------------2D903DD4B3F54F01BDE7B606" Content-Language: en-US Archived-At: Subject: Re: [Slim] Negotiation issue in draft-ietf-slim-negotiating-human-language 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: Sun, 18 Feb 2018 20:20:12 -0000 This is a multi-part message in MIME format. --------------2D903DD4B3F54F01BDE7B606 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Den 2018-02-18 kl. 20:56, skrev Bernard Aboba: > The fact that Answers containing “pointless confusion” are allowed > means that implementations need to be prepared to handle these edge > cases. I see no benefit arising from this. > > Why not require that an Answer place mutually supported language(s) > before languages only supported by the Answerer? In what situations > would it be necessary to do something else? Example within one media:  You might get an offer for spoken English, you feel quite unsure about talking English, but want to accept that but also express that your strong preference is spoken French. This is expressed by listing French before English in the answer. The offering party can then understand that it is possible to start the conversation in English, but if problems appear, it might be better to invoke a French - English interpreter, or hand it over to a French-speaking agent. Example with two media: You might get an offer for spoken English in audio and a text stream, without any language indication. You do not hear so well, so you can barely manage a spoken conversation in English. Therefore you add written English in the text stream in the answer in the quite likely hope that the offering party can use English text. You would like to indicate strong preference for receiving English text before receiving English voice, but that is not possible with the current specification, so you need to hope that the offfering party can guess that from your insertion of reception of English text in the answer. I do not think these examples provide any pointless confusion, but rather more clarity about the conditions for a successful conversation. /Gunnar > > On Feb 18, 2018, at 10:40 AM, Randall Gellens > > wrote: > >> We don't expect an answer to contain a non-offered language except in >> unusual cases. What's in an answer is decided by policies at the >> answerer. I don't think we need to get into an exercise of trying to >> describe what is permitted vs forbidden for such edge cases. I think >> we can assume that the people who create the policies want to enable >> communication and not sow pointless confusion. >> >> Sent from my iPhone >> >> On Feb 18, 2018, at 11:27 PM, Bernard Aboba > > wrote: >> >>> Gunnar said: >>> >>> "That will happen if you decide to answer with a language that was >>> not in the offer. But it is better than answering with no language >>> indication and it indicates how you might answer the call." >>> >>> [BA] I understand how an Answerer could respond only with >>> language(s) not in the Offer.  But if the Answerer can support some >>> of the offered languages, what are the restrictions on non-offered >>> languages? >>> Can an Answerer put a non-offered language first in the preference >>> list and an offered language in a less preferred position?  Should >>> it be able to include a non-offered language at all?  If you offer >>> English and >>> Swedish and receive an Answer with Swahili and Swedish, that could >>> result in confusion at best. >>> >>> On Sat, Feb 17, 2018 at 5:20 PM, Gunnar Hellström >>> > >>> wrote: >>> >>> I agree with Randall. No more normative or descriptive language >>> is needed. There is already a warning against providing language >>> indications that will be hard to match. That will happen if you >>> decide to answer with a language that was not in the offer. But >>> it is better than answering with no language indication and it >>> indicates how you might answer the call. >>> >>> There is however one small adjustment to do. The sentence about >>> having the languages in preference order in the lists should be >>> included also in the paragraph about the answer in 5.2.  Or it >>> could be pulled out from the paragraph about the offer and put >>> in a common paragraph below both paragraphs about the offer and >>> the answer. And the lists should be in plural in the sentence. >>> Here the sentence is attached last in the paragraph about the >>> answer: >>> -----------------------------5.2 paragraph about the answer, >>> with new sentence attached >>> last------------------------------------------ >>> >>> In an answer, 'hlang-send' is a list of one or more languages the answerer might send if >>> using the media for language (which in most cases contains one or more of the >>> languages in the offer's 'hlang-recv'), and 'hlang-recv' is a list of one or more of the >>> languages the answerer is prepared to receive if using the media for >>> language (which in most cases contains one or more of the languages in the offer's >>> 'hlang-send'). The lists of languages are in preference order (first is most >>> preferred). >>> >>> ---------------------------------------------------------------------------------------------------------------------------------------------------------- >>> /Gunnar >>> >>> >>> >>> >>> >>> >>> Den 2018-02-17 kl. 10:52, skrev Randall Gellens: >>>> >>>> Hi Bernard, >>>> >>>> Putting a language in an answer that was not in the offer is an >>>> unusual case (as the text says). I don’t think we need to add >>>> more text (normative or descriptive) about it. >>>> >>>> —Randall >>>> >>>> On 16 Feb 2018, at 19:36, Bernard Aboba wrote: >>>> >>>> Yes, the proposed changes seem good. One question: is there >>>> enough normative language about adding languages to an >>>> Answer that were not in the Offer? For example, can this >>>> only occur if the Answerer has no languages in common with >>>> the Offerer? Or can an Answerer add any languages(s) they >>>> would put into an Offer if roles were reversed? >>>> >>>> On Fri, Feb 16, 2018 at 02:39 Gunnar Hellström >>>> >>> > wrote: >>>> >>>> I find that the changes to version -23 prepared by >>>> Randall and provided in this archive mail are good: >>>> https://www.ietf.org/mail-archive/web/slim/current/msg01289.html >>>> >>>> >>>> That version allows answers to contain languages not >>>> contained in the offer (that was already allowed and >>>> well specified in version -23), >>>> and allows multiple languages per media and direction >>>> in the answer. >>>> >>>> I think both of these conditions are good and important >>>> for successful use of the draft. >>>> We need to imagine all kinds of feasible applications, >>>> e.g. the decision on including interpreting resources >>>> taken by the offeror after receiving the answer. That >>>> calls for providing the full and true picture about the >>>> supported languages in the answer. >>>> >>>> So, I repeat my comment from >>>> https://www.ietf.org/mail-archive/web/slim/current/msg01297.html >>>> >>>> "I find the diff you sent to be good, and also version >>>> -23 solving all other issues in a good way. So, I vote >>>> for applying your proposed changes on -23 and hope that >>>> that can be the final version." >>>> >>>> Gunnar >>>>> >>>>> >>>>> --Randall >>>>> >>>>> _______________________________________________ >>>>> SLIM mailing list >>>>> SLIM@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/slim >>>>> >>>> >>>> -- >>>> ----------------------------------------- >>>> Gunnar Hellström >>>> Omnitor >>>> gunnar.hellstrom@omnitor.se >>>> >>>> +46 708 204 288 >>>> >>>> >>>> >>>> --Randall >>>> >>>> >>>> >>>> _______________________________________________ >>>> SLIM mailing list >>>> SLIM@ietf.org >>>> https://www.ietf.org/mailman/listinfo/slim >>>> >>> >>> -- >>> ----------------------------------------- >>> Gunnar Hellström >>> Omnitor >>> gunnar.hellstrom@omnitor.se >>> +46 708 204 288 >>> >>> > > > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 --------------2D903DD4B3F54F01BDE7B606 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



Den 2018-02-18 kl. 20:56, skrev Bernard Aboba:
The fact that Answers containing “pointless confusion” are allowed means that implementations need to be prepared to handle these edge cases. I see no benefit arising from this.

Why not require that an Answer place mutually supported language(s) before languages only supported by the Answerer? In what situations would it be necessary to do something else?
<GH>
Example within one media:  You might get an offer for spoken English, you feel quite unsure about talking English, but want to accept that but also express that your strong preference is spoken French. This is expressed by listing French before English in the answer. The offering party can then understand that it is possible to start the conversation in English, but if problems appear, it might be better to invoke a French - English interpreter, or hand it over to a French-speaking agent.

Example with two media: You might get an offer for spoken English in audio and a text stream, without any language indication. You do not hear so well, so you can barely manage a spoken conversation in English. Therefore you add written English in the text stream in the answer in the quite likely hope that the offering party can use English text. You would like to indicate strong preference for receiving English text before receiving English voice, but that is not possible with the current specification, so you need to hope that the offfering party can guess that from your insertion of reception of English text in the answer.

I do not think these examples provide any pointless confusion, but rather more clarity about the conditions for a successful conversation.

/Gunnar

On Feb 18, 2018, at 10:40 AM, Randall Gellens <rg+ietf@randy.pensive.org> wrote:

We don't expect an answer to contain a non-offered language except in unusual cases. What's in an answer is decided by policies at the answerer. I don't think we need to get into an exercise of trying to describe what is permitted vs forbidden for such edge cases. I think we can assume that the people who create the policies want to enable communication and not sow pointless confusion. 

Sent from my iPhone

On Feb 18, 2018, at 11:27 PM, Bernard Aboba <bernard.aboba@gmail.com> wrote:

Gunnar said: 

"That will happen if you decide to answer with a language that was not in the offer. But it is better than answering with no language indication and it indicates how you might answer the call."

[BA] I understand how an Answerer could respond only with language(s) not in the Offer.  But if the Answerer can support some of the offered languages, what are the restrictions on non-offered languages? 
Can an Answerer put a non-offered language first in the preference list and an offered language in a less preferred position?  Should it be able to include a non-offered language at all?  If you offer English and
Swedish and receive an Answer with Swahili and Swedish, that could result in confusion at best.

On Sat, Feb 17, 2018 at 5:20 PM, Gunnar Hellström <gunnar.hellstrom@omnitor.se> wrote:
I agree with Randall. No more normative or descriptive language is needed. There is already a warning against providing language indications that will be hard to match. That will happen if you decide to answer with a language that was not in the offer. But it is better than answering with no language indication and it indicates how you might answer the call. 

There is however one small adjustment to do. The sentence about having the languages in preference order in the lists should be included also in the paragraph about the answer in 5.2.  Or it could be pulled out from the paragraph about the offer and put in a common paragraph below both paragraphs about the offer and the answer. And the lists should be in plural in the sentence.
Here the sentence is attached last in the paragraph about the answer:
-----------------------------5.2 paragraph about the answer, with new sentence attached last------------------------------------------
 In an answer, 'hlang-send' is a list of one or more languages the answerer might send if
   using the media for language (which in most cases contains one or more of the
   languages in the offer's 'hlang-recv'), and 'hlang-recv' is a list of one or more of the
   languages the answerer is prepared to receive if using the media for
   language (which in most cases contains one or more of the languages in the offer's
   'hlang-send'). The lists of languages are in preference order (first is most
   preferred).
----------------------------------------------------------------------------------------------------------------------------------------------------------
/Gunnar






Den 2018-02-17 kl. 10:52, skrev Randall Gellens:

Hi Bernard,

Putting a language in an answer that was not in the offer is an unusual case (as the text says). I don’t think we need to add more text (normative or descriptive) about it.

—Randall

On 16 Feb 2018, at 19:36, Bernard Aboba wrote:

Yes, the proposed changes seem good. One question: is there enough normative language about adding languages to an Answer that were not in the Offer? For example, can this only occur if the Answerer has no languages in common with the Offerer? Or can an Answerer add any languages(s) they would put into an Offer if roles were reversed?

On Fri, Feb 16, 2018 at 02:39 Gunnar Hellström <gunnar.hellstrom@omnitor.se> wrote:
I find that the changes to version -23 prepared by Randall and provided in this archive mail are good:
https://www.ietf.org/mail-archive/web/slim/current/msg01289.html

That version allows answers to contain languages not contained in the offer (that was already allowed and well specified in version -23),
and allows multiple languages per media and direction in the answer.

I think both of these conditions are good and important for successful use of the draft.
We need to imagine all kinds of feasible applications, e.g. the decision on including interpreting resources taken by the offeror after receiving the answer. That calls for providing the full and true picture about the supported languages in the answer. 

So, I repeat my comment from https://www.ietf.org/mail-archive/web/slim/current/msg01297.html
"I find the diff you sent to be good, and also version -23 solving all other issues in a good way. So, I vote for applying your proposed changes on -23 and hope that that can be the final version."

Gunnar


--Randall

_______________________________________________
SLIM mailing list
SLIM@ietf.org
https://www.ietf.org/mailman/listinfo/slim 

-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288


--Randall



_______________________________________________
SLIM mailing list
SLIM@ietf.org
https://www.ietf.org/mailman/listinfo/slim


-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288



_______________________________________________
SLIM mailing list
SLIM@ietf.org
https://www.ietf.org/mailman/listinfo/slim


-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288
--------------2D903DD4B3F54F01BDE7B606-- From nobody Sun Feb 18 19:20:42 2018 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 EF18A126C22 for ; Sun, 18 Feb 2018 19:20:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 KNKG-1W3Qr81 for ; Sun, 18 Feb 2018 19:20:40 -0800 (PST) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 6748A1201FA for ; Sun, 18 Feb 2018 19:20:40 -0800 (PST) Received: from [172.20.59.46] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Sun, 18 Feb 2018 19:21:34 -0800 From: "Randall Gellens" To: "Bernard Aboba" Cc: "Gunnar =?utf-8?q?Hellstr=C3=B6m?=" , slim@ietf.org Date: Sun, 18 Feb 2018 19:20:36 -0800 X-Mailer: MailMate Trial (1.10r5443) Message-ID: <7D3A0148-DFAA-459B-B5AF-C85D59E6313B@randy.pensive.org> In-Reply-To: <9B27941C-CAE7-4162-8E8B-3BFA60921578@gmail.com> References: <6754134E-63FD-4212-90D5-D07293EFE36B@randy.pensive.org> <09dcffcc-a65d-65d8-614d-fa12b790dd4f@omnitor.se> <5c33acfd-8853-4254-c6b1-fa05ea4901fd@omnitor.se> <608E5933-9EB0-489D-A845-39018CF68127@randy.pensive.org> <9B27941C-CAE7-4162-8E8B-3BFA60921578@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Slim] Negotiation issue in draft-ietf-slim-negotiating-human-language 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: Mon, 19 Feb 2018 03:20:42 -0000 On 18 Feb 2018, at 11:56, Bernard Aboba wrote: > The fact that Answers containing =E2=80=9Cpointless confusion=E2=80=9D = are allowed = > means that implementations need to be prepared to handle these edge = > cases. I see no benefit arising from this. In that case, let=E2=80=99s move forward with the draft as-is, which does= only = permits one language in the answer. > Why not require that an Answer place mutually supported language(s) = > before languages only supported by the Answerer? In what situations = > would it be necessary to do something else? I don=E2=80=99t think it=E2=80=99s necessary, because we don=E2=80=99t ex= pect non-offered = languages to be in an answer except in unusual edge cases. =E2=80=94Randall > >> On Feb 18, 2018, at 10:40 AM, Randall Gellens = >> wrote: >> >> We don't expect an answer to contain a non-offered language except in = >> unusual cases. What's in an answer is decided by policies at the = >> answerer. I don't think we need to get into an exercise of trying to = >> describe what is permitted vs forbidden for such edge cases. I think = >> we can assume that the people who create the policies want to enable = >> communication and not sow pointless confusion. >> >> Sent from my iPhone >> >>> On Feb 18, 2018, at 11:27 PM, Bernard Aboba = >>> wrote: >>> >>> Gunnar said: >>> >>> "That will happen if you decide to answer with a language that was = >>> not in the offer. But it is better than answering with no language = >>> indication and it indicates how you might answer the call." >>> >>> [BA] I understand how an Answerer could respond only with = >>> language(s) not in the Offer. But if the Answerer can support some = >>> of the offered languages, what are the restrictions on non-offered = >>> languages? >>> Can an Answerer put a non-offered language first in the preference = >>> list and an offered language in a less preferred position? Should = >>> it be able to include a non-offered language at all? If you offer = >>> English and >>> Swedish and receive an Answer with Swahili and Swedish, that could = >>> result in confusion at best. >>> >>>> On Sat, Feb 17, 2018 at 5:20 PM, Gunnar Hellstr=C3=B6m = >>>> wrote: >>>> I agree with Randall. No more normative or descriptive language is = >>>> needed. There is already a warning against providing language = >>>> indications that will be hard to match. That will happen if you = >>>> decide to answer with a language that was not in the offer. But it = >>>> is better than answering with no language indication and it = >>>> indicates how you might answer the call. >>>> >>>> There is however one small adjustment to do. The sentence about = >>>> having the languages in preference order in the lists should be = >>>> included also in the paragraph about the answer in 5.2. Or it = >>>> could be pulled out from the paragraph about the offer and put in a = >>>> common paragraph below both paragraphs about the offer and the = >>>> answer. And the lists should be in plural in the sentence. >>>> Here the sentence is attached last in the paragraph about the = >>>> answer: >>>> -----------------------------5.2 paragraph about the answer, with = >>>> new sentence attached = >>>> last------------------------------------------ >>>> In an answer, 'hlang-send' is a list of one or more languages the = >>>> answerer might send if >>>> using the media for language (which in most cases contains one = >>>> or more of the >>>> languages in the offer's 'hlang-recv'), and 'hlang-recv' is a = >>>> list of one or more of the >>>> languages the answerer is prepared to receive if using the media = >>>> for >>>> language (which in most cases contains one or more of the = >>>> languages in the offer's >>>> 'hlang-send'). The lists of languages are in preference order = >>>> (first is most >>>> preferred). >>>> --------------------------------------------------------------------= -------------------------------------------------------------------------= ------------- >>>> /Gunnar >>>> >>>> >>>> >>>> >>>> >>>> >>>>> Den 2018-02-17 kl. 10:52, skrev Randall Gellens: >>>>> Hi Bernard, >>>>> >>>>> Putting a language in an answer that was not in the offer is an = >>>>> unusual case (as the text says). I don=E2=80=99t think we need to a= dd = >>>>> more text (normative or descriptive) about it. >>>>> >>>>> =E2=80=94Randall >>>>> >>>>> On 16 Feb 2018, at 19:36, Bernard Aboba wrote: >>>>> >>>>> Yes, the proposed changes seem good. One question: is there enough = >>>>> normative language about adding languages to an Answer that were = >>>>> not in the Offer? For example, can this only occur if the Answerer = >>>>> has no languages in common with the Offerer? Or can an Answerer = >>>>> add any languages(s) they would put into an Offer if roles were = >>>>> reversed? >>>>> >>>>>> On Fri, Feb 16, 2018 at 02:39 Gunnar Hellstr=C3=B6m = >>>>>> wrote: >>>>>> I find that the changes to version -23 prepared by Randall and = >>>>>> provided in this archive mail are good: >>>>>> https://www.ietf.org/mail-archive/web/slim/current/msg01289.html >>>>>> >>>>>> That version allows answers to contain languages not contained in = >>>>>> the offer (that was already allowed and well specified in version = >>>>>> -23), >>>>>> and allows multiple languages per media and direction in the = >>>>>> answer. >>>>>> >>>>>> I think both of these conditions are good and = >>>>>> important for successful use of the draft. >>>>>> We need to imagine all kinds of feasible applications, e.g. the = >>>>>> decision on including interpreting resources taken by the offeror = >>>>>> after receiving the answer. That calls for providing the full and = >>>>>> true picture about the supported languages in the answer. >>>>>> >>>>>> So, I repeat my comment from = >>>>>> https://www.ietf.org/mail-archive/web/slim/current/msg01297.html >>>>>> "I find the diff you sent to be good, and also version -23 = >>>>>> solving all other issues in a good way. So, = >>>>>> I vote for applying your proposed changes on -23 and hope that = >>>>>> that can be the final version." >>>>>> >>>>>> Gunnar >>>>>>> >>>>>>> >>>>>>> --Randall >>>>>>> >>>>>>> _______________________________________________ >>>>>>> SLIM mailing list >>>>>>> SLIM@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/slim >>>>>> >>>>>> >>>>>> -- = >>>>>> ----------------------------------------- >>>>>> Gunnar Hellstr=C3=B6m >>>>>> Omnitor >>>>>> gunnar.hellstrom@omnitor.se >>>>>> +46 708 204 288 >>>>> >>>>> >>>>> >>>>> --Randall >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> SLIM mailing list >>>>> SLIM@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/slim >>>> >>>> -- = >>>> ----------------------------------------- >>>> Gunnar Hellstr=C3=B6m >>>> Omnitor >>>> gunnar.hellstrom@omnitor.se >>>> +46 708 204 288 >>> --Randall From nobody Sun Feb 18 23:43:37 2018 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 886B01201FA for ; Sun, 18 Feb 2018 23:43:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 p5H3Irp84wfc for ; Sun, 18 Feb 2018 23:43:30 -0800 (PST) Received: from bin-vsp-out-03.atm.binero.net (bin-mail-out-06.binero.net [195.74.38.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13765126CBF for ; Sun, 18 Feb 2018 23:43:29 -0800 (PST) X-Halon-ID: 8fb60c0b-1548-11e8-8760-0050569116f7 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [87.96.161.61]) by bin-vsp-out-03.atm.binero.net (Halon) with ESMTPSA id 8fb60c0b-1548-11e8-8760-0050569116f7; Mon, 19 Feb 2018 08:43:23 +0100 (CET) To: Randall Gellens , Bernard Aboba Cc: slim@ietf.org References: <6754134E-63FD-4212-90D5-D07293EFE36B@randy.pensive.org> <09dcffcc-a65d-65d8-614d-fa12b790dd4f@omnitor.se> <5c33acfd-8853-4254-c6b1-fa05ea4901fd@omnitor.se> <608E5933-9EB0-489D-A845-39018CF68127@randy.pensive.org> <9B27941C-CAE7-4162-8E8B-3BFA60921578@gmail.com> <7D3A0148-DFAA-459B-B5AF-C85D59E6313B@randy.pensive.org> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <811b57b1-2444-f206-b860-2034ce1b8ea4@omnitor.se> Date: Mon, 19 Feb 2018 08:43:23 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <7D3A0148-DFAA-459B-B5AF-C85D59E6313B@randy.pensive.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Slim] Negotiation issue in draft-ietf-slim-negotiating-human-language 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: Mon, 19 Feb 2018 07:43:32 -0000 Den 2018-02-19 kl. 04:20, skrev Randall Gellens: > On 18 Feb 2018, at 11:56, Bernard Aboba wrote: > >> The fact that Answers containing “pointless confusion” are allowed >> means that implementations need to be prepared to handle these edge >> cases. I see no benefit arising from this. > > In that case, let’s move forward with the draft as-is, which does only > permits one language in the answer. As explained in another reply, I do not see it adding pointless confusion. It adds clarity about the language situation and prepares for a smooth start of the dialogue. > >> Why not require that an Answer place mutually supported language(s) >> before languages only supported by the Answerer? In what situations >> would it be necessary to do something else? > > I don’t think it’s necessary, because we don’t expect non-offered > languages to be in an answer except in unusual edge cases. It is the opposite situation that is of interest to express, when the answerer has some limited capability in one of the offered languages and a much higher preference for a non-offered language in the same media. So the answer contains both, with the non-offered first. That explains the language situation well to the offeror, and makes it possible for both parties to accommodate to the situation by whatever means and resources they have; either go with only the common language or do something to make it easier for the answering party. Indicating a non-offered language in an answer with lower preference than a common language is of less interest. If you already agree on a language with good preference, why tell about your non-matched lower preference capabilities? But we do not need more rules about how indications for offered and non-offered languages are mixed or not. /Gunnar > > —Randall > >> >>> On Feb 18, 2018, at 10:40 AM, Randall Gellens >>> wrote: >>> >>> We don't expect an answer to contain a non-offered language except >>> in unusual cases. What's in an answer is decided by policies at the >>> answerer. I don't think we need to get into an exercise of trying to >>> describe what is permitted vs forbidden for such edge cases. I think >>> we can assume that the people who create the policies want to enable >>> communication and not sow pointless confusion. >>> >>> Sent from my iPhone >>> >>>> On Feb 18, 2018, at 11:27 PM, Bernard Aboba >>>> wrote: >>>> >>>> Gunnar said: >>>> >>>> "That will happen if you decide to answer with a language that was >>>> not in the offer. But it is better than answering with no language >>>> indication and it indicates how you might answer the call." >>>> >>>> [BA] I understand how an Answerer could respond only with >>>> language(s) not in the Offer.  But if the Answerer can support some >>>> of the offered languages, what are the restrictions on non-offered >>>> languages? >>>> Can an Answerer put a non-offered language first in the preference >>>> list and an offered language in a less preferred position?  Should >>>> it be able to include a non-offered language at all?  If you offer >>>> English and >>>> Swedish and receive an Answer with Swahili and Swedish, that could >>>> result in confusion at best. >>>> >>>>> On Sat, Feb 17, 2018 at 5:20 PM, Gunnar Hellström >>>>> wrote: >>>>> I agree with Randall. No more normative or descriptive language is >>>>> needed. There is already a warning against providing language >>>>> indications that will be hard to match. That will happen if you >>>>> decide to answer with a language that was not in the offer. But it >>>>> is better than answering with no language indication and it >>>>> indicates how you might answer the call. >>>>> >>>>> There is however one small adjustment to do. The sentence about >>>>> having the languages in preference order in the lists should be >>>>> included also in the paragraph about the answer in 5.2.  Or it >>>>> could be pulled out from the paragraph about the offer and put in >>>>> a common paragraph below both paragraphs about the offer and the >>>>> answer. And the lists should be in plural in the sentence. >>>>> Here the sentence is attached last in the paragraph about the answer: >>>>> -----------------------------5.2 paragraph about the answer, with >>>>> new sentence attached last------------------------------------------ >>>>>  In an answer, 'hlang-send' is a list of one or more languages the >>>>> answerer might send if >>>>>    using the media for language (which in most cases contains one >>>>> or more of the >>>>>    languages in the offer's 'hlang-recv'), and 'hlang-recv' is a >>>>> list of one or more of the >>>>>    languages the answerer is prepared to receive if using the >>>>> media for >>>>>    language (which in most cases contains one or more of the >>>>> languages in the offer's >>>>>    'hlang-send'). The lists of languages are in preference order >>>>> (first is most >>>>>    preferred). >>>>> ---------------------------------------------------------------------------------------------------------------------------------------------------------- >>>>> >>>>> /Gunnar >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> Den 2018-02-17 kl. 10:52, skrev Randall Gellens: >>>>>> Hi Bernard, >>>>>> >>>>>> Putting a language in an answer that was not in the offer is an >>>>>> unusual case (as the text says). I don’t think we need to add >>>>>> more text (normative or descriptive) about it. >>>>>> >>>>>> —Randall >>>>>> >>>>>> On 16 Feb 2018, at 19:36, Bernard Aboba wrote: >>>>>> >>>>>> Yes, the proposed changes seem good. One question: is there >>>>>> enough normative language about adding languages to an Answer >>>>>> that were not in the Offer? For example, can this only occur if >>>>>> the Answerer has no languages in common with the Offerer? Or can >>>>>> an Answerer add any languages(s) they would put into an Offer if >>>>>> roles were reversed? >>>>>> >>>>>>> On Fri, Feb 16, 2018 at 02:39 Gunnar Hellström >>>>>>> wrote: >>>>>>> I find that the changes to version -23 prepared by Randall and >>>>>>> provided in this archive mail are good: >>>>>>> https://www.ietf.org/mail-archive/web/slim/current/msg01289.html >>>>>>> >>>>>>> That version allows answers to contain languages not contained >>>>>>> in the offer (that was already allowed and well specified in >>>>>>> version -23), >>>>>>> and allows multiple languages per media and direction in the >>>>>>> answer. >>>>>>> >>>>>>> I think both of these conditions are good >>>>>>> and                     important for successful use of the draft. >>>>>>> We need to imagine all kinds of feasible applications, e.g. the >>>>>>> decision on including interpreting resources taken by the >>>>>>> offeror after receiving the answer. That calls for providing the >>>>>>> full and true picture about the supported languages in the answer. >>>>>>> >>>>>>> So, I repeat my comment from >>>>>>> https://www.ietf.org/mail-archive/web/slim/current/msg01297.html >>>>>>> "I find the diff you sent to be good, and also version -23 >>>>>>> solving all other issues in a good                       way. >>>>>>> So, I vote for applying your proposed changes on -23 and hope >>>>>>> that that can be the final version." >>>>>>> >>>>>>> Gunnar >>>>>>>> >>>>>>>> >>>>>>>> --Randall >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> SLIM mailing list >>>>>>>> SLIM@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/slim >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> ----------------------------------------- >>>>>>> Gunnar Hellström >>>>>>> Omnitor >>>>>>> gunnar.hellstrom@omnitor.se >>>>>>> +46 708 204 288 >>>>>> >>>>>> >>>>>> >>>>>> --Randall >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> SLIM mailing list >>>>>> SLIM@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/slim >>>>> >>>>> -- >>>>> ----------------------------------------- >>>>> Gunnar Hellström >>>>> Omnitor >>>>> gunnar.hellstrom@omnitor.se >>>>> +46 708 204 288 >>>> > > > > > --Randall > > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 From nobody Mon Feb 19 06:48:39 2018 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 A6EAB12762F for ; Mon, 19 Feb 2018 06:48:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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] 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 ByGmyTt_EQak for ; Mon, 19 Feb 2018 06:48:35 -0800 (PST) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::236]) (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 DEDC51276AF for ; Mon, 19 Feb 2018 06:48:34 -0800 (PST) Received: by mail-ua0-x236.google.com with SMTP id w6so1577957uae.10 for ; Mon, 19 Feb 2018 06:48:34 -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=c+gEH+ug3jmDOKbaT+kbYeSIds3h6EYqJEsi1i55M14=; b=puGWMOR3z6kXD01I+nAuXUJNftjQOaPJC+NL5gQaED7mpBpOVdadwFaEEogi+Zm6vf 8zHo60ZFn3JyiOj7UV72JTWEJG400tI/CNTJ1lPv1nfMXP1COEwBGu+LEL/Y2fUtGnIo T37DuWPJuau22TsZLP7jXOYuZVDW42qeoz0Z7QGQON5oVjCw+4W+CZHA4HArF5YmvTg1 JV0psN48mam3tS9APMEif7+rpOurVV/rtzB6J+ecmIj8geh026vOyN1jk1Gi1m/8GiV0 jMt+m7qZHad+msjafisFxvE3jRJCDNN3p4m+aG7xRc3l8UsgAeis+kA891xHwEWEHH/d LPyg== 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=c+gEH+ug3jmDOKbaT+kbYeSIds3h6EYqJEsi1i55M14=; b=fs4bkdb6DGHwPli+9aIwfmg711ulApTt9Zxh1AkSRb3OLx3Pv16/ulSMdIn4hv+B+p kmfEFqos3ZvrbVz94W62O4j5uabf7AqsSKKIuiVM+xB+MEduYzZfBnZ3dZ3JDqEhi1bv Nw/C2Gori8WTUQcVVtn1Dq/1Yr6U3a9xnp5R0un4kx1I7EgYzDyx6SjPM409J8B73UNG QDxKKa+cbGPtJLjxdj5/NRpKBBeGUDIHF3NCJudw5cN/A9oTbJU5oqM8t3PDnhYU9+wq CBDg3vY9quCLzhhHjKoAGey34mXze0wwwMoSkFVBYy89uioPZdFQFNKxqJefpmkO6aKF mxpw== X-Gm-Message-State: APf1xPA/Pq+Xpl+iVJxkJJaqmfGLJe/YbP+kImmmw++j2gI3kfUsCtkO mh8NGvisF3qsnDrZulmVLnMjELAz4zstjflLIRE= X-Google-Smtp-Source: AH8x2263bqen80ZVgEffuU5wCc37L3q0vUzVJHohv76rL9ufmzEBSDTfzdgFBB/W4xcyENuiJ6zR7Y5KYyT5cppEIJc= X-Received: by 10.176.79.7 with SMTP id n7mr11428020uah.64.1519051713513; Mon, 19 Feb 2018 06:48:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.10.24 with HTTP; Mon, 19 Feb 2018 06:48:13 -0800 (PST) In-Reply-To: <7D3A0148-DFAA-459B-B5AF-C85D59E6313B@randy.pensive.org> References: <6754134E-63FD-4212-90D5-D07293EFE36B@randy.pensive.org> <09dcffcc-a65d-65d8-614d-fa12b790dd4f@omnitor.se> <5c33acfd-8853-4254-c6b1-fa05ea4901fd@omnitor.se> <608E5933-9EB0-489D-A845-39018CF68127@randy.pensive.org> <9B27941C-CAE7-4162-8E8B-3BFA60921578@gmail.com> <7D3A0148-DFAA-459B-B5AF-C85D59E6313B@randy.pensive.org> From: Bernard Aboba Date: Mon, 19 Feb 2018 09:48:13 -0500 Message-ID: To: Randall Gellens Cc: =?UTF-8?Q?Gunnar_Hellstr=C3=B6m?= , slim@ietf.org Content-Type: multipart/alternative; boundary="f403043c3924c78f03056591c94e" Archived-At: Subject: Re: [Slim] Negotiation issue in draft-ietf-slim-negotiating-human-language 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: Mon, 19 Feb 2018 14:48:38 -0000 --f403043c3924c78f03056591c94e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Randall said: "In that case, let=E2=80=99s move forward with the draft as-is, which does = only permits one language in the answer." [BA] I'm beginning to think that is a better idea, since the edge cases are dramatically reduced (e.g. the one language would be one of the Offered languages, unless none are supported). " I don=E2=80=99t think it=E2=80=99s necessary, because we don=E2=80=99t ex= pect non-offered languages to be in an answer except in unusual edge cases." [BA] If there were only one language in the Answer that is more likely to be true, which is a good argument for that approach. On Sun, Feb 18, 2018 at 10:20 PM, Randall Gellens wrote: > On 18 Feb 2018, at 11:56, Bernard Aboba wrote: > > The fact that Answers containing =E2=80=9Cpointless confusion=E2=80=9D ar= e allowed means >> that implementations need to be prepared to handle these edge cases. I s= ee >> no benefit arising from this. >> > > In that case, let=E2=80=99s move forward with the draft as-is, which does= only > permits one language in the answer. > > Why not require that an Answer place mutually supported language(s) befor= e >> languages only supported by the Answerer? In what situations would it be >> necessary to do something else? >> > > I don=E2=80=99t think it=E2=80=99s necessary, because we don=E2=80=99t ex= pect non-offered > languages to be in an answer except in unusual edge cases. > > =E2=80=94Randall > > > >> On Feb 18, 2018, at 10:40 AM, Randall Gellens >>> wrote: >>> >>> We don't expect an answer to contain a non-offered language except in >>> unusual cases. What's in an answer is decided by policies at the answer= er. >>> I don't think we need to get into an exercise of trying to describe wha= t is >>> permitted vs forbidden for such edge cases. I think we can assume that = the >>> people who create the policies want to enable communication and not sow >>> pointless confusion. >>> >>> Sent from my iPhone >>> >>> On Feb 18, 2018, at 11:27 PM, Bernard Aboba >>>> wrote: >>>> >>>> Gunnar said: >>>> >>>> "That will happen if you decide to answer with a language that was not >>>> in the offer. But it is better than answering with no language indicat= ion >>>> and it indicates how you might answer the call." >>>> >>>> [BA] I understand how an Answerer could respond only with language(s) >>>> not in the Offer. But if the Answerer can support some of the offered >>>> languages, what are the restrictions on non-offered languages? >>>> Can an Answerer put a non-offered language first in the preference lis= t >>>> and an offered language in a less preferred position? Should it be ab= le to >>>> include a non-offered language at all? If you offer English and >>>> Swedish and receive an Answer with Swahili and Swedish, that could >>>> result in confusion at best. >>>> >>>> On Sat, Feb 17, 2018 at 5:20 PM, Gunnar Hellstr=C3=B6m < >>>>> gunnar.hellstrom@omnitor.se> wrote: >>>>> I agree with Randall. No more normative or descriptive language is >>>>> needed. There is already a warning against providing language indicat= ions >>>>> that will be hard to match. That will happen if you decide to answer = with a >>>>> language that was not in the offer. But it is better than answering w= ith no >>>>> language indication and it indicates how you might answer the call. >>>>> >>>>> There is however one small adjustment to do. The sentence about havin= g >>>>> the languages in preference order in the lists should be included als= o in >>>>> the paragraph about the answer in 5.2. Or it could be pulled out fro= m the >>>>> paragraph about the offer and put in a common paragraph below both >>>>> paragraphs about the offer and the answer. And the lists should be in >>>>> plural in the sentence. >>>>> Here the sentence is attached last in the paragraph about the answer: >>>>> -----------------------------5.2 paragraph about the answer, with new >>>>> sentence attached last------------------------------------------ >>>>> In an answer, 'hlang-send' is a list of one or more languages the >>>>> answerer might send if >>>>> using the media for language (which in most cases contains one or >>>>> more of the >>>>> languages in the offer's 'hlang-recv'), and 'hlang-recv' is a list >>>>> of one or more of the >>>>> languages the answerer is prepared to receive if using the media f= or >>>>> language (which in most cases contains one or more of the language= s >>>>> in the offer's >>>>> 'hlang-send'). The lists of languages are in preference order >>>>> (first is most >>>>> preferred). >>>>> ------------------------------------------------------------ >>>>> ------------------------------------------------------------ >>>>> ---------------------------------- >>>>> /Gunnar >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Den 2018-02-17 kl. 10:52, skrev Randall Gellens: >>>>>> Hi Bernard, >>>>>> >>>>>> Putting a language in an answer that was not in the offer is an >>>>>> unusual case (as the text says). I don=E2=80=99t think we need to ad= d more text >>>>>> (normative or descriptive) about it. >>>>>> >>>>>> =E2=80=94Randall >>>>>> >>>>>> On 16 Feb 2018, at 19:36, Bernard Aboba wrote: >>>>>> >>>>>> Yes, the proposed changes seem good. One question: is there enough >>>>>> normative language about adding languages to an Answer that were not= in the >>>>>> Offer? For example, can this only occur if the Answerer has no langu= ages in >>>>>> common with the Offerer? Or can an Answerer add any languages(s) the= y would >>>>>> put into an Offer if roles were reversed? >>>>>> >>>>>> On Fri, Feb 16, 2018 at 02:39 Gunnar Hellstr=C3=B6m < >>>>>>> gunnar.hellstrom@omnitor.se> wrote: >>>>>>> I find that the changes to version -23 prepared by Randall and >>>>>>> provided in this archive mail are good: >>>>>>> https://www.ietf.org/mail-archive/web/slim/current/msg01289.html >>>>>>> >>>>>>> That version allows answers to contain languages not contained in >>>>>>> the offer (that was already allowed and well specified in version -= 23), >>>>>>> and allows multiple languages per media and direction in the answer= . >>>>>>> >>>>>>> I think both of these conditions are good and >>>>>>> important for successful use of the draft. >>>>>>> We need to imagine all kinds of feasible applications, e.g. the >>>>>>> decision on including interpreting resources taken by the offeror a= fter >>>>>>> receiving the answer. That calls for providing the full and true pi= cture >>>>>>> about the supported languages in the answer. >>>>>>> >>>>>>> So, I repeat my comment from https://www.ietf.org/mail-arch >>>>>>> ive/web/slim/current/msg01297.html >>>>>>> "I find the diff you sent to be good, and also version -23 solving >>>>>>> all other issues in a good way. So, I vote fo= r >>>>>>> applying your proposed changes on -23 and hope that that can be the= final >>>>>>> version." >>>>>>> >>>>>>> Gunnar >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> --Randall >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> SLIM mailing list >>>>>>>> SLIM@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/slim >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> ----------------------------------------- >>>>>>> Gunnar Hellstr=C3=B6m >>>>>>> Omnitor >>>>>>> gunnar.hellstrom@omnitor.se >>>>>>> +46 708 204 288 >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> --Randall >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> SLIM mailing list >>>>>> SLIM@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/slim >>>>>> >>>>> >>>>> -- >>>>> ----------------------------------------- >>>>> Gunnar Hellstr=C3=B6m >>>>> Omnitor >>>>> gunnar.hellstrom@omnitor.se >>>>> +46 708 204 288 >>>>> >>>> >>>> > > > > --Randall > --f403043c3924c78f03056591c94e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Randall said:=C2=A0

"In that case, let=E2=80=99s move forward w= ith the draft as-is, which does only permits one language in the answer.&qu= ot;

[BA] I'm beginning to think that is a better idea, since= the edge cases are dramatically reduced (e.g. the one language would be on= e of the Offered languages, unless none are supported).=C2=A0
" I don=E2=80=99t think it=E2=80=99s necessary, be= cause we don=E2=80=99t expect non-offered languages to be in an answer exce= pt in unusual edge cases."

[BA] If there were only o= ne language in the Answer that is more likely to be true, which is a good a= rgument for that approach.=C2=A0


On Sun, Feb 18, 2018= at 10:20 PM, Randall Gellens <rg+ietf@randy.pensive.org> wrote:
On 18 Feb 2= 018, at 11:56, Bernard Aboba wrote:

The fact that Answers containing =E2=80=9Cpointless confusion=E2=80=9D are = allowed means that implementations need to be prepared to handle these edge= cases. I see no benefit arising from this.

 In that case, let=E2=80=99s move forward with the draft as-is, which does o= nly permits one language in the answer.

Why not require that an Answer place mutually supported language(s) before = languages only supported by the Answerer? In what situations would it be ne= cessary to do something else?

 I don=E2=80=99t think it=E2=80=99s necessary, because we don=E2=80=99t expe= ct non-offered languages to be in an answer except in unusual edge cases.
=E2=80=94Randall



On Feb 18, 2018, at 10:40 AM, Randall Gellens <rg+ietf@randy.pensive.org> w= rote:

We don't expect an answer to contain a non-offered language except in u= nusual cases. What's in an answer is decided by policies at the answere= r. I don't think we need to get into an exercise of trying to describe = what is permitted vs forbidden for such edge cases. I think we can assume t= hat the people who create the policies want to enable communication and not= sow pointless confusion.

Sent from my iPhone

On Feb 18, 2018, at 11:27 PM, Bernard Aboba <bernard.aboba@gmail.com> wrote:
Gunnar said:

"That will happen if you decide to answer with a language that was not= in the offer. But it is better than answering with no language indication = and it indicates how you might answer the call."

[BA] I understand how an Answerer could respond only with language(s) not i= n the Offer.=C2=A0 But if the Answerer can support some of the offered lang= uages, what are the restrictions on non-offered languages?
Can an Answerer put a non-offered language first in the preference list and= an offered language in a less preferred position?=C2=A0 Should it be able = to include a non-offered language at all?=C2=A0 If you offer English and Swedish and receive an Answer with Swahili and Swedish, that could result i= n confusion at best.

On Sat, Feb 17, 2018 at 5:20 PM, Gunnar Hellstr=C3=B6m <gunnar.hellstrom@omnitor.s= e> wrote:
I agree with Randall. No more normative or descriptive language is needed. = There is already a warning against providing language indications that will= be hard to match. That will happen if you decide to answer with a language= that was not in the offer. But it is better than answering with no languag= e indication and it indicates how you might answer the call.

There is however one small adjustment to do. The sentence about having the = languages in preference order in the lists should be included also in the p= aragraph about the answer in 5.2.=C2=A0 Or it could be pulled out from the = paragraph about the offer and put in a common paragraph below both paragrap= hs about the offer and the answer. And the lists should be in plural in the= sentence.
Here the sentence is attached last in the paragraph about the answer:
-----------------------------5.2 paragraph about the answer, with new = sentence attached last------------------------------------------
=C2=A0In an answer, 'hlang-send' is a list of one or more languages= the answerer might send if
=C2=A0 =C2=A0using the media for language (which in most cases contains one= or more of the
=C2=A0 =C2=A0languages in the offer's 'hlang-recv'), and 'h= lang-recv' is a list of one or more of the
=C2=A0 =C2=A0languages the answerer is prepared to receive if using the med= ia for
=C2=A0 =C2=A0language (which in most cases contains one or more of the lang= uages in the offer's
=C2=A0 =C2=A0'hlang-send'). The lists of languages are in preferenc= e order (first is most
=C2=A0 =C2=A0preferred).
-----------------------------------------------------------------= -----------------------------------------------------------------= ------------------------
/Gunnar






Den 2018-02-17 kl. 10:52, skrev Randall Gellens:
Hi Bernard,

Putting a language in an answer that was not in the offer is an unusual cas= e (as the text says). I don=E2=80=99t think we need to add more text (norma= tive or descriptive) about it.

=E2=80=94Randall

On 16 Feb 2018, at 19:36, Bernard Aboba wrote:

Yes, the proposed changes seem good. One question: is there enough normativ= e language about adding languages to an Answer that were not in the Offer? = For example, can this only occur if the Answerer has no languages in common= with the Offerer? Or can an Answerer add any languages(s) they would put i= nto an Offer if roles were reversed?

On Fri, Feb 16, 2018 at 02:39 Gunnar Hellstr=C3=B6m <gunnar.hellstrom@omnitor.se> wrote:
I find that the changes to version -23 prepared by Randall and provided in = this archive mail are good:
https://www.ietf.org/mail-archi= ve/web/slim/current/msg01289.html

That version allows answers to contain languages not contained in the offer= (that was already allowed and well specified in version -23),
and allows multiple languages per media and direction in the answer.

I think both of these conditions are good and=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0important for successful us= e of the draft.
We need to imagine all kinds of feasible applications, e.g. the decision on= including interpreting resources taken by the offeror after receiving the = answer. That calls for providing the full and true picture about the suppor= ted languages in the answer.

So, I repeat my comment from https:/= /www.ietf.org/mail-archive/web/slim/current/msg01297.html
"I find the diff you sent to be good, and also version -23 solving all= other issues in a good=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0way. So, I vote for applying your proposed c= hanges on -23 and hope that that can be the final version."

Gunnar


--Randall

_______________________________________________
SLIM mailing list
SLIM@ietf.org
https://www.ietf.org/mailman/listinfo/slim


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



--Randall



_______________________________________________
SLIM mailing list
SLIM@ietf.org
https://www.ietf.org/mailman/listinfo/slim

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





--Randall

--f403043c3924c78f03056591c94e-- From nobody Mon Feb 19 07:24:41 2018 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 2B703124BAC for ; Mon, 19 Feb 2018 07:24:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 gj0l4mWb9QNT for ; Mon, 19 Feb 2018 07:24:34 -0800 (PST) Received: from bin-vsp-out-01.atm.binero.net (bin-mail-out-05.binero.net [195.74.38.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DD6E127873 for ; Mon, 19 Feb 2018 07:24:24 -0800 (PST) X-Halon-ID: f120bdb1-1588-11e8-93cf-005056917a89 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [87.96.161.61]) by bin-vsp-out-01.atm.binero.net (Halon) with ESMTPSA id f120bdb1-1588-11e8-93cf-005056917a89; Mon, 19 Feb 2018 16:24:14 +0100 (CET) To: Bernard Aboba , Randall Gellens Cc: slim@ietf.org References: <6754134E-63FD-4212-90D5-D07293EFE36B@randy.pensive.org> <09dcffcc-a65d-65d8-614d-fa12b790dd4f@omnitor.se> <5c33acfd-8853-4254-c6b1-fa05ea4901fd@omnitor.se> <608E5933-9EB0-489D-A845-39018CF68127@randy.pensive.org> <9B27941C-CAE7-4162-8E8B-3BFA60921578@gmail.com> <7D3A0148-DFAA-459B-B5AF-C85D59E6313B@randy.pensive.org> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <20f21dd8-33df-b306-2b58-d43de8fceb69@omnitor.se> Date: Mon, 19 Feb 2018 16:24:18 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------F77690489881A85526350245" Content-Language: en-US Archived-At: Subject: Re: [Slim] Negotiation issue in draft-ietf-slim-negotiating-human-language 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: Mon, 19 Feb 2018 15:24:38 -0000 This is a multi-part message in MIME format. --------------F77690489881A85526350245 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Den 2018-02-19 kl. 15:48, skrev Bernard Aboba: > Randall said: > > "In that case, let’s move forward with the draft as-is, which does > only permits one language in the answer." > > [BA] I'm beginning to think that is a better idea, since the edge > cases are dramatically reduced (e.g. the one language would be one of > the Offered languages, unless none are supported). We would create even more unbalance than we already have between what is allowed within one media compared to what is allowed in multiple media. The wording is now per media and direction. If we introduce a restriction to one language per media and direction, we can still have one offered language in the answer for one media and direction and one non-offered language in the answer for another media and the same direction. That would mean that one of these can be selected for use. The fact that the answering party bothered to include the non-offered language in another media can likely be understood as an indication of preference for that language. The inclusion of the common language in one media can be understood as a safety measure to have some language that is surely possible to start with. I think that is good and we should not limit the opportunity to provide such answers in multiple media. Why should we then introduce limitations for the similar indication within one media? The edge cases do not hurt, and it is up to the applications to decide how much flexibility and clarity about the language situation they will provide to the user. > > " I don’t think it’s necessary, because we don’t expect non-offered > languages to be in an answer except in unusual edge cases." > > [BA] If there were only one language in the Answer that is more likely > to be true, which is a good argument for that approach. > > > On Sun, Feb 18, 2018 at 10:20 PM, Randall Gellens > > wrote: > > On 18 Feb 2018, at 11:56, Bernard Aboba wrote: > > The fact that Answers containing “pointless confusion” are > allowed means that implementations need to be prepared to > handle these edge cases. I see no benefit arising from this. > > > In that case, let’s move forward with the draft as-is, which does > only permits one language in the answer. > > Why not require that an Answer place mutually supported > language(s) before languages only supported by the Answerer? > In what situations would it be necessary to do something else? > > > I don’t think it’s necessary, because we don’t expect non-offered > languages to be in an answer except in unusual edge cases. > > —Randall > > > > On Feb 18, 2018, at 10:40 AM, Randall Gellens > > wrote: > > We don't expect an answer to contain a non-offered > language except in unusual cases. What's in an answer is > decided by policies at the answerer. I don't think we need > to get into an exercise of trying to describe what is > permitted vs forbidden for such edge cases. I think we can > assume that the people who create the policies want to > enable communication and not sow pointless confusion. > > Sent from my iPhone > > On Feb 18, 2018, at 11:27 PM, Bernard Aboba > > wrote: > > Gunnar said: > > "That will happen if you decide to answer with a > language that was not in the offer. But it is better > than answering with no language indication and it > indicates how you might answer the call." > > [BA] I understand how an Answerer could respond only > with language(s) not in the Offer.  But if the > Answerer can support some of the offered languages, > what are the restrictions on non-offered languages? > Can an Answerer put a non-offered language first in > the preference list and an offered language in a less > preferred position?  Should it be able to include a > non-offered language at all?  If you offer English and > Swedish and receive an Answer with Swahili and > Swedish, that could result in confusion at best. > > On Sat, Feb 17, 2018 at 5:20 PM, Gunnar Hellström > > wrote: > I agree with Randall. No more normative or > descriptive language is needed. There is already a > warning against providing language indications > that will be hard to match. That will happen if > you decide to answer with a language that was not > in the offer. But it is better than answering with > no language indication and it indicates how you > might answer the call. > > There is however one small adjustment to do. The > sentence about having the languages in preference > order in the lists should be included also in the > paragraph about the answer in 5.2. Or it could be > pulled out from the paragraph about the offer and > put in a common paragraph below both paragraphs > about the offer and the answer. And the lists > should be in plural in the sentence. > Here the sentence is attached last in the > paragraph about the answer: > -----------------------------5.2 paragraph about > the answer, with new sentence attached > last------------------------------------------ >  In an answer, 'hlang-send' is a list of one or > more languages the answerer might send if >    using the media for language (which in most > cases contains one or more of the >    languages in the offer's 'hlang-recv'), and > 'hlang-recv' is a list of one or more of the >    languages the answerer is prepared to receive > if using the media for >    language (which in most cases contains one or > more of the languages in the offer's >    'hlang-send'). The lists of languages are in > preference order (first is most >    preferred). > ---------------------------------------------------------------------------------------------------------------------------------------------------------- > /Gunnar > > > > > > > Den 2018-02-17 kl. 10:52, skrev Randall Gellens: > Hi Bernard, > > Putting a language in an answer that was not > in the offer is an unusual case (as the text > says). I don’t think we need to add more text > (normative or descriptive) about it. > > —Randall > > On 16 Feb 2018, at 19:36, Bernard Aboba wrote: > > Yes, the proposed changes seem good. One > question: is there enough normative language > about adding languages to an Answer that were > not in the Offer? For example, can this only > occur if the Answerer has no languages in > common with the Offerer? Or can an Answerer > add any languages(s) they would put into an > Offer if roles were reversed? > > On Fri, Feb 16, 2018 at 02:39 Gunnar > Hellström > wrote: > I find that the changes to version -23 > prepared by Randall and provided in this > archive mail are good: > https://www.ietf.org/mail-archive/web/slim/current/msg01289.html > > > That version allows answers to contain > languages not contained in the offer (that > was already allowed and well specified in > version -23), > and allows multiple languages per media > and direction in the answer. > > I think both of these conditions are good > and                     important for > successful use of the draft. > We need to imagine all kinds of feasible > applications, e.g. the decision on > including interpreting resources taken by > the offeror after receiving the answer. > That calls for providing the full and true > picture about the supported languages in > the answer. > > So, I repeat my comment from > https://www.ietf.org/mail-archive/web/slim/current/msg01297.html > > "I find the diff you sent to be good, and > also version -23 solving all other issues > in a good                       way. So, I > vote for applying your proposed changes on > -23 and hope that that can be the final > version." > > Gunnar > > > > --Randall > > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim > > > > > -- > ----------------------------------------- > Gunnar Hellström > Omnitor > gunnar.hellstrom@omnitor.se > > +46 708 204 288 > > > > > --Randall > > > > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim > > > > -- > ----------------------------------------- > Gunnar Hellström > Omnitor > gunnar.hellstrom@omnitor.se > > +46 708 204 288 > > > > > > > --Randall > > -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 --------------F77690489881A85526350245 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Den 2018-02-19 kl. 15:48, skrev Bernard Aboba:
Randall said: 

"In that case, let’s move forward with the draft as-is, which does only permits one language in the answer."

[BA] I'm beginning to think that is a better idea, since the edge cases are dramatically reduced (e.g. the one language would be one of the Offered languages, unless none are supported).
<GH>We would create even more unbalance than we already have between what is allowed within one media compared to what is allowed in multiple media. The wording is now per media and direction. If we introduce a restriction to one language per media and direction, we can still have one offered language in the answer for one media and direction and one non-offered language in the answer for another media and the same direction. That would mean that one of these can be selected for use.

The fact that the answering party bothered to include the non-offered language in another media can likely be understood as an indication of preference for that language. The inclusion of the common language in one media can be understood as a safety measure to have some language that is surely possible to start with.
I think that is good and we should not limit the opportunity to provide such answers in multiple media. Why should we then introduce limitations for the similar indication within one media?

The edge cases do not hurt, and it is up to the applications to decide how much flexibility and clarity about the language situation they will provide to the user. 

" I don’t think it’s necessary, because we don’t expect non-offered languages to be in an answer except in unusual edge cases."

[BA] If there were only one language in the Answer that is more likely to be true, which is a good argument for that approach. 


On Sun, Feb 18, 2018 at 10:20 PM, Randall Gellens <rg+ietf@randy.pensive.org> wrote:
On 18 Feb 2018, at 11:56, Bernard Aboba wrote:

The fact that Answers containing “pointless confusion” are allowed means that implementations need to be prepared to handle these edge cases. I see no benefit arising from this.

 In that case, let’s move forward with the draft as-is, which does only permits one language in the answer.

Why not require that an Answer place mutually supported language(s) before languages only supported by the Answerer? In what situations would it be necessary to do something else?

 I don’t think it’s necessary, because we don’t expect non-offered languages to be in an answer except in unusual edge cases.

—Randall



On Feb 18, 2018, at 10:40 AM, Randall Gellens <rg+ietf@randy.pensive.org> wrote:

We don't expect an answer to contain a non-offered language except in unusual cases. What's in an answer is decided by policies at the answerer. I don't think we need to get into an exercise of trying to describe what is permitted vs forbidden for such edge cases. I think we can assume that the people who create the policies want to enable communication and not sow pointless confusion.

Sent from my iPhone

On Feb 18, 2018, at 11:27 PM, Bernard Aboba <bernard.aboba@gmail.com> wrote:

Gunnar said:

"That will happen if you decide to answer with a language that was not in the offer. But it is better than answering with no language indication and it indicates how you might answer the call."

[BA] I understand how an Answerer could respond only with language(s) not in the Offer.  But if the Answerer can support some of the offered languages, what are the restrictions on non-offered languages?
Can an Answerer put a non-offered language first in the preference list and an offered language in a less preferred position?  Should it be able to include a non-offered language at all?  If you offer English and
Swedish and receive an Answer with Swahili and Swedish, that could result in confusion at best.

On Sat, Feb 17, 2018 at 5:20 PM, Gunnar Hellström <gunnar.hellstrom@omnitor.se> wrote:
I agree with Randall. No more normative or descriptive language is needed. There is already a warning against providing language indications that will be hard to match. That will happen if you decide to answer with a language that was not in the offer. But it is better than answering with no language indication and it indicates how you might answer the call.

There is however one small adjustment to do. The sentence about having the languages in preference order in the lists should be included also in the paragraph about the answer in 5.2.  Or it could be pulled out from the paragraph about the offer and put in a common paragraph below both paragraphs about the offer and the answer. And the lists should be in plural in the sentence.
Here the sentence is attached last in the paragraph about the answer:
-----------------------------5.2 paragraph about the answer, with new sentence attached last------------------------------------------
 In an answer, 'hlang-send' is a list of one or more languages the answerer might send if
   using the media for language (which in most cases contains one or more of the
   languages in the offer's 'hlang-recv'), and 'hlang-recv' is a list of one or more of the
   languages the answerer is prepared to receive if using the media for
   language (which in most cases contains one or more of the languages in the offer's
   'hlang-send'). The lists of languages are in preference order (first is most
   preferred).
----------------------------------------------------------------------------------------------------------------------------------------------------------
/Gunnar






Den 2018-02-17 kl. 10:52, skrev Randall Gellens:
Hi Bernard,

Putting a language in an answer that was not in the offer is an unusual case (as the text says). I don’t think we need to add more text (normative or descriptive) about it.

—Randall

On 16 Feb 2018, at 19:36, Bernard Aboba wrote:

Yes, the proposed changes seem good. One question: is there enough normative language about adding languages to an Answer that were not in the Offer? For example, can this only occur if the Answerer has no languages in common with the Offerer? Or can an Answerer add any languages(s) they would put into an Offer if roles were reversed?

On Fri, Feb 16, 2018 at 02:39 Gunnar Hellström <gunnar.hellstrom@omnitor.se> wrote:
I find that the changes to version -23 prepared by Randall and provided in this archive mail are good:
https://www.ietf.org/mail-archive/web/slim/current/msg01289.html

That version allows answers to contain languages not contained in the offer (that was already allowed and well specified in version -23),
and allows multiple languages per media and direction in the answer.

I think both of these conditions are good and                     important for successful use of the draft.
We need to imagine all kinds of feasible applications, e.g. the decision on including interpreting resources taken by the offeror after receiving the answer. That calls for providing the full and true picture about the supported languages in the answer.

So, I repeat my comment from https://www.ietf.org/mail-archive/web/slim/current/msg01297.html
"I find the diff you sent to be good, and also version -23 solving all other issues in a good                       way. So, I vote for applying your proposed changes on -23 and hope that that can be the final version."

Gunnar


--Randall

_______________________________________________
SLIM mailing list
SLIM@ietf.org
https://www.ietf.org/mailman/listinfo/slim


--
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288



--Randall



_______________________________________________
SLIM mailing list
SLIM@ietf.org
https://www.ietf.org/mailman/listinfo/slim

--
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288





--Randall


-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288
--------------F77690489881A85526350245-- From nobody Tue Feb 20 07:16:42 2018 Return-Path: X-Original-To: slim@ietf.org Delivered-To: slim@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A2DD91242F7; Tue, 20 Feb 2018 07:16:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: slim@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.72.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151913979563.4728.11606306728017394571@ietfa.amsl.com> Date: Tue, 20 Feb 2018 07:16:35 -0800 Archived-At: Subject: [Slim] I-D Action: draft-ietf-slim-negotiating-human-language-24.txt X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2018 15:16:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Selection of Language for Internet Media WG of the IETF. Title : Negotiating Human Language in Real-Time Communications Author : Randall Gellens Filename : draft-ietf-slim-negotiating-human-language-24.txt Pages : 17 Date : 2018-02-20 Abstract: Users have various human (natural) language needs, abilities, and preferences regarding spoken, written, and signed languages. This document adds new SDP media-level attributes so that when establishing interactive communication sessions ("calls"), it is possible to negotiate (communicate and match) the caller's language and media needs with the capabilities of the called party. This is especially important with emergency calls, where a call can be handled by a call taker capable of communicating with the user, or a translator or relay operator can be bridged into the call during setup, but this applies to non-emergency calls as well (as an example, when calling a company call center). This document describes the need and a solution using new Session Description Protocol (SDP) media attributes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-slim-negotiating-human-language/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-slim-negotiating-human-language-24 https://datatracker.ietf.org/doc/html/draft-ietf-slim-negotiating-human-language-24 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-slim-negotiating-human-language-24 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Feb 20 10:10:35 2018 Return-Path: X-Original-To: slim@ietf.org Delivered-To: slim@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EC62D12D943; Tue, 20 Feb 2018 10:10:23 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.72.2 Auto-Submitted: auto-generated Precedence: bulk Cc: slim@ietf.org, The IESG , draft-ietf-slim-negotiating-human-language@ietf.org, slim-chairs@ietf.org, alexey.melnikov@isode.com, rfc-editor@rfc-editor.org, bernard.aboba@gmail.com MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <151915022392.3979.9697242318707955341.idtracker@ietfa.amsl.com> Date: Tue, 20 Feb 2018 10:10:23 -0800 Archived-At: Subject: [Slim] Protocol Action: 'Negotiating Human Language in Real-Time Communications' to Proposed Standard (draft-ietf-slim-negotiating-human-language-24.txt) X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2018 18:10:24 -0000 The IESG has approved the following document: - 'Negotiating Human Language in Real-Time Communications' (draft-ietf-slim-negotiating-human-language-24.txt) as Proposed Standard This document is the product of the Selection of Language for Internet Media Working Group. The IESG contact persons are Adam Roach, Alexey Melnikov and Ben Campbell. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-slim-negotiating-human-language/ Technical Summary: In establishing a multi-media communications session, it can be important to ensure that the caller's language and media needs match the capabilities of the called party. This is important in non-emergency uses (such as when calling a company call center) or in emergencies where a call can be handled by a call taker capable of communicating with the user, or a translator or relay operator can be bridged into the call during setup. This document describes the problem of negotiating human (natural) language needs, abilities and preferences in spoken, written and signed languages. It also provides a solution using new stream attributes within the Session Description Protocol (SDP). Working Group Summary: This draft has undergone 13 revisions since its initial IETF last call (which occurred on draft -06). These revisions were required to address issues raised by the IETF community, such as: 1. The meaning of the "*" in language negotiation. The SDP directorate review in the initial IETF last call expressed concern over the handling of the asterisk, which had the properties of a session attribute while being included within individual m-lines. WG consensus was to remove the asterisk, whose role had been advisory. 2. Routing of calls. The SDP directorate review in the initial IETF last call expressed concern about whether the document intended the use of SDP for routing of SIP traffic. Language was added to indicate clearly that call routing was out of scope. 3. Combining of hlang-send/hlang-recv. In IETF last call, a reviewer suggested that the document allow combining the hlang-send and recv indications so as to allow more efficient representation in cases where language preference is symmetrical. This suggestion was not accepted by the WG since it was not clear that the efficiency was worth the additional complexity. In addition to issues brought up in IETF last call, there was substantial WG discussion on the following points: 4. Undefined language/modality combinations. Language tags do not always distinguish spoken from written language, so some combinations of languages and media are not well defined. The text in Section 5.4 resulted from WG discussion of several scenarios: a. Captioning. While the document supports negotiation of sign language in a video stream, it does not define how to indicate that captioning (e.g. placement of text within the video stream) is desired. WG Consensus did not support use of suppressed script tags for this purpose. b. SignWriting (communicating sign language in written form). Currently only a single language tag has been defined for SignWriting so that written communication of sign language in a text stream (or in captioning) is also not defined. c. Lipreading (spoken language within video). There was not WG consensus for explicitly indicating the desire for spoken language in a video stream (e.g. by use of the -Zxxx script subtag), since the ability to negotiate "lip sync" is already provided in RFC 5888. As a result of these discussions, Section 5.4 leaves a number of potential combinations of language and media undefined. Assuming that implementation experience shows a need to define these scenarios, they can be addressed in future work. 5. Preferences between media. As an example, an individual might be able to understand written English communicated using Realtime Text, but might prefer spoken English audio. The current draft enables all modes of communication to be negotiated, but does not indicate a preference between them. WG consensus was that it was acceptable and possibly more reliable for mutually supported media to be negotiated and brought up, then let the conversants decide which media to use, rather than taking on the additional complexity of negotiating media preference beforehand. During discussion, it was pointed out that quality issues could influence media preferences during a call. For example, on a call where audio, video and text are all available, sending video may interfere with audio quality so that video sending needs to be disabled. Alternatively, audio quality could be poor so that the conversants need to resort to text. So media quality issues can negate the "best laid plans" of media preference negotiation. Document Quality: There are no current implementations of draft-ietf-slim-negotiating-language. However, the North American Emergency Number Association (NENA) has referenced it in NENA 08-01 (i3 Stage 3 version 2) in describing attributes of emergency calls presented to an ESInet and within 3GPP some CRs introduced in SA1 have referenced the functionality. Therefore implementation is expected. Personnel: Bernard Aboba is the Document Shepard. The responsible area director is Alexey Melnikov. From nobody Tue Feb 20 13:29:13 2018 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 0D501120724 for ; Tue, 20 Feb 2018 13:29:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 zxrshPBbknU7 for ; Tue, 20 Feb 2018 13:29:07 -0800 (PST) Received: from bin-vsp-out-02.atm.binero.net (vsp-unauthed02.binero.net [195.74.38.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1D8412DA73 for ; Tue, 20 Feb 2018 13:29:04 -0800 (PST) X-Halon-ID: 0ba8d4f2-1685-11e8-9bc4-005056917f90 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [87.96.161.61]) by bin-vsp-out-02.atm.binero.net (Halon) with ESMTPSA id 0ba8d4f2-1685-11e8-9bc4-005056917f90; Tue, 20 Feb 2018 22:28:52 +0100 (CET) To: Randall Gellens Cc: slim@ietf.org, draft-ietf-slim-negotiating-human-language@ietf.org, slim-chairs@ietf.org, The IESG , alexey.melnikov@isode.com, bernard.aboba@gmail.com, rfc-editor@rfc-editor.org References: <151915022392.3979.9697242318707955341.idtracker@ietfa.amsl.com> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <299e3b20-211f-9610-246b-8f294edf661b@omnitor.se> Date: Tue, 20 Feb 2018 22:28:55 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <151915022392.3979.9697242318707955341.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Slim] Protocol Action: 'Negotiating Human Language in Real-Time Communications' to Proposed Standard (draft-ietf-slim-negotiating-human-language-24.txt) 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: Tue, 20 Feb 2018 21:29:09 -0000 Good to see, and congratulations Randall! Can we switch topics now to the functionality extensions, specified in: https://datatracker.ietf.org/doc/draft-hellstrom-slim-modality-grouping/ Regards Gunnar Den 2018-02-20 kl. 19:10, skrev The IESG: > The IESG has approved the following document: > - 'Negotiating Human Language in Real-Time Communications' > (draft-ietf-slim-negotiating-human-language-24.txt) as Proposed Standard > > This document is the product of the Selection of Language for Internet Media > Working Group. > > The IESG contact persons are Adam Roach, Alexey Melnikov and Ben Campbell. > > A URL of this Internet Draft is: > https://datatracker.ietf.org/doc/draft-ietf-slim-negotiating-human-language/ > > > > > Technical Summary: > > In establishing a multi-media communications session, it can be > important to ensure that the caller's language and media needs > match the capabilities of the called party. This is important > in non-emergency uses (such as when calling a company call > center) or in emergencies where a call can be handled by a > call taker capable of communicating with the user, or a > translator or relay operator can be bridged into the call > during setup. > > This document describes the problem of negotiating human > (natural) language needs, abilities and preferences > in spoken, written and signed languages. It also provides > a solution using new stream attributes within the Session > Description Protocol (SDP). > > Working Group Summary: > > > This draft has undergone 13 revisions since its initial IETF last call (which occurred on draft -06). These > revisions were required to address issues raised by the IETF community, such as: > > 1. The meaning of the "*" in language negotiation. The SDP directorate review in the initial IETF last call expressed concern > over the handling of the asterisk, which had the properties of a session attribute while being included within individual m-lines. > WG consensus was to remove the asterisk, whose role had been advisory. > > 2. Routing of calls. The SDP directorate review in the initial IETF last call expressed concern about whether the document > intended the use of SDP for routing of SIP traffic. Language was added to indicate clearly that call routing was > out of scope. > > 3. Combining of hlang-send/hlang-recv. In IETF last call, a reviewer suggested that the document allow combining the > hlang-send and recv indications so as to allow more efficient representation in cases where language preference is > symmetrical. This suggestion was not accepted by the WG since it was not clear that the efficiency was worth the > additional complexity. > > In addition to issues brought up in IETF last call, there was substantial WG discussion on the following points: > > 4. Undefined language/modality combinations. Language tags do not always distinguish spoken from written > language, so some combinations of languages and media are not well defined. The text in Section 5.4 > resulted from WG discussion of several scenarios: > > a. Captioning. While the document supports negotiation of sign language in a video stream, it does not > define how to indicate that captioning (e.g. placement of text within the video stream) is desired. > WG Consensus did not support use of suppressed script tags for this purpose. > > b. SignWriting (communicating sign language in written form). Currently only a single language tag has been defined > for SignWriting so that written communication of sign language in a text stream (or in captioning) is also not > defined. > > c. Lipreading (spoken language within video). There was not WG consensus for explicitly indicating > the desire for spoken language in a video stream (e.g. by use of the -Zxxx script subtag), since the > ability to negotiate "lip sync" is already provided in RFC 5888. > > As a result of these discussions, Section 5.4 leaves a number of potential combinations of language and > media undefined. Assuming that implementation experience shows a need to define these scenarios, they > can be addressed in future work. > > 5. Preferences between media. As an example, an individual might be able to understand written English communicated using > Realtime Text, but might prefer spoken English audio. The current draft enables all modes of communication to be > negotiated, but does not indicate a preference between them. WG consensus was that it was acceptable and > possibly more reliable for mutually supported media to be negotiated and brought up, then let the conversants > decide which media to use, rather than taking on the additional complexity of negotiating media preference beforehand. > > During discussion, it was pointed out that quality issues could influence media preferences during a call. > For example, on a call where audio, video and text are all available, sending video may interfere with > audio quality so that video sending needs to be disabled. Alternatively, audio quality could be poor so that > the conversants need to resort to text. So media quality issues can negate the "best laid plans" of > media preference negotiation. > > Document Quality: > > There are no current implementations of draft-ietf-slim-negotiating-language. However, the North American Emergency Number Association > (NENA) has referenced it in NENA 08-01 (i3 Stage 3 version 2) in describing attributes of emergency calls presented to an ESInet and > within 3GPP some CRs introduced in SA1 have referenced the functionality. Therefore implementation is expected. > > Personnel: > > Bernard Aboba is the Document Shepard. The responsible area director is Alexey Melnikov. > > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim -- ----------------------------------------- Gunnar Hellstrm Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 From nobody Sat Feb 24 22:49:57 2018 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 6A9671267BB for ; Sat, 24 Feb 2018 22:49:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.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 hVp8-cPQz8cQ for ; Sat, 24 Feb 2018 22:49:54 -0800 (PST) Received: from JPN01-OS2-obe.outbound.protection.outlook.com (mail-os2jpn01on0091.outbound.protection.outlook.com [104.47.92.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 162B1124E15 for ; Sat, 24 Feb 2018 22:49:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector1-it-aoyama-ac-jp; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Ok0mRKaQ1xUisPa9Sj6waP+AP/0VXuJCFnBayGI1UaY=; b=jolhBa51ewzWh9jQYClGmXjdmAgXcQ8GqU+edaY1/k8rioYa0PHey4ft7FgsTLbd0arkkNKwP1RvTItMVkPscDvK8Q93cddhkyEYUixiTcct4pZ25JcMkY1F5BKi/iX2OWPOUzj3fiSln/xJ4klKuv2YCd5kR0kh/QFsdpYPylo= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=duerst@it.aoyama.ac.jp; Received: from [192.168.1.2] (125.205.107.186) by OSAPR01MB1538.jpnprd01.prod.outlook.com (2603:1096:603:2e::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.527.15; Sun, 25 Feb 2018 06:49:51 +0000 To: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= , Randall Gellens , Bernard Aboba Cc: slim@ietf.org References: <6754134E-63FD-4212-90D5-D07293EFE36B@randy.pensive.org> <09dcffcc-a65d-65d8-614d-fa12b790dd4f@omnitor.se> <5c33acfd-8853-4254-c6b1-fa05ea4901fd@omnitor.se> <608E5933-9EB0-489D-A845-39018CF68127@randy.pensive.org> <9B27941C-CAE7-4162-8E8B-3BFA60921578@gmail.com> <7D3A0148-DFAA-459B-B5AF-C85D59E6313B@randy.pensive.org> <811b57b1-2444-f206-b860-2034ce1b8ea4@omnitor.se> From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <0aada25c-4b72-8857-cd6a-8b73c9f1aac5@it.aoyama.ac.jp> Date: Sun, 25 Feb 2018 15:49:50 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <811b57b1-2444-f206-b860-2034ce1b8ea4@omnitor.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [125.205.107.186] X-ClientProxiedBy: OSAPR01CA0028.jpnprd01.prod.outlook.com (2603:1096:603:14::16) To OSAPR01MB1538.jpnprd01.prod.outlook.com (2603:1096:603:2e::17) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 30f93bd4-2834-471f-4bed-08d57c1bf864 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603307)(7153060)(7193020); SRVR:OSAPR01MB1538; X-Microsoft-Exchange-Diagnostics: 1; OSAPR01MB1538; 3:lAciwu1kNt2S/T9DrNMBYExP32AR7M9Ne9FpPUVBxNh7/zJ57PZKNl3Xj8R/ZVVcxS4UoKwd+rYmnXyu6cFClKC2vO9zrV1oFHAc9n3OHwSYFCWwHdHyn6OUwf7HElZksaKBf6a+a9r/5SbVXt85T5DCo8F4P9bqNE2AwgCSyYlGQ8GqYpfdDy5ilyI5WjCh6yRLEgfpHOne20YouYBtIllxswEAoJtxK2TWfQ7fCV/qitywhM0w/GVF0t/vvZlK; 25:52oD54jnh6Vj0h86xwdErbD2k3S3vbnOr29AsshHeAsqzyyV2Ghxphg5GCsWJFBOXBxMO22RM4qDyeH4UW4uCnLAc/yCvBWKQqnULhw69FGJWUEBtzcXwDy4tipr3zunHsgwtxmOeIwycqdKa2K5TpbYjREExpy9f1cHHq2DiRRKkyoL3RW3QEoI0uIPeBZEwq2uw1IBiiLuXj/X71aXHgBfB7tZqGspS8JqL9NqgC/Z8J67pXLBl5XcXsfjA+JPV9WCvElr0johrBmlarn2FG8v61+BRwE5aNKBnesaLq5Q9yXQ1gceJUNHG3ZAI63hctorduB5vRI4PpwWmuCCEA==; 31:bh5YBcgZOGDbAFVTYVxQmA19gCioZQoBvnYtVHx0kG5af2VA+/RYQoDrOYTKlLu/KwGgyQyE2mPZfKsh5A8RsTjilm4LTP2FAhSxndxtjOY4tnF5s8yaurn5zQ5QE+9oxqPOwdflZxQPCJFwllPwKO+tT9RU2wZNAegsbiod+5uFQaXnuOcTuJdVwSDA4hhQPRPeZ7QcfqOdtzLWaUcXoty06csP98/xfTmRPi+Snhg= X-MS-TrafficTypeDiagnostic: OSAPR01MB1538: X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(3231220)(944501161)(52105095)(10201501046)(93006095)(93001095)(3002001)(6041288)(20161123562045)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123558120)(6072148)(201708071742011); SRVR:OSAPR01MB1538; BCL:0; PCL:0; RULEID:; SRVR:OSAPR01MB1538; X-Microsoft-Exchange-Diagnostics: 1; OSAPR01MB1538; 4:oq2cer+TCJ8S+/PVEC8FMhekDFI+wIpjgnESYJ504yvAuVr3NK8Y6mdDPVyffSWlIoObkrWf4O1c4hK5epJiR82AnGB9EiOu0V+K/DrvYu/Kx4R+OT1/1uvfoYonlSoz1dBnEm4LOArsFGsqx/HPDOlyFKIQtCpnDgus9chymuf/vuZ/LObt9ixX8zwko4g/qd7g85QeMJW53pCAtPk2bc9Lt+ffiDsiOmcnssaEak9LEIQN7+vYlj7+rZh52AKFT2knCSFTKTeZmfCEPy3M1A== X-Forefront-PRVS: 05947791E4 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(366004)(376002)(39380400002)(346002)(396003)(39830400003)(189003)(199004)(53754006)(50466002)(16576012)(8936002)(7736002)(53546011)(26005)(52146003)(386003)(68736007)(186003)(16526019)(93886005)(65806001)(5660300001)(47776003)(66066001)(65956001)(86362001)(6246003)(305945005)(53936002)(31696002)(8676002)(39060400002)(4326008)(81166006)(81156014)(77096007)(76176011)(6486002)(97736004)(478600001)(2870700001)(3846002)(25786009)(106356001)(2906002)(6116002)(65826007)(23676004)(2486003)(2950100002)(31686004)(229853002)(36916002)(67846002)(42882006)(117156002)(52116002)(110136005)(58126008)(786003)(105586002)(316002)(64126003)(74482002); DIR:OUT; SFP:1102; SCL:1; SRVR:OSAPR01MB1538; H:[192.168.1.2]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: it.aoyama.ac.jp does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtPU0FQUjAxTUIxNTM4OzIzOk0vU0NyOW5SMTVOcWNYU2RqRVFYdkpSODQx?= =?utf-8?B?bmFaN3BlRjJ1RUszYnh3OHNkR0VJMm5lQS91NlVBUDFFdzZGWU1GMkJ6Zjdj?= =?utf-8?B?TVpMUHBMdVY4cUFNNlRoTkN5emNzVGVaZ3dhTmNDb2ZOaExjeURmMnowY2p1?= =?utf-8?B?cjk2K2JLTFYveExmLzhhUTBBclpQNEh0Z2ZCTWw1RU42QU0wR3RJT3VrLy9R?= =?utf-8?B?Q0VIenc5SjNzK2wxNngxV1Q1QlFQVzgrRXZFeTdWZ2JpU1VwbSs5MVFuZkxL?= =?utf-8?B?czkxMmRpbDJNZW9rM21oL1U3ZjgxcE9ZLzlrSjVwc3ZqdmhQY2VxcUl4RXZr?= =?utf-8?B?Q2xvdDYrRGs1WFYvL1QrRExCUVRzY2hQNGJ2MUdjUnJrZE5UYzNPQnpOeE9U?= =?utf-8?B?MWhUSTZDUXdycUlnNllGbXBBbzFZQmtkTUI2RWprY1VzUnlkQjM5ekRvQ0tk?= =?utf-8?B?VnZGZGo1d2c4T1VySWNrREg1U2J2STZtVG5IaXcvU2xCYmd4WituWHovb05L?= =?utf-8?B?T2VMbncwNlkzVUZmOVFNUVFxblZKTnBMbU0xblJQVnppSUFwT2ZZQnk3RDl2?= =?utf-8?B?VWUvVFBhVXNtby9CelJCZE9pTVFqMXNBT3lnZHVZb0pjVmpQc092KzZKV1lQ?= =?utf-8?B?VWZiL2NTSHNDK2gwVnpnWDV5NTRjbUhwSmxVNitwYWFQOFFJempuR0ZNT2JT?= =?utf-8?B?dXl4VzNSdEQwVWh0RzJLcFdKN2lHQjBxdVNMOW5PTnVNckVLR2tmTm9kcGVH?= =?utf-8?B?R1FrY3M3NEtvK0g4b1NvcG1kVnFmK1hlQ24rS2hFeGg1Yy9XR0hIMEVnRzFk?= =?utf-8?B?L0piWWEwTzQwNDAvek9VaXJSV00vU0VIUmZnUG1oWkdVcmpGeUVBcG1QblF1?= =?utf-8?B?V1lMYndTTis5aC9tUU4rYVdRNFd2akhONE1zMlFncTBSTldxTGQza0JsUFpU?= =?utf-8?B?a3ltb25GZ0JhYW94bCtyYkViQ0kyNnFqUEhIbkVhTWN1dDRmMXl5enFJMXlR?= =?utf-8?B?NDFuN1U1a0dTTjI5NUdEU0h4YzBUcCsyUWdmeHV2RzVsN2ZITERYY2dXUkM0?= =?utf-8?B?RXRHSmo5ZWFOd01FMnhKZEpLWmxBTkNzZnZFc2FtdUpHOHkyWnhlem4vWExB?= =?utf-8?B?NjVPWTE3Rk9MTEpMR2x1TkREaXRrMHp1VEtSbFE2QTNNQmFzUHVWckMvc2NP?= =?utf-8?B?UVNDZmwvajdQNlI1Z2xvNXdvS1ltN3JaZmI5RTZjcjJMNFdCd2p6WVdUcGZx?= =?utf-8?B?S0MxVXRtemxFaFVhUnd4Y2M0R2tvWi9hWm5RajA3MXh5V1JVYXQxUUVyR1NS?= =?utf-8?B?K3dtSDdZOVkvaUxaN3FPY2RCa3pWWEZhQTQvQlY4WVdQbUpCMVNCRjhBZVVD?= =?utf-8?B?eU1MV05uNDY2REpDZFAySkVyNU52ZDc5RG5LY1pMRGM5ZFErbUh2U3BjaU5s?= =?utf-8?B?Nzhxc2FRRE9sb2t1c2VvM3FVTjBTNEhJQkRlMHVBZkxJOUxJR1VobmpGNkx1?= =?utf-8?B?ZmtlSHY0bXowRlRvWVNGRE5SWEt2eVJtdDlEY3pCNXJGVk5tdm9QZWZ6QjNB?= =?utf-8?B?MnBUNDRCYWRBMzh4aW5BY1FHUzRsMW5QOXdvNjgzZFVoSzMySzlnOHMyT0NH?= =?utf-8?B?c2VhVldNMW5OaVRTM2RKSFFUR0Yxb0phL2lGK0hidjMyc2V4bkl4bHdjMmdV?= =?utf-8?B?R2hHOG9aRW9jWTF0YjdMTk5pWTVudExnQS9lZmdpcEVIMEhlc3NNc2ptaGEw?= =?utf-8?B?QjFjK2pMdVZnbU5wSkhTNExUMERYZWcvenNsWGRJZ2xDU3VWQ3pZZ2NxZE5H?= =?utf-8?B?TWE5Mi9odWhlanluOWNxQm9EOHBzT3diN3V3TVljSFpXS1Y2TU41ZlA2MGdF?= =?utf-8?B?ZDNsNjN3ck9Zd0N1QUltOVcvVlBnSkRINnlGd1I3bTlhRkQrcUhBcnk3dE1V?= =?utf-8?B?azlRUFZPbXN5RFpYV3pFQkFtMWYwRHB1bCtlc0xFYzl3ajVvZ0pEWWtkcDY4?= =?utf-8?B?ajZsRlRINlRybEZaMWY3cDU3NUhnaXpOMXVxdz09?= X-Microsoft-Exchange-Diagnostics: 1; OSAPR01MB1538; 6:mGQFQPtBtZQnWJnNbBBic0FYN7h2iC0q+lIlzEtoarsH6xi6opcTzHzZVFyCf2/tq3duo0JDcxzMu4oVL5htvm35rGOV08ZSJqRuEcsxWxj5MV6s3W9lgDUPv61566UhF/P2y+YFriUQOK3RTPRCVHWUnkhfRR30v97/VMEzdEoCEehk/bYBleYRTOiryIP3FZ608YKvJCbwIlNIgql2z2oNzqyqUnbsDJ9SmwCj8F0ZvTG9+ebbA6k9puAGGgEJ86rzckeaYeQWUr3m4R9f0KcIqlJAxv217s6MQ35Z4enI7JLexGbAyaHU5iMjheniTDQtOZk1Z2qhUAD1GZoHJbSzxvWh7Q4DdtQXiDq43dI=; 5:vowhsJaGQ6FjAUPCPLpD55H89hOfLVtM9xYzSC/1yYc3gLe56KIxDIhTLJB5wf9MFPNzgAVjpAxi8oiBlt0eG7qA51H92hMQgVEn4QMV4zeVgllwmmrefQHtZsvv4NtAiYK9C1BOFrNaJErMCbwiQPYToEWGM6R/QXo9dM+UKfA=; 24:Ifup/YzNWPiZADA8tNrFfMm1lguK8ZygRJ0V4iQGEstxZ/7QH30EutSEG0TfEAAvqKGX4JplQ22jxLKSI7qq1PLgWZucbj6Ct9VLajkzqK0=; 7:ACZWXXCAzQkPK2rGNAvB8qHA3EA+KfxDtmH/E9LFJVe2NRkIdjmoB6NBiM0nJDkD40+x5qun30RDmBul51qJxc2hsjd186ZAk7fk7K94RZtcMnT6PR1VbktURJDLNuOpk6iLBSyJ2XBRAB9aINHA/4KehOZf4Iuw6AE9qAm7+asOr9X9V1qSgQn7H/Zl3lIFTjCC/+dtXU3fZ3wY+Y42/9Tk7/7eJxvtDC77Owe2S6tjcfkXyx9rWDfT1M+/GtMq SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Feb 2018 06:49:51.4202 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 30f93bd4-2834-471f-4bed-08d57c1bf864 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: e02030e7-4d45-463e-a968-0290e738c18e X-MS-Exchange-Transport-CrossTenantHeadersStamped: OSAPR01MB1538 Archived-At: Subject: Re: [Slim] Negotiation issue in draft-ietf-slim-negotiating-human-language 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: Sun, 25 Feb 2018 06:49:57 -0000 Hello everybody, >> On 18 Feb 2018, at 11:56, Bernard Aboba wrote: >> >>> The fact that Answers containing “pointless confusion” are allowed >>> means that implementations need to be prepared to handle these edge >>> cases. I see no benefit arising from this. This is just a general observation, but I think human language abilities are much more nuanced and fluent than e.g. supported codecs. That's why it's difficult to call such things "pointless confusions". Regards, Martin. From nobody Sun Feb 25 02:42:25 2018 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 21813126BF3 for ; Sun, 25 Feb 2018 02:42:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 cgF1Y88SmAXF for ; Sun, 25 Feb 2018 02:42:22 -0800 (PST) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 30E43120725 for ; Sun, 25 Feb 2018 02:42:22 -0800 (PST) Received: from [99.111.97.172] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Sun, 25 Feb 2018 02:43:19 -0800 From: "Randall Gellens" To: "Martin J. =?utf-8?q?D=C3=BCrst?=" Cc: "Gunnar =?utf-8?q?Hellstr=C3=B6m?=" , "Bernard Aboba" , slim@ietf.org Date: Sun, 25 Feb 2018 02:42:18 -0800 X-Mailer: MailMate Trial (1.10r5443) Message-ID: In-Reply-To: <0aada25c-4b72-8857-cd6a-8b73c9f1aac5@it.aoyama.ac.jp> References: <6754134E-63FD-4212-90D5-D07293EFE36B@randy.pensive.org> <09dcffcc-a65d-65d8-614d-fa12b790dd4f@omnitor.se> <5c33acfd-8853-4254-c6b1-fa05ea4901fd@omnitor.se> <608E5933-9EB0-489D-A845-39018CF68127@randy.pensive.org> <9B27941C-CAE7-4162-8E8B-3BFA60921578@gmail.com> <7D3A0148-DFAA-459B-B5AF-C85D59E6313B@randy.pensive.org> <811b57b1-2444-f206-b860-2034ce1b8ea4@omnitor.se> <0aada25c-4b72-8857-cd6a-8b73c9f1aac5@it.aoyama.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Slim] Negotiation issue in draft-ietf-slim-negotiating-human-language 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: Sun, 25 Feb 2018 10:42:23 -0000 On 24 Feb 2018, at 22:49, Martin J. Dürst wrote: > Hello everybody, > >>> On 18 Feb 2018, at 11:56, Bernard Aboba wrote: >>> >>>> The fact that Answers containing “pointless confusion” are >>>> allowed means that implementations need to be prepared to handle >>>> these edge cases. I see no benefit arising from this. > > This is just a general observation, but I think human language > abilities are much more nuanced and fluent than e.g. supported codecs. > That's why it's difficult to call such things "pointless confusions". > > Regards, Martin. Hi Martin, I don’t think anyone disagrees with that. The range of possibilities with human languages are far greater than what the document tries to codify. --Randall