Re: [Slim] I-D Action: draft-ietf-slim-negotiating-human-language-07.txt

Natasha Rooney <nrooney@gsma.com> Tue, 07 March 2017 14:22 UTC

Return-Path: <nrooney@gsma.com>
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 B608312962B for <slim@ietfa.amsl.com>; Tue, 7 Mar 2017 06:22:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.91
X-Spam-Level:
X-Spam-Status: No, score=-2.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gsmasso.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 6lqFZX7V5oX1 for <slim@ietfa.amsl.com>; Tue, 7 Mar 2017 06:21:44 -0800 (PST)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0085.outbound.protection.outlook.com [104.47.2.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0379A12949E for <slim@ietf.org>; Tue, 7 Mar 2017 06:18:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=GSMASSO.onmicrosoft.com; s=selector1-gsma-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=J9DoCP1bJDlWYMV7Gm3VYTyJjmbq4Yy4ttcithp79Z8=; b=T8xowmD7gMV2Nixzj8jLes4vjiDhRBBr/BboLsDFjIp0GyF6RJb9iszxdkyYL64AO3AcWWlKelLVH4w6tlAfAA6ihNnPLMdEA/2MP6REcj2SRltF6VyZZ9O55CBxvl+vSZ8PXnxLkyKvECfzzrCkFbi1UNqtpPPDJSMnku/DoCs=
Received: from HE1PR04MB3113.eurprd04.prod.outlook.com (10.171.196.31) by HE1PR04MB3113.eurprd04.prod.outlook.com (10.171.196.31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.12; Tue, 7 Mar 2017 14:18:06 +0000
Received: from HE1PR04MB3113.eurprd04.prod.outlook.com ([10.171.196.31]) by HE1PR04MB3113.eurprd04.prod.outlook.com ([10.171.196.31]) with mapi id 15.01.0947.020; Tue, 7 Mar 2017 14:18:06 +0000
From: Natasha Rooney <nrooney@gsma.com>
To: Randall Gellens <rg+ietf@randy.pensive.org>
Thread-Topic: [Slim] I-D Action: draft-ietf-slim-negotiating-human-language-07.txt
Thread-Index: AQHSkvuosMicw1+KUkOljenWkhIsJqGJdU6A
Date: Tue, 07 Mar 2017 14:18:06 +0000
Message-ID: <52E633F6-FBBB-48FF-9759-6E566914CDE6@gsma.com>
References: <148782279664.31054.8793649134696520241.idtracker@ietfa.amsl.com> <p0624060cd4d4111cd79a@[99.111.97.136]> <49fd730e-6e90-1a49-eae8-80f8b1285a76@omnitor.se> <p06240604d4d6169921b5@[99.111.97.136]> <83152ba7-c3fb-25d8-f97d-59c7840cad56@omnitor.se> <p06240601d4d790fb8bb3@[99.111.97.136]> <4b36f347-955e-e2b9-12f2-f426d47d3d33@omnitor.se> <p06240608d4d927eaec67@[99.111.97.136]> <7f844aaa-17ce-2ab7-0602-a999a40235de@omnitor.se> <p06240600d4d9f6705416@[99.111.97.136]> <825fa638-b223-d716-6a3c-238903a37b92@omnitor.se> <p06240609d4dbcec4bcbf@[99.111.97.136]> <dba331e9-1075-5091-4f62-88a136049ab5@omnitor.se> <p06240601d4dcb7ca7f8b@[192.168.2.201]> <9084ad5c-a3d1-68e1-879b-af759c463fd1@omnitor.se> <p0624060fd4dd3196d298@[192.168.2.201]>
In-Reply-To: <p0624060fd4dd3196d298@[192.168.2.201]>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3259)
authentication-results: randy.pensive.org; dkim=none (message not signed) header.d=none; randy.pensive.org; dmarc=none action=none header.from=gsma.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [146.198.144.67]
x-ms-office365-filtering-correlation-id: 2b937847-7a3d-44cd-b0ba-08d46564c63b
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:HE1PR04MB3113;
x-microsoft-exchange-diagnostics: 1; HE1PR04MB3113; 7:wo8dprd9LYWdtEaylSKfGyE7H1T8A1rPbmjQvXgUePmoxLFicaxUxGZ3Zg+v6VmBqpecJXxFlnE0ukp5vG70j6ZeVtHuapach1e22igZJgyBuXFN9oY0GpojAcMHSCYrMbfRplaoVihy+fuYOJgAtEyDKArNP9IZH9kn4RwEtvqTqefesrUGBdli3SclGwrLG3HAt1CxhZiHlEYq2iKBWxPI1ZR7MzG/8AT4kzOoit8ao7Ly3GvS42YA+LVygau0ZIgQgOW6odDDv0UZ2zkZt0miBeULIyo72J2h8yBliAuZTKbQ4L5ieURZsvEmFAy1QhafhXDq/Vir1UwuFTcTwQ==
x-microsoft-antispam-prvs: <HE1PR04MB31135E4AFA54BB4E108D29A5C32F0@HE1PR04MB3113.eurprd04.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123560025)(20161123562025)(20161123555025)(20161123558025)(20161123564025)(6042181)(6072148); SRVR:HE1PR04MB3113; BCL:0; PCL:0; RULEID:; SRVR:HE1PR04MB3113;
x-forefront-prvs: 0239D46DB6
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(377454003)(377424004)(53754006)(24454002)(83716003)(68736007)(4326008)(6246003)(106116001)(106356001)(561944003)(38730400002)(8676002)(2950100002)(86362001)(2900100001)(110136004)(54906002)(236005)(82746002)(39060400002)(25786008)(6436002)(77096006)(6486002)(230783001)(53546006)(33656002)(5890100001)(6512007)(6506006)(229853002)(36756003)(50986999)(122556002)(54896002)(5660300001)(3280700002)(7736002)(66066001)(76176999)(99286003)(93886004)(57306001)(8936002)(53936002)(102836003)(6116002)(3846002)(2906002)(50226002)(189998001)(81166006)(3660700001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR04MB3113; H:HE1PR04MB3113.eurprd04.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_52E633F6FBBB48FF97596E566914CDE6gsmacom_"
MIME-Version: 1.0
X-OriginatorOrg: gsma.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Mar 2017 14:18:06.1299 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72a4ff82-fec3-469d-aafb-ac8276216699
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR04MB3113
X-MS-Exchange-CrossPremises-AuthAs: Internal
X-MS-Exchange-CrossPremises-AuthMechanism: 04
X-MS-Exchange-CrossPremises-AuthSource: HE1PR04MB3113.eurprd04.prod.outlook.com
X-MS-Exchange-CrossPremises-SCL: 1
X-MS-Exchange-CrossPremises-messagesource: StoreDriver
X-MS-Exchange-CrossPremises-BCC:
X-MS-Exchange-CrossPremises-originalclientipaddress: 146.198.144.67
X-MS-Exchange-CrossPremises-avstamp-service: 1.0
X-MS-Exchange-CrossPremises-disclaimer-hash: 78ca8040c6722e32c2f5b0a45bf37e74b9409d645a53be96aa19958e0cee0f00
X-MS-Exchange-CrossPremises-antispam-scancontext: DIR:Originating; SFV:NSPM; SKIP:0;
X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent
X-OrganizationHeadersPreserved: HE1PR04MB3113.eurprd04.prod.outlook.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/slim/rbS2LCMG4mWUQzNi0e2phc67zfM>
Cc: "slim@ietf.org" <slim@ietf.org>, "Phillips, Addison" <addison@lab126.com>, Gunnar Hellström <gunnar.hellstrom@omnitor.se>, Bernard Aboba <bernard.aboba@gmail.com>
Subject: Re: [Slim] I-D Action: draft-ietf-slim-negotiating-human-language-07.txt
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media <slim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/slim>, <mailto:slim-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/slim/>
List-Post: <mailto:slim@ietf.org>
List-Help: <mailto:slim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/slim>, <mailto:slim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Mar 2017 14:22:03 -0000

Hi all,

I’ve been catching up on the discussions after a long business trip - so many apologies for the late response.

The idea of working on Gunnar’s suggestions within a separate draft seems like a good idea; it doesn’t delay the current draft’s progress nor does it ignore a good proposal. It seems people are ok with this decision, so let’s do that.

Gunnar - if you want to make a start on this that would be fab; Randall has offered support for this so we can rely on him for text and review.

Natasha

Natasha Rooney | Internet Engineering Director | Internet and Web Team | Technology | GSMA | nrooney@gsma.com<mailto:nrooney@gsma.com> | +44 (0) 7730 219 765 | @thisNatasha | Skype: nrooney@gsm.org<mailto:nrooney@gsm.org>

On 2 Mar 2017, at 02:21, Randall Gellens <rg+ietf@randy.pensive.org<mailto:rg+ietf@randy.pensive.org>> wrote:

Hi Gunnar,

At 11:06 PM +0100 3/1/17, Gunnar Hellström wrote:

Den 2017-03-01 kl. 18:47, skrev Randall Gellens:
At 8:26 AM +0100 3/1/17, Gunnar Hellström wrote:

 Hi Randall,

 Den 2017-03-01 kl. 02:08, skrev Randall Gellens:

 Hi Gunnar,

 I'm starting a new message to cut out the huge amount of quoting.

 Your proposal is that text be added that advises the calling client to place an asterisk on the least-preferred language/media, and advises the answering client to indicate to the answering human which language/media is not the least preferred (did not have an asterisk in the offer), is that accurate?

 Yes, with slight rewording to:
 "text that advises the offering client to place an asterisk on the least-preferred language/media indications, and advises the answering client to indicate to the answering human which language/media are not the least preferred (did not have an asterisk in the offer)"

 The inclusion of the "indications" is just to assure that it is clear that it does not need to be just one indication that gets the asterisk .
 The last part sounds awkward, but matches technically what the lack of an asterisk means. I inherited the inverted logic for the asterisk from its already defined non-denial meaning.
 If you are considering wording for the draft, I suggest that you straighten the logic to say "which language/media are most preferred (did not have an asterisk in the offer)"

 It does also not need to be an "answering human" that gets this indication and makes use of it for guidance on how to answer the call. It can just as well be e.g. a multi-modal answering machine or some other application interacting with human language. I am not sure if "answering party" is more appropriate and can be considered including such automata.

Hi Gunnar,

Thanks for clarifying, I think I understand your proposal in detail now.  After thinking it over, I still think this would be better done in a new draft, because (a) it is advice on a way of using the mechanism to convey additional information; (b) it would be good for the group to discuss the proposal and work through various cases (e.g., what if the offering client is not going to include an asterisk, what if there is more than one most-preferred language); and (c) it would be good for the group to decide if this meets your need.
Randall,
Good that you understand it now.
I realize that this kind of added rules for an already existing parameter could be specified in an additional draft. Especially since it has no impact on the current meaning of the asterisk.
I still think it is best to add the few words needed now. The preference indication is so severely unbalanced without it, in that only preference between languages in the same modality can be specified. I am afraid that it can be seen as a discrimination against those who would need to specify preference between different modalities in order to tget equal opportunities to get smoothly performed calls through, but cannot.

You are right that there are situations that will not be explained if we accept my little extra sentence or something similar.
That is true also for the currently specified indications. We have said that we nearly only specify the indications and not how the negotiation shall be performed. It can be a topic for a BCP to advice on how the negotiation could be performed both with the currently specified language and in-media preferences and with the additional preference between media. We could discuss e.g. the case when two same spoken languages are specified but with the opposite preference order by the offeror and answering party. A decision must be taken, because the protocol says that oly one language per media and direction may be indicated in the answer, and also that the answering instance need to become aware of which language it shall produce.
I do not say that we need to resolve this case. It can be discussed in a BCP, and indicated that additional policy may be applied for solving that kind of undefined cases.

Similarily, there will be situations with the additional use of the asterisk that will be good to provide extra information for in a BCP. The preference indication is very rough, with only two levels. So there wil of course be situations when the users will wonder how to set their profile, and cases when the negotiation will be hard to assign a well motivated result. But we have said that we want to have the specification on this rough level.

The two cases that you bring up can have this treatment:

1. If the calling user want to get the call denied if no languages match, then the user must make a decision if that preference is more important to specify than the preference between modalities. In order to keep complexity low, I do not think that we should specify how to code both preferences.

2. If there are more than one most-preferred language. I understand this as for example a user is equally happy to use French sign language as spoken French, and can also, but on lower preference level write French text. That would be indicated by an asterisk on the French text, and the answering party having all these three capabilities may omit the French text from the answer but keep the others. Then the answering user select one of the spoken French and French Sign Language for its start of the call, knowing that the caller will be approximately equally happy with the call in both these cases.   Was that the case you thought about for the second case?

I understand that you wanted to check more than these two cases and discuss them with the WG, so the above is just a start. We can do more cases if you want, but I do not think we need any lengthy discussion that would delay the current draft.



A new draft, especially one that will be either Informational or BCP, can be done fairly quickly. It could be quite short, perhaps only a page or two of real text plus the boilerplate text.  I am happy to help with it.

I see your point, however, my view is that this is best covered in a separate draft.  As I said above, the draft can be completed very quickly if it is Informational (or even BCP), clear and not controversial.  I am happy to help.

--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
  The highlight of the annual Computer Bowl occurred when Bill Gates,
who was a judge, posed the following question to the contestants:
  "What contest, held via Usenet, is dedicated to examples of weird,
obscure, bizarre, and really bad programming?"
  After a moment of silence, Jean-Louis Gassee (ex-honcho at Apple)
hit his buzzer and answered "Windows."
                                        --Recounted by Adam C. Engst


This email and its attachments are intended for the above named only and may be confidential. If they have come to you in error you must take no action based on them, nor must you copy or show them to anyone; please reply to this email or call +44 207 356 0600 and highlight the error.