From nobody Thu Jun 1 02:45:35 2017 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 7E1AF126DED for ; Thu, 1 Jun 2017 02:45:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 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_H4=-0.01, 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 yl41TiKjNeTl for ; Thu, 1 Jun 2017 02:45:31 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0059.outbound.protection.outlook.com [104.47.1.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5FDB12EB55 for ; Thu, 1 Jun 2017 02:45:30 -0700 (PDT) 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=nAi2BgJ0Gwqc4RBlz02/e9jPh7ouSQw49cPmBRFsXSo=; b=fUvG62t8fNbWU4RgdmIiZK4b3O4AHOZlOSE2HCpv7EqZZb7eFdDyw5/gwZeIlrD3Dw44g7tGnfYizmA/NCwvi+BAgFCWRiHz6YNMoFt+OFXjVkD3dyy/+pHnL/l2Mt+UYbRODgEBrJiZUjND48oHm3WD4TdAFmr/OFw4RKqS5fY= Received: from AM2PR04MB0802.eurprd04.prod.outlook.com (10.160.56.28) by AM2PR04MB0804.eurprd04.prod.outlook.com (10.160.57.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1124.9; Thu, 1 Jun 2017 09:45:27 +0000 Received: from AM2PR04MB0802.eurprd04.prod.outlook.com ([fe80::250d:5ecf:c7fd:d3b1]) by AM2PR04MB0802.eurprd04.prod.outlook.com ([fe80::250d:5ecf:c7fd:d3b1%15]) with mapi id 15.01.1124.020; Thu, 1 Jun 2017 09:45:28 +0000 From: Natasha Rooney To: Randall Gellens CC: =?utf-8?B?R3VubmFyIEhlbGxzdHLDtm0=?= , Bernard Aboba , "slim@ietf.org" Thread-Topic: [Slim] Open Issues on draft-ietf-slim-negotiating-human-language Thread-Index: AQHSvfFennYJ1euDyk6DzIklHhGSTaIKg9uAgAFY1YCAADpHAIAD5L0A Date: Thu, 1 Jun 2017 09:45:27 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) 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-originating-ip: [62.189.0.100] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM2PR04MB0804; 7:BxjD8D0fNtjP8pgEsDXd1/NCBysSBBuFl8eSTLfJd3lnzV4x/ZscQHn6EGba0sDmHX66PZGWU7Pu+y3gVTFWONpEH4g+9HRz68GkVcAXf2YO29dkE72sro8p7dMn0xhGxR/8efJgxagC0xHQSn6zt37Jq5sy4egQrMKZt0KmBAn29z2W7wrpoBMtIECgwQjOOk5r61SIoDRW4YkCvOAB4tRrcJukuKco7HuEG8d6JQ/zcrpp87ixXUZ7jt9hTid1sv1mFDeJHkGHckCY6OOqIQiLUubaXL8UF89EZi6/YGL9iPo3vQNXs3F56JkNRz8ZbDc8Dvo03SsXuzWLdVpFcQ== x-ms-traffictypediagnostic: AM2PR04MB0804: x-ms-office365-filtering-correlation-id: e01a32b0-8e34-4924-25ca-08d4a8d2ef7c x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:AM2PR04MB0804; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700090)(100105000095)(100000701090)(100105300095)(100000702090)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(100000703090)(100105400095)(3002001)(93006095)(93001095)(6041248)(20161123564025)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123558100)(6072148)(100000704090)(100105200095)(100000705090)(100105500095); SRVR:AM2PR04MB0804; BCL:0; PCL:0; RULEID:(100000800090)(100110000095)(100000801090)(100110300095)(100000802090)(100110100095)(100000803090)(100110400095)(100000804090)(100110200095)(100000805090)(100110500095); SRVR:AM2PR04MB0804; x-forefront-prvs: 0325F6C77B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39840400002)(39850400002)(39400400002)(39410400002)(39450400003)(377454003)(377424004)(24454002)(3846002)(189998001)(102836003)(6116002)(82746002)(36756003)(2950100002)(2906002)(3280700002)(229853002)(83716003)(3660700001)(2900100001)(230783001)(93886004)(57306001)(66066001)(5660300001)(86362001)(606005)(7906003)(81166006)(50226002)(7736002)(8676002)(33656002)(8936002)(76176999)(50986999)(5250100002)(53546009)(478600001)(5890100001)(110136004)(54896002)(54906002)(14454004)(236005)(53936002)(6436002)(4326008)(6506006)(6246003)(38730400002)(39060400002)(6512007)(6306002)(6486002)(25786009)(99286003)(966005); DIR:OUT; SFP:1101; SCL:1; SRVR:AM2PR04MB0804; H:AM2PR04MB0802.eurprd04.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DD8DA8BD65E64825B928CCC06BAFC8A2gsmacom_" MIME-Version: 1.0 X-OriginatorOrg: gsma.com X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jun 2017 09:45:27.9478 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72a4ff82-fec3-469d-aafb-ac8276216699 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR04MB0804 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: AM2PR04MB0802.eurprd04.prod.outlook.com X-MS-Exchange-CrossPremises-TransportTrafficType: Email X-MS-Exchange-CrossPremises-TransportTrafficSubType: X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-originalclientipaddress: 62.189.0.100 X-MS-Exchange-CrossPremises-transporttraffictype: Email X-MS-Exchange-CrossPremises-transporttrafficsubtype: 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: AM2PR04MB0804.eurprd04.prod.outlook.com Archived-At: Subject: Re: [Slim] Open Issues on 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, 01 Jun 2017 09:45:34 -0000 --_000_DD8DA8BD65E64825B928CCC06BAFC8A2gsmacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIGxhc3QgcmVtYWluaW5nIGl0ZW0gb2YgVGlja2V0IDI2IGlzIGFza2luZyBmb3IgYW4gZXhw bGFuYXRpb24gb2YgdGhlIHJvbGUgb2YgKiBvbmx5LiBDYW4gd2UgZ2V0IHRoaXMgYWRkZWQgYW5k IHRoZW4gY2xvc2UgdGhlIHRpY2tldD8NCg0KSeKAmWxsIGFkZHJlc3MgMzQgc2VwYXJhdGVseS4N Cg0KTmF0YXNoYSBSb29uZXkgfCBJbnRlcm5ldCBFbmdpbmVlcmluZyBEaXJlY3RvciB8IEludGVy bmV0IGFuZCBXZWIgVGVhbSB8IFRlY2hub2xvZ3kgfCBHU01BIHwgbnJvb25leUBnc21hLmNvbTxt YWlsdG86bnJvb25leUBnc21hLmNvbT4gfCArNDQgKDApIDc3MzAgMjE5IDc2NSB8IEB0aGlzTmF0 YXNoYSB8IFNreXBlOiBucm9vbmV5QGdzbS5vcmc8bWFpbHRvOm5yb29uZXlAZ3NtLm9yZz4NCg0K T24gMjkgTWF5IDIwMTcsIGF0IDIzOjE3LCBSYW5kYWxsIEdlbGxlbnMgPHJnK2lldGZAcmFuZHku cGVuc2l2ZS5vcmc8bWFpbHRvOnJnK2lldGZAcmFuZHkucGVuc2l2ZS5vcmc+PiB3cm90ZToNCg0K QXQgODo0OSBQTSArMDIwMCA1LzI5LzE3LCBHdW5uYXIgSGVsbHN0csO2bSB3cm90ZToNCg0KRGVu IDIwMTctMDUtMjkga2wuIDAwOjE1LCBza3JldiBSYW5kYWxsIEdlbGxlbnM6DQpJIHRoaW5rIHRo ZSBlZGl0cyBzbyBmYXIgYWRkcmVzcyAjMTksICMyNywgMjggc28gdGhleSBjYW4gYmUgY2xvc2Vk LiAjMzgsICMzOSBhcmUgYWRkcmVzc2VkIGluIC0wOSBzbyBJIHdpbGwgcG9zdCB0aGF0IGFuZCB0 aG9zZSBjYW4gYmUgY2xvc2VkLiAgSSB0aGluayAjMjYsICMyOSwgIzMyLCAjMzQsICMzNSB3ZXJl IG5vdCBhY2NlcHRlZC4NClRoaXMgaXMgbXkgdmlldzoNCg0KIzI2IGNhbiBiZSBsZWZ0IG5vbi1h Y2NlcHRlZCBpZiAjMzQgaXMgYWNjZXB0ZWQuDQoNCiMyNiBjYW4gYmUgZG9uZSB3aXRoIGFuIElu Zm9ybWF0aW9uYWwgZHJhZnQgdGhhdCBwcm92aWRlcyBhZHZpY2UgdG8gaW1wbGVtZW50ZXJzLCBh cyBwcmV2aW91c2x5IGRpc2N1c3NlZC4gICMzNCB3YXMgZGlzY3Vzc2VkIGEgbG9uZyB0aW1lIGFn byBhbmQgaXQgd2FzIGRlY2lkZWQgdGhhdCB3ZSBkaWQgbm90IG5lZWQgdG8gYWRkIGNvbXBsZXhp dHkgYW5kIHRoYXQgd2Ugd291bGQga2VlcCB0aGUgbW9yZSBzaW1wbGUgc3ludGF4Lg0KDQogQnV0 IGlmICMzNCBpcyBub3QgYWNjZXB0ZWQsIHdlIGNvdWxkIG5lZWQgIzI2Lg0KIzI5IGlzIG9rIHRv IG5vdCBhY2NlcHQuIEFsbCBvdGhlciBhc3BlY3RzIG9mIHRoZSBhdHRyaWJ1dGUgcmVnaXN0cmF0 aW9ucyBhcmUgc29sdmVkLg0KDQojMzQ6IEkgaGF2ZSBub3Qgc2VlbiBhbnl0aGluZyBhYm91dCBu b3QgYWNjZXB0aW5nIGl0LCBzbyBJIHN1Z2dlc3QgdG8gYWNjZXB0IGl0Lg0KIzM1IHN5bnRheCBm b3IgYmlkaXJlY3Rpb25hbGx5IHN5bW1ldHJpYyBjYXNlcyAtIHdpbGwgaW5jcmVhc2UgY29tcGxl eGl0eSAtIEkgd291bGQgc3VnZ2VzdCB0byBub3QgYWNjZXB0IGl0LCBidXQgSSBjYW5ub3QgcmVt ZW1iZXIgdGhhdCB3ZSBjb25jbHVkZWQgdGhhdCBiZWZvcmUuDQoNCiMzMiByZXF1aXJlcyB0aGUg dHdvIGV4dGVuc2lvbnMgYWJvdXQgcmVsYXRpdmUgcHJlZmVyZW5jZSBhbmQgc2ltdWx0YW5laXR5 IHRvIGJlIHNvbHZlZC4gV2UgaGF2ZSBub3Qgc2FpZCB0aGF0IHdlIHdvdWxkIG5vdCBhY2NlcHQg IzMyLiAgSSBzdWdnZXN0IHRoYXQgd2UgYWNjZXB0IGl0Lg0KDQpXZSd2ZSByZXBlYXRlZGx5IGRl Y2lkZWQgdG8gbm90IGFkZCByZWxhdGl2ZSBwcmVmZXJlbmNlcyAobm9yIGFueSBjb29yZGluYXRp b24gYmV0d2VlbiBtZWRpYSkgaW4gdGhpcyBkcmFmdC4gIFRoaXMgY2FuIGFsbCBiZSBkb25lIGlu IGEgc3Vic2VxdWVudCBkcmFmdC4NCg0KLS1SYW5keQ0KDQoNCg0KDQpHdW5uYXINCg0KDQoNCi0t UmFuZHkNCg0KQXQgMTE6MjUgQU0gLTA3MDAgNC8yNS8xNywgQmVybmFyZCBBYm9iYSB3cm90ZToN Cg0KIEN1cnJlbnRseSAxMCBJc3N1ZXMgcmVtYWluIG9wZW4gZnJvbSBJRVRGIExhc3QgQ2FsbDoN Cg0KPGh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL3NsaW0vcmVwb3J0LzE+aHR0cHM6Ly90cmFj LmlldGYub3JnL3RyYWMvc2xpbS9yZXBvcnQvMQ0KDQoNCiBUaGVzZSBpbmNsdWRlOg0KDQo8aHR0 cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvc2xpbS9yZXBvcnQvMT9zb3J0PXRpY2tldCZhc2M9MSZw YWdlPTE+VGlja2V0PGh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL3NsaW0vcmVwb3J0LzE/c29y dD1zdW1tYXJ5JmFzYz0xJnBhZ2U9MT5TdW1tYXJ5PGh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFj L3NsaW0vcmVwb3J0LzE/c29ydD1jb21wb25lbnQmYXNjPTEmcGFnZT0xPkNvbXBvbmVudDxodHRw czovL3RyYWMuaWV0Zi5vcmcvdHJhYy9zbGltL3JlcG9ydC8xP3NvcnQ9dmVyc2lvbiZhc2M9MSZw YWdlPTE+VmVyc2lvbjxodHRwczovL3RyYWMuaWV0Zi5vcmcvdHJhYy9zbGltL3JlcG9ydC8xP3Nv cnQ9bWlsZXN0b25lJmFzYz0xJnBhZ2U9MT5NaWxlc3RvbmU8aHR0cHM6Ly90cmFjLmlldGYub3Jn L3RyYWMvc2xpbS9yZXBvcnQvMT9zb3J0PXR5cGUmYXNjPTEmcGFnZT0xPlR5cGU8aHR0cHM6Ly90 cmFjLmlldGYub3JnL3RyYWMvc2xpbS9yZXBvcnQvMT9zb3J0PW93bmVyJmFzYz0xJnBhZ2U9MT5P d25lcjxodHRwczovL3RyYWMuaWV0Zi5vcmcvdHJhYy9zbGltL3JlcG9ydC8xP3NvcnQ9c3RhdHVz JmFzYz0xJnBhZ2U9MT5TdGF0dXM8aHR0cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvc2xpbS9yZXBv cnQvMT9zb3J0PWNyZWF0ZWQmYXNjPTEmcGFnZT0xPkNyZWF0ZWQ8aHR0cHM6Ly90cmFjLmlldGYu b3JnL3RyYWMvc2xpbS90aWNrZXQvMjc+IzI3PGh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL3Ns aW0vdGlja2V0LzI3PlRoZSBjYXNlcyBpbiB0aGUgIlNpbGx5IHN0YXRlcyIgc2VjdGlvbiA1LjQg YXJlIG5vdCBhbGwgc2lsbHkubmVnb3RpYXRpbmctaHVtYW4tbGFuZ3VhZ2UyLjA8aHR0cHM6Ly90 cmFjLmlldGYub3JnL3RyYWMvc2xpbS9taWxlc3RvbmUvbWlsZXN0b25lMT5taWxlc3RvbmUxZGVm ZWN0PG1haWx0bzpndW5uYXIuaGVsbHN0cm9tQG9tbml0b3Iuc2U+Z3VubmFyLmhlbGxzdHJvbUBv bW5pdG9yLnNlbmV3TWFyPG1haWx0bzpndW5uYXIuaGVsbHN0cm9tQG9tbml0b3Iuc2VuZXdNYXI+ IDIyLCAyMDE3PGh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL3NsaW0vdGlja2V0LzE5PiMxOTxo dHRwczovL3RyYWMuaWV0Zi5vcmcvdHJhYy9zbGltL3RpY2tldC8xOT5Vc2UgTWVkaWEgVHlwZSBy ZWdpc3RyYXRpb24gdGVtcGxhdGVtdWx0aWxhbmdjb250ZW50ZW5oYW5jZW1lbnQ8bWFpbHRvOnJm Yy5uaWsudG9ta2luc29uQGdtYWlsLmNvbT5yZmMubmlrLnRvbWtpbnNvbkBnbWFpbC5jb21hc3Np Z25lZEF1ZzxtYWlsdG86cmZjLm5pay50b21raW5zb25AZ21haWwuY29tYXNzaWduZWRBdWc+IDE3 LCAyMDE2PGh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL3NsaW0vdGlja2V0LzI4PiMyODxodHRw czovL3RyYWMuaWV0Zi5vcmcvdHJhYy9zbGltL3RpY2tldC8yOD5FeGFtcGxlcyBzZWN0aW9uIDUu NSByZXF1aXJlcyBleHBhbnNpb25uZWdvdGlhdGluZy1odW1hbi1sYW5ndWFnZTIuMDxodHRwczov L3RyYWMuaWV0Zi5vcmcvdHJhYy9zbGltL21pbGVzdG9uZS9taWxlc3RvbmUxPm1pbGVzdG9uZTFk ZWZlY3Q8bWFpbHRvOnJnJTJCaWV0ZkByYW5keS5wZW5zaXZlLm9yZzxtYWlsdG86MkJpZXRmQHJh bmR5LnBlbnNpdmUub3JnPj5yZytpZXRmQHJhbmR5LnBlbnNpdmUub3JnYXNzaWduZWRNYXI8bWFp bHRvOnJnK2lldGZAcmFuZHkucGVuc2l2ZS5vcmdhc3NpZ25lZE1hcj4gMjIsIDIwMTc8aHR0cHM6 Ly90cmFjLmlldGYub3JnL3RyYWMvc2xpbS90aWNrZXQvMzI+IzMyPGh0dHBzOi8vdHJhYy5pZXRm Lm9yZy90cmFjL3NsaW0vdGlja2V0LzMyPkF1ZGlvL1ZpZGVvIENvb3JkaW5hdGlvbm5lZ290aWF0 aW5nLWh1bWFuLWxhbmd1YWdlMi4wPGh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL3NsaW0vbWls ZXN0b25lL21pbGVzdG9uZTE+bWlsZXN0b25lMWRlZmVjdDxtYWlsdG86cmclMkJpZXRmQHJhbmR5 LnBlbnNpdmUub3JnPG1haWx0bzoyQmlldGZAcmFuZHkucGVuc2l2ZS5vcmc+PnJnK2lldGZAcmFu ZHkucGVuc2l2ZS5vcmduZXdNYXI8bWFpbHRvOnJnK2lldGZAcmFuZHkucGVuc2l2ZS5vcmduZXdN YXI+IDIyLCAyMDE3PGh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL3NsaW0vdGlja2V0LzM0PiMz NDxodHRwczovL3RyYWMuaWV0Zi5vcmcvdHJhYy9zbGltL3RpY2tldC8zND5Vc2UgdGhlIEFjY2Vw dC1MYW5ndWFnZSBzeW50YXhuZWdvdGlhdGluZy1odW1hbi1sYW5ndWFnZTIuMDxodHRwczovL3Ry YWMuaWV0Zi5vcmcvdHJhYy9zbGltL21pbGVzdG9uZS9taWxlc3RvbmUxPm1pbGVzdG9uZTFkZWZl Y3Q8bWFpbHRvOnJnJTJCaWV0ZkByYW5keS5wZW5zaXZlLm9yZzxtYWlsdG86MkJpZXRmQHJhbmR5 LnBlbnNpdmUub3JnPj5yZytpZXRmQHJhbmR5LnBlbnNpdmUub3JnYXNzaWduZWRNYXI8bWFpbHRv OnJnK2lldGZAcmFuZHkucGVuc2l2ZS5vcmdhc3NpZ25lZE1hcj4gMjIsIDIwMTc8aHR0cHM6Ly90 cmFjLmlldGYub3JnL3RyYWMvc2xpbS90aWNrZXQvMzU+IzM1PGh0dHBzOi8vdHJhYy5pZXRmLm9y Zy90cmFjL3NsaW0vdGlja2V0LzM1PkhhdmUgYW4gYXR0cmlidXRlIHRvIGFiYnJldmlhdGUgdGhl IGJpZGlyZWN0aW9uYWxseS1zeW1tZXRyaWMgY2FzZW5lZ290aWF0aW5nLWh1bWFuLWxhbmd1YWdl Mi4wPGh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL3NsaW0vbWlsZXN0b25lL21pbGVzdG9uZTE+ bWlsZXN0b25lMWRlZmVjdDxtYWlsdG86cmclMkJpZXRmQHJhbmR5LnBlbnNpdmUub3JnPG1haWx0 bzoyQmlldGZAcmFuZHkucGVuc2l2ZS5vcmc+PnJnK2lldGZAcmFuZHkucGVuc2l2ZS5vcmdhc3Np Z25lZE1hcjxtYWlsdG86cmcraWV0ZkByYW5keS5wZW5zaXZlLm9yZ2Fzc2lnbmVkTWFyPiAyMiwg MjAxNzxodHRwczovL3RyYWMuaWV0Zi5vcmcvdHJhYy9zbGltL3RpY2tldC8zOD4jMzg8aHR0cHM6 Ly90cmFjLmlldGYub3JnL3RyYWMvc2xpbS90aWNrZXQvMzg+Um91dGluZyBvdXQgb2Ygc2NvcGVu ZWdvdGlhdGluZy1odW1hbi1sYW5ndWFnZTEuMDxodHRwczovL3RyYWMuaWV0Zi5vcmcvdHJhYy9z bGltL21pbGVzdG9uZS9taWxlc3RvbmUxPm1pbGVzdG9uZTFkZWZlY3Q8bWFpbHRvOmRyYWZ0LWll dGYtc2xpbS1uZWdvdGlhdGluZy1odW1hbi1sYW5ndWFnZUBpZXRmLm9yZz5kcmFmdC1pZXRmLXNs aW0tbmVnb3RpYXRpbmctaHVtYW4tbGFuZ3VhZ2VAaWV0Zi5vcmduZXdBcHI8bWFpbHRvOmRyYWZ0 LWlldGYtc2xpbS1uZWdvdGlhdGluZy1odW1hbi1sYW5ndWFnZUBpZXRmLm9yZ25ld0Fwcj4gMjUs IDIwMTc8aHR0cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvc2xpbS90aWNrZXQvMzk+IzM5PGh0dHBz Oi8vdHJhYy5pZXRmLm9yZy90cmFjL3NsaW0vdGlja2V0LzM5PlN5bnRheCBDb2xsYXBzZW5lZ290 aWF0aW5nLWh1bWFuLWxhbmd1YWdlMS4wPGh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL3NsaW0v bWlsZXN0b25lL21pbGVzdG9uZTE+bWlsZXN0b25lMWRlZmVjdDxtYWlsdG86ZHJhZnQtaWV0Zi1z bGltLW5lZ290aWF0aW5nLWh1bWFuLWxhbmd1YWdlQGlldGYub3JnPmRyYWZ0LWlldGYtc2xpbS1u ZWdvdGlhdGluZy1odW1hbi1sYW5ndWFnZUBpZXRmLm9yZ25ld0FwcjxtYWlsdG86ZHJhZnQtaWV0 Zi1zbGltLW5lZ290aWF0aW5nLWh1bWFuLWxhbmd1YWdlQGlldGYub3JnbmV3QXByPiAyNSwgMjAx NzxodHRwczovL3RyYWMuaWV0Zi5vcmcvdHJhYy9zbGltL3RpY2tldC8yNj4jMjY8aHR0cHM6Ly90 cmFjLmlldGYub3JnL3RyYWMvc2xpbS90aWNrZXQvMjY+TWFrZSB1c2Ugb2YgdGhlIGFzdGVyaXNr IG1vZGlmaWVyIG9uIG1lZGlhIGxldmVsIHdpdGggc2Vzc2lvbiBzY29wZSBhbHNvIGZvciBtZWRp YSBsZXZlbCBwdXJwb3Nlc25lZ290aWF0aW5nLWh1bWFuLWxhbmd1YWdlMi4wPGh0dHBzOi8vdHJh Yy5pZXRmLm9yZy90cmFjL3NsaW0vbWlsZXN0b25lL21pbGVzdG9uZTE+bWlsZXN0b25lMWVuaGFu Y2VtZW50PG1haWx0bzpndW5uYXIuaGVsbHN0cm9tQG9tbml0b3Iuc2U+Z3VubmFyLmhlbGxzdHJv bUBvbW5pdG9yLnNlbmV3TWFyPG1haWx0bzpndW5uYXIuaGVsbHN0cm9tQG9tbml0b3Iuc2VuZXdN YXI+IDIyLCAyMDE3PGh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL3NsaW0vdGlja2V0LzI5PiMy OTxodHRwczovL3RyYWMuaWV0Zi5vcmcvdHJhYy9zbGltL3RpY2tldC8yOT5JbmNsdWRlIG1vcmUg ZmllbGRzIGZvciBhdHRyaWJ1dGUgcmVnaXN0cmF0aW9uIGZyb20gNDU2NmJpcw0KDQogX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiBTTElNIG1haWxpbmcg bGlzdA0KIFNMSU1AaWV0Zi5vcmc8bWFpbHRvOlNMSU1AaWV0Zi5vcmc+DQogaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zbGltDQoNCg0KDQotLQ0KLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkd1bm5hciBIZWxsc3Ryw7ZtDQpPbW5pdG9yDQpn dW5uYXIuaGVsbHN0cm9tQG9tbml0b3Iuc2U8bWFpbHRvOmd1bm5hci5oZWxsc3Ryb21Ab21uaXRv ci5zZT4NCis0NiA3MDggMjA0IDI4OA0KDQoNCi0tDQpSYW5kYWxsIEdlbGxlbnMNCk9waW5pb25z IGFyZSBwZXJzb25hbDsgICAgZmFjdHMgYXJlIHN1c3BlY3Q7ICAgIEkgc3BlYWsgZm9yIG15c2Vs ZiBvbmx5DQotLS0tLS0tLS0tLS0tLSBSYW5kb21seSBzZWxlY3RlZCB0YWc6IC0tLS0tLS0tLS0t LS0tLQ0KSSBkbyBub3QgbmVlZCB0byBleHBsYWluIHdoeSBJIHNheSB0aGluZ3MuICBUaGF0J3Mg dGhlIGludGVyZXN0aW5nIHRoaW5nDQphYm91dCBiZWluZyB0aGUgUHJlc2lkZW50LiAgTWF5YmUg c29tZWJvZHkgbmVlZHMgdG8gZXhwbGFpbiB0byBtZSB3aHkNCnRoZXkgc2F5IHNvbWV0aGluZywg YnV0IEkgZG9uJ3QgZmVlbCBsaWtlIEkgb3dlIGFueWJvZHkgYW4gZXhwbGFuYXRpb24uDQogICAg ICAgICAgLS1HZW9yZ2UgVy4gQnVzaCwgaW4gYW4gaW50ZXJ2aWV3IHdpdGggQm9iIFdvb2R3YXJk Lg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KU0xJ TSBtYWlsaW5nIGxpc3QNClNMSU1AaWV0Zi5vcmc8bWFpbHRvOlNMSU1AaWV0Zi5vcmc+DQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NsaW0NCg0KDQpUaGlzIGVtYWlsIGFu ZCBpdHMgYXR0YWNobWVudHMgYXJlIGludGVuZGVkIGZvciB0aGUgYWJvdmUgbmFtZWQgb25seSBh bmQgbWF5IGJlIGNvbmZpZGVudGlhbC4gSWYgdGhleSBoYXZlIGNvbWUgdG8geW91IGluIGVycm9y IHlvdSBtdXN0IHRha2Ugbm8gYWN0aW9uIGJhc2VkIG9uIHRoZW0sIG5vciBtdXN0IHlvdSBjb3B5 IG9yIHNob3cgdGhlbSB0byBhbnlvbmU7IHBsZWFzZSByZXBseSB0byB0aGlzIGVtYWlsIG9yIGNh bGwgKzQ0IDIwNyAzNTYgMDYwMCBhbmQgaGlnaGxpZ2h0IHRoZSBlcnJvci4NCg== --_000_DD8DA8BD65E64825B928CCC06BAFC8A2gsmacom_ Content-Type: text/html; charset="utf-8" Content-ID: <280692408DE55540A17048F670C8A316@eurprd04.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KVGhlIGxhc3QgcmVtYWluaW5nIGl0 ZW0gb2YgVGlja2V0IDI2IGlzIGFza2luZyBmb3IgYW4gZXhwbGFuYXRpb24gb2YgdGhlIHJvbGUg b2YgKiBvbmx5LiBDYW4gd2UgZ2V0IHRoaXMgYWRkZWQgYW5kIHRoZW4gY2xvc2UgdGhlIHRpY2tl dD8NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkni gJlsbCBhZGRyZXNzIDM0IHNlcGFyYXRlbHkuJm5ic3A7PGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFz cz0iIj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2 ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQt Y2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFs OyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4 dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29y ZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsgLXdlYmtpdC10 ZXh0LXN0cm9rZS13aWR0aDogMHB4OyI+DQo8YnIgY2xhc3M9IiI+DQpOYXRhc2hhIFJvb25leSB8 IEludGVybmV0IEVuZ2luZWVyaW5nJm5ic3A7RGlyZWN0b3IgfCBJbnRlcm5ldCBhbmQgV2ViIFRl YW0gfCZuYnNwO1RlY2hub2xvZ3kgfCBHU01BIHwmbmJzcDs8YSBocmVmPSJtYWlsdG86bnJvb25l eUBnc21hLmNvbSIgY2xhc3M9IiI+bnJvb25leUBnc21hLmNvbTwvYT4mbmJzcDt8ICYjNDM7NDQg KDApIDc3MzAgMjE5Jm5ic3A7NzY1IHwgQHRoaXNOYXRhc2hhIHwgU2t5cGU6Jm5ic3A7PGEgaHJl Zj0ibWFpbHRvOm5yb29uZXlAZ3NtLm9yZyIgY2xhc3M9IiI+bnJvb25leUBnc20ub3JnPC9hPjwv ZGl2Pg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0 ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIDI5IE1heSAyMDE3LCBhdCAyMzoxNywgUmFu ZGFsbCBHZWxsZW5zICZsdDs8YSBocmVmPSJtYWlsdG86cmcmIzQzO2lldGZAcmFuZHkucGVuc2l2 ZS5vcmciIGNsYXNzPSIiPnJnJiM0MztpZXRmQHJhbmR5LnBlbnNpdmUub3JnPC9hPiZndDsgd3Jv dGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBj bGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+QXQgODo0OSBQTSAmIzQzOzAyMDAgNS8yOS8xNywgR3Vu bmFyIEhlbGxzdHLDtm0gd3JvdGU6PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJsb2Nr cXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+RGVuIDIwMTctMDUtMjkga2wuIDAwOjE1LCBza3Jl diBSYW5kYWxsIEdlbGxlbnM6PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIg Y2xhc3M9IiI+SSB0aGluayB0aGUgZWRpdHMgc28gZmFyIGFkZHJlc3MgIzE5LCAjMjcsIDI4IHNv IHRoZXkgY2FuIGJlIGNsb3NlZC4gIzM4LCAjMzkgYXJlIGFkZHJlc3NlZCBpbiAtMDkgc28gSSB3 aWxsIHBvc3QgdGhhdCBhbmQgdGhvc2UgY2FuIGJlIGNsb3NlZC4gJm5ic3A7SSB0aGluayAjMjYs ICMyOSwgIzMyLCAjMzQsICMzNSB3ZXJlIG5vdCBhY2NlcHRlZC48YnIgY2xhc3M9IiI+DQo8L2Js b2NrcXVvdGU+DQpUaGlzIGlzIG15IHZpZXc6PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0K IzI2IGNhbiBiZSBsZWZ0IG5vbi1hY2NlcHRlZCBpZiAjMzQgaXMgYWNjZXB0ZWQuPGJyIGNsYXNz PSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KIzI2IGNhbiBiZSBkb25lIHdpdGgg YW4gSW5mb3JtYXRpb25hbCBkcmFmdCB0aGF0IHByb3ZpZGVzIGFkdmljZSB0byBpbXBsZW1lbnRl cnMsIGFzIHByZXZpb3VzbHkgZGlzY3Vzc2VkLiAmbmJzcDsjMzQgd2FzIGRpc2N1c3NlZCBhIGxv bmcgdGltZSBhZ28gYW5kIGl0IHdhcyBkZWNpZGVkIHRoYXQgd2UgZGlkIG5vdCBuZWVkIHRvIGFk ZCBjb21wbGV4aXR5IGFuZCB0aGF0IHdlIHdvdWxkIGtlZXAgdGhlIG1vcmUgc2ltcGxlIHN5bnRh eC48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBj bGFzcz0iIj4mbmJzcDtCdXQgaWYgIzM0IGlzIG5vdCBhY2NlcHRlZCwgd2UgY291bGQgbmVlZCAj MjYuPGJyIGNsYXNzPSIiPg0KIzI5IGlzIG9rIHRvIG5vdCBhY2NlcHQuIEFsbCBvdGhlciBhc3Bl Y3RzIG9mIHRoZSBhdHRyaWJ1dGUgcmVnaXN0cmF0aW9ucyBhcmUgc29sdmVkLjxiciBjbGFzcz0i Ij4NCjxiciBjbGFzcz0iIj4NCiMzNDogSSBoYXZlIG5vdCBzZWVuIGFueXRoaW5nIGFib3V0IG5v dCBhY2NlcHRpbmcgaXQsIHNvIEkgc3VnZ2VzdCB0byBhY2NlcHQgaXQuPGJyIGNsYXNzPSIiPg0K IzM1IHN5bnRheCBmb3IgYmlkaXJlY3Rpb25hbGx5IHN5bW1ldHJpYyBjYXNlcyAtIHdpbGwgaW5j cmVhc2UgY29tcGxleGl0eSAtIEkgd291bGQgc3VnZ2VzdCB0byBub3QgYWNjZXB0IGl0LCBidXQg SSBjYW5ub3QgcmVtZW1iZXIgdGhhdCB3ZSBjb25jbHVkZWQgdGhhdCBiZWZvcmUuPGJyIGNsYXNz PSIiPg0KPGJyIGNsYXNzPSIiPg0KIzMyIHJlcXVpcmVzIHRoZSB0d28gZXh0ZW5zaW9ucyBhYm91 dCByZWxhdGl2ZSBwcmVmZXJlbmNlIGFuZCBzaW11bHRhbmVpdHkgdG8gYmUgc29sdmVkLiBXZSBo YXZlIG5vdCBzYWlkIHRoYXQgd2Ugd291bGQgbm90IGFjY2VwdCAjMzIuICZuYnNwO0kgc3VnZ2Vz dCB0aGF0IHdlIGFjY2VwdCBpdC48YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xh c3M9IiI+DQpXZSd2ZSByZXBlYXRlZGx5IGRlY2lkZWQgdG8gbm90IGFkZCByZWxhdGl2ZSBwcmVm ZXJlbmNlcyAobm9yIGFueSBjb29yZGluYXRpb24gYmV0d2VlbiBtZWRpYSkgaW4gdGhpcyBkcmFm dC4gJm5ic3A7VGhpcyBjYW4gYWxsIGJlIGRvbmUgaW4gYSBzdWJzZXF1ZW50IGRyYWZ0LjxiciBj bGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCi0tUmFuZHk8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9 IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8YnIg Y2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpHdW5uYXI8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj48YnIg Y2xhc3M9IiI+DQotLVJhbmR5PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KQXQgMTE6MjUg QU0gLTA3MDAgNC8yNS8xNywgQmVybmFyZCBBYm9iYSB3cm90ZTo8YnIgY2xhc3M9IiI+DQo8YnIg Y2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4mbmJzcDtDdXJyZW50 bHkgMTAgSXNzdWVzIHJlbWFpbiBvcGVuIGZyb20gSUVURiBMYXN0IENhbGw6PGJyIGNsYXNzPSIi Pg0KPGJyIGNsYXNzPSIiPg0KJmx0OzxhIGhyZWY9Imh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFj L3NsaW0vcmVwb3J0LzEiIGNsYXNzPSIiPmh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL3NsaW0v cmVwb3J0LzE8L2E+Jmd0OzxhIGhyZWY9Imh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL3NsaW0v cmVwb3J0LzEiIGNsYXNzPSIiPmh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL3NsaW0vcmVwb3J0 LzE8L2E+PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJm5ic3A7 VGhlc2UgaW5jbHVkZTo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQombHQ7PGEgaHJlZj0i aHR0cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvc2xpbS9yZXBvcnQvMT9zb3J0PXRpY2tldCZhbXA7 YXNjPTEmYW1wO3BhZ2U9MSIgY2xhc3M9IiI+aHR0cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvc2xp bS9yZXBvcnQvMT9zb3J0PXRpY2tldCZhbXA7YXNjPTEmYW1wO3BhZ2U9MTwvYT4mZ3Q7VGlja2V0 Jmx0OzxhIGhyZWY9Imh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL3NsaW0vcmVwb3J0LzE/c29y dD1zdW1tYXJ5JmFtcDthc2M9MSZhbXA7cGFnZT0xIiBjbGFzcz0iIj5odHRwczovL3RyYWMuaWV0 Zi5vcmcvdHJhYy9zbGltL3JlcG9ydC8xP3NvcnQ9c3VtbWFyeSZhbXA7YXNjPTEmYW1wO3BhZ2U9 MTwvYT4mZ3Q7U3VtbWFyeSZsdDs8YSBocmVmPSJodHRwczovL3RyYWMuaWV0Zi5vcmcvdHJhYy9z bGltL3JlcG9ydC8xP3NvcnQ9Y29tcG9uZW50JmFtcDthc2M9MSZhbXA7cGFnZT0xIiBjbGFzcz0i Ij5odHRwczovL3RyYWMuaWV0Zi5vcmcvdHJhYy9zbGltL3JlcG9ydC8xP3NvcnQ9Y29tcG9uZW50 JmFtcDthc2M9MSZhbXA7cGFnZT0xPC9hPiZndDtDb21wb25lbnQmbHQ7PGEgaHJlZj0iaHR0cHM6 Ly90cmFjLmlldGYub3JnL3RyYWMvc2xpbS9yZXBvcnQvMT9zb3J0PXZlcnNpb24mYW1wO2FzYz0x JmFtcDtwYWdlPTEiIGNsYXNzPSIiPmh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL3NsaW0vcmVw b3J0LzE/c29ydD12ZXJzaW9uJmFtcDthc2M9MSZhbXA7cGFnZT0xPC9hPiZndDtWZXJzaW9uJmx0 OzxhIGhyZWY9Imh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL3NsaW0vcmVwb3J0LzE/c29ydD1t aWxlc3RvbmUmYW1wO2FzYz0xJmFtcDtwYWdlPTEiIGNsYXNzPSIiPmh0dHBzOi8vdHJhYy5pZXRm Lm9yZy90cmFjL3NsaW0vcmVwb3J0LzE/c29ydD1taWxlc3RvbmUmYW1wO2FzYz0xJmFtcDtwYWdl PTE8L2E+Jmd0O01pbGVzdG9uZSZsdDs8YSBocmVmPSJodHRwczovL3RyYWMuaWV0Zi5vcmcvdHJh Yy9zbGltL3JlcG9ydC8xP3NvcnQ9dHlwZSZhbXA7YXNjPTEmYW1wO3BhZ2U9MSIgY2xhc3M9IiI+ aHR0cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvc2xpbS9yZXBvcnQvMT9zb3J0PXR5cGUmYW1wO2Fz Yz0xJmFtcDtwYWdlPTE8L2E+Jmd0O1R5cGUmbHQ7PGEgaHJlZj0iaHR0cHM6Ly90cmFjLmlldGYu b3JnL3RyYWMvc2xpbS9yZXBvcnQvMT9zb3J0PW93bmVyJmFtcDthc2M9MSZhbXA7cGFnZT0xIiBj bGFzcz0iIj5odHRwczovL3RyYWMuaWV0Zi5vcmcvdHJhYy9zbGltL3JlcG9ydC8xP3NvcnQ9b3du ZXImYW1wO2FzYz0xJmFtcDtwYWdlPTE8L2E+Jmd0O093bmVyJmx0OzxhIGhyZWY9Imh0dHBzOi8v dHJhYy5pZXRmLm9yZy90cmFjL3NsaW0vcmVwb3J0LzE/c29ydD1zdGF0dXMmYW1wO2FzYz0xJmFt cDtwYWdlPTEiIGNsYXNzPSIiPmh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL3NsaW0vcmVwb3J0 LzE/c29ydD1zdGF0dXMmYW1wO2FzYz0xJmFtcDtwYWdlPTE8L2E+Jmd0O1N0YXR1cyZsdDs8YSBo cmVmPSJodHRwczovL3RyYWMuaWV0Zi5vcmcvdHJhYy9zbGltL3JlcG9ydC8xP3NvcnQ9Y3JlYXRl ZCZhbXA7YXNjPTEmYW1wO3BhZ2U9MSIgY2xhc3M9IiI+aHR0cHM6Ly90cmFjLmlldGYub3JnL3Ry YWMvc2xpbS9yZXBvcnQvMT9zb3J0PWNyZWF0ZWQmYW1wO2FzYz0xJmFtcDtwYWdlPTE8L2E+Jmd0 O0NyZWF0ZWQmbHQ7PGEgaHJlZj0iaHR0cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvc2xpbS90aWNr ZXQvMjciIGNsYXNzPSIiPmh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL3NsaW0vdGlja2V0LzI3 PC9hPiZndDsjMjcmbHQ7PGEgaHJlZj0iaHR0cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvc2xpbS90 aWNrZXQvMjciIGNsYXNzPSIiPmh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL3NsaW0vdGlja2V0 LzI3PC9hPiZndDtUaGUNCiBjYXNlcyBpbiB0aGUgJnF1b3Q7U2lsbHkgc3RhdGVzJnF1b3Q7IHNl Y3Rpb24gNS40IGFyZSBub3QgYWxsIHNpbGx5Lm5lZ290aWF0aW5nLWh1bWFuLWxhbmd1YWdlMi4w Jmx0OzxhIGhyZWY9Imh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL3NsaW0vbWlsZXN0b25lL21p bGVzdG9uZTEiIGNsYXNzPSIiPmh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL3NsaW0vbWlsZXN0 b25lL21pbGVzdG9uZTE8L2E+Jmd0O21pbGVzdG9uZTFkZWZlY3QmbHQ7PGEgaHJlZj0ibWFpbHRv Omd1bm5hci5oZWxsc3Ryb21Ab21uaXRvci5zZSIgY2xhc3M9IiI+bWFpbHRvOmd1bm5hci5oZWxs c3Ryb21Ab21uaXRvci5zZTwvYT4mZ3Q7PGEgaHJlZj0ibWFpbHRvOmd1bm5hci5oZWxsc3Ryb21A b21uaXRvci5zZW5ld01hciIgY2xhc3M9IiI+Z3VubmFyLmhlbGxzdHJvbUBvbW5pdG9yLnNlbmV3 TWFyPC9hPg0KIDIyLCAyMDE3Jmx0OzxhIGhyZWY9Imh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFj L3NsaW0vdGlja2V0LzE5IiBjbGFzcz0iIj5odHRwczovL3RyYWMuaWV0Zi5vcmcvdHJhYy9zbGlt L3RpY2tldC8xOTwvYT4mZ3Q7IzE5Jmx0OzxhIGhyZWY9Imh0dHBzOi8vdHJhYy5pZXRmLm9yZy90 cmFjL3NsaW0vdGlja2V0LzE5IiBjbGFzcz0iIj5odHRwczovL3RyYWMuaWV0Zi5vcmcvdHJhYy9z bGltL3RpY2tldC8xOTwvYT4mZ3Q7VXNlIE1lZGlhIFR5cGUgcmVnaXN0cmF0aW9uIHRlbXBsYXRl bXVsdGlsYW5nY29udGVudGVuaGFuY2VtZW50Jmx0OzxhIGhyZWY9Im1haWx0bzpyZmMubmlrLnRv bWtpbnNvbkBnbWFpbC5jb20iIGNsYXNzPSIiPm1haWx0bzpyZmMubmlrLnRvbWtpbnNvbkBnbWFp bC5jb208L2E+Jmd0OzxhIGhyZWY9Im1haWx0bzpyZmMubmlrLnRvbWtpbnNvbkBnbWFpbC5jb21h c3NpZ25lZEF1ZyIgY2xhc3M9IiI+cmZjLm5pay50b21raW5zb25AZ21haWwuY29tYXNzaWduZWRB dWc8L2E+DQogMTcsIDIwMTYmbHQ7PGEgaHJlZj0iaHR0cHM6Ly90cmFjLmlldGYub3JnL3RyYWMv c2xpbS90aWNrZXQvMjgiIGNsYXNzPSIiPmh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL3NsaW0v dGlja2V0LzI4PC9hPiZndDsjMjgmbHQ7PGEgaHJlZj0iaHR0cHM6Ly90cmFjLmlldGYub3JnL3Ry YWMvc2xpbS90aWNrZXQvMjgiIGNsYXNzPSIiPmh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL3Ns aW0vdGlja2V0LzI4PC9hPiZndDtFeGFtcGxlcyBzZWN0aW9uIDUuNSByZXF1aXJlcw0KIGV4cGFu c2lvbm5lZ290aWF0aW5nLWh1bWFuLWxhbmd1YWdlMi4wJmx0OzxhIGhyZWY9Imh0dHBzOi8vdHJh Yy5pZXRmLm9yZy90cmFjL3NsaW0vbWlsZXN0b25lL21pbGVzdG9uZTEiIGNsYXNzPSIiPmh0dHBz Oi8vdHJhYy5pZXRmLm9yZy90cmFjL3NsaW0vbWlsZXN0b25lL21pbGVzdG9uZTE8L2E+Jmd0O21p bGVzdG9uZTFkZWZlY3QmbHQ7bWFpbHRvOnJnJTxhIGhyZWY9Im1haWx0bzoyQmlldGZAcmFuZHku cGVuc2l2ZS5vcmciIGNsYXNzPSIiPjJCaWV0ZkByYW5keS5wZW5zaXZlLm9yZzwvYT4mZ3Q7PGEg aHJlZj0ibWFpbHRvOnJnJiM0MztpZXRmQHJhbmR5LnBlbnNpdmUub3JnYXNzaWduZWRNYXIiIGNs YXNzPSIiPnJnJiM0MztpZXRmQHJhbmR5LnBlbnNpdmUub3JnYXNzaWduZWRNYXI8L2E+DQogMjIs IDIwMTcmbHQ7PGEgaHJlZj0iaHR0cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvc2xpbS90aWNrZXQv MzIiIGNsYXNzPSIiPmh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL3NsaW0vdGlja2V0LzMyPC9h PiZndDsjMzImbHQ7PGEgaHJlZj0iaHR0cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvc2xpbS90aWNr ZXQvMzIiIGNsYXNzPSIiPmh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL3NsaW0vdGlja2V0LzMy PC9hPiZndDtBdWRpby9WaWRlbyBDb29yZGluYXRpb25uZWdvdGlhdGluZy1odW1hbi1sYW5ndWFn ZTIuMCZsdDs8YSBocmVmPSJodHRwczovL3RyYWMuaWV0Zi5vcmcvdHJhYy9zbGltL21pbGVzdG9u ZS9taWxlc3RvbmUxIiBjbGFzcz0iIj5odHRwczovL3RyYWMuaWV0Zi5vcmcvdHJhYy9zbGltL21p bGVzdG9uZS9taWxlc3RvbmUxPC9hPiZndDttaWxlc3RvbmUxZGVmZWN0Jmx0O21haWx0bzpyZyU8 YSBocmVmPSJtYWlsdG86MkJpZXRmQHJhbmR5LnBlbnNpdmUub3JnIiBjbGFzcz0iIj4yQmlldGZA cmFuZHkucGVuc2l2ZS5vcmc8L2E+Jmd0OzxhIGhyZWY9Im1haWx0bzpyZyYjNDM7aWV0ZkByYW5k eS5wZW5zaXZlLm9yZ25ld01hciIgY2xhc3M9IiI+cmcmIzQzO2lldGZAcmFuZHkucGVuc2l2ZS5v cmduZXdNYXI8L2E+DQogMjIsIDIwMTcmbHQ7PGEgaHJlZj0iaHR0cHM6Ly90cmFjLmlldGYub3Jn L3RyYWMvc2xpbS90aWNrZXQvMzQiIGNsYXNzPSIiPmh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFj L3NsaW0vdGlja2V0LzM0PC9hPiZndDsjMzQmbHQ7PGEgaHJlZj0iaHR0cHM6Ly90cmFjLmlldGYu b3JnL3RyYWMvc2xpbS90aWNrZXQvMzQiIGNsYXNzPSIiPmh0dHBzOi8vdHJhYy5pZXRmLm9yZy90 cmFjL3NsaW0vdGlja2V0LzM0PC9hPiZndDtVc2UgdGhlIEFjY2VwdC1MYW5ndWFnZSBzeW50YXhu ZWdvdGlhdGluZy1odW1hbi1sYW5ndWFnZTIuMCZsdDs8YSBocmVmPSJodHRwczovL3RyYWMuaWV0 Zi5vcmcvdHJhYy9zbGltL21pbGVzdG9uZS9taWxlc3RvbmUxIiBjbGFzcz0iIj5odHRwczovL3Ry YWMuaWV0Zi5vcmcvdHJhYy9zbGltL21pbGVzdG9uZS9taWxlc3RvbmUxPC9hPiZndDttaWxlc3Rv bmUxZGVmZWN0Jmx0O21haWx0bzpyZyU8YSBocmVmPSJtYWlsdG86MkJpZXRmQHJhbmR5LnBlbnNp dmUub3JnIiBjbGFzcz0iIj4yQmlldGZAcmFuZHkucGVuc2l2ZS5vcmc8L2E+Jmd0OzxhIGhyZWY9 Im1haWx0bzpyZyYjNDM7aWV0ZkByYW5keS5wZW5zaXZlLm9yZ2Fzc2lnbmVkTWFyIiBjbGFzcz0i Ij5yZyYjNDM7aWV0ZkByYW5keS5wZW5zaXZlLm9yZ2Fzc2lnbmVkTWFyPC9hPg0KIDIyLCAyMDE3 Jmx0OzxhIGhyZWY9Imh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL3NsaW0vdGlja2V0LzM1IiBj bGFzcz0iIj5odHRwczovL3RyYWMuaWV0Zi5vcmcvdHJhYy9zbGltL3RpY2tldC8zNTwvYT4mZ3Q7 IzM1Jmx0OzxhIGhyZWY9Imh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL3NsaW0vdGlja2V0LzM1 IiBjbGFzcz0iIj5odHRwczovL3RyYWMuaWV0Zi5vcmcvdHJhYy9zbGltL3RpY2tldC8zNTwvYT4m Z3Q7SGF2ZSBhbiBhdHRyaWJ1dGUgdG8gYWJicmV2aWF0ZQ0KIHRoZSBiaWRpcmVjdGlvbmFsbHkt c3ltbWV0cmljIGNhc2VuZWdvdGlhdGluZy1odW1hbi1sYW5ndWFnZTIuMCZsdDs8YSBocmVmPSJo dHRwczovL3RyYWMuaWV0Zi5vcmcvdHJhYy9zbGltL21pbGVzdG9uZS9taWxlc3RvbmUxIiBjbGFz cz0iIj5odHRwczovL3RyYWMuaWV0Zi5vcmcvdHJhYy9zbGltL21pbGVzdG9uZS9taWxlc3RvbmUx PC9hPiZndDttaWxlc3RvbmUxZGVmZWN0Jmx0O21haWx0bzpyZyU8YSBocmVmPSJtYWlsdG86MkJp ZXRmQHJhbmR5LnBlbnNpdmUub3JnIiBjbGFzcz0iIj4yQmlldGZAcmFuZHkucGVuc2l2ZS5vcmc8 L2E+Jmd0OzxhIGhyZWY9Im1haWx0bzpyZyYjNDM7aWV0ZkByYW5keS5wZW5zaXZlLm9yZ2Fzc2ln bmVkTWFyIiBjbGFzcz0iIj5yZyYjNDM7aWV0ZkByYW5keS5wZW5zaXZlLm9yZ2Fzc2lnbmVkTWFy PC9hPg0KIDIyLCAyMDE3Jmx0OzxhIGhyZWY9Imh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL3Ns aW0vdGlja2V0LzM4IiBjbGFzcz0iIj5odHRwczovL3RyYWMuaWV0Zi5vcmcvdHJhYy9zbGltL3Rp Y2tldC8zODwvYT4mZ3Q7IzM4Jmx0OzxhIGhyZWY9Imh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFj L3NsaW0vdGlja2V0LzM4IiBjbGFzcz0iIj5odHRwczovL3RyYWMuaWV0Zi5vcmcvdHJhYy9zbGlt L3RpY2tldC8zODwvYT4mZ3Q7Um91dGluZyBvdXQgb2Ygc2NvcGVuZWdvdGlhdGluZy1odW1hbi1s YW5ndWFnZTEuMCZsdDs8YSBocmVmPSJodHRwczovL3RyYWMuaWV0Zi5vcmcvdHJhYy9zbGltL21p bGVzdG9uZS9taWxlc3RvbmUxIiBjbGFzcz0iIj5odHRwczovL3RyYWMuaWV0Zi5vcmcvdHJhYy9z bGltL21pbGVzdG9uZS9taWxlc3RvbmUxPC9hPiZndDttaWxlc3RvbmUxZGVmZWN0Jmx0OzxhIGhy ZWY9Im1haWx0bzpkcmFmdC1pZXRmLXNsaW0tbmVnb3RpYXRpbmctaHVtYW4tbGFuZ3VhZ2VAaWV0 Zi5vcmciIGNsYXNzPSIiPm1haWx0bzpkcmFmdC1pZXRmLXNsaW0tbmVnb3RpYXRpbmctaHVtYW4t bGFuZ3VhZ2VAaWV0Zi5vcmc8L2E+Jmd0OzxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLXNsaW0t bmVnb3RpYXRpbmctaHVtYW4tbGFuZ3VhZ2VAaWV0Zi5vcmduZXdBcHIiIGNsYXNzPSIiPmRyYWZ0 LWlldGYtc2xpbS1uZWdvdGlhdGluZy1odW1hbi1sYW5ndWFnZUBpZXRmLm9yZ25ld0FwcjwvYT4N CiAyNSwgMjAxNyZsdDs8YSBocmVmPSJodHRwczovL3RyYWMuaWV0Zi5vcmcvdHJhYy9zbGltL3Rp Y2tldC8zOSIgY2xhc3M9IiI+aHR0cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvc2xpbS90aWNrZXQv Mzk8L2E+Jmd0OyMzOSZsdDs8YSBocmVmPSJodHRwczovL3RyYWMuaWV0Zi5vcmcvdHJhYy9zbGlt L3RpY2tldC8zOSIgY2xhc3M9IiI+aHR0cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvc2xpbS90aWNr ZXQvMzk8L2E+Jmd0O1N5bnRheCBDb2xsYXBzZW5lZ290aWF0aW5nLWh1bWFuLWxhbmd1YWdlMS4w Jmx0OzxhIGhyZWY9Imh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL3NsaW0vbWlsZXN0b25lL21p bGVzdG9uZTEiIGNsYXNzPSIiPmh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL3NsaW0vbWlsZXN0 b25lL21pbGVzdG9uZTE8L2E+Jmd0O21pbGVzdG9uZTFkZWZlY3QmbHQ7PGEgaHJlZj0ibWFpbHRv OmRyYWZ0LWlldGYtc2xpbS1uZWdvdGlhdGluZy1odW1hbi1sYW5ndWFnZUBpZXRmLm9yZyIgY2xh c3M9IiI+bWFpbHRvOmRyYWZ0LWlldGYtc2xpbS1uZWdvdGlhdGluZy1odW1hbi1sYW5ndWFnZUBp ZXRmLm9yZzwvYT4mZ3Q7PGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtc2xpbS1uZWdvdGlhdGlu Zy1odW1hbi1sYW5ndWFnZUBpZXRmLm9yZ25ld0FwciIgY2xhc3M9IiI+ZHJhZnQtaWV0Zi1zbGlt LW5lZ290aWF0aW5nLWh1bWFuLWxhbmd1YWdlQGlldGYub3JnbmV3QXByPC9hPg0KIDI1LCAyMDE3 Jmx0OzxhIGhyZWY9Imh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL3NsaW0vdGlja2V0LzI2IiBj bGFzcz0iIj5odHRwczovL3RyYWMuaWV0Zi5vcmcvdHJhYy9zbGltL3RpY2tldC8yNjwvYT4mZ3Q7 IzI2Jmx0OzxhIGhyZWY9Imh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL3NsaW0vdGlja2V0LzI2 IiBjbGFzcz0iIj5odHRwczovL3RyYWMuaWV0Zi5vcmcvdHJhYy9zbGltL3RpY2tldC8yNjwvYT4m Z3Q7TWFrZSB1c2Ugb2YgdGhlIGFzdGVyaXNrIG1vZGlmaWVyDQogb24gbWVkaWEgbGV2ZWwgd2l0 aCBzZXNzaW9uIHNjb3BlIGFsc28gZm9yIG1lZGlhIGxldmVsIHB1cnBvc2VzbmVnb3RpYXRpbmct aHVtYW4tbGFuZ3VhZ2UyLjAmbHQ7PGEgaHJlZj0iaHR0cHM6Ly90cmFjLmlldGYub3JnL3RyYWMv c2xpbS9taWxlc3RvbmUvbWlsZXN0b25lMSIgY2xhc3M9IiI+aHR0cHM6Ly90cmFjLmlldGYub3Jn L3RyYWMvc2xpbS9taWxlc3RvbmUvbWlsZXN0b25lMTwvYT4mZ3Q7bWlsZXN0b25lMWVuaGFuY2Vt ZW50Jmx0OzxhIGhyZWY9Im1haWx0bzpndW5uYXIuaGVsbHN0cm9tQG9tbml0b3Iuc2UiIGNsYXNz PSIiPm1haWx0bzpndW5uYXIuaGVsbHN0cm9tQG9tbml0b3Iuc2U8L2E+Jmd0OzxhIGhyZWY9Im1h aWx0bzpndW5uYXIuaGVsbHN0cm9tQG9tbml0b3Iuc2VuZXdNYXIiIGNsYXNzPSIiPmd1bm5hci5o ZWxsc3Ryb21Ab21uaXRvci5zZW5ld01hcjwvYT4NCiAyMiwgMjAxNyZsdDs8YSBocmVmPSJodHRw czovL3RyYWMuaWV0Zi5vcmcvdHJhYy9zbGltL3RpY2tldC8yOSIgY2xhc3M9IiI+aHR0cHM6Ly90 cmFjLmlldGYub3JnL3RyYWMvc2xpbS90aWNrZXQvMjk8L2E+Jmd0OyMyOSZsdDs8YSBocmVmPSJo dHRwczovL3RyYWMuaWV0Zi5vcmcvdHJhYy9zbGltL3RpY2tldC8yOSIgY2xhc3M9IiI+aHR0cHM6 Ly90cmFjLmlldGYub3JnL3RyYWMvc2xpbS90aWNrZXQvMjk8L2E+Jmd0O0luY2x1ZGUgbW9yZSBm aWVsZHMgZm9yIGF0dHJpYnV0ZQ0KIHJlZ2lzdHJhdGlvbiBmcm9tIDQ1NjZiaXM8YnIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQombmJzcDtfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxiciBjbGFzcz0iIj4NCiZuYnNwO1NMSU0gbWFpbGluZyBsaXN0PGJy IGNsYXNzPSIiPg0KJm5ic3A7PGEgaHJlZj0ibWFpbHRvOlNMSU1AaWV0Zi5vcmciIGNsYXNzPSIi PlNMSU1AaWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zbGltIiBjbGFzcz0iIj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NsaW08L2E+PGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1 b3RlPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNs YXNzPSIiPg0KLS08YnIgY2xhc3M9IiI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLTxiciBjbGFzcz0iIj4NCkd1bm5hciBIZWxsc3Ryw7ZtPGJyIGNsYXNzPSIiPg0K T21uaXRvcjxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Im1haWx0bzpndW5uYXIuaGVsbHN0cm9tQG9t bml0b3Iuc2UiIGNsYXNzPSIiPmd1bm5hci5oZWxsc3Ryb21Ab21uaXRvci5zZTwvYT48YnIgY2xh c3M9IiI+DQomIzQzOzQ2IDcwOCAyMDQgMjg4PGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0K PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KLS0gPGJyIGNsYXNzPSIiPg0KUmFuZGFsbCBH ZWxsZW5zPGJyIGNsYXNzPSIiPg0KT3BpbmlvbnMgYXJlIHBlcnNvbmFsOyAmbmJzcDsmbmJzcDsm bmJzcDtmYWN0cyBhcmUgc3VzcGVjdDsgJm5ic3A7Jm5ic3A7Jm5ic3A7SSBzcGVhayBmb3IgbXlz ZWxmIG9ubHk8YnIgY2xhc3M9IiI+DQotLS0tLS0tLS0tLS0tLSBSYW5kb21seSBzZWxlY3RlZCB0 YWc6IC0tLS0tLS0tLS0tLS0tLTxiciBjbGFzcz0iIj4NCkkgZG8gbm90IG5lZWQgdG8gZXhwbGFp biB3aHkgSSBzYXkgdGhpbmdzLiAmbmJzcDtUaGF0J3MgdGhlIGludGVyZXN0aW5nIHRoaW5nPGJy IGNsYXNzPSIiPg0KYWJvdXQgYmVpbmcgdGhlIFByZXNpZGVudC4gJm5ic3A7TWF5YmUgc29tZWJv ZHkgbmVlZHMgdG8gZXhwbGFpbiB0byBtZSB3aHk8YnIgY2xhc3M9IiI+DQp0aGV5IHNheSBzb21l dGhpbmcsIGJ1dCBJIGRvbid0IGZlZWwgbGlrZSBJIG93ZSBhbnlib2R5IGFuIGV4cGxhbmF0aW9u LjxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOy0tR2VvcmdlIFcuIEJ1c2gsIGluIGFuIGludGVydmlldyB3aXRo IEJvYiBXb29kd2FyZC48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxiciBjbGFzcz0iIj4NClNMSU0gbWFp bGluZyBsaXN0PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0ibWFpbHRvOlNMSU1AaWV0Zi5vcmciIGNs YXNzPSIiPlNMSU1AaWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9zbGltPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8cCBzdHlsZT0iZm9u dC1mYW1pbHk6IEFyaWFsLHNhbnMtc2VyaWY7Zm9udC1zaXplOjExcHg7Y29sb3I6Izk5OTk5OTsi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLHNhbnMtc2VyaWY7 Y29sb3I6Izk5OTk5OTsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IEFyaWFsOyBtc28tZmFyZWFz dC10aGVtZS1mb250OiBtaW5vci1sYXRpbjsgbXNvLWJpZGktZm9udC1mYW1pbHk6ICZxdW90O0Fy aWFsJnF1b3Q7OyBtc28tYW5zaS1sYW5ndWFnZTogRU4tVVM7IG1zby1mYXJlYXN0LWxhbmd1YWdl OiBFTi1HQjsgbXNvLWJpZGktbGFuZ3VhZ2U6IEFSLVNBIj5UaGlzDQogZW1haWwgYW5kIGl0cyBh dHRhY2htZW50cyBhcmUgaW50ZW5kZWQgZm9yIHRoZSBhYm92ZSBuYW1lZCBvbmx5IGFuZCBtYXkg YmUgY29uZmlkZW50aWFsLiBJZiB0aGV5IGhhdmUgY29tZSB0byB5b3UgaW4gZXJyb3IgeW91IG11 c3QgdGFrZSBubyBhY3Rpb24gYmFzZWQgb24gdGhlbSwgbm9yIG11c3QgeW91IGNvcHkgb3Igc2hv dyB0aGVtIHRvIGFueW9uZTsgcGxlYXNlIHJlcGx5IHRvIHRoaXMgZW1haWwgb3IgY2FsbCAmIzQz OzQ0IDIwNyAzNTYgMDYwMA0KIGFuZCBoaWdobGlnaHQgdGhlIGVycm9yLiA8L3NwYW4+PC9wPg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_DD8DA8BD65E64825B928CCC06BAFC8A2gsmacom_-- From nobody Thu Jun 1 02:54:27 2017 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 75BEF127867 for ; Thu, 1 Jun 2017 02:54:26 -0700 (PDT) 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 fuugojmZSV7X for ; Thu, 1 Jun 2017 02:54:24 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30052.outbound.protection.outlook.com [40.107.3.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78269126DED for ; Thu, 1 Jun 2017 02:54:23 -0700 (PDT) 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=0XVVTha/pmHEPp6viJZltj/bZ8xV0YB0lJHUQv/hrQ0=; b=GIkMl/ReM2OYmJ9yp1if3QMBWDOoTmU6nJiQHCYVV8ijG3ffCsO7p7euXPwBsTvSagzz9/hDTwX2ihtDZzEIJqiSf07qyCtiQUpQcpZx1LZKpzjQntd81zgkOGBQDY7PP9/a21pE4aokkRmMQ7M6hoN7ZQNVNZ68TAWR2aJ6lwQ= Received: from AM2PR04MB0802.eurprd04.prod.outlook.com (10.160.56.28) by AM2PR04MB0803.eurprd04.prod.outlook.com (10.160.57.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1124.9; Thu, 1 Jun 2017 09:54:21 +0000 Received: from AM2PR04MB0802.eurprd04.prod.outlook.com ([fe80::250d:5ecf:c7fd:d3b1]) by AM2PR04MB0802.eurprd04.prod.outlook.com ([fe80::250d:5ecf:c7fd:d3b1%15]) with mapi id 15.01.1124.020; Thu, 1 Jun 2017 09:54:21 +0000 From: Natasha Rooney To: Randall Gellens CC: "slim@ietf.org" Thread-Topic: [Slim] Collapse attribute syntax to one line in draft-ietf-slim-negotiating-human-language Thread-Index: AQHS1/5CHXUAGwNU9U+Ma8BGS6i4S6IL79sAgAPaOgA= Date: Thu, 1 Jun 2017 09:54:21 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) 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-originating-ip: [62.189.0.100] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM2PR04MB0803; 7:DJRoWKLPvFZH8kFrLz1E3fe45h+hocrnb47YJfCzv0EB2Cox24w/jzvwd/5xrTf2l10bL9Go0cbUt2qAsqXkJV3axhq8KNDeIyKR+PiS7MLb8ByhrNpbDPEwXPiIupOXokeYpyGkyYWyvRziKN/oVhdiY11QN0fXLch/TiBCyAvNeWziQuJtH4Z514DnRfYE7AxWKAFP1Ex5fmH19P6qpfzNt1sH2Bv271mPO4Z5SwdhLY4kfkcnyVz/rQoo2/FH7TVQZbPrAsWcsddA8ns6rb9SWLK8gUmR3Egffk6FkuRuNRW1icJre2l2eKpy2mgXww6qo5/4u+QX3+pu2cEsEA== x-ms-traffictypediagnostic: AM2PR04MB0803: x-ms-office365-filtering-correlation-id: 59b0bb7c-dbcf-4159-7d28-08d4a8d42d5d x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:AM2PR04MB0803; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(10201501046)(6041248)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123555025)(20161123564025)(20161123562025)(6072148); SRVR:AM2PR04MB0803; BCL:0; PCL:0; RULEID:; SRVR:AM2PR04MB0803; x-forefront-prvs: 0325F6C77B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39850400002)(39400400002)(39450400003)(39410400002)(39840400002)(24454002)(377454003)(82746002)(50986999)(7906003)(7736002)(66066001)(478600001)(236005)(6512007)(54896002)(6306002)(6436002)(606005)(5890100001)(6506006)(83716003)(86362001)(5250100002)(14454004)(76176999)(99286003)(38730400002)(966005)(2950100002)(5660300001)(110136004)(6486002)(57306001)(53936002)(36756003)(229853002)(2906002)(3660700001)(3280700002)(8676002)(81166006)(8936002)(50226002)(189998001)(6246003)(53546009)(2900100001)(25786009)(33656002)(4326008)(230783001)(6116002)(3846002)(102836003); DIR:OUT; SFP:1101; SCL:1; SRVR:AM2PR04MB0803; H:AM2PR04MB0802.eurprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_B8657F32BB2240FE8D096EB3EC4408D9gsmacom_" MIME-Version: 1.0 X-OriginatorOrg: gsma.com X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jun 2017 09:54:21.2154 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72a4ff82-fec3-469d-aafb-ac8276216699 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR04MB0803 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: AM2PR04MB0802.eurprd04.prod.outlook.com X-MS-Exchange-CrossPremises-TransportTrafficType: Email X-MS-Exchange-CrossPremises-TransportTrafficSubType: X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-originalclientipaddress: 62.189.0.100 X-MS-Exchange-CrossPremises-transporttraffictype: Email X-MS-Exchange-CrossPremises-transporttrafficsubtype: 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: AM2PR04MB0803.eurprd04.prod.outlook.com Archived-At: Subject: Re: [Slim] Collapse attribute syntax to one line 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, 01 Jun 2017 09:54:26 -0000 --_000_B8657F32BB2240FE8D096EB3EC4408D9gsmacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhpcyBzZWVtcyBzdWZmaWNpZW50IGdpdmVuIG91ciBwcmV2aW91cyBjb252ZXJzYXRpb25zLiBx LXZhbHVlcyBjYW4gYmUgYXBwbGllZCB3aXRoaW4gZnVydGhlciB3b3JrIChhbHRob3VnaCBJIGRv buKAmXQgc2VlIHdoeSBvcmRlcmluZyBkb2VzbuKAmXQgZG8gdGhlIGpvYiwgd29ya3MgaW4gd2Vi KS4NCg0KQmVybmFyZCAtIGFueSBmdXJ0aGVyIHRob3VnaHRzPw0KDQpOYXRhc2hhIFJvb25leSB8 IEludGVybmV0IEVuZ2luZWVyaW5nIERpcmVjdG9yIHwgSW50ZXJuZXQgYW5kIFdlYiBUZWFtIHwg VGVjaG5vbG9neSB8IEdTTUEgfCBucm9vbmV5QGdzbWEuY29tPG1haWx0bzpucm9vbmV5QGdzbWEu Y29tPiB8ICs0NCAoMCkgNzczMCAyMTkgNzY1IHwgQHRoaXNOYXRhc2hhIHwgU2t5cGU6IG5yb29u ZXlAZ3NtLm9yZzxtYWlsdG86bnJvb25leUBnc20ub3JnPg0KDQpPbiAzMCBNYXkgMjAxNywgYXQg MDA6MDQsIFJhbmRhbGwgR2VsbGVucyA8cmcraWV0ZkByYW5keS5wZW5zaXZlLm9yZzxtYWlsdG86 cmcraWV0ZkByYW5keS5wZW5zaXZlLm9yZz4+IHdyb3RlOg0KDQpJIHVwbG9hZGVkIHZlcnNpb24g LTEwLCB3aGljaCBpbmNsdWRlcyB0aGUgc3ludGF4IGNoYW5nZSB0byBzaW5nbGUgbGluZSwgYWxv bmcgd2l0aCBhIGZldyBlZGl0b3JpYWwgY2xhcmlmaWNhdGlvbnMuICAoVmVyc2lvbiAtMDkgYWNj aWRlbnRseSBvbWl0dGVkIGFuIGVkaXRvcmlhbCBjbGFyaWZpY2F0aW9uLikNCg0KWW91IGNhbiBz ZWUgYSBkaWZmIG9mIHRoZSBjaGFuZ2VzIGZyb20gMDggdG8gMTAgaGVyZToNCmh0dHBzOi8vd3d3 LmlldGYub3JnL3JmY2RpZmY/dXJsMT1kcmFmdC1pZXRmLXNsaW0tbmVnb3RpYXRpbmctaHVtYW4t bGFuZ3VhZ2UtMDgmdXJsMj1kcmFmdC1pZXRmLXNsaW0tbmVnb3RpYXRpbmctaHVtYW4tbGFuZ3Vh Z2UtMTANCg0KSWYgdGhlcmUgb2JqZWN0aW9ucyB0byB0aGUgY2hhbmdlIGZyb20gbXVsdGktbGlu ZSB0byBzaW5nbGUtbGluZSwgdGhpcyBjYW4gYmUgcmV2ZXJ0ZWQuDQoNCi0tUmFuZHkNCg0KDQoN CkF0IDI6NTcgUE0gLTA3MDAgNS8yOC8xNywgUmFuZGFsbCBHZWxsZW5zIHdyb3RlOg0KDQpJbiBy ZXNwb25zZSB0byBBZGFtIFJvYWNoJ3MgY29tbWVudHMgYXMgd2VsbCBhcyBvdGhlciBjb21tZW50 cywgSSBpbnRlbmQgdG8gdXBkYXRlIHRoZSBkcmFmdCB0byBjb2xsYXBzZSB0aGUgYXR0cmlidXRl IHN5bnRheCB0byBvbmUgbGluZTsgZWFjaCBhdHRyaWJ1dGUgY2FuIG9jY3VyIGF0IG1vc3Qgb25j ZSBwZXIgbWVkaWEsIHdpdGggYWxsIGxhbmd1YWdlcyBvbiB0aGUgc2FtZSBsaW5lLiAgVGhpcyB3 aWxsIGZ1cnRoZXIgcmVkdWNlIHRoZSBzaXplIG9mIHRoZSBTRFAgYmxvY2suDQoNCklmIHlvdSBv YmplY3QgdG8gdGhpcywgcGxlYXNlIHJlcGx5Lg0KDQpIZXJlIGlzIHRoZSBzZWN0aW9uIG9mIEFk YW0ncyByZXZpZXc6DQoNCkF0IDg6MzEgUE0gKzAwMDAgMy8yOC8xNywgU2FicmluYSBUYW5hbWFs IHZpYSBSVCB3cm90ZToNCiBJJ2xsIG5vdGUgdGhhdCBtdWNoIG9mIHRoaXMgY2FuIGJlIGZpeGVk IGlmIHRoZSBzeW50YXggaXMgY29sbGFwc2VkIHNvDQogdGhhdCBlYWNoIG1lZGlhIHNlY3Rpb24g Y2FuIGhhdmUgYXQgbW9zdCBvbmUgaGxhbmctc2VuZCBhbmQgb25lDQogaGxhbmctcmVjZWl2ZSwg ZWFjaCBvZiB3aGljaCBjb250YWluIGEgbGlzdCBvZiBvbmUgb3IgbW9yZSBsYW5ndWFnZXMNCiB0 aGF0IGNhbiBiZSBzZW50IG9yIHJlY2VpdmVkLiBUaGlzIGlzIGFsc28gbXVjaCBtb3JlIGNvbnNp c3RlbnQgd2l0aCB0aGUNCiB3YXkgU0RQIGF0dHJpYnV0ZXMgYXJlIHVzZWQgaW4gZ2VuZXJhbC4g VGhlIHByZXNlbmNlIG9mIGEgIioiIHRva2VuIG9uDQogdGhhdCBsaW5lIHdvdWxkIGluZGljYXRl IHRoZSAiY2FsbCBzaG91bGQgaGFwcGVuIGV2ZW4gd2l0aG91dCBtYXRjaGluZw0KIGxhbmd1YWdl cyIgY2hhcmFjdGVyaXN0aWM7IHNpbmNlIHRoZXJlIGlzIG9ubHkgb25lIHBsYWNlIHRvIGFkZCB0 aGlzDQogaW5kaWNhdG9yLCB0aGUgYW1iaWd1aXR5IG9mIHNvbWUgbGluZXMgaW5kaWNhdGluZyBp dCBhbmQgb3RoZXJzIG5vdA0KIGRpc2FwcGVhcnMuIFRoZSBwcmVjZWRpbmcgZXhhbXBsZSB3b3Vs ZCBjb2xsYXBzZSB0bzoNCg0KIG09YXVkaW8gNDkyNTAgUlRQL0FWUCAyMA0KIGE9aGxhbmctc2Vu ZDplcyBldSBlbiAqDQogYT1obGFuZy1yZWN2OmVzIGV1IGVuICoNCg0KIC4uLmFuZCB0aGUgZXhh bXBsZSB0ZXh0IHdvdWxkIGJlIHJldmlzZWQgdG8gcmVtb3ZlIHRoZSBpbXBsaWNhdGlvbiB0aGF0 DQogKnNlbmRpbmcqICJlcyIgbmVjZXNzYXJpbHkgaW1wbGllcyAqcmVjZWl2aW5nKiAiZXMiLg0K DQogSSdsbCBmdXJ0aGVyIG5vdGUgdGhhdCB0aGUgbWFqb3JpdHkgb2YgU0RQIGxpYnJhcmllcyBJ J3ZlIHdvcmtlZCB3aXRoDQogd291bGQgbWFrZSBhY2Nlc3NpbmcgdGhlIGFsbC1vbi1vbmUtbGlu ZSBmb3JtYXQgZWFzaWVyIHRoYW4NCiBvbmUtbGluZS1wZXItbGFuZ3VhZ2UgYXMgd2VsbC4NCg0K SGVyZSBpcyB0aGUgcHJvcG9zZWQgQUJORjoNCg0KICAgQXR0cmlidXRlIFN5bnRheDoNCg0KICAg ICAgaGxhbmctdmFsdWUgPSAgTGFuZ3VhZ2UtVGFnICooIFNQIExhbmd1YWdlLXRhZyApIFsgU1Ag YXN0ZXJpc2sgXQ0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICA7IExhbmd1YWdlLVRhZyBh cyBkZWZpbmVkIGluIEJDUCA0Nw0KDQogICAgICBhc3RlcmlzayAgICA9ICAiKiIgICA7IGFuIGFz dGVyaXNrIChBU0NJSSAlMkEpIGNoYXJhY3Rlcg0KDQogICAgICBzcCAgICAgICAgICA9ICAxKiIg IiA7IG9uZSBvciBtb3JlIEFTQ0lJIHNwYWNlICglMjApIGNoYXJhY3RlcnMNCg0KLS0NClJhbmRh bGwgR2VsbGVucw0KT3BpbmlvbnMgYXJlIHBlcnNvbmFsOyAgICBmYWN0cyBhcmUgc3VzcGVjdDsg ICAgSSBzcGVhayBmb3IgbXlzZWxmIG9ubHkNCi0tLS0tLS0tLS0tLS0tIFJhbmRvbWx5IHNlbGVj dGVkIHRhZzogLS0tLS0tLS0tLS0tLS0tDQpJZiBmb3JjZWQgdG8gdHJhdmVsIG9uIGFuIGFpcnBs YW5lLCB0cnkgYW5kIGdldCBpbiB0aGUgY2FiaW4gd2l0aA0KdGhlIENhcHRhaW4sIHNvIHlvdSBj YW4ga2VlcCBhbiBleWUgb24gaGltIGFuZCBudWRnZSBoaW0gaWYgaGUNCmZhbGxzIGFzbGVlcCBv ciBwb2ludCBvdXQgYW55IG1vdW50YWlucyBsb29taW5nIHVwIGFoZWFkIC4uLg0KICAgICAgIC0t TWlrZSBIYXJkaW5nLCBUaGUgQXJtY2hhaXIgQW5hcmNoaXN0J3MgQWxtYW5hYy4NCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClNMSU0gbWFpbGluZyBs aXN0DQpTTElNQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NsaW0NCg0KDQotLQ0KUmFuZGFsbCBHZWxsZW5zDQpPcGluaW9ucyBhcmUgcGVyc29uYWw7ICAg IGZhY3RzIGFyZSBzdXNwZWN0OyAgICBJIHNwZWFrIGZvciBteXNlbGYgb25seQ0KLS0tLS0tLS0t LS0tLS0gUmFuZG9tbHkgc2VsZWN0ZWQgdGFnOiAtLS0tLS0tLS0tLS0tLS0NCktub3dsZWRnZSBh bHdheXMgZGVzaXJlcyBpbmNyZWFzZTsgaXQgaXMgbGlrZSBmaXJlLCB3aGljaCBtdXN0DQpmaXJz dCBiZSBraW5kbGVkIGJ5IHNvbWUgZXh0ZXJuYWwgYWdlbnQsIGJ1dCB3aGljaCB3aWxsIGFmdGVy d2FyZHMNCnByb3BhZ2F0ZSBpdHNlbGYuICAgICAgICAgICAgICAgICAgICAgICAtLURyLiBTYW11 ZWwgSm9obnNvbg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KU0xJTSBtYWlsaW5nIGxpc3QNClNMSU1AaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vc2xpbQ0KDQoNClRoaXMgZW1haWwgYW5kIGl0cyBhdHRhY2ht ZW50cyBhcmUgaW50ZW5kZWQgZm9yIHRoZSBhYm92ZSBuYW1lZCBvbmx5IGFuZCBtYXkgYmUgY29u ZmlkZW50aWFsLiBJZiB0aGV5IGhhdmUgY29tZSB0byB5b3UgaW4gZXJyb3IgeW91IG11c3QgdGFr ZSBubyBhY3Rpb24gYmFzZWQgb24gdGhlbSwgbm9yIG11c3QgeW91IGNvcHkgb3Igc2hvdyB0aGVt IHRvIGFueW9uZTsgcGxlYXNlIHJlcGx5IHRvIHRoaXMgZW1haWwgb3IgY2FsbCArNDQgMjA3IDM1 NiAwNjAwIGFuZCBoaWdobGlnaHQgdGhlIGVycm9yLg0K --_000_B8657F32BB2240FE8D096EB3EC4408D9gsmacom_ Content-Type: text/html; charset="utf-8" Content-ID: <7848A087AFF5B7469F75A740F0EC678A@eurprd04.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KVGhpcyBzZWVtcyBzdWZmaWNpZW50 IGdpdmVuIG91ciBwcmV2aW91cyBjb252ZXJzYXRpb25zLiBxLXZhbHVlcyBjYW4gYmUgYXBwbGll ZCB3aXRoaW4gZnVydGhlciB3b3JrIChhbHRob3VnaCBJIGRvbuKAmXQgc2VlIHdoeSBvcmRlcmlu ZyBkb2VzbuKAmXQgZG8gdGhlIGpvYiwgd29ya3MgaW4gd2ViKS4NCjxkaXYgY2xhc3M9IiI+PGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkJlcm5hcmQgLSBhbnkgZnVydGhlciB0 aG91Z2h0cz88YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0iY29sb3I6 IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBm b250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0 OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxp Z246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUt c3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10 ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7Ij4N CjxiciBjbGFzcz0iIj4NCk5hdGFzaGEgUm9vbmV5IHwgSW50ZXJuZXQgRW5naW5lZXJpbmcmbmJz cDtEaXJlY3RvciB8IEludGVybmV0IGFuZCBXZWIgVGVhbSB8Jm5ic3A7VGVjaG5vbG9neSB8IEdT TUEgfCZuYnNwOzxhIGhyZWY9Im1haWx0bzpucm9vbmV5QGdzbWEuY29tIiBjbGFzcz0iIj5ucm9v bmV5QGdzbWEuY29tPC9hPiZuYnNwO3wgJiM0Mzs0NCAoMCkgNzczMCAyMTkmbmJzcDs3NjUgfCBA dGhpc05hdGFzaGEgfCBTa3lwZTombmJzcDs8YSBocmVmPSJtYWlsdG86bnJvb25leUBnc20ub3Jn IiBjbGFzcz0iIj5ucm9vbmV5QGdzbS5vcmc8L2E+PC9kaXY+DQo8L2Rpdj4NCjxiciBjbGFzcz0i Ij4NCjxkaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9 IiI+T24gMzAgTWF5IDIwMTcsIGF0IDAwOjA0LCBSYW5kYWxsIEdlbGxlbnMgJmx0OzxhIGhyZWY9 Im1haWx0bzpyZyYjNDM7aWV0ZkByYW5keS5wZW5zaXZlLm9yZyIgY2xhc3M9IiI+cmcmIzQzO2ll dGZAcmFuZHkucGVuc2l2ZS5vcmc8L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBw bGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5J IHVwbG9hZGVkIHZlcnNpb24gLTEwLCB3aGljaCBpbmNsdWRlcyB0aGUgc3ludGF4IGNoYW5nZSB0 byBzaW5nbGUgbGluZSwgYWxvbmcgd2l0aCBhIGZldyBlZGl0b3JpYWwgY2xhcmlmaWNhdGlvbnMu ICZuYnNwOyhWZXJzaW9uIC0wOSBhY2NpZGVudGx5IG9taXR0ZWQgYW4gZWRpdG9yaWFsIGNsYXJp ZmljYXRpb24uKTxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCllvdSBjYW4gc2VlIGEgZGlm ZiBvZiB0aGUgY2hhbmdlcyBmcm9tIDA4IHRvIDEwIGhlcmU6PGJyIGNsYXNzPSIiPg0KPGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwxPWRyYWZ0LWlldGYtc2xpbS1uZWdv dGlhdGluZy1odW1hbi1sYW5ndWFnZS0wOCZhbXA7dXJsMj1kcmFmdC1pZXRmLXNsaW0tbmVnb3Rp YXRpbmctaHVtYW4tbGFuZ3VhZ2UtMTAiIGNsYXNzPSIiPmh0dHBzOi8vd3d3LmlldGYub3JnL3Jm Y2RpZmY/dXJsMT1kcmFmdC1pZXRmLXNsaW0tbmVnb3RpYXRpbmctaHVtYW4tbGFuZ3VhZ2UtMDgm YW1wO3VybDI9ZHJhZnQtaWV0Zi1zbGltLW5lZ290aWF0aW5nLWh1bWFuLWxhbmd1YWdlLTEwPC9h PjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCklmIHRoZXJlIG9iamVjdGlvbnMgdG8gdGhl IGNoYW5nZSBmcm9tIG11bHRpLWxpbmUgdG8gc2luZ2xlLWxpbmUsIHRoaXMgY2FuIGJlIHJldmVy dGVkLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCi0tUmFuZHk8YnIgY2xhc3M9IiI+DQo8 YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpBdCAyOjU3IFBNIC0w NzAwIDUvMjgvMTcsIFJhbmRhbGwgR2VsbGVucyB3cm90ZTo8YnIgY2xhc3M9IiI+DQo8YnIgY2xh c3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5JbiByZXNwb25zZSB0byBB ZGFtIFJvYWNoJ3MgY29tbWVudHMgYXMgd2VsbCBhcyBvdGhlciBjb21tZW50cywgSSBpbnRlbmQg dG8gdXBkYXRlIHRoZSBkcmFmdCB0byBjb2xsYXBzZSB0aGUgYXR0cmlidXRlIHN5bnRheCB0byBv bmUgbGluZTsgZWFjaCBhdHRyaWJ1dGUgY2FuIG9jY3VyIGF0IG1vc3Qgb25jZSBwZXIgbWVkaWEs IHdpdGggYWxsIGxhbmd1YWdlcyBvbiB0aGUgc2FtZSBsaW5lLg0KICZuYnNwO1RoaXMgd2lsbCBm dXJ0aGVyIHJlZHVjZSB0aGUgc2l6ZSBvZiB0aGUgU0RQIGJsb2NrLjxiciBjbGFzcz0iIj4NCjxi ciBjbGFzcz0iIj4NCklmIHlvdSBvYmplY3QgdG8gdGhpcywgcGxlYXNlIHJlcGx5LjxiciBjbGFz cz0iIj4NCjxiciBjbGFzcz0iIj4NCkhlcmUgaXMgdGhlIHNlY3Rpb24gb2YgQWRhbSdzIHJldmll dzo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpBdCA4OjMxIFBNICYjNDM7MDAwMCAzLzI4 LzE3LCBTYWJyaW5hIFRhbmFtYWwgdmlhIFJUIHdyb3RlOjxiciBjbGFzcz0iIj4NCjxibG9ja3F1 b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPiZuYnNwO0knbGwgbm90ZSB0aGF0IG11Y2ggb2YgdGhp cyBjYW4gYmUgZml4ZWQgaWYgdGhlIHN5bnRheCBpcyBjb2xsYXBzZWQgc288YnIgY2xhc3M9IiI+ DQombmJzcDt0aGF0IGVhY2ggbWVkaWEgc2VjdGlvbiBjYW4gaGF2ZSBhdCBtb3N0IG9uZSBobGFu Zy1zZW5kIGFuZCBvbmU8YnIgY2xhc3M9IiI+DQombmJzcDtobGFuZy1yZWNlaXZlLCBlYWNoIG9m IHdoaWNoIGNvbnRhaW4gYSBsaXN0IG9mIG9uZSBvciBtb3JlIGxhbmd1YWdlczxiciBjbGFzcz0i Ij4NCiZuYnNwO3RoYXQgY2FuIGJlIHNlbnQgb3IgcmVjZWl2ZWQuIFRoaXMgaXMgYWxzbyBtdWNo IG1vcmUgY29uc2lzdGVudCB3aXRoIHRoZTxiciBjbGFzcz0iIj4NCiZuYnNwO3dheSBTRFAgYXR0 cmlidXRlcyBhcmUgdXNlZCBpbiBnZW5lcmFsLiBUaGUgcHJlc2VuY2Ugb2YgYSAmcXVvdDsqJnF1 b3Q7IHRva2VuIG9uPGJyIGNsYXNzPSIiPg0KJm5ic3A7dGhhdCBsaW5lIHdvdWxkIGluZGljYXRl IHRoZSAmcXVvdDtjYWxsIHNob3VsZCBoYXBwZW4gZXZlbiB3aXRob3V0IG1hdGNoaW5nPGJyIGNs YXNzPSIiPg0KJm5ic3A7bGFuZ3VhZ2VzJnF1b3Q7IGNoYXJhY3RlcmlzdGljOyBzaW5jZSB0aGVy ZSBpcyBvbmx5IG9uZSBwbGFjZSB0byBhZGQgdGhpczxiciBjbGFzcz0iIj4NCiZuYnNwO2luZGlj YXRvciwgdGhlIGFtYmlndWl0eSBvZiBzb21lIGxpbmVzIGluZGljYXRpbmcgaXQgYW5kIG90aGVy cyBub3Q8YnIgY2xhc3M9IiI+DQombmJzcDtkaXNhcHBlYXJzLiBUaGUgcHJlY2VkaW5nIGV4YW1w bGUgd291bGQgY29sbGFwc2UgdG86PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJm5ic3A7 bT1hdWRpbyA0OTI1MCBSVFAvQVZQIDIwPGJyIGNsYXNzPSIiPg0KJm5ic3A7YT1obGFuZy1zZW5k OmVzIGV1IGVuICo8YnIgY2xhc3M9IiI+DQombmJzcDthPWhsYW5nLXJlY3Y6ZXMgZXUgZW4gKjxi ciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCiZuYnNwOy4uLmFuZCB0aGUgZXhhbXBsZSB0ZXh0 IHdvdWxkIGJlIHJldmlzZWQgdG8gcmVtb3ZlIHRoZSBpbXBsaWNhdGlvbiB0aGF0PGJyIGNsYXNz PSIiPg0KJm5ic3A7KnNlbmRpbmcqICZxdW90O2VzJnF1b3Q7IG5lY2Vzc2FyaWx5IGltcGxpZXMg KnJlY2VpdmluZyogJnF1b3Q7ZXMmcXVvdDsuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0K Jm5ic3A7SSdsbCBmdXJ0aGVyIG5vdGUgdGhhdCB0aGUgbWFqb3JpdHkgb2YgU0RQIGxpYnJhcmll cyBJJ3ZlIHdvcmtlZCB3aXRoPGJyIGNsYXNzPSIiPg0KJm5ic3A7d291bGQgbWFrZSBhY2Nlc3Np bmcgdGhlIGFsbC1vbi1vbmUtbGluZSBmb3JtYXQgZWFzaWVyIHRoYW48YnIgY2xhc3M9IiI+DQom bmJzcDtvbmUtbGluZS1wZXItbGFuZ3VhZ2UgYXMgd2VsbC48YnIgY2xhc3M9IiI+DQo8L2Jsb2Nr cXVvdGU+DQo8YnIgY2xhc3M9IiI+DQpIZXJlIGlzIHRoZSBwcm9wb3NlZCBBQk5GOjxiciBjbGFz cz0iIj4NCjxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwO0F0dHJpYnV0ZSBTeW50YXg6 PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7aGxhbmctdmFsdWUgPSAmbmJzcDtMYW5ndWFnZS1UYWcgKiggU1AgTGFuZ3VhZ2Ut dGFnICkgWyBTUCBhc3RlcmlzayBdPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7OyBMYW5ndWFnZS1UYWcg YXMgZGVmaW5lZCBpbiBCQ1AgNDc8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQombmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDthc3RlcmlzayAmbmJzcDsmbmJzcDsmbmJzcDs9 ICZuYnNwOyZxdW90OyomcXVvdDsgJm5ic3A7Jm5ic3A7OyBhbiBhc3RlcmlzayAoQVNDSUkgJTJB KSBjaGFyYWN0ZXI8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDtzcCAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDs9ICZuYnNwOzEqJnF1b3Q7ICZxdW90OyA7IG9uZSBvciBtb3Jl IEFTQ0lJIHNwYWNlICglMjApIGNoYXJhY3RlcnM8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+ DQotLTxiciBjbGFzcz0iIj4NClJhbmRhbGwgR2VsbGVuczxiciBjbGFzcz0iIj4NCk9waW5pb25z IGFyZSBwZXJzb25hbDsgJm5ic3A7Jm5ic3A7Jm5ic3A7ZmFjdHMgYXJlIHN1c3BlY3Q7ICZuYnNw OyZuYnNwOyZuYnNwO0kgc3BlYWsgZm9yIG15c2VsZiBvbmx5PGJyIGNsYXNzPSIiPg0KLS0tLS0t LS0tLS0tLS0gUmFuZG9tbHkgc2VsZWN0ZWQgdGFnOiAtLS0tLS0tLS0tLS0tLS08YnIgY2xhc3M9 IiI+DQpJZiBmb3JjZWQgdG8gdHJhdmVsIG9uIGFuIGFpcnBsYW5lLCB0cnkgYW5kIGdldCBpbiB0 aGUgY2FiaW4gd2l0aDxiciBjbGFzcz0iIj4NCnRoZSBDYXB0YWluLCBzbyB5b3UgY2FuIGtlZXAg YW4gZXllIG9uIGhpbSBhbmQgbnVkZ2UgaGltIGlmIGhlPGJyIGNsYXNzPSIiPg0KZmFsbHMgYXNs ZWVwIG9yIHBvaW50IG91dCBhbnkgbW91bnRhaW5zIGxvb21pbmcgdXAgYWhlYWQgLi4uPGJyIGNs YXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7LS1NaWtl IEhhcmRpbmcsIFRoZSBBcm1jaGFpciBBbmFyY2hpc3QncyBBbG1hbmFjLjxiciBjbGFzcz0iIj4N CjxiciBjbGFzcz0iIj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyIGNsYXNzPSIiPg0KU0xJTSBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+DQpTTElN QGlldGYub3JnPGJyIGNsYXNzPSIiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zbGltPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KPGJy IGNsYXNzPSIiPg0KLS0gPGJyIGNsYXNzPSIiPg0KUmFuZGFsbCBHZWxsZW5zPGJyIGNsYXNzPSIi Pg0KT3BpbmlvbnMgYXJlIHBlcnNvbmFsOyAmbmJzcDsmbmJzcDsmbmJzcDtmYWN0cyBhcmUgc3Vz cGVjdDsgJm5ic3A7Jm5ic3A7Jm5ic3A7SSBzcGVhayBmb3IgbXlzZWxmIG9ubHk8YnIgY2xhc3M9 IiI+DQotLS0tLS0tLS0tLS0tLSBSYW5kb21seSBzZWxlY3RlZCB0YWc6IC0tLS0tLS0tLS0tLS0t LTxiciBjbGFzcz0iIj4NCktub3dsZWRnZSBhbHdheXMgZGVzaXJlcyBpbmNyZWFzZTsgaXQgaXMg bGlrZSBmaXJlLCB3aGljaCBtdXN0PGJyIGNsYXNzPSIiPg0KZmlyc3QgYmUga2luZGxlZCBieSBz b21lIGV4dGVybmFsIGFnZW50LCBidXQgd2hpY2ggd2lsbCBhZnRlcndhcmRzPGJyIGNsYXNzPSIi Pg0KcHJvcGFnYXRlIGl0c2VsZi4gJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7LS1Eci4gU2FtdWVsIEpvaG5z b248YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxiciBjbGFzcz0iIj4NClNMSU0gbWFpbGluZyBsaXN0PGJy IGNsYXNzPSIiPg0KU0xJTUBpZXRmLm9yZzxiciBjbGFzcz0iIj4NCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vc2xpbTxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPHAgc3R5bGU9ImZv bnQtZmFtaWx5OiBBcmlhbCxzYW5zLXNlcmlmO2ZvbnQtc2l6ZToxMXB4O2NvbG9yOiM5OTk5OTk7 Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCxzYW5zLXNlcmlm O2NvbG9yOiM5OTk5OTk7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiBBcmlhbDsgbXNvLWZhcmVh c3QtdGhlbWUtZm9udDogbWlub3ItbGF0aW47IG1zby1iaWRpLWZvbnQtZmFtaWx5OiAmcXVvdDtB cmlhbCZxdW90OzsgbXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFzdC1sYW5ndWFn ZTogRU4tR0I7IG1zby1iaWRpLWxhbmd1YWdlOiBBUi1TQSI+VGhpcw0KIGVtYWlsIGFuZCBpdHMg YXR0YWNobWVudHMgYXJlIGludGVuZGVkIGZvciB0aGUgYWJvdmUgbmFtZWQgb25seSBhbmQgbWF5 IGJlIGNvbmZpZGVudGlhbC4gSWYgdGhleSBoYXZlIGNvbWUgdG8geW91IGluIGVycm9yIHlvdSBt dXN0IHRha2Ugbm8gYWN0aW9uIGJhc2VkIG9uIHRoZW0sIG5vciBtdXN0IHlvdSBjb3B5IG9yIHNo b3cgdGhlbSB0byBhbnlvbmU7IHBsZWFzZSByZXBseSB0byB0aGlzIGVtYWlsIG9yIGNhbGwgJiM0 Mzs0NCAyMDcgMzU2IDA2MDANCiBhbmQgaGlnaGxpZ2h0IHRoZSBlcnJvci4gPC9zcGFuPjwvcD4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_B8657F32BB2240FE8D096EB3EC4408D9gsmacom_-- From nobody Thu Jun 1 06:50:05 2017 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 106AD129411 for ; Thu, 1 Jun 2017 06:50:04 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 fO7dybgKbFCF for ; Thu, 1 Jun 2017 06:50:01 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 806A21242EA for ; Thu, 1 Jun 2017 06:50:01 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Thu, 1 Jun 2017 06:52:18 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Mailer: Eudora for Mac OS X Date: Thu, 1 Jun 2017 06:49:56 -0700 To: Natasha Rooney From: Randall Gellens Cc: Gunnar =?iso-8859-1?Q?Hellstr=F6m?= , Bernard Aboba , "slim@ietf.org" Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Slim] Open Issues on 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, 01 Jun 2017 13:50:04 -0000 At 9:45 AM +0000 6/1/17, Natasha Rooney wrote: > The last remaining item of Ticket 26 is asking=20 > for an explanation of the role of * only. Can=20 > we get this added and then close the ticket? The syntax does not permit a * only, there has to be at least one language t= ag. > > I'll address 34 separately. > > > Natasha Rooney | Internet Engineering Director=20 > | Internet and Web Team | Technology | GSMA=20 > | nrooney@gsma.com |=20 > +44 (0) 7730 219 765 | @thisNatasha |=20 > Skype: nrooney@gsm.org > >> On 29 May 2017, at 23:17, Randall Gellens=20 >> <rg+ietf@randy.pensive.org>=20 >> wrote: >> >> At 8:49 PM +0200 5/29/17, Gunnar Hellstr=F6m wrote: >> >>> Den 2017-05-29 kl. 00:15, skrev Randall Gellens: >>> >>>> I think the edits so far address #19, #27,=20 >>>> 28 so they can be closed. #38, #39 are=20 >>>> addressed in -09 so I will post that and=20 >>>> those can be closed. I think #26, #29, #32,=20 >>>> #34, #35 were not accepted. >>>> >>> This is my view: >>> >>> #26 can be left non-accepted if #34 is accepted. >>> >> >> #26 can be done with an Informational draft=20 >> that provides advice to implementers, as=20 >> previously discussed. #34 was discussed a=20 >> long time ago and it was decided that we did=20 >> not need to add complexity and that we would=20 >> keep the more simple syntax. >> >>> But if #34 is not accepted, we could need #26. >>> #29 is ok to not accept. All other aspects of=20 >>> the attribute registrations are solved. >>> >>> #34: I have not seen anything about not=20 >>> accepting it, so I suggest to accept it. >>> #35 syntax for bidirectionally symmetric=20 >>> cases - will increase complexity - I would=20 >>> suggest to not accept it, but I cannot=20 >>> remember that we concluded that before. >>> >>> #32 requires the two extensions about=20 >>> relative preference and simultaneity to be=20 >>> solved. We have not said that we would not=20 >>> accept #32. I suggest that we accept it. >>> >> >> We've repeatedly decided to not add relative=20 >> preferences (nor any coordination between=20 >> media) in this draft. This can all be done in=20 >> a subsequent draft. >> >> --Randy >> >>> >>> >>> >>> Gunnar >>> >>>> >>>> --Randy >>>> >>>> At 11:25 AM -0700 4/25/17, Bernard Aboba wrote: >>>> >>>>> Currently 10 Issues remain open from IETF Last Call: >>>>> >>>>>=20 >>>>> <https://trac.ietf.org/trac/= slim/report/1>https://trac.ietf.or= g/trac/slim/report/1 >>>>> >>>>> >>>>> These include: >>>>> >>>>>=20 >>>>> <https://trac.ietf.org/trac/slim/report/1?sort=3Dticket&asc=3D1&page=3D1= >Ticket<https://trac.ietf.org/trac/slim/report/1?sort=3Dsummary&asc=3D1&page= =3D1>Summary<https://trac.ietf.org/trac/slim/report/1?sort=3Dcomponent&asc= =3D1&page=3D1>Component<https://trac.ietf.org/trac/slim/report/1?sort=3Dversio= n&asc=3D1&page=3D1>Version<https://trac.ietf.org/trac/slim/report/1?sort=3Dm= ilestone&asc=3D1&page=3D1>Milestone<https://trac.ietf.org/trac/slim/report/1?sort= =3Dtype&asc=3D1&page=3D1>Type<https://trac.ietf.org/trac/slim/report/1?sort=3Dow= ner&asc=3D1&page=3D1>=20 >>>>> Owner<https://trac.ietf.org/trac/slim/report/1?sort=3Dstatus&asc=3D1&page= =3D1>Status<https://trac.ietf.org/trac/slim/report/1?sort=3Dcreated&asc=3D1&pa= ge=3D1>Created<https://trac.ietf.= org/trac/slim/ticket/27>#27<https= ://trac.ietf.org/trac/slim/ticket/27>The=20 >>>>> cases in the "Silly states" section 5.4 are=20 >>>>> not all=20 >>>>> silly.negotiating-human-language2.0<https://trac.ietf.org/trac/slim/milestone/milestone1>mil= estone1defect<mailto:gunnar.hellstrom@om= nitor.se>gunnar.hellstrom@omnitor.= senewMar=20 >>>>> 22,=20 >>>>> 2017<https://trac.ietf.org/= trac/slim/ticket/19>#19<https://t= rac.ietf.org/trac/slim/ticket/19>Use=20 >>>>> Media Type registration=20 >>>>> templatemultilangcontentenhancement<mailto:rfc.nik.tomkinson@gmail.com>rfc.nik.tomkinson@gmail.comassignedAug=20 >>>>> 17,=20 >>>>> 2016<https://trac.ietf.org/= trac/slim/ticket/28>#28<https://t= rac.ietf.org/trac/slim/ticket/28>Examples=20 >>>>> section 5.5 requires=20 >>>>> expansionnegotiating-human-language2.0<https://trac.ietf.org/trac/slim/milestone/milestone1>= milestone1defect2Bietf@randy.pen= sive.org>rg+ietf@randy.pensive.= orgassignedMar=20 >>>>> 22,=20 >>>>> 2017<https://trac.ietf.org/= trac/slim/ticket/32>#32<https://t= rac.ietf.org/trac/slim/ticket/32>Audio/Video=20 >>>>> Coordinationnegotiating-human-language2.0<https://trac.ietf.org/trac/slim/milestone/mileston= e1>milestone1defect2Bietf@randy.= pensive.org>rg+ietf@randy.pensive.or= gnewMar=20 >>>>> 22,=20 >>>>> 2017<https://trac.ietf.org/= trac/slim/ticket/34>#34<https://t= rac.ietf.org/trac/slim/ticket/34>Use=20 >>>>> the Accept-Language=20 >>>>> syntaxnegotiating-human-language2.0<https://trac.ietf.org/trac/slim/milestone/milestone1>mil= estone1defect2Bietf@randy.pensiv= e.org>rg+ietf@randy.pensive.org= assignedMar=20 >>>>> 22,=20 >>>>> 2017<https://trac.ietf.org/= trac/slim/ticket/35>#35<https://t= rac.ietf.org/trac/slim/ticket/35>Have=20 >>>>> an attribute to abbreviate the=20 >>>>> bidirectionally-symmetric=20 >>>>> casenegotiating-human-language2.0<https://trac.ietf.org/trac/slim/milestone/milestone1>miles= tone1defect2Bietf@randy.pensive.= org>rg+ietf@randy.pensive.orgas= signedMar=20 >>>>> 22,=20 >>>>> 2017<https://trac.ietf.org/= trac/slim/ticket/38>#38<https://t= rac.ietf.org/trac/slim/ticket/38>Routing=20 >>>>> out of=20 >>>>> scopenegotiating-human-language1.0<https://trac.ietf.org/trac/slim/milestone/milestone1>mile= stone1defect<mai= lto:draft-ietf-slim-negotiating-human-language@ietf.org>draft-ietf-slim-negotiating-hu= man-language@ietf.orgnewApr=20 >>>>> 25,=20 >>>>> 2017<https://trac.ietf.org/= trac/slim/ticket/39>#39<https://t= rac.ietf.org/trac/slim/ticket/39>Syntax=20 >>>>> Collapsenegotiating-human-language1.0<https://trac.ietf.org/trac/slim/milestone/milestone1>m= ilestone1defect<= mailto:draft-ietf-slim-negotiating-human-language@ietf.org>draft-ietf-slim-negotiating= -human-language@ietf.orgnewApr=20 >>>>> 25,=20 >>>>> 2017<https://trac.ietf.org/= trac/slim/ticket/26>#26<https://t= rac.ietf.org/trac/slim/ticket/26>Make=20 >>>>> use of the asterisk modifier on media level=20 >>>>> with session scope also for media level=20 >>>>> purposesnegotiating-human-language2.0<https://trac.ietf.org/trac/slim/milestone/milestone1>m= ilestone1enhancement<mailto:gunnar.hells= trom@omnitor.se>gunnar.hellstrom@o= mnitor.senewMar=20 >>>>> 22,=20 >>>>> 2017<https://trac.ietf.org/= trac/slim/ticket/29>#29<https://t= rac.ietf.org/trac/slim/ticket/29>Include=20 >>>>> more fields for attribute registration from=20 >>>>> 4566bis >>>>> >>>>> _______________________________________________ >>>>> SLIM mailing list >>>>> SLIM@ietf.org >>>>>=20 >>>>> https://www.ietf.org/mailm= an/listinfo/slim >>>>> >>>> >>>> >>> >>> -- >>> ----------------------------------------- >>> Gunnar Hellstr=F6m >>> Omnitor >>> gunnar.hellstrom@omnitor.se >>> +46 708 204 288 >>> >> >> >> -- >> Randall Gellens >> Opinions are personal; facts are suspect; I speak for myself only >> -------------- Randomly selected tag: --------------- >> I do not need to explain why I say things. That's the interesting thing >> about being the President. Maybe somebody needs to explain to me why >> they say something, but I don't feel like I owe anybody an explanation. >> --George W. Bush, in an interview with Bob Woodward. >> >> _______________________________________________ >> SLIM mailing list >> SLIM@ietf.org >> https://www.ietf.org/mailman/listinfo/slim >> > > This email and its attachments are intended for=20 > the above named only and may be confidential.=20 > If they have come to you in error you must take=20 > no action based on them, nor must you copy or=20 > show them to anyone; please reply to this email=20 > or call +44 207 356 0600 and highlight the=20 > error. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- The First Amendment is often inconvenient. But that is besides the point. Inconvenience does not absolve the government of its obligation to tolerate speech. --Justice Anthony Kennedy, in 91-155 From nobody Thu Jun 1 07:00:48 2017 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 5B9EF1277BB for ; Thu, 1 Jun 2017 07:00:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 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_H3=-0.01, 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 6k8cGR-6U0PM for ; Thu, 1 Jun 2017 07:00:44 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20045.outbound.protection.outlook.com [40.107.2.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D315E120727 for ; Thu, 1 Jun 2017 07:00:42 -0700 (PDT) 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=UQFIAJKygDiTAOHS2Cq6zPi7+DYFSC2Hr+z6nY+DRaQ=; b=ub4kw1PNmvNr0HMn66OlyqanGB8eDTHQ8QvRwPKbUCgpeUJaBsRIGcen1jam2FW10hK2GThYsUI+ErpU9VR6hLSZ4BD3GtFhxumKb9h3vmW+0HONxqZGVkTcgmnpZB1KaS9RehyIFOlf26R/U+M5PUqg9kqdixOfVBqGgiBDp0Y= Received: from AM2PR04MB0802.eurprd04.prod.outlook.com (10.160.56.28) by AM2PR04MB0802.eurprd04.prod.outlook.com (10.160.56.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1124.9; Thu, 1 Jun 2017 14:00:40 +0000 Received: from AM2PR04MB0802.eurprd04.prod.outlook.com ([fe80::250d:5ecf:c7fd:d3b1]) by AM2PR04MB0802.eurprd04.prod.outlook.com ([fe80::250d:5ecf:c7fd:d3b1%15]) with mapi id 15.01.1124.020; Thu, 1 Jun 2017 14:00:40 +0000 From: Natasha Rooney To: Randall Gellens CC: =?utf-8?B?R3VubmFyIEhlbGxzdHLDtm0=?= , Bernard Aboba , "slim@ietf.org" Thread-Topic: [Slim] Open Issues on draft-ietf-slim-negotiating-human-language Thread-Index: AQHSvfFennYJ1euDyk6DzIklHhGSTaIKg9uAgAFY1YCAADpHAIAD5L0AgABEUACAAAL/gA== Date: Thu, 1 Jun 2017 14:00:39 +0000 Message-ID: <2A61C813-6E0C-488C-9A73-972D47D62719@gsma.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) 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-originating-ip: [62.189.0.100] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM2PR04MB0802; 7:nkOYssyHKhRL0McMDJx8nIg9TrR3q49oPLqZcPWagVfolGfvaR8T/RUq/VHxRgz4hzscC+QPhbxYXHRro8o7HaBKliHY5m+8vmEalvW57Jpz805NYVUJ55yr9miHonZXAyJdaNoQo6sA+SzIc9t++fCio+NceWBlqKNFxNtNyC/xfFpKwNq6z42h8Hh8Ex4YKeFaeVeqihflVkdaMjP1yu6OfwMYrv+r25eTsVhTgmmBTtNl93dAL1QwcgpMk1RmOQDoqbjNt111YujX00J2XcNsyO6IrvJbLzVAAaO44pGA89v8AygiRFc5rYFI26IMJcfe4NfHFFfNLxqkhGAxnA== x-ms-traffictypediagnostic: AM2PR04MB0802: x-ms-office365-filtering-correlation-id: 33e52ec3-2822-4b86-3b3a-08d4a8f69623 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:AM2PR04MB0802; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700099)(100105000095)(100000701098)(100105300095)(100000702098)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(100000703098)(100105400095)(10201501046)(6041248)(20161123555025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123558100)(20161123560025)(6072148)(100000704098)(100105200095)(100000705098)(100105500095); SRVR:AM2PR04MB0802; BCL:0; PCL:0; RULEID:(100000800098)(100110000095)(100000801098)(100110300095)(100000802098)(100110100095)(100000803098)(100110400095)(100000804098)(100110200095)(100000805098)(100110500095); SRVR:AM2PR04MB0802; x-forefront-prvs: 0325F6C77B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39410400002)(39400400002)(39840400002)(39450400003)(24454002)(54906002)(236005)(478600001)(99286003)(38730400002)(36756003)(53936002)(6246003)(110136004)(76176999)(50986999)(7736002)(229853002)(6506006)(6512007)(54896002)(6486002)(5660300001)(189998001)(6436002)(86362001)(33656002)(2906002)(2950100002)(53546009)(25786009)(5250100002)(5890100001)(82746002)(3280700002)(3660700001)(4326008)(39060400002)(14454004)(230783001)(102836003)(3846002)(6116002)(93886004)(66066001)(8936002)(2900100001)(8676002)(81166006)(57306001)(83716003)(50226002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM2PR04MB0802; H:AM2PR04MB0802.eurprd04.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_2A61C8136E0C488C9A73972D47D62719gsmacom_" MIME-Version: 1.0 X-OriginatorOrg: gsma.com X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jun 2017 14:00:39.9457 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72a4ff82-fec3-469d-aafb-ac8276216699 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR04MB0802 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: AM2PR04MB0802.eurprd04.prod.outlook.com X-MS-Exchange-CrossPremises-TransportTrafficType: Email X-MS-Exchange-CrossPremises-TransportTrafficSubType: X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-originalclientipaddress: 62.189.0.100 X-MS-Exchange-CrossPremises-transporttraffictype: Email X-MS-Exchange-CrossPremises-transporttrafficsubtype: 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: AM2PR04MB0802.eurprd04.prod.outlook.com Archived-At: Subject: Re: [Slim] Open Issues on 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, 01 Jun 2017 14:00:46 -0000 --_000_2A61C8136E0C488C9A73972D47D62719gsmacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpPbiAxIEp1biAyMDE3LCBhdCAxNDo0OSwgUmFuZGFsbCBHZWxsZW5zIDxyZytpZXRmQHJhbmR5 LnBlbnNpdmUub3JnPG1haWx0bzpyZytpZXRmQHJhbmR5LnBlbnNpdmUub3JnPj4gd3JvdGU6DQoN ClRoZSBzeW50YXggZG9lcyBub3QgcGVybWl0IGEgKiBvbmx5LCB0aGVyZSBoYXMgdG8gYmUgYXQg bGVhc3Qgb25lIGxhbmd1YWdlIHRhZy4NCg0KVGhhdOKAmXMgZmluZSAtIGJ1dCBjYW4gd2UganVz dCBleHBsYWluIHRoYXQgc29tZXdoZXJlPw0KDQoNClRoaXMgZW1haWwgYW5kIGl0cyBhdHRhY2ht ZW50cyBhcmUgaW50ZW5kZWQgZm9yIHRoZSBhYm92ZSBuYW1lZCBvbmx5IGFuZCBtYXkgYmUgY29u ZmlkZW50aWFsLiBJZiB0aGV5IGhhdmUgY29tZSB0byB5b3UgaW4gZXJyb3IgeW91IG11c3QgdGFr ZSBubyBhY3Rpb24gYmFzZWQgb24gdGhlbSwgbm9yIG11c3QgeW91IGNvcHkgb3Igc2hvdyB0aGVt IHRvIGFueW9uZTsgcGxlYXNlIHJlcGx5IHRvIHRoaXMgZW1haWwgb3IgY2FsbCArNDQgMjA3IDM1 NiAwNjAwIGFuZCBoaWdobGlnaHQgdGhlIGVycm9yLg0K --_000_2A61C8136E0C488C9A73972D47D62719gsmacom_ Content-Type: text/html; charset="utf-8" Content-ID: <627CA1E6ED14A948948BB596C348617D@eurprd04.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGRpdj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiAxIEp1 biAyMDE3LCBhdCAxNDo0OSwgUmFuZGFsbCBHZWxsZW5zICZsdDs8YSBocmVmPSJtYWlsdG86cmcm IzQzO2lldGZAcmFuZHkucGVuc2l2ZS5vcmciIGNsYXNzPSIiPnJnJiM0MztpZXRmQHJhbmR5LnBl bnNpdmUub3JnPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hh bmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhl bHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFu dC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3Jt YWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTog bm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4 dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0 YW50OyIgY2xhc3M9IiI+VGhlDQogc3ludGF4IGRvZXMgbm90IHBlcm1pdCBhICogb25seSwgdGhl cmUgaGFzIHRvIGJlIGF0IGxlYXN0IG9uZSBsYW5ndWFnZSB0YWcuPC9zcGFuPjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PlRoYXTigJlzIGZpbmUgLSBi dXQgY2FuIHdlIGp1c3QgZXhwbGFpbiB0aGF0IHNvbWV3aGVyZT88L2Rpdj4NCjxiciBjbGFzcz0i Ij4NCjxwIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsc2Fucy1zZXJpZjtmb250LXNpemU6MTFw eDtjb2xvcjojOTk5OTk5OyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTog QXJpYWwsc2Fucy1zZXJpZjtjb2xvcjojOTk5OTk5OyBtc28tZmFyZWFzdC1mb250LWZhbWlseTog QXJpYWw7IG1zby1mYXJlYXN0LXRoZW1lLWZvbnQ6IG1pbm9yLWxhdGluOyBtc28tYmlkaS1mb250 LWZhbWlseTogJnF1b3Q7QXJpYWwmcXVvdDs7IG1zby1hbnNpLWxhbmd1YWdlOiBFTi1VUzsgbXNv LWZhcmVhc3QtbGFuZ3VhZ2U6IEVOLUdCOyBtc28tYmlkaS1sYW5ndWFnZTogQVItU0EiPlRoaXMN CiBlbWFpbCBhbmQgaXRzIGF0dGFjaG1lbnRzIGFyZSBpbnRlbmRlZCBmb3IgdGhlIGFib3ZlIG5h bWVkIG9ubHkgYW5kIG1heSBiZSBjb25maWRlbnRpYWwuIElmIHRoZXkgaGF2ZSBjb21lIHRvIHlv dSBpbiBlcnJvciB5b3UgbXVzdCB0YWtlIG5vIGFjdGlvbiBiYXNlZCBvbiB0aGVtLCBub3IgbXVz dCB5b3UgY29weSBvciBzaG93IHRoZW0gdG8gYW55b25lOyBwbGVhc2UgcmVwbHkgdG8gdGhpcyBl bWFpbCBvciBjYWxsICYjNDM7NDQgMjA3IDM1NiAwNjAwDQogYW5kIGhpZ2hsaWdodCB0aGUgZXJy b3IuIDwvc3Bhbj48L3A+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_2A61C8136E0C488C9A73972D47D62719gsmacom_-- From nobody Thu Jun 1 07:19:50 2017 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 6F0A012932A for ; Thu, 1 Jun 2017 07:19:49 -0700 (PDT) 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, 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 cYLDt5JU3qSv for ; Thu, 1 Jun 2017 07:19:45 -0700 (PDT) Received: from bin-vsp-out-01.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 91B2A1289B0 for ; Thu, 1 Jun 2017 07:19:45 -0700 (PDT) X-Halon-ID: 59584d70-46d5-11e7-b757-005056917a89 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [77.53.231.21]) by bin-vsp-out-01.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Thu, 1 Jun 2017 16:19:39 +0200 (CEST) To: Randall Gellens , Natasha Rooney References: Cc: Bernard Aboba , "slim@ietf.org" From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <827326b9-c69b-6bd9-ea0f-708146b185c6@omnitor.se> Date: Thu, 1 Jun 2017 16:19:39 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Slim] Open Issues on 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, 01 Jun 2017 14:19:49 -0000 Den 2017-06-01 kl. 15:49, skrev Randall Gellens: > At 9:45 AM +0000 6/1/17, Natasha Rooney wrote: > >> The last remaining item of Ticket 26 is asking for an explanation of = >> the role of * only. Can we get this added and then close the ticket? > > The syntax does not permit a * only, there has to be at least one=20 > language tag. I guess that Natasha means that it is only the description of the use of = the asterisk that is needed in ticket #26. I have provided an even better motivated use of the asterisk as a media=20 level parameter in a very recent proposal. It is under subject: "New wording for the use of the asterisk in=20 draft-ietf-slim-negotiating-human-language" It can be entered as a solution proposal for ticket #26. I think that without that wording, it is not possible to have the=20 asterisk as a media level parameter. However, it is depending on Ticket #34. So, a decision on #34 is needed=20 first. Regards Gunnar > >> >> I'll address 34 separately. >> >> Natasha Rooney | Internet Engineering Director | Internet and Web=20 >> Team | Technology | GSMA | nrooney@gsma.com=20 >> | +44 (0) 7730 219 765 | @thisNatasha | Skype:=20 >> nrooney@gsm.org >> >>> On 29 May 2017, at 23:17, Randall Gellens=20 >>> <rg+ietf@randy.pensive.org> wrote: >>> >>> At 8:49 PM +0200 5/29/17, Gunnar Hellstr=F6m wrote: >>> >>>> Den 2017-05-29 kl. 00:15, skrev Randall Gellens: >>>> >>>>> I think the edits so far address #19, #27, 28 so they can be=20 >>>>> closed. #38, #39 are addressed in -09 so I will post that and=20 >>>>> those can be closed. I think #26, #29, #32, #34, #35 were not=20 >>>>> accepted. >>>>> >>>> This is my view: >>>> >>>> #26 can be left non-accepted if #34 is accepted. >>>> >>> >>> #26 can be done with an Informational draft that provides advice to = >>> implementers, as previously discussed. #34 was discussed a long=20 >>> time ago and it was decided that we did not need to add complexity=20 >>> and that we would keep the more simple syntax. >>> >>>> But if #34 is not accepted, we could need #26. >>>> #29 is ok to not accept. All other aspects of the attribute=20 >>>> registrations are solved. >>>> >>>> #34: I have not seen anything about not accepting it, so I suggest = >>>> to accept it. >>>> #35 syntax for bidirectionally symmetric cases - will increase=20 >>>> complexity - I would suggest to not accept it, but I cannot=20 >>>> remember that we concluded that before. >>>> >>>> #32 requires the two extensions about relative preference and=20 >>>> simultaneity to be solved. We have not said that we would not=20 >>>> accept #32. I suggest that we accept it. >>>> >>> >>> We've repeatedly decided to not add relative preferences (nor any=20 >>> coordination between media) in this draft. This can all be done in=20 >>> a subsequent draft. >>> >>> --Randy >>> >>>> >>>> >>>> >>>> Gunnar >>>> >>>>> >>>>> --Randy >>>>> >>>>> At 11:25 AM -0700 4/25/17, Bernard Aboba wrote: >>>>> >>>>>> Currently 10 Issues remain open from IETF Last Call: >>>>>> >>>>>> >>>>>> <https://trac.ietf.org/t= rac/slim/report/1>https://trac.= ietf.org/trac/slim/report/1=20 >>>>>> >>>>>> >>>>>> >>>>>> These include: >>>>>> >>>>>> >>>>>> <https://trac.ietf.org/trac/slim/report/1?sort=3Dticket&asc=3D1&pa= ge=3D1>Ticket<https://trac.ietf.org/trac/slim/report/1?sort=3Dsummary&as= c=3D1&page=3D1>Summary<https://trac.ietf.org/trac/slim/report/1?sort=3D= component&asc=3D1&page=3D1>Component<https://trac.ietf.org/trac/slim/rep= ort/1?sort=3Dversion&asc=3D1&page=3D1>Version<https://trac.ietf.org/tr= ac/slim/report/1?sort=3Dmilestone&asc=3D1&page=3D1>Milestone<https://trac.i= etf.org/trac/slim/report/1?sort=3Dtype&asc=3D1&page=3D1>Type<https://trac.= ietf.org/trac/slim/report/1?sort=3Downer&asc=3D1&page=3D1>=20 >>>>>> Owner<https://trac.ietf.org/trac/slim/report/1?sort=3Dstatus&asc=3D1= &page=3D1>Status<https://trac.ietf.org/trac/slim/report/1?sort=3Dcreated= &asc=3D1&page=3D1>Created<http= s://trac.ietf.org/trac/slim/ticket/27>#27<https://trac.ietf.org/trac/slim/ticket/27>The=20 >>>>>> cases in the "Silly states" section 5.4 are not all=20 >>>>>> silly.negotiating-human-language2.0<https://trac.ietf.org/trac/slim/milestone/milesto= ne1>milestone1defect<mailto:gunnar.he= llstrom@omnitor.se>gunnar.hells= trom@omnitor.senewMar=20 >>>>>> 22,=20 >>>>>> 2017<https://trac.ietf.= org/trac/slim/ticket/19>#19<ht= tps://trac.ietf.org/trac/slim/ticket/19>Use=20 >>>>>> Media Type registration=20 >>>>>> templatemultilangcontentenhancement<mailto:rfc.nik.tomkinson@gmail.com>rfc.nik.tomkinson@gmail.comassignedAug=20 >>>>>> 17,=20 >>>>>> 2016<https://trac.ietf.= org/trac/slim/ticket/28>#28<ht= tps://trac.ietf.org/trac/slim/ticket/28>Examples=20 >>>>>> section 5.5 requires=20 >>>>>> expansionnegotiating-human-language2.0<https://trac.ietf.org/trac/slim/milestone/mile= stone1>milestone1defect2Bietf= @randy.pensive.org>rg+ietf@r= andy.pensive.orgassignedMar=20 >>>>>> 22,=20 >>>>>> 2017<https://trac.ietf.= org/trac/slim/ticket/32>#32<ht= tps://trac.ietf.org/trac/slim/ticket/32>Audio/Video=20 >>>>>> Coordinationnegotiating-human-language2.0<https://trac.ietf.org/trac/slim/milestone/m= ilestone1>milestone1defect2Bi= etf@randy.pensive.org>rg+ietf@ran= dy.pensive.orgnewMar=20 >>>>>> 22,=20 >>>>>> 2017<https://trac.ietf.= org/trac/slim/ticket/34>#34<ht= tps://trac.ietf.org/trac/slim/ticket/34>Use=20 >>>>>> the Accept-Language=20 >>>>>> syntaxnegotiating-human-language2.0<https://trac.ietf.org/trac/slim/milestone/milesto= ne1>milestone1defect2Bietf@ra= ndy.pensive.org>rg+ietf@rand= y.pensive.orgassignedMar=20 >>>>>> 22,=20 >>>>>> 2017<https://trac.ietf.= org/trac/slim/ticket/35>#35<ht= tps://trac.ietf.org/trac/slim/ticket/35>Have=20 >>>>>> an attribute to abbreviate the bidirectionally-symmetric=20 >>>>>> casenegotiating-human-language2.0<https://trac.ietf.org/trac/slim/milestone/milestone= 1>milestone1defect2Bietf@rand= y.pensive.org>rg+ietf@randy.= pensive.orgassignedMar=20 >>>>>> 22,=20 >>>>>> 2017<https://trac.ietf.= org/trac/slim/ticket/38>#38<ht= tps://trac.ietf.org/trac/slim/ticket/38>Routing=20 >>>>>> out of=20 >>>>>> scopenegotiating-human-language1.0<https://trac.ietf.org/trac/slim/milestone/mileston= e1>milestone1defect<mailto:draft-ietf-slim-negotiating-human-language@ietf.org>draft-ietf-sli= m-negotiating-human-language@ietf.orgnewApr=20 >>>>>> 25,=20 >>>>>> 2017<https://trac.ietf.= org/trac/slim/ticket/39>#39<ht= tps://trac.ietf.org/trac/slim/ticket/39>Syntax=20 >>>>>> Collapsenegotiating-human-language1.0<https://trac.ietf.org/trac/slim/milestone/miles= tone1>milestone1defect<mailto:draft-ietf-slim-negotiating-human-language@ietf.org>draft-ietf-= slim-negotiating-human-language@ietf.orgnewApr=20 >>>>>> 25,=20 >>>>>> 2017<https://trac.ietf.= org/trac/slim/ticket/26>#26<ht= tps://trac.ietf.org/trac/slim/ticket/26>Make=20 >>>>>> use of the asterisk modifier on media level with session scope=20 >>>>>> also for media level=20 >>>>>> purposesnegotiating-human-language2.0<https://trac.ietf.org/trac/slim/milestone/miles= tone1>milestone1enhancement<mailto:gu= nnar.hellstrom@omnitor.se>gunna= r.hellstrom@omnitor.senewMar=20 >>>>>> 22,=20 >>>>>> 2017<https://trac.ietf.= org/trac/slim/ticket/29>#29<ht= tps://trac.ietf.org/trac/slim/ticket/29>Include=20 >>>>>> more fields for attribute registration from 4566bis >>>>>> >>>>>> _______________________________________________ >>>>>> SLIM mailing list >>>>>> SLIM@ietf.org >>>>>> >>>>>> https://www.ietf.org/m= ailman/listinfo/slim=20 >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> -- >>>> ----------------------------------------- >>>> Gunnar Hellstr=F6m >>>> Omnitor >>>> gunnar.hellstrom@omnitor.se >>>> +46 708 204 288 >>>> >>> >>> >>> -- >>> Randall Gellens >>> Opinions are personal; facts are suspect; I speak for myself=20 >>> only >>> -------------- Randomly selected tag: --------------- >>> I do not need to explain why I say things. That's the interesting=20 >>> thing >>> about being the President. Maybe somebody needs to explain to me wh= y >>> they say something, but I don't feel like I owe anybody an=20 >>> explanation. >>> --George W. Bush, in an interview with Bob Woodward. >>> >>> _______________________________________________ >>> SLIM mailing list >>> SLIM@ietf.org >>> https://www.ietf.org/mailman/listinfo/slim >>> >> >> 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=20 >> take no action based on them, nor must you copy or show them to=20 >> anyone; please reply to this email or call +44 207 356 0600 and=20 >> highlight the error. > > --=20 ----------------------------------------- Gunnar Hellstr=F6m Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 From nobody Thu Jun 1 07:33:36 2017 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 D9D35128D2E for ; Thu, 1 Jun 2017 07:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ah8qK5Df_fus for ; Thu, 1 Jun 2017 07:33:31 -0700 (PDT) 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 7085812741D for ; Thu, 1 Jun 2017 07:33:29 -0700 (PDT) X-Halon-ID: 45b50e74-46d7-11e7-bca7-0050569116f7 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [77.53.231.21]) by bin-vsp-out-03.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Thu, 1 Jun 2017 16:33:25 +0200 (CEST) To: slim@ietf.org References: From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: Date: Thu, 1 Jun 2017 16:33:25 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------7A798E40B88B286CAFF617E2" Archived-At: Subject: Re: [Slim] Collapse attribute syntax to one line 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, 01 Jun 2017 14:33:35 -0000 This is a multi-part message in MIME format. --------------7A798E40B88B286CAFF617E2 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Den 2017-06-01 kl. 11:54, skrev Natasha Rooney: > This seems sufficient given our previous conversations. q-values can > be applied within further work (although I don’t see why ordering > doesn’t do the job, works in web). It is not feasible to change syntax by adding q-values in an extension. That will cause interop problems, or complicated needs to negotiate protocol version. So, we need to decide the syntax now and stick closely to it. Ordering is not sufficient because we have a need to set preferences between different media. Ordering only works within a media. And, a minor drawback: ordering does not allow to specify a number of languages in the same media with the same preference. One always will look as if it is more preferred than another. - but I think we can live with that. Maybe the main question is: Will our own one-line syntax really be less complex to parse than the Accept-Language syntax that we might be able to find ready library routines for? Adam Roach had views on complexity to parse different solutions. Maybe you, Adam can have a view on this? Regards Gunnar > > Bernard - any further thoughts? > > Natasha Rooney | Internet Engineering Director | Internet and Web Team > | Technology | GSMA | nrooney@gsma.com | +44 > (0) 7730 219 765 | @thisNatasha | Skype: nrooney@gsm.org > > >> On 30 May 2017, at 00:04, Randall Gellens > > wrote: >> >> I uploaded version -10, which includes the syntax change to single >> line, along with a few editorial clarifications. (Version -09 >> accidently omitted an editorial clarification.) >> >> You can see a diff of the changes from 08 to 10 here: >> https://www.ietf.org/rfcdiff?url1=draft-ietf-slim-negotiating-human-language-08&url2=draft-ietf-slim-negotiating-human-language-10 >> >> If there objections to the change from multi-line to single-line, >> this can be reverted. >> >> --Randy >> >> >> >> At 2:57 PM -0700 5/28/17, Randall Gellens wrote: >> >>> In response to Adam Roach's comments as well as other comments, I >>> intend to update the draft to collapse the attribute syntax to one >>> line; each attribute can occur at most once per media, with all >>> languages on the same line. This will further reduce the size of >>> the SDP block. >>> >>> If you object to this, please reply. >>> >>> Here is the section of Adam's review: >>> >>> At 8:31 PM +0000 3/28/17, Sabrina Tanamal via RT wrote: >>>> I'll note that much of this can be fixed if the syntax is collapsed so >>>> that each media section can have at most one hlang-send and one >>>> hlang-receive, each of which contain a list of one or more languages >>>> that can be sent or received. This is also much more consistent >>>> with the >>>> way SDP attributes are used in general. The presence of a "*" token on >>>> that line would indicate the "call should happen even without matching >>>> languages" characteristic; since there is only one place to add this >>>> indicator, the ambiguity of some lines indicating it and others not >>>> disappears. The preceding example would collapse to: >>>> >>>> m=audio 49250 RTP/AVP 20 >>>> a=hlang-send:es eu en * >>>> a=hlang-recv:es eu en * >>>> >>>> ...and the example text would be revised to remove the implication >>>> that >>>> *sending* "es" necessarily implies *receiving* "es". >>>> >>>> I'll further note that the majority of SDP libraries I've worked with >>>> would make accessing the all-on-one-line format easier than >>>> one-line-per-language as well. >>> >>> Here is the proposed ABNF: >>> >>> Attribute Syntax: >>> >>> hlang-value = Language-Tag *( SP Language-tag ) [ SP asterisk ] >>> >>> ; Language-Tag as defined in BCP 47 >>> >>> asterisk = "*" ; an asterisk (ASCII %2A) character >>> >>> sp = 1*" " ; one or more ASCII space (%20) characters >>> >>> -- >>> Randall Gellens >>> Opinions are personal; facts are suspect; I speak for myself only >>> -------------- Randomly selected tag: --------------- >>> If forced to travel on an airplane, try and get in the cabin with >>> the Captain, so you can keep an eye on him and nudge him if he >>> falls asleep or point out any mountains looming up ahead ... >>> --Mike Harding, The Armchair Anarchist's Almanac. >>> >>> _______________________________________________ >>> SLIM mailing list >>> SLIM@ietf.org >>> https://www.ietf.org/mailman/listinfo/slim >> >> >> -- >> Randall Gellens >> Opinions are personal; facts are suspect; I speak for myself only >> -------------- Randomly selected tag: --------------- >> Knowledge always desires increase; it is like fire, which must >> first be kindled by some external agent, but which will afterwards >> propagate itself. --Dr. Samuel Johnson >> >> _______________________________________________ >> SLIM mailing list >> SLIM@ietf.org >> https://www.ietf.org/mailman/listinfo/slim > > 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. > > > > _______________________________________________ > 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 --------------7A798E40B88B286CAFF617E2 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Den 2017-06-01 kl. 11:54, skrev Natasha Rooney:
This seems sufficient given our previous conversations. q-values can be applied within further work (although I don’t see why ordering doesn’t do the job, works in web).
It is not feasible to change syntax by adding q-values in an extension. That will cause interop problems, or complicated needs to negotiate protocol version. So, we need to decide the syntax now and stick closely to it.

Ordering is not sufficient because we have a need to set preferences between different media.
Ordering only works within a media.

And, a minor drawback: ordering does not allow to specify a number of languages in the same media with the same preference. One always will look as if it is more preferred than another. - but I think we can live with that.

Maybe the main question is: Will our own one-line syntax really be less complex to parse than the Accept-Language syntax that we might be able to find ready library routines for?
Adam Roach had views on complexity to parse different solutions. Maybe you, Adam can have a view on this?

Regards

Gunnar


Bernard - any further thoughts?

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

On 30 May 2017, at 00:04, Randall Gellens <rg+ietf@randy.pensive.org> wrote:

I uploaded version -10, which includes the syntax change to single line, along with a few editorial clarifications.  (Version -09 accidently omitted an editorial clarification.)

You can see a diff of the changes from 08 to 10 here:
https://www.ietf.org/rfcdiff?url1=draft-ietf-slim-negotiating-human-language-08&url2=draft-ietf-slim-negotiating-human-language-10

If there objections to the change from multi-line to single-line, this can be reverted.

--Randy



At 2:57 PM -0700 5/28/17, Randall Gellens wrote:

In response to Adam Roach's comments as well as other comments, I intend to update the draft to collapse the attribute syntax to one line; each attribute can occur at most once per media, with all languages on the same line.  This will further reduce the size of the SDP block.

If you object to this, please reply.

Here is the section of Adam's review:

At 8:31 PM +0000 3/28/17, Sabrina Tanamal via RT wrote:
 I'll note that much of this can be fixed if the syntax is collapsed so
 that each media section can have at most one hlang-send and one
 hlang-receive, each of which contain a list of one or more languages
 that can be sent or received. This is also much more consistent with the
 way SDP attributes are used in general. The presence of a "*" token on
 that line would indicate the "call should happen even without matching
 languages" characteristic; since there is only one place to add this
 indicator, the ambiguity of some lines indicating it and others not
 disappears. The preceding example would collapse to:

 m=audio 49250 RTP/AVP 20
 a=hlang-send:es eu en *
 a=hlang-recv:es eu en *

 ...and the example text would be revised to remove the implication that
 *sending* "es" necessarily implies *receiving* "es".

 I'll further note that the majority of SDP libraries I've worked with
 would make accessing the all-on-one-line format easier than
 one-line-per-language as well.

Here is the proposed ABNF:

   Attribute Syntax:

      hlang-value =  Language-Tag *( SP Language-tag ) [ SP asterisk ]

                           ; Language-Tag as defined in BCP 47

      asterisk    =  "*"   ; an asterisk (ASCII %2A) character

      sp          =  1*" " ; one or more ASCII space (%20) characters

--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
If forced to travel on an airplane, try and get in the cabin with
the Captain, so you can keep an eye on him and nudge him if he
falls asleep or point out any mountains looming up ahead ...
       --Mike Harding, The Armchair Anarchist's Almanac.

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


--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Knowledge always desires increase; it is like fire, which must
first be kindled by some external agent, but which will afterwards
propagate itself.                       --Dr. Samuel Johnson

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

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. 



_______________________________________________
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
--------------7A798E40B88B286CAFF617E2-- From nobody Thu Jun 1 08:07:43 2017 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 9F78E12ECB7 for ; Thu, 1 Jun 2017 08:07:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 A1Ja9WGHHnKc for ; Thu, 1 Jun 2017 08:07:38 -0700 (PDT) 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 83F3712ECB6 for ; Thu, 1 Jun 2017 08:07:33 -0700 (PDT) X-Halon-ID: 07846893-46dc-11e7-bca7-0050569116f7 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [77.53.231.21]) by bin-vsp-out-03.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Thu, 1 Jun 2017 17:07:28 +0200 (CEST) To: "slim@ietf.org" From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: Date: Thu, 1 Jun 2017 17:07:28 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------D6A30C39EBC94C1A9F946EA3" Archived-At: Subject: [Slim] Thoughts on negotiation for the real-time case 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, 01 Jun 2017 15:07:42 -0000 This is a multi-part message in MIME format. --------------D6A30C39EBC94C1A9F946EA3 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit While we are waiting on decisions on the outstanding issues, I think it can be fruitful to spend some thoughts about the negotiation for the real-time case. ( I am sorry if this investigation again surfaces the already known shortcomings, but please read it also for other observations.) *Look at this use case* Disregarding routing, we assume that a call from a caller reaches a callee UA and a callee. The callee UA is provided with the language preferences of the callee by some settings. The callee UA can either do the negotiation and compose an answer autonomously or interact with the user to compose an answer. In both cases, the callee must be informed about which modalities and languages the callee is supposed to select from (or is supposed to use if only one alternative remains), for starting the conversation. Knowing that, the callee answers and expresses a greeting in a selected language and modality. The caller gets the answer and also needs to be informed about the outcome of the negotiation, so that the caller can start the conversation in an acceptable modality and language. Section 3 in the draft indicates that we can have many languages per media stream in the offer, but only one language per media stream in the answer. We can have many media streams in both the offer and answer. Assume an offer containing spoken languages en, fr and written en, all both ways Assume a callee UA configured for spoken sp, fr, en and written en, all both ways Assume that the callee UA autonomously takes the decision. It needs some algorithms. There is no guidance in the current draft about how to handle the two media. We have a match on written English both ways, but no way to decide if the callee shall start using spoken or written. That may be handled by a built-in algorithm saying "use spoken whenever available". For slection among the matching spoken languages, in this case it can be either polite to the caller and select spoken 'en' both ways, or it can be convenient for the callee and select 'fr' both ways. Selecting different spoken languages in the different directions is not recommended according to the note at end of 5.5. So, assuming we have the callee UA set to the polite algorithm, and to use spoken whenever there is a match, the UA might answer spoken en both ways and written en both ways, and provide the information to the callee to SPEAK ENGLISH, and provide the matching languages as additional information. The answer will be displayed to the caller and the caller can tune in to listen to English and talk English and know that the text stream can be used as occasional fall-back for written English. Having a callee UA requiring interaction with the user to take the decisions results in very similar exchange. The user may have some out-of-band experience that tells that for this caller, it will be better to use written English, or spoken French. But the decision will be taken and likely one spoken language and written English will be included in the answer and the call starting in a similar way as in the autonomous case. The negotiation supports the initial exchange in the call. It is the ambition that it shall be close to the most convenient choice for both parties, but they are free to change language and modality during the call if they find reasons to do so. It is inconvenient and time consuming to change language, so it is best if the initial selection is a good choice. --------------------------------------------------- Can we learn something from this example and other thoughts about negotiation? *1. The negotiation seems to work reasonably well for both the autonomous and interactive UA style in this case.* *2. There are things we cannot express that may lead to a less optimized decisions:* *2.1 Languages in the same modality are automatically assigned different preferences, even if the user want to rate them equal. * A possibility to rate them equal would enable a better match for the case when one user has a preference and the other has not. This shortcoming can lead to less optimized decisions on how to start the call, but there will seldomly be any major inconveniences. *No change urgently needed* *2.2 Preference between modalities cannot be expressed* Languages in different modalities provide no guidance for which one to select if there is a match in more than one modality. Local algorithms or interaction with the user must be used to take the decision on how to start the call. An algorithm that says "use spoken whenever there is a match in spoken" may be useful in many cases, but very unfavourable for the calling user who strongly prefers written, but can just barely manage spoken. This is a severe shortcoming of the current draft. *A way to indicate most preferred modality or preference across all modalities is needed.* *2.3 Requirement to only have one language per media in the answer. * The requirement in section 3 and 5.2 to only have one language per media in the answer has both good and bad influence. It is good that a consistent decision needs to be taken and the callee will get exact guidance for what language to use for each media and direction. If the decision is made by the callee UA autonomously, the callee may by external information get the impression that the decision is not optimal, but the UA will require the user to start the call in one specific language and it would be confusing to deviate from that decision. The user will feel controlled by the device. It may be less fortunate that the caller does not get the full picture about the callee language capabilities if the initially selection turns out to be inconvenient. However, there is a limit for what information a user is able to take in during a call, so this limitation is not likely to have any severe influence on the user satisfaction. If the users feel a need to switch language during the call, they may figure out what is more suitable. The callee has the full information and can guide to a good switch. *No change urgently needed.* *3. No way to differentiate a need for two simultaneous media from a need for two alternative media.* This shortcoming was not visible from the example above. If for example the calling user requires to receive both spoken and written form of language simultaneously to grasp the contents, there is currently no way to indicate that need for simultaneous use of different media. Both media can be included, and assigned language indications, but it will be interpreted as if it is alternatives to select from. A way to indicate that one media is another representation of another media and that they are provided together is needed for these cases. The need exists in both the offer and the answer. *An addition for expression of simultaneous modalities is needed.* *4. Different preferences in different directions.* The current draft can express different set of language capabilities in different directions. The decision algorithm will be capable of deciding to use one media and language in one direction and one media and language in the other direction. Local algorithms may be needed for selecting the same language in both directions in most cases even if different media are used. However, if the user has some, but much lower capabilities for a language in the opposite direction to a preferred language and direction, there is currently no way to express this difference in preference, and there is a huge risk for mistakes in decisions when capability in both directions of the same modality is indicated. Conclusion: There is a possibility to express different capabilities in different directions, but there is a lack of possibilities to express differencies in preference between different modalities in the same direction. *This is the same limitation as described in 2.2 above and requires the same extension.* *Another use case put other light on the negotiation possibilities:* A caller want to speak English and receive written English. In some situations, the user may also be able to receive spoken English but want to have that as last resort. The user is also able to send written text, but so slowly that the user really want to avoid that if possible. The current draft only offers a possibility to send an offer with spoken English both ways and written English both ways. The huge difference in preference between the directions in each media is not possible to indicate. The callee UA and callee is capable of spoken English both ways and written English both ways. The UA can only judge by what is specified and may go from the principle to use spoken whenever there is a match, so spoken English both ways will be selected, and the calling user will be dissatisfied and need to devote time to ask the callee to use text instead of talking. *This example clearly requires a way to indicate differences in preference between different modalities in the same direction. * Regards Gunnar -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 --------------D6A30C39EBC94C1A9F946EA3 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

While we are waiting on decisions on the outstanding issues, I think it can be fruitful to spend some thoughts about the negotiation for the real-time case.

( I am sorry if this investigation again surfaces the already known shortcomings, but please read it also for other observations.)

Look at this use case

Disregarding routing, we assume that a call from a caller reaches a callee UA and a callee.

The callee UA is provided with the language preferences of the callee by some settings.

The callee UA can either do the negotiation and compose an answer autonomously or interact with the user to compose an answer.

In both cases, the callee must be informed about which modalities and languages the callee is supposed to select from (or is supposed to use if only one alternative remains), for starting the conversation.

Knowing that, the callee answers and expresses a greeting in a selected language and modality.

The caller gets the answer and also needs to be informed about the outcome of the negotiation, so that the caller can start the conversation in an acceptable modality and language.

Section 3 in the draft indicates that we can have many languages per media stream in the offer, but only one language per media stream in the answer.  We can have many media streams in both the offer and answer.

Assume an offer containing spoken languages en, fr and written en,  all both ways

Assume a callee UA configured for spoken sp, fr, en and written en, all both ways

Assume that the callee UA autonomously takes the decision. It needs some algorithms. There is no guidance in the current draft about how to handle the two media. We have a match on written English both ways, but no way to decide if the callee shall start using spoken or written.  That may be handled by a built-in algorithm saying "use spoken whenever available".  For slection among the matching spoken languages, in this case it can be either polite to the caller and select spoken 'en' both ways, or it can be convenient for the callee and select 'fr' both ways. Selecting different spoken languages in the different directions is not recommended according to the note at end of 5.5. 

So, assuming we have the callee UA set to the polite algorithm, and to use spoken whenever there is a match, the  UA might answer spoken en both ways and written en both ways, and provide the information to the callee to SPEAK ENGLISH, and provide the matching languages as additional information.

The answer will be displayed to the caller and the caller can tune in to listen to English and talk English and know that the text stream can be used as occasional fall-back for written English.

Having a callee UA requiring interaction with the user to take the decisions results in very similar exchange. The user may have some out-of-band experience that tells that for this caller, it will be better to use written English, or spoken French. But the decision will be taken and likely one spoken language and written English will be included in the answer and the call starting in a similar way as in the autonomous case.

The negotiation supports the initial exchange in the call. It is the ambition that it shall be close to the most convenient choice for both parties, but they are free to change language and modality during the call if they find reasons to do so. It is inconvenient and time consuming to change language, so it is best if the initial selection is a good choice.

---------------------------------------------------

Can we learn something from this example and other thoughts about negotiation?

1. The negotiation seems to work reasonably well for both the autonomous and interactive UA style in this case.

2. There are things we cannot express that may lead to a less optimized decisions:

2.1 Languages in the same modality are automatically assigned different preferences, even if the user want to rate them equal.
A possibility to rate them equal would enable a better match for the case when one user has a preference and the other has not. 

This shortcoming can lead to less optimized decisions on how to start the call, but there will seldomly be any major inconveniences.

No change urgently needed

2.2 Preference between modalities cannot be expressed

Languages in different modalities provide no guidance for which one to select if there is a match in more than one modality. Local algorithms or interaction with the user must be used to take the decision on how to start the call. An algorithm that says "use spoken whenever there is a match in spoken" may be useful in many cases, but very unfavourable for the calling user who strongly prefers written, but can just barely manage spoken. This is a severe shortcoming of the current draft. A way to indicate most preferred modality or preference across all modalities is needed.

2.3 Requirement to only have one language per media in the answer.
The requirement in section 3 and 5.2 to only have one language per media in the answer has both good and bad influence.

It is good that a consistent decision needs to be taken and the callee will get exact guidance for what language to use for each media and direction.

If the decision is made by the callee UA autonomously, the callee may by external information get the impression that the decision is not optimal, but the UA will require the user to start the call in one specific language and it would be confusing to deviate from that decision. The user will feel controlled by the device. 

It may be less fortunate that the caller does not get the full picture about the callee language capabilities if the initially selection turns out to be inconvenient.

However, there is a limit for what information a user is able to take in during a call, so this limitation is not likely to have any severe influence on the user satisfaction. If the users feel a need to switch language during the call, they may figure out what is more suitable. The callee has the full information and can guide to a good switch.

No change urgently needed.

3. No way to differentiate a need for two simultaneous media from a need for two alternative media.

This shortcoming was not visible from the example above.

If for example the calling user requires to receive both spoken and written form of language simultaneously to grasp the contents, there is currently no way to indicate that need for simultaneous use of different media.

Both media can be included, and assigned language indications, but it will be interpreted as if it is alternatives to select from.

A way to indicate that one media is another representation of another media and that they are provided together is needed for these cases. The need exists in both the offer and the answer.

An addition for expression of simultaneous modalities is needed.

4. Different preferences in different directions.

The current draft can express different set of language capabilities in different directions.

The decision algorithm will be capable of deciding to use one media and language in one direction and one media and language in the other direction. Local algorithms may be needed for selecting the same language in both directions in most cases even if different media are used. 

However, if the user has some, but much lower capabilities for a language in the opposite direction to a preferred language and direction, there is currently no way to express this difference in preference, and there is a huge risk for mistakes in decisions when capability in both directions of the same modality is indicated.

Conclusion: There is a possibility to express different capabilities in different directions, but there is a lack of possibilities to express differencies in preference between different modalities in the same direction.

This is the same limitation as described in 2.2 above and requires the same extension.


Another use case put other light on the negotiation possibilities:

A caller want to speak English and receive written English.

In some situations, the user may also be able to receive spoken English but want to have that as last resort.

The user is also able to send written text, but so slowly that the user really want to avoid that if possible.

The current draft only offers a possibility to send an offer with spoken English both ways and written English both ways. The huge difference in preference between the directions in each media is not possible to indicate.

The callee UA and callee is capable of spoken English both ways and written English both ways. The UA can only judge by what is specified and may go from the principle to use spoken whenever there is a match,
 so spoken English both ways will be selected, and the calling user will be dissatisfied and need to devote time to ask the callee to use text instead of talking.

This example clearly requires a way to indicate differences in preference between different modalities in the same direction.


Regards

Gunnar



-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288
--------------D6A30C39EBC94C1A9F946EA3-- From nobody Thu Jun 1 10:03:27 2017 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 7F66E128D6F for ; Thu, 1 Jun 2017 10:03:26 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 goaU6U0ugItc for ; Thu, 1 Jun 2017 10:03:24 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 873E912EB07 for ; Thu, 1 Jun 2017 10:03:23 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Thu, 1 Jun 2017 10:05:39 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <2A61C813-6E0C-488C-9A73-972D47D62719@gsma.com> References: <2A61C813-6E0C-488C-9A73-972D47D62719@gsma.com> X-Mailer: Eudora for Mac OS X Date: Thu, 1 Jun 2017 10:03:12 -0700 To: Natasha Rooney From: Randall Gellens Cc: Gunnar =?iso-8859-1?Q?Hellstr=F6m?= , Bernard Aboba , "slim@ietf.org" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Archived-At: Subject: Re: [Slim] Open Issues on 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, 01 Jun 2017 17:03:26 -0000 At 2:00 PM +0000 6/1/17, Natasha Rooney wrote: >> On 1 Jun 2017, at 14:49, Randall Gellens >> <rg+ietf@randy.pensive.org> >> wrote: >> >> The syntax does not permit a * only, there has to be at least one >> language tag. >> > > That's fine - but can we just explain that somewhere? We do. Section 5.2 says: In an offer, each value MAY have an asterisk appended as the final value. An asterisk appended to either value in an offer indicates a request by the caller to the callee to not fail the call if there is no language in common. See Section 5.3 for more information and discussion. Section 5.3 says: The mechanism for indicating this preference is that, in an offer, if the last value of any 'hlang-recv' or 'hlang-send' for any media is an asterisk, this indicates a request to not fail the call. The called party MAY ignore the indication, e.g., for the emergency services use case, regardless of the absence of an asterisk, a PSAP will likely not fail the call; some call centers might reject a call even if the offer contains an asterisk. Section 6.1 says: Attribute Syntax: hlang-value = Language-Tag *( SP Language-tag ) [ SP asterisk ] ; Language-Tag as defined in BCP 47 asterisk = "*" ; an asterisk (0x2A) character SP = 1*" " ; one or more space (0x20) characters So, the text in both 5.2 and 5.3 make clear that an asterisk may be appended, but can't appear on its own. The text also explains what an asterisk means. The syntax in 6.1 also clearly shows that an asterisk can only appear after one or more language tags. (As a separate issue, Gunnar felt that using the word "value" to mean the set of language tags as well as each language tag or asterisk is confusing, so I'm thinking I will use the word "token" for the second use, to refer to each tag or asterisk.) -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Never look at the trombones, it only encourages them. --Richard Strauss From nobody Thu Jun 1 10:04:04 2017 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 30DC012EB0B for ; Thu, 1 Jun 2017 10:04:02 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 ooM-Xt4siARL for ; Thu, 1 Jun 2017 10:03:59 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 624FA129409 for ; Thu, 1 Jun 2017 10:03:59 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Thu, 1 Jun 2017 10:06:15 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <827326b9-c69b-6bd9-ea0f-708146b185c6@omnitor.se> References: <827326b9-c69b-6bd9-ea0f-708146b185c6@omnitor.se> X-Mailer: Eudora for Mac OS X Date: Thu, 1 Jun 2017 10:03:55 -0700 To: Gunnar =?iso-8859-1?Q?Hellstr=F6m?= , Natasha Rooney From: Randall Gellens Cc: Bernard Aboba , "slim@ietf.org" Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Slim] Open Issues on 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, 01 Jun 2017 17:04:02 -0000 At 4:19 PM +0200 6/1/17, Gunnar Hellstr=F6m wrote: > Den 2017-06-01 kl. 15:49, skrev Randall Gellens: >> At 9:45 AM +0000 6/1/17, Natasha Rooney wrote: >> >>> The last remaining item of Ticket 26 is=20 >>> asking for an explanation of the role of *=20 >>> only. Can we get this added and then close=20 >>> the ticket? >> >> The syntax does not permit a * only, there has=20 >> to be at least one language tag. > I guess that Natasha means that it is only the=20 > description of the use of the asterisk that is=20 > needed in ticket #26. If that is the case, the current text sufficiently explains it. > > I have provided an even better motivated use of=20 > the asterisk as a media level parameter in a=20 > very recent proposal. > It is under subject: "New wording for the use=20 > of the asterisk in=20 > draft-ietf-slim-negotiating-human-language" > It can be entered as a solution proposal for ticket #26. > > I think that without that wording, it is not=20 > possible to have the asterisk as a media level=20 > parameter. > > However, it is depending on Ticket #34. So, a=20 > decision on #34 is needed first. > > Regards > Gunnar > >> >>> >>> I'll address 34 separately. >>> >>> Natasha Rooney | Internet Engineering=20 >>> Director | Internet and Web Team | Technology=20 >>> | GSMA |=20 >>> nrooney@gsma.com |=20 >>> +44 (0) 7730 219 765 | @thisNatasha | Skype:=20 >>> nrooney@gsm.org >>> >>>> On 29 May 2017, at 23:17, Randall Gellens=20 >>>> <rg+ietf@randy.pensive.org>=20 >>>> wrote: >>>> >>>> At 8:49 PM +0200 5/29/17, Gunnar Hellstr=F6m wrote: >>>> >>>>> Den 2017-05-29 kl. 00:15, skrev Randall Gellens: >>>>> >>>>>> I think the edits so far address #19,=20 >>>>>> #27, 28 so they can be closed. #38, #39=20 >>>>>> are addressed in -09 so I will post that=20 >>>>>> and those can be closed. I think #26,=20 >>>>>> #29, #32, #34, #35 were not accepted. >>>>>> >>>>> This is my view: >>>>> >>>>> #26 can be left non-accepted if #34 is accepted. >>>>> >>>> >>>> #26 can be done with an Informational draft=20 >>>> that provides advice to implementers, as=20 >>>> previously discussed. #34 was discussed a=20 >>>> long time ago and it was decided that we did=20 >>>> not need to add complexity and that we would=20 >>>> keep the more simple syntax. >>>> >>>>> But if #34 is not accepted, we could need #26. >>>>> #29 is ok to not accept. All other aspects=20 >>>>> of the attribute registrations are solved. >>>>> >>>>> #34: I have not seen anything about not=20 >>>>> accepting it, so I suggest to accept it. >>>>> #35 syntax for bidirectionally symmetric=20 >>>>> cases - will increase complexity - I would=20 >>>>> suggest to not accept it, but I cannot=20 >>>>> remember that we concluded that before. >>>>> >>>>> #32 requires the two extensions about=20 >>>>> relative preference and simultaneity to be=20 >>>>> solved. We have not said that we would not=20 >>>>> accept #32. I suggest that we accept it. >>>>> >>>> >>>> We've repeatedly decided to not add=20 >>>> relative preferences (nor any coordination=20 >>>> between media) in this draft. This can all=20 >>>> be done in a subsequent draft. >>>> >>>> --Randy >>>> >>>>> >>>>> >>>>> >>>>> Gunnar >>>>> >>>>>> >>>>>> --Randy >>>>>> >>>>>> At 11:25 AM -0700 4/25/17, Bernard Aboba wrote: >>>>>> >>>>>>> Currently 10 Issues remain open from IETF Last Call: >>>>>>> >>>>>>> >>>>>>>=20 >>>>>>> <https://trac.ietf.org/tra= c/slim/report/1>https://trac.ietf.= org/trac/slim/report/1 >>>>>>> >>>>>>> >>>>>>> These include: >>>>>>> >>>>>>> >>>>>>>=20 >>>>>>> <https://trac.ietf.org/trac/slim/report/1?sort=3Dticket&asc=3D1&page=3D= 1>Ticket<https://trac.ietf.org/trac/slim/report/1?sort=3Dsummary&asc=3D1&page= =3D1>Summary<https://trac.ietf.org/trac/slim/report/1?sort=3Dcomponent&asc= =3D1&page=3D1>Component<https://trac.ietf.org/trac/slim/report/1?sort=3Dversio= n&asc=3D1&page=3D1>Version<https://trac.ietf.org/trac/slim/report/1?sort=3Dm= ilestone&asc=3D1&page=3D1>Milestone<https://trac.ietf.org/trac/slim/report/1?sort= =3Dtype&asc=3D1&page=3D1>Type<https://trac.ietf.org/trac/slim/report/1?sort=3Dow= ner&asc=3D1&page=3D1>=20 >>>>>>> Owner<https://trac.ietf.org/trac/slim/report/1?sort=3Dstatus&asc=3D1&pa= ge=3D1>Status<https://trac.ietf.org/trac/slim/report/1?sort=3Dcreated&asc=3D= 1&page=3D1>Created<https://trac.i= etf.org/trac/slim/ticket/27>#27<h= ttps://trac.ietf.org/trac/slim/ticket/27>The=20 >>>>>>> cases in the "Silly states" section 5.4=20 >>>>>>> are not all=20 >>>>>>> silly.negotiating-human-language2.0<https://trac.ietf.org/trac/slim/milestone/milestone1>m= ilestone1defect<mailto:gunnar.hellstrom@= omnitor.se>gunnar.hellstrom@omnito= r.senewMar=20 >>>>>>> 22,=20 >>>>>>> 2017<https://trac.ietf.or= g/trac/slim/ticket/19>#19<https:/= /trac.ietf.org/trac/slim/ticket/19>Use=20 >>>>>>> Media Type registration=20 >>>>>>> templatemultilangcontentenhancement<mailto:rfc.nik.tomkinson@gmail.com>rfc.nik.tomkinson@gmail.comassignedAug=20 >>>>>>> 17,=20 >>>>>>> 2016<https://trac.ietf.or= g/trac/slim/ticket/28>#28<https:/= /trac.ietf.org/trac/slim/ticket/28>Examples=20 >>>>>>> section 5.5 requires=20 >>>>>>> expansionnegotiating-human-language2.0<https://trac.ietf.org/trac/slim/milestone/milestone= 1>milestone1defect2Bietf@randy.p= ensive.org>rg+ietf@randy.pensiv= e.orgassignedMar=20 >>>>>>> 22,=20 >>>>>>> 2017<https://trac.ietf.or= g/trac/slim/ticket/32>#32<https:/= /trac.ietf.org/trac/slim/ticket/32>Audio/Video=20 >>>>>>> Coordinationnegotiating-human-language2.0<https://trac.ietf.org/trac/slim/milestone/milest= one1>milestone1defect2Bietf@rand= y.pensive.org>rg+ietf@randy.pensive.= orgnewMar=20 >>>>>>> 22,=20 >>>>>>> 2017<https://trac.ietf.or= g/trac/slim/ticket/34>#34<https:/= /trac.ietf.org/trac/slim/ticket/34>Use=20 >>>>>>> the Accept-Language=20 >>>>>>> syntaxnegotiating-human-language2.0<https://trac.ietf.org/trac/slim/milestone/milestone1>m= ilestone1defect2Bietf@randy.pens= ive.org>rg+ietf@randy.pensive.o= rgassignedMar=20 >>>>>>> 22,=20 >>>>>>> 2017<https://trac.ietf.or= g/trac/slim/ticket/35>#35<https:/= /trac.ietf.org/trac/slim/ticket/35>Have=20 >>>>>>> an attribute to abbreviate the=20 >>>>>>> bidirectionally-symmetric=20 >>>>>>> casenegotiating-human-language2.0<https://trac.ietf.org/trac/slim/milestone/milestone1>mil= estone1defect2Bietf@randy.pensiv= e.org>rg+ietf@randy.pensive.org= assignedMar=20 >>>>>>> 22,=20 >>>>>>> 2017<https://trac.ietf.or= g/trac/slim/ticket/38>#38<https:/= /trac.ietf.org/trac/slim/ticket/38>Routing=20 >>>>>>> out of=20 >>>>>>> scopenegotiating-human-language1.0<https://trac.ietf.org/trac/slim/milestone/milestone1>mi= lestone1defect<m= ailto:draft-ietf-slim-negotiating-human-language@ietf.org>draft-ietf-slim-negotiating-= human-language@ietf.orgnewApr=20 >>>>>>> 25,=20 >>>>>>> 2017<https://trac.ietf.or= g/trac/slim/ticket/39>#39<https:/= /trac.ietf.org/trac/slim/ticket/39>Syntax=20 >>>>>>> Collapsenegotiating-human-language1.0<https://trac.ietf.org/trac/slim/milestone/milestone1= >milestone1defect<mailto:draft-ietf-slim-negotiating-human-language@ietf.org>draft-ietf-slim-negotiati= ng-human-language@ietf.orgnewApr=20 >>>>>>> 25,=20 >>>>>>> 2017<https://trac.ietf.or= g/trac/slim/ticket/26>#26<https:/= /trac.ietf.org/trac/slim/ticket/26>Make=20 >>>>>>> use of the asterisk modifier on media=20 >>>>>>> level with session scope also for media=20 >>>>>>> level=20 >>>>>>> purposesnegotiating-human-language2.0<https://trac.ietf.org/trac/slim/milestone/milestone1= >milestone1enhancement<mailto:gunnar.hel= lstrom@omnitor.se>gunnar.hellstrom= @omnitor.senewMar=20 >>>>>>> 22,=20 >>>>>>> 2017<https://trac.ietf.or= g/trac/slim/ticket/29>#29<https:/= /trac.ietf.org/trac/slim/ticket/29>Include=20 >>>>>>> more fields for attribute registration=20 >>>>>>> from 4566bis >>>>>>> >>>>>>> _______________________________________________ >>>>>>> SLIM mailing list >>>>>>> SLIM@ietf.org >>>>>>> >>>>>>>=20 >>>>>>> https://www.ietf.org/mai= lman/listinfo/slim >>>>>>> >>>>>> >>>>>> >>>>> >>>>> -- >>>>> ----------------------------------------- >>>>> Gunnar Hellstr=F6m >>>>> Omnitor >>>>> gunnar.hellstrom@omnitor.se >>>>> +46 708 204 288 >>>>> >>>> >>>> >>>> -- >>>> Randall Gellens >>>> Opinions are personal; facts are suspect; I speak for myself on= ly >>>> -------------- Randomly selected tag: --------------- >>>> I do not need to explain why I say things. That's the interesting th= ing >>>> about being the President. Maybe somebody needs to explain to me why >>>> they say something, but I don't feel like I owe anybody an explanatio= n. >>>> --George W. Bush, in an interview with Bob Woodward. >>>> >>>> _______________________________________________ >>>> SLIM mailing list >>>> SLIM@ietf.org >>>> https://www.ietf.org/mailman/listinfo/slim >>>> >>> >>> This email and its attachments are intended=20 >>> for the above named only and may be=20 >>> confidential. If they have come to you in=20 >>> error you must take no action based on them,=20 >>> nor must you copy or show them to anyone;=20 >>> please reply to this email or call +44 207=20 >>> 356 0600 and highlight the error. >> >> > > -- > ----------------------------------------- > Gunnar Hellstr=F6m > Omnitor > gunnar.hellstrom@omnitor.se > +46 708 204 288 -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Voltaire said "The art of government consists of taking as much money as possible from one party of citizens to give to the other." The difference between the dominant political parties is which groups they assign which roles. From nobody Thu Jun 1 10:17:12 2017 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 8651A129A9A for ; Thu, 1 Jun 2017 10:17:11 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 E57tvmtoSJMM for ; Thu, 1 Jun 2017 10:17:09 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 60F6A12F253 for ; Thu, 1 Jun 2017 10:17:09 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Thu, 1 Jun 2017 10:19:26 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Mailer: Eudora for Mac OS X Date: Thu, 1 Jun 2017 10:17:05 -0700 To: Gunnar =?iso-8859-1?Q?Hellstr=F6m?= , slim@ietf.org From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Slim] Collapse attribute syntax to one line 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, 01 Jun 2017 17:17:11 -0000 The group has repeatedly discussed q-values and=20 priority and has always decided to not go down=20 that path. At 4:33 PM +0200 6/1/17, Gunnar Hellstr=F6m wrote: > Den 2017-06-01 kl. 11:54, skrev Natasha Rooney: > >> This seems sufficient given our previous=20 >> conversations. q-values can be applied within=20 >> further work (although I don't see why=20 >> ordering doesn't do the job, works in web). >> > It is not feasible to change syntax by adding=20 > q-values in an extension. That will cause=20 > interop problems, or complicated needs to=20 > negotiate protocol version. So, we need to=20 > decide the syntax now and stick closely to it. > > Ordering is not sufficient because we have a=20 > need to set preferences between different media. > Ordering only works within a media. > > And, a minor drawback: ordering does not allow=20 > to specify a number of languages in the same=20 > media with the same preference. One always will=20 > look as if it is more preferred than another. -=20 > but I think we can live with that. > > Maybe the main question is: Will our own=20 > one-line syntax really be less complex to parse=20 > than the Accept-Language syntax that we might=20 > be able to find ready library routines for? > Adam Roach had views on complexity to parse=20 > different solutions. Maybe you, Adam can have a=20 > view on this? > > Regards > > Gunnar > >> >> Bernard - any further thoughts? >> >> >> Natasha Rooney | Internet Engineering Director=20 >> | Internet and Web Team | Technology | GSMA |=20 >> nrooney@gsma.com |=20 >> +44 (0) 7730 219 765 | @thisNatasha | Skype:=20 >> nrooney@gsm.org >> >>> On 30 May 2017, at 00:04, Randall Gellens=20 >>> <rg+ietf@randy.pensive.org>=20 >>> wrote: >>> >>> I uploaded version -10, which includes the=20 >>> syntax change to single line, along with a=20 >>> few editorial clarifications. (Version -09=20 >>> accidently omitted an editorial=20 >>> clarification.) >>> >>> You can see a diff of the changes from 08 to 10 here: >>>=20 >>> https://www.= ietf.org/rfcdiff?url1=3Ddraft-ietf-slim-negotiating-human-language-08&url2= =3Ddraft-ietf-slim-negotiating-human-language-10 >>> >>> If there objections to the change from=20 >>> multi-line to single-line, this can be=20 >>> reverted. >>> >>> --Randy >>> >>> >>> >>> At 2:57 PM -0700 5/28/17, Randall Gellens wrote: >>> >>>> In response to Adam Roach's comments as well=20 >>>> as other comments, I intend to update the=20 >>>> draft to collapse the attribute syntax to=20 >>>> one line; each attribute can occur at most=20 >>>> once per media, with all languages on the=20 >>>> same line. This will further reduce the size=20 >>>> of the SDP block. >>>> >>>> If you object to this, please reply. >>>> >>>> Here is the section of Adam's review: >>>> >>>> At 8:31 PM +0000 3/28/17, Sabrina Tanamal via RT wrote: >>>> >>>>> I'll note that much of this can be fixed if the syntax is collapsed s= o >>>>> that each media section can have at most one hlang-send and one >>>>> hlang-receive, each of which contain a list of one or more languages >>>>> that can be sent or received. This is also much more consistent with = the >>>>> way SDP attributes are used in general. The presence of a "*" token o= n >>>>> that line would indicate the "call should happen even without matchin= g >>>>> languages" characteristic; since there is only one place to add this >>>>> indicator, the ambiguity of some lines indicating it and others not >>>>> disappears. The preceding example would collapse to: >>>>> >>>>> m=3Daudio 49250 RTP/AVP 20 >>>>> a=3Dhlang-send:es eu en * >>>>> a=3Dhlang-recv:es eu en * >>>>> >>>>> ...and the example text would be revised to remove the implication th= at >>>>> *sending* "es" necessarily implies *receiving* "es". >>>>> >>>>> I'll further note that the majority of SDP libraries I've worked with >>>>> would make accessing the all-on-one-line format easier than >>>>> one-line-per-language as well. >>>>> >>>> >>>> Here is the proposed ABNF: >>>> >>>> Attribute Syntax: >>>> >>>> hlang-value =3D Language-Tag *( SP Language-tag ) [ SP asterisk ] >>>> >>>> ; Language-Tag as defined in BCP 47 >>>> >>>> asterisk =3D "*" ; an asterisk (ASCII %2A) character >>>> >>>> sp =3D 1*" " ; one or more ASCII space (%20) characters >>>> >>>> -- >>>> Randall Gellens >>>> Opinions are personal; facts are suspect; I speak for myself only >>>> -------------- Randomly selected tag: --------------- >>>> If forced to travel on an airplane, try and get in the cabin with >>>> the Captain, so you can keep an eye on him and nudge him if he >>>> falls asleep or point out any mountains looming up ahead ... >>>> --Mike Harding, The Armchair Anarchist's Almanac. >>>> >>>> _______________________________________________ >>>> SLIM mailing list >>>> SLIM@ietf.org >>>>=20 >>>> https://www.ietf.org/mailma= n/listinfo/slim >>>> >>> >>> >>> -- >>> Randall Gellens >>> Opinions are personal; facts are suspect; I speak for myself only >>> -------------- Randomly selected tag: --------------- >>> Knowledge always desires increase; it is like fire, which must >>> first be kindled by some external agent, but which will afterwards >>> propagate itself. --Dr. Samuel Johnson >>> >>> _______________________________________________ >>> SLIM mailing list >>> SLIM@ietf.org >>>=20 >>> https://www.ietf.org/mailman= /listinfo/slim >>> >> >> This email and its attachments are intended=20 >> for the above named only and may be=20 >> confidential. If they have come to you in=20 >> error you must take no action based on them,=20 >> nor must you copy or show them to anyone;=20 >> please reply to this email or call +44 207 356=20 >> 0600 and highlight the error. >> >> >> >> _______________________________________________ >> SLIM mailing list >> SLIM@ietf.org >>=20 >> https://www.ietf.org/mailman/= listinfo/slim >> > > -- > ----------------------------------------- > Gunnar Hellstr=F6m > Omnitor > gunnar.hellstrom@omnitor.se > +46 708 204 288 > > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Snacktrek, n.: The peculiar habit, when searching for a snack, of constantly returning to the refrigerator in hopes that something new will have materialized. --Rich Hall, "Sniglets" From nobody Thu Jun 1 11:01:26 2017 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 A228912EB5C for ; Thu, 1 Jun 2017 11:01:24 -0700 (PDT) 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, 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 ioIpBMNB18y1 for ; Thu, 1 Jun 2017 11:01:21 -0700 (PDT) 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 D200F129A8E for ; Thu, 1 Jun 2017 11:01:20 -0700 (PDT) X-Halon-ID: 4eac9d3b-46f4-11e7-bca7-0050569116f7 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [77.53.231.21]) by bin-vsp-out-03.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Thu, 1 Jun 2017 20:01:16 +0200 (CEST) To: Randall Gellens , slim@ietf.org References: From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: Date: Thu, 1 Jun 2017 20:01:15 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Slim] Collapse attribute syntax to one line 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, 01 Jun 2017 18:01:25 -0000 Den 2017-06-01 kl. 19:17, skrev Randall Gellens: > The group has repeatedly discussed q-values and priority and has > always decided to not go down that path. I expect our shepherd to lead us to the decision. We had one reviewer requesting us to use the Accept-Language syntax with the q-values. I can accept either way, either the one-line syntax used in version -10, or the Accept-Language syntax. If we go with the current one-line syntax, I will propose to add the preference between modalities by giving the asterisk a preference interpretation on media level. And I will propose to use the -t language subtag for simultaneous languages in other modalities. This may lack some flexibility but will likely be sufficient. If we go with the Accept-Language syntax, then I will propose to let the q-values have scope over the whole SDP in order to assign preference between modalities, and I will propose to let equal q-values or q-values within a narrow interval to indicate a preference for using simultaneous languages in different media. The first item is nice and flexible, the second, for simultaneity may be less elegant. I hope you will accept either solution. And do it already in the current draft. So we just need the decision on the Accept-Language syntax proposal and then move on. Regards Gunnar > > At 4:33 PM +0200 6/1/17, Gunnar Hellström wrote: > >> Den 2017-06-01 kl. 11:54, skrev Natasha Rooney: >> >>> This seems sufficient given our previous conversations. q-values >>> can be applied within further work (although I don't see why >>> ordering doesn't do the job, works in web). >>> >> It is not feasible to change syntax by adding q-values in an >> extension. That will cause interop problems, or complicated needs to >> negotiate protocol version. So, we need to decide the syntax now and >> stick closely to it. >> >> Ordering is not sufficient because we have a need to set preferences >> between different media. >> Ordering only works within a media. >> >> And, a minor drawback: ordering does not allow to specify a number >> of languages in the same media with the same preference. One always >> will look as if it is more preferred than another. - but I think we >> can live with that. >> >> Maybe the main question is: Will our own one-line syntax really be >> less complex to parse than the Accept-Language syntax that we might >> be able to find ready library routines for? >> Adam Roach had views on complexity to parse different solutions. >> Maybe you, Adam can have a view on this? >> >> Regards >> >> Gunnar >> >>> >>> Bernard - any further thoughts? >>> >>> >>> Natasha Rooney | Internet Engineering Director | Internet and Web >>> Team | Technology | GSMA | nrooney@gsma.com >>> | +44 (0) 7730 219 765 | @thisNatasha | Skype: >>> nrooney@gsm.org >>> >>>> On 30 May 2017, at 00:04, Randall Gellens >>>> <rg+ietf@randy.pensive.org> wrote: >>>> >>>> I uploaded version -10, which includes the syntax change to single >>>> line, along with a few editorial clarifications. (Version -09 >>>> accidently omitted an editorial clarification.) >>>> >>>> You can see a diff of the changes from 08 to 10 here: >>>> >>>> https://www.ietf.org/rfcdiff?url1=draft-ietf-slim-negotiating-human-language-08&url2=draft-ietf-slim-negotiating-human-language-10 >>>> >>>> >>>> If there objections to the change from multi-line to single-line, >>>> this can be reverted. >>>> >>>> --Randy >>>> >>>> >>>> >>>> At 2:57 PM -0700 5/28/17, Randall Gellens wrote: >>>> >>>>> In response to Adam Roach's comments as well as other comments, I >>>>> intend to update the draft to collapse the attribute syntax to one >>>>> line; each attribute can occur at most once per media, with all >>>>> languages on the same line. This will further reduce the size of >>>>> the SDP block. >>>>> >>>>> If you object to this, please reply. >>>>> >>>>> Here is the section of Adam's review: >>>>> >>>>> At 8:31 PM +0000 3/28/17, Sabrina Tanamal via RT wrote: >>>>> >>>>>> I'll note that much of this can be fixed if the syntax is >>>>>> collapsed so >>>>>> that each media section can have at most one hlang-send and one >>>>>> hlang-receive, each of which contain a list of one or more >>>>>> languages >>>>>> that can be sent or received. This is also much more consistent >>>>>> with the >>>>>> way SDP attributes are used in general. The presence of a "*" >>>>>> token on >>>>>> that line would indicate the "call should happen even without >>>>>> matching >>>>>> languages" characteristic; since there is only one place to add >>>>>> this >>>>>> indicator, the ambiguity of some lines indicating it and others not >>>>>> disappears. The preceding example would collapse to: >>>>>> >>>>>> m=audio 49250 RTP/AVP 20 >>>>>> a=hlang-send:es eu en * >>>>>> a=hlang-recv:es eu en * >>>>>> >>>>>> ...and the example text would be revised to remove the >>>>>> implication that >>>>>> *sending* "es" necessarily implies *receiving* "es". >>>>>> >>>>>> I'll further note that the majority of SDP libraries I've worked >>>>>> with >>>>>> would make accessing the all-on-one-line format easier than >>>>>> one-line-per-language as well. >>>>>> >>>>> >>>>> Here is the proposed ABNF: >>>>> >>>>> Attribute Syntax: >>>>> >>>>> hlang-value = Language-Tag *( SP Language-tag ) [ SP asterisk ] >>>>> >>>>> ; Language-Tag as defined in BCP 47 >>>>> >>>>> asterisk = "*" ; an asterisk (ASCII %2A) character >>>>> >>>>> sp = 1*" " ; one or more ASCII space (%20) characters >>>>> >>>>> -- >>>>> Randall Gellens >>>>> Opinions are personal; facts are suspect; I speak for myself only >>>>> -------------- Randomly selected tag: --------------- >>>>> If forced to travel on an airplane, try and get in the cabin with >>>>> the Captain, so you can keep an eye on him and nudge him if he >>>>> falls asleep or point out any mountains looming up ahead ... >>>>> --Mike Harding, The Armchair Anarchist's Almanac. >>>>> >>>>> _______________________________________________ >>>>> SLIM mailing list >>>>> SLIM@ietf.org >>>>> >>>>> https://www.ietf.org/mailman/listinfo/slim >>>>> >>>>> >>>> >>>> >>>> -- >>>> Randall Gellens >>>> Opinions are personal; facts are suspect; I speak for myself only >>>> -------------- Randomly selected tag: --------------- >>>> Knowledge always desires increase; it is like fire, which must >>>> first be kindled by some external agent, but which will afterwards >>>> propagate itself. --Dr. Samuel Johnson >>>> >>>> _______________________________________________ >>>> SLIM mailing list >>>> SLIM@ietf.org >>>> >>>> https://www.ietf.org/mailman/listinfo/slim >>>> >>>> >>> >>> 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. >>> >>> >>> >>> _______________________________________________ >>> 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 From nobody Thu Jun 1 11:11:06 2017 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 A2864129B77 for ; Thu, 1 Jun 2017 11:11:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 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, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.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 2zi7SKyUdizc for ; Thu, 1 Jun 2017 11:11:02 -0700 (PDT) Received: from mail-qt0-x244.google.com (mail-qt0-x244.google.com [IPv6:2607:f8b0:400d:c0d::244]) (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 C0D0F1200E5 for ; Thu, 1 Jun 2017 11:11:01 -0700 (PDT) Received: by mail-qt0-x244.google.com with SMTP id j13so6671186qta.3 for ; Thu, 01 Jun 2017 11:11:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=gqIDpsxwapx88wlgGfAIhjsx2/foJZD+PLOJduod1Zc=; b=O8DQrnJRzTqJv2cs9xK9gFhv/qRBwqaHE/Jue35p/eS9CGzKCD+z93GbV2Yq+3XQvv vG3+kurwrVkTn+F2HTV88xVHEPdgdWduagS+8XHDbwt00S2EesGPCWAqrQnQwrbW7gGQ Z0mndSRtEEva2ro26uxnW2W4pdCC1AW8s0Zts7MY1tEIrplD3OuqrO8uF50wDqG9ynLL /Fdm9ezR4qRWkLrxtsvdcY2bpWhf96Y4BK9NLhTzndBmaEaJiwyygneEoz0e+CXU/4lz m63o5+dvWH/XtqxdXzkK8jmr4kqN1n1zfAinU8sBEPYH+E8GG34hTkjx5sWEwAZ0Ty+F CUlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=gqIDpsxwapx88wlgGfAIhjsx2/foJZD+PLOJduod1Zc=; b=NW0lgkNI8iEMknxJkr4vi0ZqvtRJ2UPJ7ACW85l6fz4KXAdybPmO3cSSVSyuoF3kme Fh74zCp2urLB4Z+MgWsBsguIAxAJk9uXhe3IWhyz7FKK0SJBKvcWjZxIzNVHT8FEs9hh iOeS68ikNo4srxj1u2PoigbN9QXm2JxYoQC13dMZFQZre9J96/RCSu38ihkw5uoupFGC x8Z8mSYIoTdwLdfsBVSQ6slyJhHcroBBvlplYTZW2ybEFWOc/JjAICzPNTdXhf0XtXy5 NrIa31lrsWHgu8bVB3GYQ00HFLRzpPsrLGBrU4sYmsxrhSEEzrFsBSGtTH8pmuob2xTp 326g== X-Gm-Message-State: AODbwcBl8+mYzJgIC56eEIaTDjbk55Ml51vPtBN9Lc4kJDirUmxv90uT y3oFGlDGuse4uSua X-Received: by 10.200.51.2 with SMTP id t2mr3590050qta.130.1496340660778; Thu, 01 Jun 2017 11:11:00 -0700 (PDT) Received: from [10.96.43.88] (neustar-sthide-nat1.neustar.biz. [156.154.81.54]) by smtp.gmail.com with ESMTPSA id l14sm13379077qtf.40.2017.06.01.11.10.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Jun 2017 11:11:00 -0700 (PDT) From: Brian Rosen Message-Id: <64D68B73-256D-4478-A970-5037B0187D73@brianrosen.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_B144ACB0-D8E2-4DFB-9B1A-8D454374722C" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 1 Jun 2017 14:10:58 -0400 In-Reply-To: Cc: Randall Gellens , slim@ietf.org To: =?utf-8?Q?Gunnar_Hellstr=C3=B6m?= References: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Slim] Collapse attribute syntax to one line 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, 01 Jun 2017 18:11:05 -0000 --Apple-Mail=_B144ACB0-D8E2-4DFB-9B1A-8D454374722C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Gunnar And yet you persist. We have agreed NOT to do preferences between modalities. Any suggestion = that we do so is out of scope for this document. If you want to write a = draft that extends the mechanism, please do and I=E2=80=99ll review it, = but PLEASE don=E2=80=99t keep suggesting that we handle preferences = between media in this document. We agreed NOT to do it. I would prefer the current syntax, and not Accept-Language syntax. Brian > On Jun 1, 2017, at 2:01 PM, Gunnar Hellstr=C3=B6m = wrote: >=20 > Den 2017-06-01 kl. 19:17, skrev Randall Gellens: >> The group has repeatedly discussed q-values and priority and has = always decided to not go down that path. > I expect our shepherd to lead us to the decision. We had one reviewer = requesting us to use the Accept-Language syntax with the q-values. >=20 > I can accept either way, either the one-line syntax used in version = -10, or the Accept-Language syntax. >=20 > If we go with the current one-line syntax, I will propose to add the = preference between modalities by giving the asterisk a preference = interpretation on media level. > And I will propose to use the -t language subtag for simultaneous = languages in other modalities. > This may lack some flexibility but will likely be sufficient. >=20 > If we go with the Accept-Language syntax, then I will propose to let = the q-values have scope over the whole SDP in order to assign preference = between modalities, > and I will propose to let equal q-values or q-values within a narrow = interval to indicate a preference for using simultaneous languages in = different media. The first item is nice and flexible, the second, for = simultaneity may be less elegant. >=20 > I hope you will accept either solution. And do it already in the = current draft. >=20 > So we just need the decision on the Accept-Language syntax proposal = and then move on. >=20 > Regards >=20 > Gunnar >=20 >=20 >=20 >=20 >=20 >=20 >>=20 >> At 4:33 PM +0200 6/1/17, Gunnar Hellstr=C3=B6m wrote: >>=20 >>> Den 2017-06-01 kl. 11:54, skrev Natasha Rooney: >>>=20 >>>> This seems sufficient given our previous conversations. q-values = can be applied within further work (although I don't see why ordering = doesn't do the job, works in web). >>>>=20 >>> It is not feasible to change syntax by adding q-values in an = extension. That will cause interop problems, or complicated needs to = negotiate protocol version. So, we need to decide the syntax now and = stick closely to it. >>>=20 >>> Ordering is not sufficient because we have a need to set preferences = between different media. >>> Ordering only works within a media. >>>=20 >>> And, a minor drawback: ordering does not allow to specify a number = of languages in the same media with the same preference. One always will = look as if it is more preferred than another. - but I think we can live = with that. >>>=20 >>> Maybe the main question is: Will our own one-line syntax really be = less complex to parse than the Accept-Language syntax that we might be = able to find ready library routines for? >>> Adam Roach had views on complexity to parse different solutions. = Maybe you, Adam can have a view on this? >>>=20 >>> Regards >>>=20 >>> Gunnar >>>=20 >>>>=20 >>>> Bernard - any further thoughts? >>>>=20 >>>>=20 >>>> Natasha Rooney | Internet Engineering Director | Internet and Web = Team | Technology | GSMA | nrooney@gsma.com | = +44 (0) 7730 219 765 | @thisNatasha | Skype: = nrooney@gsm.org >>>>=20 >>>>> On 30 May 2017, at 00:04, Randall Gellens = <rg+ietf@randy.pensive.org> wrote: >>>>>=20 >>>>> I uploaded version -10, which includes the syntax change to single = line, along with a few editorial clarifications. (Version -09 accidently = omitted an editorial clarification.) >>>>>=20 >>>>> You can see a diff of the changes from 08 to 10 here: >>>>>=20 >>>>> = https://www.= ietf.org/rfcdiff?url1=3Ddraft-ietf-slim-negotiating-human-language-08&url2= =3Ddraft-ietf-slim-negotiating-human-language-10=20 >>>>>=20 >>>>> If there objections to the change from multi-line to single-line, = this can be reverted. >>>>>=20 >>>>> --Randy >>>>>=20 >>>>>=20 >>>>>=20 >>>>> At 2:57 PM -0700 5/28/17, Randall Gellens wrote: >>>>>=20 >>>>>> In response to Adam Roach's comments as well as other comments, I = intend to update the draft to collapse the attribute syntax to one line; = each attribute can occur at most once per media, with all languages on = the same line. This will further reduce the size of the SDP block. >>>>>>=20 >>>>>> If you object to this, please reply. >>>>>>=20 >>>>>> Here is the section of Adam's review: >>>>>>=20 >>>>>> At 8:31 PM +0000 3/28/17, Sabrina Tanamal via RT wrote: >>>>>>=20 >>>>>>> I'll note that much of this can be fixed if the syntax is = collapsed so >>>>>>> that each media section can have at most one hlang-send and one >>>>>>> hlang-receive, each of which contain a list of one or more = languages >>>>>>> that can be sent or received. This is also much more consistent = with the >>>>>>> way SDP attributes are used in general. The presence of a "*" = token on >>>>>>> that line would indicate the "call should happen even without = matching >>>>>>> languages" characteristic; since there is only one place to add = this >>>>>>> indicator, the ambiguity of some lines indicating it and others = not >>>>>>> disappears. The preceding example would collapse to: >>>>>>>=20 >>>>>>> m=3Daudio 49250 RTP/AVP 20 >>>>>>> a=3Dhlang-send:es eu en * >>>>>>> a=3Dhlang-recv:es eu en * >>>>>>>=20 >>>>>>> ...and the example text would be revised to remove the = implication that >>>>>>> *sending* "es" necessarily implies *receiving* "es". >>>>>>>=20 >>>>>>> I'll further note that the majority of SDP libraries I've worked = with >>>>>>> would make accessing the all-on-one-line format easier than >>>>>>> one-line-per-language as well. >>>>>>>=20 >>>>>>=20 >>>>>> Here is the proposed ABNF: >>>>>>=20 >>>>>> Attribute Syntax: >>>>>>=20 >>>>>> hlang-value =3D Language-Tag *( SP Language-tag ) [ SP asterisk ] >>>>>>=20 >>>>>> ; Language-Tag as defined in BCP 47 >>>>>>=20 >>>>>> asterisk =3D "*" ; an asterisk (ASCII %2A) character >>>>>>=20 >>>>>> sp =3D 1*" " ; one or more ASCII space (%20) characters >>>>>>=20 >>>>>> -- >>>>>> Randall Gellens >>>>>> Opinions are personal; facts are suspect; I speak for myself only >>>>>> -------------- Randomly selected tag: --------------- >>>>>> If forced to travel on an airplane, try and get in the cabin with >>>>>> the Captain, so you can keep an eye on him and nudge him if he >>>>>> falls asleep or point out any mountains looming up ahead ... >>>>>> --Mike Harding, The Armchair Anarchist's Almanac. >>>>>>=20 >>>>>> _______________________________________________ >>>>>> SLIM mailing list >>>>>> SLIM@ietf.org >>>>>>=20 >>>>>> = https://www.ietf.org/mailman/l= istinfo/slim=20 >>>>>>=20 >>>>>=20 >>>>>=20 >>>>> -- >>>>> Randall Gellens >>>>> Opinions are personal; facts are suspect; I speak for myself only >>>>> -------------- Randomly selected tag: --------------- >>>>> Knowledge always desires increase; it is like fire, which must >>>>> first be kindled by some external agent, but which will afterwards >>>>> propagate itself. --Dr. Samuel Johnson >>>>>=20 >>>>> _______________________________________________ >>>>> SLIM mailing list >>>>> SLIM@ietf.org >>>>>=20 >>>>> = https://www.ietf.org/mailman/l= istinfo/slim=20 >>>>>=20 >>>>=20 >>>> 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. >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> SLIM mailing list >>>> SLIM@ietf.org >>>>=20 >>>> = https://www.ietf.org/mailman/l= istinfo/slim=20 >>>>=20 >>>=20 >>> -- >>> ----------------------------------------- >>> Gunnar Hellstr=C3=B6m >>> Omnitor >>> gunnar.hellstrom@omnitor.se >>> +46 708 204 288 >>>=20 >>> _______________________________________________ >>> SLIM mailing list >>> SLIM@ietf.org >>> 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 > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim = --Apple-Mail=_B144ACB0-D8E2-4DFB-9B1A-8D454374722C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Gunnar

And = yet you persist.

We have agreed NOT to do preferences between modalities. =  Any suggestion that we do so is out of scope for this document. =  If you want to write a draft that extends the mechanism, please do = and I=E2=80=99ll review it, but PLEASE don=E2=80=99t keep suggesting = that we handle preferences between media in this document.  We = agreed NOT to do it.

I would prefer the current syntax, and not Accept-Language = syntax.

Brian

On Jun 1, 2017, at 2:01 PM, = Gunnar Hellstr=C3=B6m <gunnar.hellstrom@omnitor.se> wrote:

Den 2017-06-01 kl. 19:17, skrev = Randall Gellens:
The group has repeatedly discussed q-values and priority and = has always decided to not go down that path.
I expect our shepherd to lead us to the = decision. We had one reviewer requesting us to use the Accept-Language = syntax with the q-values.

I can accept either way, either the one-line = syntax used in version -10, or the Accept-Language syntax.
If we go with the current one-line syntax, I = will propose to add the preference between modalities by giving the = asterisk a preference interpretation on media level.
And I will propose to use the -t language subtag = for simultaneous languages in other modalities.
This may lack some flexibility but will likely = be sufficient.

If we go with the = Accept-Language syntax, then I will propose to let the q-values have = scope over the whole SDP in order to assign preference between = modalities,
and I will propose to let equal q-values = or q-values within a narrow interval to indicate a preference for using = simultaneous languages in different media. The first item is nice and = flexible, the second, for simultaneity may be less elegant.
I hope you will accept either solution. And do = it already in the current draft.

So we just need the decision on the = Accept-Language syntax proposal and then move on.
Regards

Gunnar


At 4:33 PM = +0200 6/1/17, Gunnar Hellstr=C3=B6m wrote:

Den 2017-06-01 kl. = 11:54, skrev Natasha Rooney:

This seems sufficient given our previous = conversations. q-values can be applied within further work (although I = don't see why ordering doesn't do the job, works in web).

It is not feasible to change = syntax by adding q-values in an extension. That will cause interop = problems, or complicated needs to negotiate protocol version. So, we = need to decide the syntax now and stick closely to it.

Ordering is not sufficient because we have a need to set = preferences between different media.
Ordering only works = within a media.

And, a minor drawback: = ordering does not allow to specify a number of languages in the same = media with the same preference. One always will look as if it is more = preferred than another. - but I think we can live with that.

Maybe the main question is: Will our own = one-line syntax really be less complex to parse than the Accept-Language = syntax that we might be able to find ready library routines for?
Adam Roach had views on complexity to parse different = solutions. Maybe you, Adam can have a view on this?

Regards

Gunnar


Bernard - = any further thoughts?


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

On 30 May = 2017, at 00:04, Randall Gellens <<mailto:rg+ietf@randy.pensive.org>rg+ietf@randy.pensive.org> wrote:

I uploaded version -10, which includes the syntax change to = single line, along with a few editorial clarifications. (Version -09 = accidently omitted an editorial clarification.)

You can see a diff of the changes from 08 to 10 here:

<https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-slim-negotiating= -human-language-08&url2=3Ddraft-ietf-slim-negotiating-human-language-1= 0>https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-slim-negotiating= -human-language-08&url2=3Ddraft-ietf-slim-negotiating-human-language-1= 0 
If there objections to the change from multi-line to = single-line, this can be reverted.

--Randy


At 2:57 PM = -0700 5/28/17, Randall Gellens wrote:

In response to Adam = Roach's comments as well as other comments, I intend to update the draft = to collapse the attribute syntax to one line; each attribute can occur = at most once per media, with all languages on the same line. This will = further reduce the size of the SDP block.

If = you object to this, please reply.

Here is = the section of Adam's review:

At 8:31 PM = +0000 3/28/17, Sabrina Tanamal via RT wrote:

I'll note that much of = this can be fixed if the syntax is collapsed so
that each = media section can have at most one hlang-send and one
hlang-receive, each of which contain a list of one or more = languages
that can be sent or received. This is also much = more consistent with the
way SDP attributes are used in = general. The presence of a "*" token on
that line would = indicate the "call should happen even without matching
languages" characteristic; since there is only one place to = add this
indicator, the ambiguity of some lines indicating = it and others not
disappears. The preceding example would = collapse to:

m=3Daudio 49250 RTP/AVP 20
a=3Dhlang-send:es eu en *
a=3Dhlang-recv:es eu = en *

...and the example text would be = revised to remove the implication that
*sending* "es" = necessarily implies *receiving* "es".

I'll = further note that the majority of SDP libraries I've worked with
would make accessing the all-on-one-line format easier = than
one-line-per-language as well.


Here is the proposed ABNF:

Attribute Syntax:

hlang-value =3D Language-Tag *( SP Language-tag ) [ SP = asterisk ]

; Language-Tag as defined in BCP = 47

asterisk =3D "*" ; an asterisk (ASCII = %2A) character

sp =3D 1*" " ; one or more = ASCII space (%20) characters

--
Randall Gellens
Opinions are personal; facts = are suspect; I speak for myself only
-------------- = Randomly selected tag: ---------------
If forced to travel = on an airplane, try and get in the cabin with
the Captain, = so you can keep an eye on him and nudge him if he
falls = asleep or point out any mountains looming up ahead ...
--Mike Harding, The Armchair Anarchist's Almanac.

_______________________________________________
SLIM mailing list
<mailto:SLIM@ietf.org>SLIM@ietf.org

<https://www.ietf.org/mailman/listinfo/slim>https://www.ietf.org/mailman/listinfo/slim 



--
Randall Gellens
Opinions are personal; facts = are suspect; I speak for myself only
-------------- = Randomly selected tag: ---------------
Knowledge always = desires increase; it is like fire, which must
first be = kindled by some external agent, but which will afterwards
propagate itself. --Dr. Samuel Johnson

_______________________________________________
SLIM mailing list
<mailto:SLIM@ietf.org>SLIM@ietf.org

<https://www.ietf.org/mailman/listinfo/slim>https://www.ietf.org/mailman/listinfo/slim 


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.


_______________________________________________
SLIM mailing list
<mailto:SLIM@ietf.org>SLIM@ietf.org

<https://www.ietf.org/mailman/listinfo/slim>https://www.ietf.org/mailman/listinfo/slim 


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

_______________________________________________
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

= --Apple-Mail=_B144ACB0-D8E2-4DFB-9B1A-8D454374722C-- From nobody Thu Jun 1 11:16:55 2017 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 372FB12F280 for ; Thu, 1 Jun 2017 11:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 7F-iu0QAtjxT for ; Thu, 1 Jun 2017 11:16:50 -0700 (PDT) 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 B22B312F287 for ; Thu, 1 Jun 2017 11:16:49 -0700 (PDT) X-Halon-ID: 77ce4ca0-46f6-11e7-bca7-0050569116f7 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [77.53.231.21]) by bin-vsp-out-03.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Thu, 1 Jun 2017 20:16:44 +0200 (CEST) To: Randall Gellens , slim@ietf.org References: <149609884905.14640.4714137651572553743@ietfa.amsl.com> <54839aba-7ac8-79e4-74f8-927eb455d8af@omnitor.se> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <029e25ca-fbf7-b6b1-9432-497f2dfb5a0a@omnitor.se> Date: Thu, 1 Jun 2017 20:16:43 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------ED8651E774AD1C06607C1931" Archived-At: Subject: Re: [Slim] I-D Action: draft-ietf-slim-negotiating-human-language-10.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: Thu, 01 Jun 2017 18:16:54 -0000 This is a multi-part message in MIME format. --------------ED8651E774AD1C06607C1931 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit New info on 2.5 below Den 2017-05-31 kl. 21:23, skrev Gunnar Hellström: > Den 2017-05-31 kl. 15:57, skrev Randall Gellens: >> At 10:58 AM +0200 5/31/17, Gunnar Hellström wrote: >> >>> Randall, >>> >>> Your response on change proposal 2 caused a more thorough review of >>> weak points in the reasoning in section 5.2. >>> >>> So, change 2 expanded to a number of sub-proposals that, when >>> accepted, should result in less risk for mis-interpretations. >>> >>> See also the other comments. >>> >>> Thanks, >>> >>> Gunnar >>> >>> >>> Den 2017-05-31 kl. 01:56, skrev Randall Gellens: >>> >>>> At 10:51 PM +0200 5/30/17, Gunnar Hellström wrote: >>>> >>>>> Randall, >>>>> >>>>> good to see progress. >>>>> >>>>> I have a few edit proposals: >>>>> >>>>> ---Change 1--- >>>>> >>>>> Last two lines of 1. Introduction >>>>> >>>>> When the draft is ready, it is no draft anymore. Plus divide the >>>>> aspects in two sentences. >>>>> >>>>> ----old text--- >>>>> >>>>> To reduce the complexity of the solution, this draft focuses on >>>>> negotiating language per media; routing is out of scope. >>>>> >>>>> ---New text--- >>>>> >>>>> To keep the complexity of the solution low, this document focuses on >>>>> negotiating language per media. Routing aspects are out of scope. >>>>> >>>>> -- end of change 1. ---- >>>>> >>>> >>>> The use of "draft" was an error, I'll change it to "document." I >>>> prefer the semicolon to maintain the two parts since it has closer >>>> linkage between the two than would a period. >>>> >>> Accepted. >>> >>>> >>>>> >>>>> ---Change 2 -- >>>>> >>>>> Last lines of 5.2 >>>>> >>>>> We must be clear about that the result normally is alternative >>>>> languages to use, normally not simultaneously. Without this >>>>> clarification, we are not better than the old SDP lang attribute. >>>>> >>>>> ---Old text --- >>>>> Note that media and language negotiation might result in more media >>>>> streams being accepted than are needed by the users (e.g., if more >>>>> preferred and less preferred combinations of media and language are >>>>> all accepted). This is not a problem. >>>>> >>>>> ---New text ---- >>>>> Without any further indications of preferences or requirements >>>>> for simultaneity, the language indications should be seen as >>>>> alternatives to select from. Media and language negotiation might >>>>> result in more media streams and languages being accepted than are >>>>> needed by the users >>>>> (e.g., if more preferred and less preferred combinations of media >>>>> and language are >>>>> all accepted). >>>>> >>>>> ---End of change 2 --- >>>>> >>>> >>>> I don't think it's true that we're no better off than the old SDP >>>> lang attribute, for multiple reasons, not least of which is that >>>> 'lang' is not used for negotiating language in interactive media. >>>> Further, I think the result of extra streams is that there are >>>> extra streams that probably won't be used. >>>> >>> I just mean that it must be absolutely clear that the language >>> indications for the same direction are alternatives to select from, >>> and not an indication that they will be used simultaneously. (not >>> until we have the extension sorted out that will indicate >>> simultaneous use in specific cases). >>> >>> The problem we had with 'Lang' was that the intention was not >>> absolutely clear if it was about alternatives or simultaneous usage. >>> You read it one way and I read it another way. >>> >>> In 5.2 we still have wording that can be read as if offering or >>> answering with two languages in the same direction will imply that >>> the user is prepared to use both simultaneously. We must be sure >>> that the normal case means that the languages are alternatives to >>> select from. >>> >>> Multiple reviewers indicated that they had problems understanding >>> our attributes. Some read it as if we have some pairing specified >>> and others saw other relations that we have not intended. I think we >>> need to take these warnings from independent readers and sort out >>> any risk for mis-interpretation of our intentions. >>> >>> Making a new effort to sort this out completely in 5.2 gives us: >>> >>> --Change 2.1-- >>> --Old text 2.1-- >>> This document defines two media-level attributes starting with >>> 'hlang' (short for "human interactive language") to negotiate which >>> human language is used in each interactive media stream. >>> --New text 2.1--- >>> This document defines two media-level attributes starting with >>> 'hlang' (short for "human interactive language") to negotiate which >>> human language alternative(s) the users are prepared to use in >>> each interactive media stream. >> >> I think the editorial clarifications have resolved any potential >> confusion noted by the previous reviewers. Further, the current >> wording only discusses language per media, while the text in 5.2 >> explicitly says that it's possible that some media might not be >> used. I think the combination makes it clear that there is >> absolutely no expectation that users use all languages since it >> clearly says they might not use all media. I do not think the >> wording "language alternative(s)" is good; I think it introduces more >> confusion. However, I can change "language is used" to "language is >> selected for use" for clarity. > Accepted >> >>> >>> >>> >>> --End of change 2.1--- >>> >>> --Old text 2.2--- >>> Each can appear in an offer for a media >>> stream. >>> --New text 2.2--- >>> Each can appear in an offer and answer for a media >>> stream. >>> >>> >>> --End of change 2.2--- >>> >>> ---Old text 2.3 --- >>> >>> In an offer, the 'hlang-send' value is a list of one or more >>> language(s) the offerer is willing to use when sending using the >>> media, and the 'hlang-recv' value is a list of one or more >>> language(s) the offerer is willing to use when receiving using the >>> media. >>> ----New text 2.3--- >>> In an offer, the 'hlang-send' value is a list of one or more >>> alternative language(s) the offerer is willing to use when >>> sending using the >>> media, and the 'hlang-recv' value is a list of one or more >>> alternative language(s) the offerer is willing to use when >>> receiving using the >>> media. >>> >>> >>> ---End of change 2.3--- >>> >>> ---Old text 2.4 --- >>> The list of languages is in preference order (first is most >>> preferred). >>> ---New text 2.4--- >>> The list of alternative languages is in preference order (first >>> is most >>> preferred). >>> >>> >>> ---End of change 2.4--- > Did you accept 2.2, 2.3, 2.4 ? >>> >>> ---Change 2.5----- >>> Requiring exactly one language per direction in the answer requires >>> a tight coupling between the device and the user that we have >>> avoided to specify. It would require either that the device takes >>> the negotiation decision and dictates to the user e.g. "SPEAK GERMAN >>> NOW !, or that there is a user interface interaction to decide which >>> language to answer in, e.g. "The calling part may accept French or >>> German, indicate here which one you will answer with". >>> >>> We do not want to dictate that kind of tight coupling, and >>> therefore must allow a number of alternative languages in various >>> media to appear in the answer. >>> >>> ---Old text 2.5--- >>> In an answer, 'hlang-send' is the language the answerer will send >>> when using the media (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 in the media (which in most cases is >>> one >>> of the languages in the offer's 'hlang-send'). >>> ---New text 2.5--- >>> In an answer, 'hlang-send' may be one or a list of alternative >>> languages the >>> answerer will select from for sending if using the media for language >>> (which in most cases is one of the languages in the offer's >>> 'hlang-recv'), >>> and 'hlang-recv' may be one or a list of alternative languages the >>> answerer >>> can accept to receive if the media is used for language (which in >>> most cases is one >>> of the languages in the offer's 'hlang-send'). >> >> Having one language per media in the answer has been part of the >> draft all along. I don't recall seeing an objection to this before. >> Further, Section 3 has said all along that attempting to negotiate >> multiple languages per media is out of scope: >> >> (Negotiating multiple simultaneous languages within a media stream is >> out of scope of this document.) > Yes, the user will only use one language. But have you thought > about the consequences for how to accomplish a negotiation result of > just one language in a media, and just that language will also be used > by the answering human? > > It will require tight coupling in the user interface of a kind that > you do not want to discuss. If the UA decides that the answering part > will send spoken german, then that needs to be conveyed to the user. > If the UA instead lets the user decide, then there must be a > question-answer exchange between the UA and the user to enable the UA > to have just one language for the media in the answer. > > We have agreed that some kind of such coupling is needed, and we do > not specify how. But the requirements on the operation will be much > less strict if we allow a list of languages per media to be the result > of the negotiation. > > The paranthesis " (Negotiating multiple simultaneous languages > within a media stream is > out of scope of this document.) " will then apply to the user. > > > This is a quite new finding from when trying to think through a real > negotiation, so I am prepared to discuss how strict we should be. After the exercise with the negotiation today, I see that I can relax this requirement. But it needs to be clear that the negotiated language in a media just maybe used for language. So that it is clear that no simultaneous use is normally required. That leads to --New text 2.5 --- 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 in the media (which in most cases is one of the languages in the offer's 'hlang-send'). ---end of 2.5 ------------------------- Gunnar > > >> >>> >>> >>> ---End of change 2.5 >>> >>> ---Old text 2.6--- >>> >>> When placing an emergency call, and in any other case where the >>> language cannot be inferred from context, in an offer each media >>> stream primarily intended for human language communication SHOULD >>> specify both (or for asymmetrical language use, one of) the 'hlang- >>> send' and 'hlang-recv' attributes. >>> ---New text 2.6--- >>> When placing an emergency call, and in any other case where the >>> language cannot be inferred from context, in an offer each media >>> stream primarily intended as an alternative for human language >>> communication SHOULD >>> specify both (or for asymmetrical language use, one of) the 'hlang- >>> send' and 'hlang-recv' attributes. >> >> I don't think this text is needed. A stream can be negotiated as >> being intended for human interactive communication but the text says >> the stream might not be used. > I think "primarily intended for human language communication" is a > quite strong indication that the purpose is to use it. I wanted to > reduce that impression by inserting the "as an alternative". >> >>> >>> >>> --End of change 2.6--- >>> >>> >>> ---Old text 2.7--- >>> Clients acting on behalf of end users are expected to set one or both >>> 'hlang-send' and 'hlang-recv' attributes on each media stream >>> primarily intended for human communication in an offer when placing >>> an outgoing session, >>> ---New text 2.7--- >>> Clients acting on behalf of end users are expected to set one or both >>> 'hlang-send' and 'hlang-recv' attributes on each media stream >>> primarily intended as an alternative for human communication in >>> an offer when placing >>> an outgoing session, >> >> I don't think this text is needed. A stream can be negotiated as >> being intended for human interactive communication but the text says >> the stream might not be used. > Again - "intended" is strong and may need to be weakened to > indicate that it might not be used. >> >> >>> >>> >>> ---End of change 2.7--- >>> >>> ---Old text 2.8--- >>> >>> Note that media and language negotiation might result in more media >>> streams being accepted than are needed by the users (e.g., if more >>> preferred and less preferred combinations of media and language are >>> all accepted). This is not a problem. >>> ---New text 2.8--- >>> Media and language negotiation might result in more media >>> streams and language alternatives being accepted than are needed by >>> the users (e.g., if more preferred and less preferred combinations >>> of media and language are all accepted). The users are expected to >>> sort out which media and language alternatives to really use in the >>> session, possibly supported by using refined indications. >> >> If you think such text is needed, I suggest putting in a separate >> document containing advice to implementers, where you can go into >> detail on how the indications function. > You may delete the last phrase after the comma. The remaining > part describes better the real situation than the current text. > We take the discussion about refined indications separately. > > >> >>> >>> >>> ---End of change 2.8---- >>> >>>> >>>>> >>>>> ---Change 3--- >>>>> >>>>> In 5.3 >>>>> >>>>> sharpen up the description on how to use the asterisk. The >>>>> current description confused most reviewers. >>>>> >>>>> ---old text---- >>>>> >>>>> The mechanism for indicating this preference is that, in an >>>>> offer, if >>>>> the last value of either 'hlang-recv' or 'hlang-send' is an >>>>> asterisk, >>>>> this indicates a request to not fail the call. >>>>> >>>>> ---new text--- >>>>> The mechanism for indicating this preference is that, in an >>>>> offer, if >>>>> the last parameter of any 'hlang-recv' or 'hlang-send' value in >>>>> the whole SDP >>>>> is an asterisk, this indicates a request to not fail the call. >>>>> >>>>> ---end of change 3--- >>>>> >>>> >>>> I think it's more clear to word it as so: >>>> >>>> The mechanism for indicating this preference is that, in an offer, if >>>> the last value of any 'hlang-recv' or 'hlang-send' for any media is >>>> an asterisk, this indicates a request to not fail the call. The >>>> called party MAY ignore the indication, e.g., for the emergency >>>> services use case, regardless of the absence of an asterisk, a PSAP >>>> will likely not fail the call; some call centers might reject a call >>>> even if the offer contains an asterisk. >>>> >>> The important part was to change from "either" to "any", so >>> that is good. >>> >>> But we should also be strict about what we call the parts of the >>> attribute values. >>> I prefer to call the whole string after 'hlang-recv:" or >>> 'hlang-send:' the "value", and the separate language tags or >>> asterisk then being "parameters" of that value. I think it is >>> inconsistent to say that "the last value of the attribute value" may >>> be an asterisk. Better to say that "the last parameter of the value" >>> may be an asterisk. > Did you accept to call the language tags and the asterisk > "parameters" of the value, instead of values in the value? >>> >>> (I will return to the asterisk with a separate proposal for how to >>> use its placement for something useful.) >> >> Such proposal should go in a separate document containing advice to >> implementers. >> >>> >>>> >>>>> >>>>> ----Change 4--- >>>>> >>>>> In 5.5, >>>>> >>>>> Some example shows use of sign language one way and text the other. >>>>> >>>>> ---Old text---- >>>>> >>>>> Note that, even though the examples all show the same language >>>>> >>>>> --New text---- >>>>> Note that, even though most examples show the same language >>>>> >>>>> ---End of change 4---- >>>>> >>>> >>>> The text does say "(even when the modality differs)" to cover >>>> this, but for clarification, I can delete "all" and add "(or >>>> essentially the same)": >>>> >>> I think of the case when a deaf-blind person prefers to send a >>> sign language and receive a written language. These languages do not >>> have the same language tags even if they are used in the same >>> geographic region. >> >> Yes, the language tags are different between the spoken/written form >> of a language and the signed form. That's what the "essentially the >> same" means. Can you suggest a better description of the commonality >> between these forms? > I think "essentially the same" will do. It can mean "in most cases > the same" as well as "close to the same". > >> >>> >>> We also have the working cases when I accept to receive Norweigan >>> but speak Swedish myself, or someone accepting to receive Italian, >>> but want to speak Spanish themselves, and other similar language >>> mixes. These cases will more likely be satisfied not by true >>> language matching, but by never using the request to fail the call, >>> and let the users sort out the communication with some guidance from >>> the indications. (both seeing what the other party expects will >>> prepare them for the a bit unusual language mix.) >>> >>> Your proposed change will work for these cases. Accepted. >>> >>>> >>>> Note that, even though the examples show the same (or essentially the >>>> same) language being used in both directions (even when the modality >>>> differs), there is no requirement that this be the case. However, in >>>> practice, doing so is likely to increase the chances of successful >>>> matching. >>>> >>> ---Change 5--- >>> >>>>> >>>>> In 6.1. >>>>> >>>>> SDP values are UTF-8 coded, not ASCII. >>>>> >>>>> ---Old text--- >>>>> >>>>> >>>>> >>>>> asterisk = "*" ; an asterisk (ASCII %2A) character >>>>> >>>>> sp = 1*" " ; one or more ASCII space (%20) characters >>>>> >>>>> ---New text--- >>>>> >>>>> >>>>> asterisk = "*" ; an asterisk (%x2A) character >>>>> >>>>> SP = 1*" " ; one or more space (%x20) characters >>>>> >>>>> --End of change 5 ---- >>>>> >>>> >>>> I'll change "ASCII %" to "0x" for clarity. >>>> >>> Note also the change from "sp" to "SP" >> >> Thanks, fixed. > > Thanks, > Gunnar >> >>> >>>> >>>>> >>>>> -- >>>>> >>>>> Regards >>>>> Gunnar >>>>> >>>>> >>>>> Den 2017-05-30 kl. 01:00, skrev >>>>> internet-drafts@ietf.org: >>>>> >>>>>> >>>>>> 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 of the IETF. >>>>>> >>>>>> Title : Negotiating Human Language in Real-Time Communications >>>>>> Author : Randall Gellens >>>>>> Filename : draft-ietf-slim-negotiating-human-language-10.txt >>>>>> Pages : 17 >>>>>> Date : 2017-05-29 >>>>>> >>>>>> 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 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-10 >>>>>> >>>>>> >>>>>> >>>>>> https://datatracker.ietf.org/doc/html/draft-ietf-slim-negotiating-human-language-10 >>>>>> >>>>>> >>>>>> A diff from the previous version is available at: >>>>>> >>>>>> >>>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-slim-negotiating-human-language-10 >>>>>> >>>>>> >>>>>> >>>>>> 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/ >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>> >>> _______________________________________________ >>> 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 --------------ED8651E774AD1C06607C1931 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

New info on 2.5 below


Den 2017-05-31 kl. 21:23, skrev Gunnar Hellström:
Den 2017-05-31 kl. 15:57, skrev Randall Gellens:
At 10:58 AM +0200 5/31/17, Gunnar Hellström wrote:

 Randall,

 Your response on change proposal 2 caused a more thorough review of weak points in the reasoning in section 5.2.

 So, change 2 expanded to a number of sub-proposals that, when accepted, should result in less risk for mis-interpretations.

 See also the other comments.

 Thanks,

 Gunnar


 Den 2017-05-31 kl. 01:56, skrev Randall Gellens:

 At 10:51 PM +0200 5/30/17, Gunnar Hellström wrote:

 Randall,

 good to see progress.

 I have a few edit proposals:

 ---Change 1---

 Last two lines of 1. Introduction

 When the draft is ready, it is no draft anymore. Plus divide the aspects in two sentences.

 ----old text---

 To reduce the complexity of the solution, this draft focuses on
 negotiating language per media; routing is out of scope.

 ---New text---

 To keep the complexity of the solution low, this document focuses on
 negotiating language per media. Routing aspects are out of scope.

 -- end of change 1. ----


 The use of "draft" was an error, I'll change it to "document." I prefer the semicolon to maintain the two parts since it has closer linkage between the two than would a period.

 <GH>Accepted.



 ---Change 2 --

 Last lines of 5.2

 We must be clear about that the result normally is alternative languages to use, normally not simultaneously. Without this clarification, we are not better than the old SDP lang attribute.

 ---Old text ---
 Note that media and language negotiation might result in more media
 streams being accepted than are needed by the users (e.g., if more
 preferred and less preferred combinations of media and language are
 all accepted). This is not a problem.

 ---New text ----
 Without any further indications of preferences or requirements for simultaneity, the language indications should be seen as alternatives to select from. Media and language negotiation might result in more media streams and languages being accepted than are needed by the users
 (e.g., if more preferred and less preferred combinations of media and language are
 all accepted).

 ---End of change 2 ---


 I don't think it's true that we're no better off than the old SDP lang attribute, for multiple reasons, not least of which is that 'lang' is not used for negotiating language in interactive media. Further, I think the result of extra streams is that there are extra streams that probably won't be used.

 <GH> I just mean that it must be absolutely clear that the language indications for the same direction are alternatives to select from, and not an indication that they will be used simultaneously. (not until we have the extension sorted out that will indicate simultaneous use in specific cases).

 The problem we had with 'Lang' was that the intention was not absolutely clear if it was about alternatives or simultaneous usage. You read it one way and I read it another way.

 In 5.2 we still have wording that can be read as if offering or answering with two languages in the same direction will imply that the user is prepared to use both simultaneously. We must be sure that the normal case means that the languages are alternatives to select from.

 Multiple reviewers indicated that they had problems understanding our attributes. Some read it as if we have some pairing specified and others saw other relations that we have not intended. I think we need to take these warnings from independent readers and sort out any risk for mis-interpretation of our intentions.

 Making a new effort to sort this out completely in 5.2 gives us:

 --Change 2.1--
 --Old text 2.1--
    This document defines two media-level attributes starting with
    'hlang' (short for "human interactive language") to negotiate which
    human language is used in each interactive media stream.
 --New text 2.1---
    This document defines two media-level attributes starting with
    'hlang' (short for "human interactive language") to negotiate which
    human language alternative(s) the users are prepared to use in each interactive media stream.

I think the editorial clarifications have resolved any potential confusion noted by the previous reviewers.  Further, the current wording only discusses language per media, while the text in 5.2 explicitly says that it's possible that some media might not be used.  I think the combination makes it clear that there is absolutely no expectation that users use all languages since it clearly says they might not use all media.  I do not think the wording "language alternative(s)" is good; I think it introduces more confusion.  However, I can change "language is used" to "language is selected for use" for clarity.
<GH>Accepted




 --End of change 2.1---

 --Old text 2.2---
    Each can appear in an offer for a media
    stream.
 --New text 2.2---
    Each can appear in an offer and answer for a media
    stream.


 --End of change 2.2---

 ---Old text 2.3 ---

  In an offer, the 'hlang-send' value is a list of one or more
    language(s) the offerer is willing to use when sending using the
    media, and the 'hlang-recv' value is a list of one or more
    language(s) the offerer is willing to use when receiving using the
    media.
 ----New text 2.3---
  In an offer, the 'hlang-send' value is a list of one or more
    alternative language(s) the offerer is willing to use when sending using the
    media, and the 'hlang-recv' value is a list of one or more
    alternative language(s) the offerer is willing to use when receiving using the
    media.


 ---End of change 2.3---

 ---Old text 2.4 ---
    The list of languages is in preference order (first is most
    preferred).
 ---New text 2.4---
    The list of alternative languages is in preference order (first is most
    preferred).


 ---End of change 2.4---
<GH>Did you accept 2.2, 2.3, 2.4 ?

 ---Change 2.5-----
 Requiring exactly one language per direction in the answer requires a tight coupling between the device and the user that we have avoided to specify. It would require either that the device takes the negotiation decision and dictates to the user e.g. "SPEAK GERMAN NOW !, or that there is a user interface interaction to decide which language to answer in, e.g. "The calling part may accept French or German, indicate here which one you will answer with".

 We do not want to dictate that kind of tight coupling, and therefore must allow a number of alternative languages in various media to appear in the answer.

 ---Old text 2.5---
  In an answer, 'hlang-send' is the language the answerer will send
    when using the media (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 in the media (which in most cases is one
    of the languages in the offer's 'hlang-send').
 ---New text 2.5---
  In an answer, 'hlang-send' may be one or a list of alternative languages the
  answerer will select from for sending if using the media for language
 (which in most cases is one of the languages in the offer's 'hlang-recv'),
 and 'hlang-recv' may be one or a list of alternative languages the answerer
  can accept to receive if the media is used for language (which in most cases is one
    of the languages in the offer's 'hlang-send').

Having one language per media in the answer has been part of the draft all along.  I don't recall seeing an objection to this before.  Further, Section 3 has said all along that attempting to negotiate multiple languages per media is out of scope:

   (Negotiating multiple simultaneous languages within a media stream is
   out of scope of this document.)
<GH>Yes, the user will only use one language. But have you thought about the consequences for how to accomplish a negotiation result of just one language in a media, and just that language will also be used by the answering human?

It will require tight coupling in the user interface of a kind that you do not want to discuss. If the UA decides that the answering part will send spoken german, then that needs to be conveyed to the user.  If the UA instead lets the user decide, then there must be a question-answer exchange between the UA and the user to enable the UA to have just one language for the media in the answer.

We have agreed that some kind of such coupling is needed, and we do not specify how. But the requirements on the operation will be much less strict if we allow a list of languages per media to be the result of the negotiation.

The paranthesis "   (Negotiating multiple simultaneous languages within a media stream is
   out of scope of this document.) " will then apply to the user.


This is a quite new finding from when trying to think through a real negotiation, so I am prepared to discuss how strict we should be.
<GH>After the exercise with the negotiation today, I see that I can relax this requirement.
But it needs to be clear that the negotiated language in a media just maybe used for language.
So that it is clear that no simultaneous use is normally required.

That leads to
--New text 2.5 ---
  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 in the media (which in most cases is one
    of the languages in the offer's 'hlang-send').

 ---end of 2.5 -------------------------

Gunnar

 



 ---End of change 2.5

 ---Old text 2.6---

  When placing an emergency call, and in any other case where the
    language cannot be inferred from context, in an offer each media
    stream primarily intended for human language communication SHOULD
    specify both (or for asymmetrical language use, one of) the 'hlang-
    send' and 'hlang-recv' attributes.
 ---New text 2.6---
  When placing an emergency call, and in any other case where the
    language cannot be inferred from context, in an offer each media
    stream primarily intended as an alternative for human language communication SHOULD
    specify both (or for asymmetrical language use, one of) the 'hlang-
    send' and 'hlang-recv' attributes.

I don't think this text is needed.  A stream can be negotiated as being intended for human interactive communication but the text says the stream might not be used.
<GH>I think "primarily intended for human language communication" is a quite strong indication that the purpose is to use it. I wanted to reduce that impression by inserting the "as an alternative".



 --End of change 2.6---


 ---Old text 2.7---
  Clients acting on behalf of end users are expected to set one or both
    'hlang-send' and 'hlang-recv' attributes on each media stream
    primarily intended for human communication in an offer when placing
    an outgoing session,
 ---New text 2.7---
  Clients acting on behalf of end users are expected to set one or both
    'hlang-send' and 'hlang-recv' attributes on each media stream
    primarily intended as an alternative for human communication in an offer when placing
    an outgoing session,

I don't think this text is needed.  A stream can be negotiated as being intended for human interactive communication but the text says the stream might not be used.
<GH>Again - "intended" is strong and may need to be weakened to indicate that it might not be used.




 ---End of change 2.7---

 ---Old text 2.8---

  Note that media and language negotiation might result in more media
    streams being accepted than are needed by the users (e.g., if more
    preferred and less preferred combinations of media and language are
    all accepted).  This is not a problem.
  ---New text 2.8---
  Media and language negotiation might result in more media
    streams and language alternatives being accepted than are needed by
    the users (e.g., if more preferred and less preferred combinations
    of media and language are all accepted).  The users are expected to
    sort out which media and language alternatives to really use in the
    session, possibly supported by using refined indications.

If you think such text is needed, I suggest putting in a separate document containing advice to implementers, where you can go into detail on how the indications function.
<GH> You may delete the last phrase after the comma. The remaining part describes better the real situation than the current text.
We take the discussion about refined indications separately.

 



 ---End of change 2.8----



 ---Change 3---

 In 5.3

 sharpen up the description on how to use the asterisk. The current description confused most reviewers.

 ---old text----

 The mechanism for indicating this preference is that, in an offer, if
 the last value of either 'hlang-recv' or 'hlang-send' is an asterisk,
 this indicates a request to not fail the call.

 ---new text---
 The mechanism for indicating this preference is that, in an offer, if
 the last parameter of any 'hlang-recv' or 'hlang-send' value in the whole SDP
 is an asterisk, this indicates a request to not fail the call.

 ---end of change 3---


 I think it's more clear to word it as so:

 The mechanism for indicating this preference is that, in an offer, if
 the last value of any 'hlang-recv' or 'hlang-send' for any media is
 an asterisk, this indicates a request to not fail the call. The
 called party MAY ignore the indication, e.g., for the emergency
 services use case, regardless of the absence of an asterisk, a PSAP
 will likely not fail the call; some call centers might reject a call
 even if the offer contains an asterisk.

 <GH> The important part was to change from "either" to "any", so that is good.

 But we should also be strict about what we call the parts of the attribute values.
 I prefer to call the whole string after 'hlang-recv:" or 'hlang-send:' the "value", and the separate language tags or asterisk then being "parameters" of that value. I think it is inconsistent to say that "the last value of the attribute value" may be an asterisk. Better to say that "the last parameter of the value" may be an asterisk.
<GH>Did you accept to call the language tags and the asterisk "parameters" of the value, instead of values in the value?

 (I will return to the asterisk with a separate proposal for how to use its placement for something useful.)

Such proposal should go in a separate document containing advice to implementers.




 ----Change 4---

 In 5.5,

 Some example shows use of sign language one way and text the other.

 ---Old text----

 Note that, even though the examples all show the same language

 --New text----
 Note that, even though most examples show the same language

 ---End of change 4----


 The text does say "(even when the modality differs)" to cover this, but for clarification, I can delete "all" and add "(or essentially the same)":

 <GH>I think of the case when a deaf-blind person prefers to send a sign language and receive a written language. These languages do not have the same language tags even if they are used in the same geographic region.

Yes, the language tags are different between the spoken/written form of a language and the signed form.  That's what the "essentially the same" means.  Can you suggest a better description of the commonality between these forms?
<GH>I think "essentially the same" will do. It can mean "in most cases the same" as well as "close to the same".
 


 We also have the working cases when I accept to receive Norweigan but speak Swedish myself, or someone accepting to receive Italian, but want to speak Spanish themselves, and other similar language mixes. These cases will more likely be satisfied not by true language matching, but by never using the request to fail the call, and let the users sort out the communication with some guidance from the indications. (both seeing what the other party expects will prepare them for the a bit unusual language mix.)

 Your proposed change will work for these cases. Accepted.


 Note that, even though the examples show the same (or essentially the
 same) language being used in both directions (even when the modality
 differs), there is no requirement that this be the case. However, in
 practice, doing so is likely to increase the chances of successful
 matching.

 ---Change 5---


 In 6.1.

 SDP values are UTF-8 coded, not ASCII.

 ---Old text---



 asterisk = "*" ; an asterisk (ASCII %2A) character

 sp = 1*" " ; one or more ASCII space (%20) characters

 ---New text---


 asterisk = "*" ; an asterisk (%x2A) character

 SP = 1*" " ; one or more space (%x20) characters

 --End of change 5 ----


 I'll change "ASCII %" to "0x" for clarity.

 <GH> Note also the change from "sp" to "SP"

Thanks, fixed.

Thanks,
Gunnar




 --

 Regards
 Gunnar


 Den 2017-05-30 kl. 01:00, skrev <mailto:internet-drafts@ietf.org><mailto:internet-drafts@ietf.org><mailto:internet-drafts@ietf.org>internet-drafts@ietf.org:


 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 of the IETF.

 Title : Negotiating Human Language in Real-Time Communications
 Author : Randall Gellens
 Filename : draft-ietf-slim-negotiating-human-language-10.txt
 Pages : 17
 Date : 2017-05-29

 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 SDP media
 attributes.


 The IETF datatracker status page for this draft is:


<https://datatracker.ietf.org/doc/draft-ietf-slim-negotiating-human-language/><https://datatracker.ietf.org/doc/draft-ietf-slim-negotiating-human-language/><https://datatracker.ietf.org/doc/draft-ietf-slim-negotiating-human-language/>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-10><https://tools.ietf.org/html/draft-ietf-slim-negotiating-human-language-10><https://tools.ietf.org/html/draft-ietf-slim-negotiating-human-language-10>https://tools.ietf.org/html/draft-ietf-slim-negotiating-human-language-10


<https://datatracker.ietf.org/doc/html/draft-ietf-slim-negotiating-human-language-10><https://datatracker.ietf.org/doc/html/draft-ietf-slim-negotiating-human-language-10><https://datatracker.ietf.org/doc/html/draft-ietf-slim-negotiating-human-language-10>https://datatracker.ietf.org/doc/html/draft-ietf-slim-negotiating-human-language-10

 A diff from the previous version is available at:


<https://www.ietf.org/rfcdiff?url2=draft-ietf-slim-negotiating-human-language-10><https://www.ietf.org/rfcdiff?url2=draft-ietf-slim-negotiating-human-language-10><https://www.ietf.org/rfcdiff?url2=draft-ietf-slim-negotiating-human-language-10>https://www.ietf.org/rfcdiff?url2=draft-ietf-slim-negotiating-human-language-10


 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/><ftp://ftp.ietf.org/internet-drafts/><ftp://ftp.ietf.org/internet-drafts/>ftp://ftp.ietf.org/internet-drafts/

 _______________________________________________
 SLIM mailing list

<mailto:SLIM@ietf.org><mailto:SLIM@ietf.org><mailto:SLIM@ietf.org>SLIM@ietf.org


<https://www.ietf.org/mailman/listinfo/slim><https://www.ietf.org/mailman/listinfo/slim><https://www.ietf.org/mailman/listinfo/slim>https://www.ietf.org/mailman/listinfo/slim


 --
 -----------------------------------------
 Gunnar Hellström
 Omnitor

<mailto:gunnar.hellstrom@omnitor.se><mailto:gunnar.hellstrom@omnitor.se><mailto:gunnar.hellstrom@omnitor.se>gunnar.hellstrom@omnitor.se
 +46 708 204 288

 _______________________________________________
 SLIM mailing list
 <mailto:SLIM@ietf.org>SLIM@ietf.org

<https://www.ietf.org/mailman/listinfo/slim>https://www.ietf.org/mailman/listinfo/slim




 --
 -----------------------------------------
 Gunnar Hellström
 Omnitor
 <mailto:gunnar.hellstrom@omnitor.se>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

-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288
--------------ED8651E774AD1C06607C1931-- From nobody Thu Jun 1 11:23:53 2017 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 4A193127077 for ; Thu, 1 Jun 2017 11:23:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, 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=comcast.net 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 v2jz5kEKZZ9l for ; Thu, 1 Jun 2017 11:23:49 -0700 (PDT) Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (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 EE206129C4B for ; Thu, 1 Jun 2017 11:23:48 -0700 (PDT) Received: from resomta-ch2-07v.sys.comcast.net ([69.252.207.103]) by resqmta-ch2-08v.sys.comcast.net with SMTP id GUjfdn4h6AfZsGUlAdNdcu; Thu, 01 Jun 2017 18:23:48 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1496341428; bh=LBlO/8W/FcVf1AeptSxBSbwmbeQaoq8Ws3u+fswfvlU=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=RH+1flg3jLvt0AKaWHrqi5QvQlcxb2X3BCu3plpBrbezDTMR8uB5Ljd6t7n81tnJq IeQZEizLh0lbRo5+RMKjd7lqSQ+iX64kHKBQVADFMFvHsu2pbWb1n8ZLtGrAS3Pq0o +1/mTMYZ4OpVWhuHCRYezCUUp1SuJJv8VFxmpx+XpjC4+ahXx4YhYwAkYVuvSGm31R 3ffJvpPBWyNW5JWDJLGuMyU2K6H1k5XLYJFZ2eWgFxoGoD9mhoqKLIzlV8V09HZDG2 ZXWwYoMw/CfLReriURGvUEbI7WxbwtRcMmkEcLcaAkqRkAcGDoeBmgj0iiQPWzTKVm 5AlC/ejKpFOyg== Received: from [192.168.1.110] ([24.62.227.142]) by resomta-ch2-07v.sys.comcast.net with SMTP id GUl9dZF5pt1ZsGUl9dxPJv; Thu, 01 Jun 2017 18:23:48 +0000 To: slim@ietf.org References: <64D68B73-256D-4478-A970-5037B0187D73@brianrosen.net> From: Paul Kyzivat Message-ID: Date: Thu, 1 Jun 2017 14:23:47 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <64D68B73-256D-4478-A970-5037B0187D73@brianrosen.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfGKXTd2lGvPrMVvfZVKQbpPlCzNIlFjf57PDOes6XtpMn/UguXydVASPyvV0GmKB/br1Hn/1lg2Ha8Ii9oEmThn448ir92ZUizMxxK/ALtsNm8gBp67l z3JnFdPN6K7HpI9r55RKa6KVzIo8r1FfKnGDwsIckNVQaad6/L3rZ4T/ Archived-At: Subject: Re: [Slim] Collapse attribute syntax to one line 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, 01 Jun 2017 18:23:51 -0000 On 6/1/17 2:10 PM, Brian Rosen wrote: > Gunnar > > And yet you persist. > > We have agreed NOT to do preferences between modalities. Any suggestion > that we do so is out of scope for this document. If you want to write a > draft that extends the mechanism, please do and I’ll review it, but > PLEASE don’t keep suggesting that we handle preferences between media in > this document. We agreed NOT to do it. > > I would prefer the current syntax, and not Accept-Language syntax. How about enhancing the syntax to support parameters for the values, but only as a future extension mechanism? Unknown parameters to be ignored. Then at least the hooks will be there to introduce something later if desired. Thanks, Paul > Brian > >> On Jun 1, 2017, at 2:01 PM, Gunnar Hellström >> > wrote: >> >> Den 2017-06-01 kl. 19:17, skrev Randall Gellens: >>> The group has repeatedly discussed q-values and priority and has >>> always decided to not go down that path. >> I expect our shepherd to lead us to the decision. We had one reviewer >> requesting us to use the Accept-Language syntax with the q-values. >> >> I can accept either way, either the one-line syntax used in version >> -10, or the Accept-Language syntax. >> >> If we go with the current one-line syntax, I will propose to add the >> preference between modalities by giving the asterisk a preference >> interpretation on media level. >> And I will propose to use the -t language subtag for simultaneous >> languages in other modalities. >> This may lack some flexibility but will likely be sufficient. >> >> If we go with the Accept-Language syntax, then I will propose to let >> the q-values have scope over the whole SDP in order to assign >> preference between modalities, >> and I will propose to let equal q-values or q-values within a narrow >> interval to indicate a preference for using simultaneous languages in >> different media. The first item is nice and flexible, the second, for >> simultaneity may be less elegant. >> >> I hope you will accept either solution. And do it already in the >> current draft. >> >> So we just need the decision on the Accept-Language syntax proposal >> and then move on. >> >> Regards >> >> Gunnar >> >> >> >> >> >> >>> >>> At 4:33 PM +0200 6/1/17, Gunnar Hellström wrote: >>> >>>> Den 2017-06-01 kl. 11:54, skrev Natasha Rooney: >>>> >>>>> This seems sufficient given our previous conversations. q-values >>>>> can be applied within further work (although I don't see why >>>>> ordering doesn't do the job, works in web). >>>>> >>>> It is not feasible to change syntax by adding q-values in an >>>> extension. That will cause interop problems, or complicated needs to >>>> negotiate protocol version. So, we need to decide the syntax now and >>>> stick closely to it. >>>> >>>> Ordering is not sufficient because we have a need to set preferences >>>> between different media. >>>> Ordering only works within a media. >>>> >>>> And, a minor drawback: ordering does not allow to specify a number >>>> of languages in the same media with the same preference. One always >>>> will look as if it is more preferred than another. - but I think we >>>> can live with that. >>>> >>>> Maybe the main question is: Will our own one-line syntax really be >>>> less complex to parse than the Accept-Language syntax that we might >>>> be able to find ready library routines for? >>>> Adam Roach had views on complexity to parse different solutions. >>>> Maybe you, Adam can have a view on this? >>>> >>>> Regards >>>> >>>> Gunnar >>>> >>>>> >>>>> Bernard - any further thoughts? >>>>> >>>>> >>>>> Natasha Rooney | Internet Engineering Director | Internet and Web >>>>> Team | Technology | GSMA | >>>>> nrooney@gsma.com >>>>> | +44 (0) 7730 219 765 | @thisNatasha | Skype: >>>>> nrooney@gsm.org >>>>> >>>>>> On 30 May 2017, at 00:04, Randall Gellens >>>>>> <rg+ietf@randy.pensive.org >>>>>> > wrote: >>>>>> >>>>>> I uploaded version -10, which includes the syntax change to single >>>>>> line, along with a few editorial clarifications. (Version -09 >>>>>> accidently omitted an editorial clarification.) >>>>>> >>>>>> You can see a diff of the changes from 08 to 10 here: >>>>>> >>>>>> https://www.ietf.org/rfcdiff?url1=draft-ietf-slim-negotiating-human-language-08&url2=draft-ietf-slim-negotiating-human-language-10 >>>>>> >>>>>> If there objections to the change from multi-line to single-line, >>>>>> this can be reverted. >>>>>> >>>>>> --Randy >>>>>> >>>>>> >>>>>> >>>>>> At 2:57 PM -0700 5/28/17, Randall Gellens wrote: >>>>>> >>>>>>> In response to Adam Roach's comments as well as other comments, I >>>>>>> intend to update the draft to collapse the attribute syntax to >>>>>>> one line; each attribute can occur at most once per media, with >>>>>>> all languages on the same line. This will further reduce the size >>>>>>> of the SDP block. >>>>>>> >>>>>>> If you object to this, please reply. >>>>>>> >>>>>>> Here is the section of Adam's review: >>>>>>> >>>>>>> At 8:31 PM +0000 3/28/17, Sabrina Tanamal via RT wrote: >>>>>>> >>>>>>>> I'll note that much of this can be fixed if the syntax is >>>>>>>> collapsed so >>>>>>>> that each media section can have at most one hlang-send and one >>>>>>>> hlang-receive, each of which contain a list of one or more languages >>>>>>>> that can be sent or received. This is also much more consistent >>>>>>>> with the >>>>>>>> way SDP attributes are used in general. The presence of a "*" >>>>>>>> token on >>>>>>>> that line would indicate the "call should happen even without >>>>>>>> matching >>>>>>>> languages" characteristic; since there is only one place to add this >>>>>>>> indicator, the ambiguity of some lines indicating it and others not >>>>>>>> disappears. The preceding example would collapse to: >>>>>>>> >>>>>>>> m=audio 49250 RTP/AVP 20 >>>>>>>> a=hlang-send:es eu en * >>>>>>>> a=hlang-recv:es eu en * >>>>>>>> >>>>>>>> ...and the example text would be revised to remove the >>>>>>>> implication that >>>>>>>> *sending* "es" necessarily implies *receiving* "es". >>>>>>>> >>>>>>>> I'll further note that the majority of SDP libraries I've worked >>>>>>>> with >>>>>>>> would make accessing the all-on-one-line format easier than >>>>>>>> one-line-per-language as well. >>>>>>>> >>>>>>> >>>>>>> Here is the proposed ABNF: >>>>>>> >>>>>>> Attribute Syntax: >>>>>>> >>>>>>> hlang-value = Language-Tag *( SP Language-tag ) [ SP asterisk ] >>>>>>> >>>>>>> ; Language-Tag as defined in BCP 47 >>>>>>> >>>>>>> asterisk = "*" ; an asterisk (ASCII %2A) character >>>>>>> >>>>>>> sp = 1*" " ; one or more ASCII space (%20) characters >>>>>>> >>>>>>> -- >>>>>>> Randall Gellens >>>>>>> Opinions are personal; facts are suspect; I speak for myself only >>>>>>> -------------- Randomly selected tag: --------------- >>>>>>> If forced to travel on an airplane, try and get in the cabin with >>>>>>> the Captain, so you can keep an eye on him and nudge him if he >>>>>>> falls asleep or point out any mountains looming up ahead ... >>>>>>> --Mike Harding, The Armchair Anarchist's Almanac. >>>>>>> >>>>>>> _______________________________________________ >>>>>>> SLIM mailing list >>>>>>> SLIM@ietf.org >>>>>>> >>>>>>> https://www.ietf.org/mailman/listinfo/slim >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Randall Gellens >>>>>> Opinions are personal; facts are suspect; I speak for myself only >>>>>> -------------- Randomly selected tag: --------------- >>>>>> Knowledge always desires increase; it is like fire, which must >>>>>> first be kindled by some external agent, but which will afterwards >>>>>> propagate itself. --Dr. Samuel Johnson >>>>>> >>>>>> _______________________________________________ >>>>>> SLIM mailing list >>>>>> SLIM@ietf.org >>>>>> >>>>>> https://www.ietf.org/mailman/listinfo/slim >>>>>> >>>>> >>>>> 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. >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >> >> _______________________________________________ >> SLIM mailing list >> SLIM@ietf.org >> https://www.ietf.org/mailman/listinfo/slim > > > > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim > From nobody Thu Jun 1 11:28:07 2017 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 8137112F280 for ; Thu, 1 Jun 2017 11:28:05 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 DMQBI_fQerQO for ; Thu, 1 Jun 2017 11:28:04 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 6CAD5129C4B for ; Thu, 1 Jun 2017 11:28:04 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Thu, 1 Jun 2017 11:30:21 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <029e25ca-fbf7-b6b1-9432-497f2dfb5a0a@omnitor.se> References: <149609884905.14640.4714137651572553743@ietfa.amsl.com> <54839aba-7ac8-79e4-74f8-927eb455d8af@omnitor.se> <029e25ca-fbf7-b6b1-9432-497f2dfb5a0a@omnitor.se> X-Mailer: Eudora for Mac OS X Date: Thu, 1 Jun 2017 11:28:01 -0700 To: Gunnar =?iso-8859-1?Q?Hellstr=F6m?= , slim@ietf.org From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Slim] I-D Action: draft-ietf-slim-negotiating-human-language-10.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: Thu, 01 Jun 2017 18:28:05 -0000 Edited down for clarity. At 8:16 PM +0200 6/1/17, Gunnar Hellstr=F6m wrote: >>>> >>>> ---Change 2.5----- >>>> Requiring exactly one language per direction=20 >>>> in the answer requires a tight coupling=20 >>>> between the device and the user that we have=20 >>>> avoided to specify. It would require either=20 >>>> that the device takes the negotiation=20 >>>> decision and dictates to the user e.g.=20 >>>> "SPEAK GERMAN NOW !, or that there is a user=20 >>>> interface interaction to decide which=20 >>>> language to answer in, e.g. "The calling=20 >>>> part may accept French or German, indicate=20 >>>> here which one you will answer with". >>>> >>>> We do not want to dictate that kind of tight=20 >>>> coupling, and therefore must allow a number=20 >>>> of alternative languages in various media to=20 >>>> appear in the answer. >>>> >>>> ---Old text 2.5--- >>>> In an answer, 'hlang-send' is the language the answerer will send >>>> when using the media (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 in the media (which in most cases is one >>>> of the languages in the offer's 'hlang-send'). >>>> ---New text 2.5--- >>>> In an answer, 'hlang-send' may be one or a=20 >>>> list of alternative languages the >>>> answerer will select from for sending if using the media for language >>>> (which in most cases is one of the languages in the offer's 'hlang-rec= v'), >>>> and 'hlang-recv' may be one or a list of=20 >>>> alternative languages the answerer >>>> can accept to receive if the media is used=20 >>>> for language (which in most cases is one >>>> of the languages in the offer's 'hlang-send'). >>>> >>> >>> Having one language per media in the answer=20 >>> has been part of the draft all along. I don't=20 >>> recall seeing an objection to this before.=20 >>> Further, Section 3 has said all along that=20 >>> attempting to negotiate multiple languages=20 >>> per media is out of scope: >>> >>> (Negotiating multiple simultaneous languages within a media stream is >>> out of scope of this document.) >>> >> Yes, the user will only use one language.=20 >> But have you thought about the consequences=20 >> for how to accomplish a negotiation result of=20 >> just one language in a media, and just that=20 >> language will also be used by the answering=20 >> human? >> >> It will require tight coupling in the user=20 >> interface of a kind that you do not want to=20 >> discuss. If the UA decides that the answering=20 >> part will send spoken german, then that needs=20 >> to be conveyed to the user. If the UA instead=20 >> lets the user decide, then there must be a=20 >> question-answer exchange between the UA and=20 >> the user to enable the UA to have just one=20 >> language for the media in the answer. >> >> We have agreed that some kind of such coupling=20 >> is needed, and we do not specify how. But the=20 >> requirements on the operation will be much=20 >> less strict if we allow a list of languages=20 >> per media to be the result of the negotiation. >> >> The paranthesis " (Negotiating multiple=20 >> simultaneous languages within a media stream is >> out of scope of this document.) " will then apply to the user. >> >> >> This is a quite new finding from when trying=20 >> to think through a real negotiation, so I am=20 >> prepared to discuss how strict we should be. >> > After the exercise with the negotiation=20 > today, I see that I can relax this requirement. > But it needs to be clear that the negotiated=20 > language in a media just maybe used for=20 > language. > So that it is clear that no simultaneous use is normally required. > > That leads to > --New text 2.5 --- > In an answer, 'hlang-send' is the language the answerer will send > if using the media for language (which in most=20 > cases is one of the languages in > the offer's 'hlang-recv'), and 'hlang-recv' is the language the > answerer expects to receive in the media (which in most cases is one > of the languages in the offer's 'hlang-send'). > > ---end of 2.5 ------------------------- Your request is to change "when using the media"=20 to "if using the media for language". I can live=20 with this. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- There are two ways to write error-free programs; only the third one works. From nobody Thu Jun 1 11:35:10 2017 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 76C1412F3D6 for ; Thu, 1 Jun 2017 11:35:09 -0700 (PDT) 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, 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 vn0_y49ykoi3 for ; Thu, 1 Jun 2017 11:35:07 -0700 (PDT) Received: from bin-vsp-out-01.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 E93C112EA7F for ; Thu, 1 Jun 2017 11:35:06 -0700 (PDT) X-Halon-ID: 06a9b3ca-46f9-11e7-b757-005056917a89 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [77.53.231.21]) by bin-vsp-out-01.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Thu, 1 Jun 2017 20:35:02 +0200 (CEST) To: slim@ietf.org References: <149609884905.14640.4714137651572553743@ietfa.amsl.com> <54839aba-7ac8-79e4-74f8-927eb455d8af@omnitor.se> <029e25ca-fbf7-b6b1-9432-497f2dfb5a0a@omnitor.se> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <5e4385da-3d6f-d268-d1a7-e97f860c57cc@omnitor.se> Date: Thu, 1 Jun 2017 20:35:02 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Slim] I-D Action: draft-ietf-slim-negotiating-human-language-10.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: Thu, 01 Jun 2017 18:35:09 -0000 Den 2017-06-01 kl. 20:28, skrev Randall Gellens: > Edited down for clarity. > > At 8:16 PM +0200 6/1/17, Gunnar Hellström wrote: > >>>>> >>>>> ---Change 2.5----- >>>>> Requiring exactly one language per direction in the answer >>>>> requires a tight coupling between the device and the user that we >>>>> have avoided to specify. It would require either that the device >>>>> takes the negotiation decision and dictates to the user e.g. >>>>> "SPEAK GERMAN NOW !, or that there is a user interface interaction >>>>> to decide which language to answer in, e.g. "The calling part may >>>>> accept French or German, indicate here which one you will answer >>>>> with". >>>>> >>>>> We do not want to dictate that kind of tight coupling, and >>>>> therefore must allow a number of alternative languages in various >>>>> media to appear in the answer. >>>>> >>>>> ---Old text 2.5--- >>>>> In an answer, 'hlang-send' is the language the answerer will send >>>>> when using the media (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 in the media (which in most cases is one >>>>> of the languages in the offer's 'hlang-send'). >>>>> ---New text 2.5--- >>>>> In an answer, 'hlang-send' may be one or a list of alternative >>>>> languages the >>>>> answerer will select from for sending if using the media for >>>>> language >>>>> (which in most cases is one of the languages in the offer's >>>>> 'hlang-recv'), >>>>> and 'hlang-recv' may be one or a list of alternative languages >>>>> the answerer >>>>> can accept to receive if the media is used for language (which in >>>>> most cases is one >>>>> of the languages in the offer's 'hlang-send'). >>>>> >>>> >>>> Having one language per media in the answer has been part of the >>>> draft all along. I don't recall seeing an objection to this before. >>>> Further, Section 3 has said all along that attempting to negotiate >>>> multiple languages per media is out of scope: >>>> >>>> (Negotiating multiple simultaneous languages within a media stream is >>>> out of scope of this document.) >>>> >>> Yes, the user will only use one language. But have you thought >>> about the consequences for how to accomplish a negotiation result of >>> just one language in a media, and just that language will also be >>> used by the answering human? >>> >>> It will require tight coupling in the user interface of a kind that >>> you do not want to discuss. If the UA decides that the answering >>> part will send spoken german, then that needs to be conveyed to the >>> user. If the UA instead lets the user decide, then there must be a >>> question-answer exchange between the UA and the user to enable the >>> UA to have just one language for the media in the answer. >>> >>> We have agreed that some kind of such coupling is needed, and we do >>> not specify how. But the requirements on the operation will be much >>> less strict if we allow a list of languages per media to be the >>> result of the negotiation. >>> >>> The paranthesis " (Negotiating multiple simultaneous languages >>> within a media stream is >>> out of scope of this document.) " will then apply to the user. >>> >>> >>> This is a quite new finding from when trying to think through a >>> real negotiation, so I am prepared to discuss how strict we should be. >>> >> After the exercise with the negotiation today, I see that I can >> relax this requirement. >> But it needs to be clear that the negotiated language in a media >> just maybe used for language. >> So that it is clear that no simultaneous use is normally required. >> >> That leads to >> --New text 2.5 --- >> 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 in the media (which in most cases is one >> of the languages in the offer's 'hlang-send'). >> >> ---end of 2.5 ------------------------- > > Your request is to change "when using the media" to "if using the > media for language". I can live with this. > Good, accepted. -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 From nobody Fri Jun 2 12:29:04 2017 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 9D949126CD6 for ; Fri, 2 Jun 2017 12:29:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 3wm-v5-aC6Cn for ; Fri, 2 Jun 2017 12:28:59 -0700 (PDT) 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 4F200126C26 for ; Fri, 2 Jun 2017 12:28:59 -0700 (PDT) X-Halon-ID: b7028359-47c9-11e7-bca7-0050569116f7 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [77.53.231.21]) by bin-vsp-out-03.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Fri, 2 Jun 2017 21:28:54 +0200 (CEST) To: "slim@ietf.org" From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <60996923-fa37-9926-d1f7-a330020de8db@omnitor.se> Date: Fri, 2 Jun 2017 21:28:53 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------A4AE6FC0300E709DD644E13A" Archived-At: Subject: [Slim] Issues #27 and #32 - simultaneous languages 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, 02 Jun 2017 19:29:03 -0000 This is a multi-part message in MIME format. --------------A4AE6FC0300E709DD644E13A Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit For the case that result of decision on Ticket #34 is that we stay on the current one-line syntax, I want to show how the solution on tickets #27 and #32 can be expressed regarding how to indicate need for simultaneous media. The application is e.g. rapidly added subtitling of audio in the text stream, or added sign language interpretation of audio in the video stream. This would be for simultaneous use, when the user has value also of the original language in the same direction. My simple proposal is to use the t language subtag on the extra provided language. Defined in RFC 6497. If this addition would go into the current draft, it could be done with the following modifications. ---Change 1. --- In 5.2 ---old text--- Note that [RFC5646] Section 4.1 advises to "tag content wisely" and not include unnecessary subtags. ---new text---- Note that [RFC5646] Section 4.1 advises to "tag content wisely" and not include unnecessary subtags. An indication of a transformed version of a language provided simultaneously with the original but in another media, should be indicated by inserting a 't' extension after the language expected to be in transformed form. It is therefore of special importance to consider this possible use of the 't' extension during language matching. The use of this indication is for provision of rapid subtitling of speech and interpretation between sign language and spoken language when there is an interest to also provide the original. The 't' extension of BCP47 is specified in RFC 6497[RFC6497]. See section 5.x for further information and discussion on the indication of simultaneous languages. ---end of change 1---- ---Change 2, new text 5.x-------------- 5.x Transformed simultaneous language In certain applications it is of interest to indicate a transformed version of the contents of a media stream in another media, while still also providing the original. This may for example be for rapid subtitling of speech either manually or automatically. It may also be sign language interpretation of speech, or spoken interpretation of sign language. When the transformed language is provided or requested simultaneously with the original, this condition should be indicated by using the T extension to BCP47 as specified in RFC 6497[RFC6497], by attaching a t subtag on the language tag for the language that is expected to be provided in a transformed modality. Briefly, the 't' extension consists of the string "-t" followed by the source language subtag. Example: "en-t-en" is an English transform of an English source (in another modality). On reception of an indication including a language with the 't' extension for the receive direction, the answering party should interpret this as a request to send both the original and the transformed content provided that both are included in the indications. (e.g. both spoken and written ) On reception of an indication including an offer of a language with the 't' extension for the send direction, the answering party should interpret this as a request to arrange for reception of both the original and the transformed content simultaneously. The media that the 't' extension is attached to should only be interpreted as an expectation for how the transformation will be made. Conditions in the established session MAY cause the original and transformation to swap roles from what the subtags indicated. ---add new text last in current section 5.5 - examples---------- Example: A request for a written English subtitling to be received by the caller in the text stream created from a spoken English source in the audio stream. The caller also indicates a preference to speak English: m=audio 49250 RTP/AVP 20 a=hlang-recv:en a=hlang-send:en* m=text 45020 RTP/AVP 103 104 a=hlang-recv:en-t-en* An acknowledgement of the request: m=audio 49250 RTP/AVP 20 a=hlang-send:en a=hlang-recv:en m=text 45020 RTP/AVP 103 104 a=hlang-send:en-t-en In the session, the caller will receive both spoken English and written English. The caller will send English speech. ----end of new text ------------------------- ------add to references---- [rfc6497] RFC 6497 Davis, M. et.al. "BCP 47 Extension T - Transformed Content", RFC 6497, February 2012. -----end of changes ------------ -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 --------------A4AE6FC0300E709DD644E13A Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

For the case that result of decision on Ticket #34 is that we stay on the current one-line syntax, I want to show how the solution on tickets #27 and #32 can be expressed regarding how to indicate need for simultaneous media.

The application is e.g. rapidly added subtitling of audio in the text stream, or added sign language interpretation of audio in the video stream.

This would be for simultaneous use, when the user has value also of the original language in the same direction.

My simple proposal is to use the t language subtag on the extra provided language. Defined in RFC 6497.

If this addition would go into the current draft, it could be done with the following modifications.

---Change 1. ---

In 5.2

---old text---

Note that [RFC5646] Section 4.1 advises to "tag content wisely" and not include unnecessary subtags.

---new text----

Note that [RFC5646] Section 4.1 advises to "tag content wisely" and not include unnecessary subtags.

An indication of a transformed version of a language provided simultaneously with the original but in another media, should be indicated by inserting a 't' extension after the language expected to be in transformed form. It is therefore of special importance to consider this possible use of the  't' extension during language matching. The use of this indication is for provision of rapid subtitling of speech and interpretation between sign language and spoken language when there is an interest to also provide the original. The 't' extension of BCP47 is specified in RFC 6497[RFC6497].

See section 5.x for further information and discussion on the indication of simultaneous languages.  

---end of change 1----

---Change 2, new text 5.x--------------

5.x Transformed simultaneous language

In certain applications it is of interest to indicate a transformed version of the contents of a media stream in another media, while still also providing the original.

This may for example be for rapid subtitling of speech either manually or automatically. It may also be sign language interpretation of speech, or spoken interpretation of sign language.

When the transformed language is provided or requested simultaneously with the original, this condition should be indicated by using the T extension to BCP47 as specified in RFC 6497[RFC6497], by attaching a t subtag on the language tag for the language that is expected to be provided in a transformed modality. 

Briefly, the 't' extension consists of the string "-t" followed by the source language subtag. 

Example: "en-t-en"   is an English transform of an English source (in another modality).

On reception of an indication including a language with the 't' extension for the receive direction, the answering party should interpret this as a request to send both the original and the transformed content provided that both are included in the indications. (e.g. both spoken and written )

On reception of an indication including an offer of a language with the 't' extension for the send direction, the answering party should interpret this as a request to arrange for reception of both the original and the transformed content simultaneously. 

The media that the 't' extension is attached to should only be interpreted as an expectation for how the transformation will be made. Conditions in the established session MAY cause the original and transformation to swap roles from what the subtags indicated. 




---add new text last in current section 5.5 - examples----------

Example: A request for a written English subtitling to be received by the caller in the text stream created from a spoken English source in the audio stream. The caller also indicates a preference to speak English:

      m=audio 49250 RTP/AVP 20
      a=hlang-recv:en
      a=hlang-send:en*
 
      m=text 45020 RTP/AVP 103 104
      a=hlang-recv:en-t-en*

 An acknowledgement of the request:

      m=audio 49250 RTP/AVP 20
      a=hlang-send:en
      a=hlang-recv:en
 
      m=text 45020 RTP/AVP 103 104
      a=hlang-send:en-t-en

In the session, the caller will receive both spoken English and written English. The caller will send English speech. 
 
----end of new text -------------------------
------add to references----

[rfc6497]   RFC 6497 Davis, M. et.al. "BCP 47 Extension T - Transformed Content", RFC 6497, February 2012.

-----end of changes ------------



-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288
--------------A4AE6FC0300E709DD644E13A-- From nobody Fri Jun 2 19:41:40 2017 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 76268124BFA for ; Fri, 2 Jun 2017 19:41:39 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 MBqCIfWvv-dz for ; Fri, 2 Jun 2017 19:41:37 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 8CA5C129BA1 for ; Fri, 2 Jun 2017 19:41:37 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Fri, 2 Jun 2017 19:43:55 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <60996923-fa37-9926-d1f7-a330020de8db@omnitor.se> References: <60996923-fa37-9926-d1f7-a330020de8db@omnitor.se> X-Mailer: Eudora for Mac OS X Date: Fri, 2 Jun 2017 19:41:33 -0700 To: Gunnar =?iso-8859-1?Q?Hellstr=F6m?= , "slim@ietf.org" From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Slim] Issues #27 and #32 - simultaneous languages 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, 03 Jun 2017 02:41:39 -0000 Hi Gunnar, You propose an interesting mechanism that I think=20 should be pursued, just not in the current draft.=20 We've repeatedly discussed means of requesting=20 various services, including real-time captioning;=20 these are useful and an automated way of=20 requesting that seems useful, but the group has=20 repeatedly decided to keep the current draft=20 simple. As with your suggestion for relative=20 preference and priority, I've offered to help=20 write a separate draft, and Brian has offered to=20 review it. I think this is the way to proceed. At 9:28 PM +0200 6/2/17, Gunnar Hellstr=F6m wrote: > For the case that result of decision on Ticket=20 > #34 is that we stay on the current one-line=20 > syntax, I want to show how the solution on=20 > tickets #27 and #32 can be expressed regarding=20 > how to indicate need for simultaneous media. > > The application is e.g. rapidly added=20 > subtitling of audio in the text stream, or=20 > added sign language interpretation of audio in=20 > the video stream. > > This would be for simultaneous use, when the=20 > user has value also of the original language in=20 > the same direction. > > My simple proposal is to use the t language=20 > subtag on the extra provided language. Defined=20 > in RFC 6497. > > If this addition would go into the current=20 > draft, it could be done with the following=20 > modifications. > > ---Change 1. --- > > In 5.2 > > ---old text--- > > Note that [RFC5646] Section 4.1 advises to "tag=20 > content wisely" and not include unnecessary=20 > subtags. > > ---new text---- > > > Note that [RFC5646] Section 4.1 advises to "tag=20 > content wisely" and not include unnecessary=20 > subtags. > > An indication of a transformed version of a=20 > language provided simultaneously with the=20 > original but in another media, should be=20 > indicated by inserting a 't' extension after=20 > the language expected to be in transformed=20 > form. It is therefore of special importance to=20 > consider this possible use of the 't'=20 > extension during language matching. The use of=20 > this indication is for provision of rapid=20 > subtitling of speech and interpretation between=20 > sign language and spoken language when there is=20 > an interest to also provide the original. The=20 > 't' extension of BCP47 is specified in RFC=20 > 6497[RFC6497]. > > See section 5.x for further information and=20 > discussion on the indication of simultaneous=20 > languages. > > ---end of change 1---- > > ---Change 2, new text 5.x-------------- > > 5.x Transformed simultaneous language > > In certain applications it is of interest to=20 > indicate a transformed version of the contents=20 > of a media stream in another media, while still=20 > also providing the original. > > This may for example be for rapid subtitling of=20 > speech either manually or automatically. It may=20 > also be sign language interpretation of speech,=20 > or spoken interpretation of sign language. > > When the transformed language is provided or=20 > requested simultaneously with the original,=20 > this condition should be indicated by using the=20 > T extension to BCP47 as specified in RFC=20 > 6497[RFC6497], by attaching a t subtag on the=20 > language tag for the language that is expected=20 > to be provided in a transformed modality. > > Briefly, the 't' extension consists of the=20 > string "-t" followed by the source language=20 > subtag. > > Example: "en-t-en" is an English transform of=20 > an English source (in another modality). > > On reception of an indication including a=20 > language with the 't' extension for the receive=20 > direction, the answering party should interpret=20 > this as a request to send both the original and=20 > the transformed content provided that both are=20 > included in the indications. (e.g. both spoken=20 > and written ) > > On reception of an indication including an=20 > offer of a language with the 't' extension for=20 > the send direction, the answering party should=20 > interpret this as a request to arrange for=20 > reception of both the original and the=20 > transformed content simultaneously. > > The media that the 't' extension is attached to=20 > should only be interpreted as an expectation=20 > for how the transformation will be made.=20 > Conditions in the established session MAY cause=20 > the original and transformation to swap roles=20 > from what the subtags indicated. > > > > > ---add new text last in current section 5.5 - examples---------- > > Example: A request for a written English=20 > subtitling to be received by the caller in the=20 > text stream created from a spoken English=20 > source in the audio stream. The caller also=20 > indicates a preference to speak English: > > m=3Daudio 49250 RTP/AVP 20 > a=3Dhlang-recv:en > a=3Dhlang-send:en* > > m=3Dtext 45020 RTP/AVP 103 104 > a=3Dhlang-recv:en-t-en* > > An acknowledgement of the request: > > m=3Daudio 49250 RTP/AVP 20 > a=3Dhlang-send:en > a=3Dhlang-recv:en > > m=3Dtext 45020 RTP/AVP 103 104 > a=3Dhlang-send:en-t-en > > In the session, the caller will receive both=20 > spoken English and written English. The caller=20 > will send English speech. > > ----end of new text ------------------------- > ------add to references---- > > [rfc6497] RFC 6497 Davis, M. et.al. "BCP 47=20 > Extension T - Transformed Content", RFC 6497,=20 > February 2012. > > -----end of changes ------------ > > > > -- > ----------------------------------------- > Gunnar Hellstr=F6m > Omnitor > gunnar.hellstrom@omnitor.se > +46 708 204 288 > > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- We should never forget that everything Adolf Hitler did in Germany was legal and everything the Hungarian freedom fighters did in Hungary was illegal. --Martin Luther King, Jr., 1963 From nobody Sat Jun 3 01:48:37 2017 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 E11B4120724 for ; Sat, 3 Jun 2017 01:48:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 RwjQMZ5OVTgI for ; Sat, 3 Jun 2017 01:48:32 -0700 (PDT) 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 DA995120227 for ; Sat, 3 Jun 2017 01:48:31 -0700 (PDT) X-Halon-ID: 686a5d7e-4839-11e7-bcc7-005056917f90 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [77.53.231.21]) by bin-vsp-out-02.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Sat, 3 Jun 2017 10:48:25 +0200 (CEST) To: Randall Gellens , "slim@ietf.org" References: <60996923-fa37-9926-d1f7-a330020de8db@omnitor.se> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: Date: Sat, 3 Jun 2017 10:48:24 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------7EB6C5D93B5F1F4088B790EC" Archived-At: Subject: Re: [Slim] Issues #27 and #32 - simultaneous languages 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, 03 Jun 2017 08:48:36 -0000 This is a multi-part message in MIME format. --------------7EB6C5D93B5F1F4088B790EC Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Den 2017-06-03 kl. 04:41, skrev Randall Gellens: > Hi Gunnar, > > You propose an interesting mechanism that I think should be pursued, > just not in the current draft. We've repeatedly discussed means of > requesting various services, including real-time captioning; these are > useful and an automated way of requesting that seems useful, but the > group has repeatedly decided to keep the current draft simple. As > with your suggestion for relative preference and priority, I've > offered to help write a separate draft, and Brian has offered to > review it. I think this is the way to proceed. Hi Randall, Thanks for positive comments. I suggest that we meet in the middle. We propose to the WG and our management that: 1. We make the proposal in the mail below, for simultaneous languages as a separate extension draft and by that move the remaining parts of tickets #27 and #32 about subtitling etc to that separate extension. 2. We include in the current draft the functionality for expressing preferred modality, as a solution on ticket #26 as expressed in mail with subject "New wording for the use of the asterisk in draft-ietf-slim-negotiating-human-language" 3. You may if you want add further wording weakening the requirement to obey the indications for preferred modality in the same style as you already have for the call denial. 4. You may if you want call the indication "most suitable modality" or "main modality" instead of the "preferred modality" if you feel that that has less linkage to the more complex indications and media negotiations we have discussed earlier. In this way, we can rapidly close out all remaining discussions and tickets and move on to publication. We get a way to solve the remaining part of Ticket #26 that required a good motivation for placement of the asterisk. The current placement rule "in any media" is too fuzzy, while the new wording for use of the asterisk adds good motivations for explicit placement. We rather reduce complexity than increase complexity. It would also be hard to go from placement "in any media" to placement in a specific media by an extension. That would cause interop issues. Better to solve it now. We also satisfy the external expectations we have on our outcome from ETSI, 3GPP and a number of NG emergency service projects. We can reject Ticket #34 about the Accept-Language syntax and go for the current one-line syntax. And we can be satisfied that we do respect the policy rules, e.g. from the UN Convention for Rights of Persons with Disabilities( UN CRPD), that we cannot say that the current draft does. I assume that ISOC / IETF require us to respect the CRPD as ITU-T and ETSI does in their work. Agreed? Gunnar > > At 9:28 PM +0200 6/2/17, Gunnar Hellström wrote: > >> For the case that result of decision on Ticket #34 is that we stay >> on the current one-line syntax, I want to show how the solution on >> tickets #27 and #32 can be expressed regarding how to indicate need >> for simultaneous media. >> >> The application is e.g. rapidly added subtitling of audio in the >> text stream, or added sign language interpretation of audio in the >> video stream. >> >> This would be for simultaneous use, when the user has value also of >> the original language in the same direction. >> >> My simple proposal is to use the t language subtag on the extra >> provided language. Defined in RFC 6497. >> >> If this addition would go into the current draft, it could be done >> with the following modifications. >> >> ---Change 1. --- >> >> In 5.2 >> >> ---old text--- >> >> Note that [RFC5646] Section 4.1 advises to "tag content wisely" and >> not include unnecessary subtags. >> >> ---new text---- >> >> >> Note that [RFC5646] Section 4.1 advises to "tag content wisely" and >> not include unnecessary subtags. >> >> An indication of a transformed version of a language provided >> simultaneously with the original but in another media, should be >> indicated by inserting a 't' extension after the language expected to >> be in transformed form. It is therefore of special importance to >> consider this possible use of the 't' extension during language >> matching. The use of this indication is for provision of rapid >> subtitling of speech and interpretation between sign language and >> spoken language when there is an interest to also provide the >> original. The 't' extension of BCP47 is specified in RFC 6497[RFC6497]. >> >> See section 5.x for further information and discussion on the >> indication of simultaneous languages. >> ---end of change 1---- >> >> ---Change 2, new text 5.x-------------- >> >> 5.x Transformed simultaneous language >> >> In certain applications it is of interest to indicate a transformed >> version of the contents of a media stream in another media, while >> still also providing the original. >> >> This may for example be for rapid subtitling of speech either >> manually or automatically. It may also be sign language >> interpretation of speech, or spoken interpretation of sign language. >> >> When the transformed language is provided or requested >> simultaneously with the original, this condition should be indicated >> by using the T extension to BCP47 as specified in RFC 6497[RFC6497], >> by attaching a t subtag on the language tag for the language that is >> expected to be provided in a transformed modality. >> >> Briefly, the 't' extension consists of the string "-t" followed by >> the source language subtag. >> >> Example: "en-t-en" is an English transform of an English source >> (in another modality). >> >> On reception of an indication including a language with the 't' >> extension for the receive direction, the answering party should >> interpret this as a request to send both the original and the >> transformed content provided that both are included in the >> indications. (e.g. both spoken and written ) >> >> On reception of an indication including an offer of a language with >> the 't' extension for the send direction, the answering party should >> interpret this as a request to arrange for reception of both the >> original and the transformed content simultaneously. >> >> The media that the 't' extension is attached to should only be >> interpreted as an expectation for how the transformation will be >> made. Conditions in the established session MAY cause the original >> and transformation to swap roles from what the subtags indicated. >> >> >> >> >> ---add new text last in current section 5.5 - examples---------- >> >> Example: A request for a written English subtitling to be received >> by the caller in the text stream created from a spoken English source >> in the audio stream. The caller also indicates a preference to speak >> English: >> >> m=audio 49250 RTP/AVP 20 >> a=hlang-recv:en >> a=hlang-send:en* >> >> m=text 45020 RTP/AVP 103 104 >> a=hlang-recv:en-t-en* >> >> An acknowledgement of the request: >> >> m=audio 49250 RTP/AVP 20 >> a=hlang-send:en >> a=hlang-recv:en >> >> m=text 45020 RTP/AVP 103 104 >> a=hlang-send:en-t-en >> >> In the session, the caller will receive both spoken English and >> written English. The caller will send English speech. >> >> ----end of new text ------------------------- >> ------add to references---- >> >> [rfc6497] RFC 6497 Davis, M. et.al. "BCP 47 Extension T - >> Transformed Content", RFC 6497, February 2012. >> >> -----end of changes ------------ >> >> >> >> -- >> ----------------------------------------- >> 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 --------------7EB6C5D93B5F1F4088B790EC Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Den 2017-06-03 kl. 04:41, skrev Randall Gellens:
Hi Gunnar,

You propose an interesting mechanism that I think should be pursued, just not in the current draft. We've repeatedly discussed means of requesting various services, including real-time captioning; these are useful and an automated way of requesting that seems useful, but the group has repeatedly decided to keep the current draft simple.  As with your suggestion for relative preference and priority, I've offered to help write a separate draft, and Brian has offered to review it.  I think this is the way to proceed.
Hi Randall,
Thanks for positive comments.
I suggest that we meet in the middle.
We propose to the WG and our management that:
  1. We make the proposal in the mail below, for simultaneous languages as a separate extension draft and by that move the remaining parts of tickets #27 and #32 about subtitling etc to that separate extension.

  2. We include in the current draft the functionality for expressing preferred modality, as a solution on ticket #26 as expressed in mail with subject "New wording for the use of the asterisk in draft-ietf-slim-negotiating-human-language"

  3. You may if you want add further wording weakening the requirement to obey the indications for preferred modality in the same style as you already have for the call denial.

  4. You may if you want call the indication "most suitable modality" or "main modality" instead of the "preferred modality" if you feel that that has less linkage to the more complex indications and media negotiations we have discussed earlier.

In this way, we can rapidly close out all remaining discussions and tickets and move on to publication.

We get a way to solve the remaining part of Ticket #26 that required a good motivation for placement of the asterisk. The current placement rule "in any media" is too fuzzy, while the new wording for use of the asterisk adds good motivations for explicit placement. We rather reduce complexity than increase complexity. It would also be hard to go from placement "in any media" to placement in a specific media by an extension. That would cause interop issues. Better to solve it now.

We also satisfy the external expectations we have on our outcome from ETSI, 3GPP and a number of NG emergency service projects.

We can reject Ticket #34 about the Accept-Language syntax and go for the current one-line syntax.

And we can be satisfied that we do respect the policy rules, e.g. from the UN Convention for Rights of Persons with Disabilities( UN CRPD),  that we cannot say that the current draft does.  I assume that ISOC / IETF require us to respect the CRPD as ITU-T and ETSI does in their work.

Agreed?


Gunnar



At 9:28 PM +0200 6/2/17, Gunnar Hellström wrote:

 For the case that result of decision on Ticket #34 is that we stay on the current one-line syntax, I want to show how the solution on tickets #27 and #32 can be expressed regarding how to indicate need for simultaneous media.

 The application is e.g. rapidly added subtitling of audio in the text stream, or added sign language interpretation of audio in the video stream.

 This would be for simultaneous use, when the user has value also of the original language in the same direction.

 My simple proposal is to use the t language subtag on the extra provided language. Defined in RFC 6497.

 If this addition would go into the current draft, it could be done with the following modifications.

 ---Change 1. ---

 In 5.2

 ---old text---

 Note that [RFC5646] Section 4.1 advises to "tag content wisely" and not include unnecessary subtags.

 ---new text----


 Note that [RFC5646] Section 4.1 advises to "tag content wisely" and not include unnecessary subtags.

 An indication of a transformed version of a language provided simultaneously with the original but in another media, should be indicated by inserting a 't' extension after the language expected to be in transformed form. It is therefore of special importance to consider this possible use of the  't' extension during language matching. The use of this indication is for provision of rapid subtitling of speech and interpretation between sign language and spoken language when there is an interest to also provide the original. The 't' extension of BCP47 is specified in RFC 6497[RFC6497].

 See section 5.x for further information and discussion on the indication of simultaneous languages.
 ---end of change 1----

 ---Change 2, new text 5.x--------------

 5.x Transformed simultaneous language

 In certain applications it is of interest to indicate a transformed version of the contents of a media stream in another media, while still also providing the original.

 This may for example be for rapid subtitling of speech either manually or automatically. It may also be sign language interpretation of speech, or spoken interpretation of sign language.

 When the transformed language is provided or requested simultaneously with the original, this condition should be indicated by using the T extension to BCP47 as specified in RFC 6497[RFC6497], by attaching a t subtag on the language tag for the language that is expected to be provided in a transformed modality.

 Briefly, the 't' extension consists of the string "-t" followed by the source language subtag.

 Example: "en-t-en"   is an English transform of an English source (in another modality).

 On reception of an indication including a language with the 't' extension for the receive direction, the answering party should interpret this as a request to send both the original and the transformed content provided that both are included in the indications. (e.g. both spoken and written )

 On reception of an indication including an offer of a language with the 't' extension for the send direction, the answering party should interpret this as a request to arrange for reception of both the original and the transformed content simultaneously.

 The media that the 't' extension is attached to should only be interpreted as an expectation for how the transformation will be made. Conditions in the established session MAY cause the original and transformation to swap roles from what the subtags indicated.




 ---add new text last in current section 5.5 - examples----------

 Example: A request for a written English subtitling to be received by the caller in the text stream created from a spoken English source in the audio stream. The caller also indicates a preference to speak English:

       m=audio 49250 RTP/AVP 20
       a=hlang-recv:en
       a=hlang-send:en*

       m=text 45020 RTP/AVP 103 104
       a=hlang-recv:en-t-en*

  An acknowledgement of the request:

       m=audio 49250 RTP/AVP 20
       a=hlang-send:en
       a=hlang-recv:en

       m=text 45020 RTP/AVP 103 104
       a=hlang-send:en-t-en

 In the session, the caller will receive both spoken English and written English. The caller will send English speech.

 ----end of new text -------------------------
  ------add to references----

 [rfc6497] RFC 6497 Davis, M. et.al. "BCP 47 Extension T - Transformed Content", RFC 6497, February 2012.

 -----end of changes ------------



 --
 -----------------------------------------
 Gunnar Hellström
 Omnitor
 <mailto:gunnar.hellstrom@omnitor.se>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
--------------7EB6C5D93B5F1F4088B790EC-- From nobody Sat Jun 3 11:07:36 2017 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 EFD9A12EB61 for ; Sat, 3 Jun 2017 11:07:34 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 W3SFdQQ8jt-d for ; Sat, 3 Jun 2017 11:07:32 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id AA76212EB5E for ; Sat, 3 Jun 2017 11:07:32 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Sat, 3 Jun 2017 11:09:51 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <60996923-fa37-9926-d1f7-a330020de8db@omnitor.se> X-Mailer: Eudora for Mac OS X Date: Sat, 3 Jun 2017 11:07:28 -0700 To: Gunnar =?iso-8859-1?Q?Hellstr=F6m?= , "slim@ietf.org" From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Slim] Issues #27 and #32 - simultaneous languages 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, 03 Jun 2017 18:07:35 -0000 Hi Gunnar, Thanks for your reply. It seems to me that we=20 should not add new functionality nor new=20 complexity to the current draft. As I've=20 repeatedly said, I am happy to help write a=20 separate draft. At 10:48 AM +0200 6/3/17, Gunnar Hellstr=F6m wrote: > Den 2017-06-03 kl. 04:41, skrev Randall Gellens: > >> Hi Gunnar, >> >> You propose an interesting mechanism that I=20 >> think should be pursued, just not in the=20 >> current draft. We've repeatedly discussed=20 >> means of requesting various services,=20 >> including real-time captioning; these are=20 >> useful and an automated way of requesting that=20 >> seems useful, but the group has repeatedly=20 >> decided to keep the current draft simple. As=20 >> with your suggestion for relative preference=20 >> and priority, I've offered to help write a=20 >> separate draft, and Brian has offered to=20 >> review it. I think this is the way to proceed. >> > Hi Randall, > Thanks for positive comments. > I suggest that we meet in the middle. > We propose to the WG and our management that: > > 1. We make the proposal in the mail below,=20 > for simultaneous languages as a separate=20 > extension draft and by that move the remaining=20 > parts of tickets #27 and #32 about subtitling=20 > etc to that separate extension. > > 2. We include in the current draft the=20 > functionality for expressing preferred=20 > modality, as a solution on ticket #26 as=20 > expressed in mail with subject "New wording for=20 > the use of the asterisk in=20 > draft-ietf-slim-negotiating-human-language" > > 3. You may if you want add further wording=20 > weakening the requirement to obey the=20 > indications for preferred modality in the same=20 > style as you already have for the call denial. > > 4. You may if you want call the indication=20 > "most suitable modality" or "main modality"=20 > instead of the "preferred modality" if you feel=20 > that that has less linkage to the more complex=20 > indications and media negotiations we have=20 > discussed earlier. > > In this way, we can rapidly close out all=20 > remaining discussions and tickets and move on=20 > to publication. > > We get a way to solve the remaining part of=20 > Ticket #26 that required a good motivation for=20 > placement of the asterisk. The current=20 > placement rule "in any media" is too fuzzy,=20 > while the new wording for use of the asterisk=20 > adds good motivations for explicit placement.=20 > We rather reduce complexity than increase=20 > complexity. It would also be hard to go from=20 > placement "in any media" to placement in a=20 > specific media by an extension. That would=20 > cause interop issues. Better to solve it now. > > We also satisfy the external expectations we=20 > have on our outcome from ETSI, 3GPP and a=20 > number of NG emergency service projects. > > We can reject Ticket #34 about the=20 > Accept-Language syntax and go for the current=20 > one-line syntax. > > And we can be satisfied that we do respect the=20 > policy rules, e.g. from the UN Convention for=20 > Rights of Persons with Disabilities( UN CRPD),=20 > that we cannot say that the current draft does.=20 > I assume that ISOC / IETF require us to respect=20 > the CRPD as ITU-T and ETSI does in their work. > > Agreed? > > > Gunnar > > >> >> At 9:28 PM +0200 6/2/17, Gunnar Hellstr=F6m wrote: >> >>> For the case that result of decision on=20 >>> Ticket #34 is that we stay on the current=20 >>> one-line syntax, I want to show how the=20 >>> solution on tickets #27 and #32 can be=20 >>> expressed regarding how to indicate need for=20 >>> simultaneous media. >>> >>> The application is e.g. rapidly added=20 >>> subtitling of audio in the text stream, or=20 >>> added sign language interpretation of audio=20 >>> in the video stream. >>> >>> This would be for simultaneous use, when the=20 >>> user has value also of the original language=20 >>> in the same direction. >>> >>> My simple proposal is to use the t language=20 >>> subtag on the extra provided language.=20 >>> Defined in RFC 6497. >>> >>> If this addition would go into the current=20 >>> draft, it could be done with the following=20 >>> modifications. >>> >>> ---Change 1. --- >>> >>> In 5.2 >>> >>> ---old text--- >>> >>> Note that [RFC5646] Section 4.1 advises to=20 >>> "tag content wisely" and not include=20 >>> unnecessary subtags. >>> >>> ---new text---- >>> >>> >>> Note that [RFC5646] Section 4.1 advises to=20 >>> "tag content wisely" and not include=20 >>> unnecessary subtags. >>> >>> An indication of a transformed version of a=20 >>> language provided simultaneously with the=20 >>> original but in another media, should be=20 >>> indicated by inserting a 't' extension after=20 >>> the language expected to be in transformed=20 >>> form. It is therefore of special importance=20 >>> to consider this possible use of the 't'=20 >>> extension during language matching. The use=20 >>> of this indication is for provision of rapid=20 >>> subtitling of speech and interpretation=20 >>> between sign language and spoken language=20 >>> when there is an interest to also provide the=20 >>> original. The 't' extension of BCP47 is=20 >>> specified in RFC 6497[RFC6497]. >>> >>> See section 5.x for further information and=20 >>> discussion on the indication of simultaneous=20 >>> languages. >>> ---end of change 1---- >>> >>> ---Change 2, new text 5.x-------------- >>> >>> 5.x Transformed simultaneous language >>> >>> In certain applications it is of interest to=20 >>> indicate a transformed version of the=20 >>> contents of a media stream in another media,=20 >>> while still also providing the original. >>> >>> This may for example be for rapid subtitling=20 >>> of speech either manually or automatically.=20 >>> It may also be sign language interpretation=20 >>> of speech, or spoken interpretation of sign=20 >>> language. >>> >>> When the transformed language is provided or=20 >>> requested simultaneously with the original,=20 >>> this condition should be indicated by using=20 >>> the T extension to BCP47 as specified in RFC=20 >>> 6497[RFC6497], by attaching a t subtag on the=20 >>> language tag for the language that is=20 >>> expected to be provided in a transformed=20 >>> modality. >>> >>> Briefly, the 't' extension consists of the=20 >>> string "-t" followed by the source language=20 >>> subtag. >>> >>> Example: "en-t-en" is an English transform of=20 >>> an English source (in another modality). >>> >>> On reception of an indication including a=20 >>> language with the 't' extension for the=20 >>> receive direction, the answering party should=20 >>> interpret this as a request to send both the=20 >>> original and the transformed content provided=20 >>> that both are included in the indications.=20 >>> (e.g. both spoken and written ) >>> >>> On reception of an indication including an=20 >>> offer of a language with the 't' extension=20 >>> for the send direction, the answering party=20 >>> should interpret this as a request to arrange=20 >>> for reception of both the original and the=20 >>> transformed content simultaneously. >>> >>> The media that the 't' extension is attached=20 >>> to should only be interpreted as an=20 >>> expectation for how the transformation will=20 >>> be made. Conditions in the established=20 >>> session MAY cause the original and=20 >>> transformation to swap roles from what the=20 >>> subtags indicated. >>> >>> >>> >>> >>> ---add new text last in current section 5.5 - examples---------- >>> >>> Example: A request for a written English=20 >>> subtitling to be received by the caller in=20 >>> the text stream created from a spoken English=20 >>> source in the audio stream. The caller also=20 >>> indicates a preference to speak English: >>> >>> m=3Daudio 49250 RTP/AVP 20 >>> a=3Dhlang-recv:en >>> a=3Dhlang-send:en* >>> >>> m=3Dtext 45020 RTP/AVP 103 104 >>> a=3Dhlang-recv:en-t-en* >>> >>> An acknowledgement of the request: >>> >>> m=3Daudio 49250 RTP/AVP 20 >>> a=3Dhlang-send:en >>> a=3Dhlang-recv:en >>> >>> m=3Dtext 45020 RTP/AVP 103 104 >>> a=3Dhlang-send:en-t-en >>> >>> In the session, the caller will receive both=20 >>> spoken English and written English. The=20 >>> caller will send English speech. >>> >>> ----end of new text ------------------------- >>> ------add to references---- >>> >>> [rfc6497] RFC 6497 Davis, M. et.al. "BCP 47=20 >>> Extension T - Transformed Content", RFC 6497,=20 >>> February 2012. >>> >>> -----end of changes ------------ >>> >>> >>> >>> -- >>> ----------------------------------------- >>> Gunnar Hellstr=F6m >>> Omnitor >>>=20 >>> = gunnar.hellstrom@omnitor.se >>> +46 708 204 288 >>> >>> _______________________________________________ >>> SLIM mailing list >>> SLIM@ietf.org >>>=20 >>> https://www.ietf.org/mailman= /listinfo/slim >>> >> >> > > -- > ----------------------------------------- > Gunnar Hellstr=F6m > Omnitor > gunnar.hellstrom@omnitor.se > +46 708 204 288 -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Intelligence and war are games, perhaps the only meaningful games left. If any player becomes too proficient, the game is threatened with termination. --William S. Burroughs From nobody Sun Jun 4 00:09:25 2017 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 EAB1C1294B9 for ; Sun, 4 Jun 2017 00:09:24 -0700 (PDT) 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 1AR5qFMKOuPL for ; Sun, 4 Jun 2017 00:09:21 -0700 (PDT) Received: from bin-vsp-out-02.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 7966E129456 for ; Sun, 4 Jun 2017 00:09:21 -0700 (PDT) X-Halon-ID: b8fc3268-48f4-11e7-bcc7-005056917f90 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [77.53.231.21]) by bin-vsp-out-02.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Sun, 4 Jun 2017 09:09:17 +0200 (CEST) To: slim@ietf.org References: <149609884905.14640.4714137651572553743@ietfa.amsl.com> <54839aba-7ac8-79e4-74f8-927eb455d8af@omnitor.se> <8ca64f00-b1d1-e4da-05cf-0e4663178d85@omnitor.se> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: Date: Sun, 4 Jun 2017 09:09:16 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <8ca64f00-b1d1-e4da-05cf-0e4663178d85@omnitor.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Slim] New wording for the use of the asterisk 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, 04 Jun 2017 07:09:25 -0000 Randall, This is a contiuation of the discussion under topic "Issues #27 and #32 - simultaneous languages" Assume that I make a separate draft for indication of preferred modality. I would then like to use the coding with the asterisk proposed below. Knowing that that is on its way, how would you describe the use of the asterisk in the current draft so that no interop issues appear when the preferred modality extension is published? And how would you describe the use of the asterisk in the current draft so that it will be accepted as a media level parameter? Right now you say that the asterisk may be attached to any hlang attribute for any direction. An implementation following that advice may for an offer attach it to a modality that is not at all preferred. An implementation knowing the extension may then take very wrong decisions about how to best start the session. I am afraid that in this situation the preferred modality indication would need to move to a new attribute or parameter, adding even more complexity. E.g. a media level attribute a=modalitypref: hi or a session level attribute a=modalitypref: written, spoken (in order of preference). I would like to save us that added complexity. How? Regards Gunnar Den 2017-05-31 kl. 21:31, skrev Gunnar Hellström: > Den 2017-05-31 kl. 15:58, skrev Randall Gellens: >> This text should go in a separate document containing advice to >> implementers. > It adds an even better motivation than my earlier proposals for having > the asterisk as a parameter on media level, > and it adds a mild recommendation about the preference between media > that we need to make the draft useful in reality. Therefore I suggest > to accept it into the current draft. ( if issue #34 is rejected ) > > Without this change, the confusion about the placement of the asterisk > and the question why the asterisk is a media parameter is still valid. > > Regards > Gunnar >> >> At 3:24 PM +0200 5/31/17, Gunnar Hellström wrote: >> >>> Regarding the many review comments about the use of the asterisk >>> parameter in draft-ietf-slim-negotiating-human-language, ( e.g. by >>> Adam Roach on 28/3/2017) I propose the following change that both >>> gives a meaning to the position of the asterisk and satisfies issue >>> #26 with media preferences. >>> >>> I propose to use this solution if there is a decision to not >>> satisfy Issue #34, to use the Accept-Language syntax.: >>> >>> --Change proposal - to draft version -10--- >>> >>> --First change-- >>> >>> in section 5.2 >>> >>> --old text- >>> >>> In an offer, each value MAY have an asterisk appended as the final >>> value. An asterisk appended to either value in an offer >>> indicates a >>> request by the caller to the callee to not fail the call if >>> there is >>> no language in common. See Section 5.3 for more information and >>> discussion. >>> >>> -new text >>> >>> In an offer or answer, each value MAY have an asterisk appended >>> as the final >>> parameter. An asterisk appended to a value in an offer indicates a >>> that the caller has higher preference for the corresponding >>> modality >>> to be used in the specified direction than other modalities for >>> the indicated >>> direction without an asterisk. If no such preference is indicated >>> in any hlang- >>> attribute, it should be taken as a preference by the caller to get >>> the call denied >>> if no languages are in common between the caller and the callee. >>> In an answer, the asterisk indicates a modality that is preferred >>> by the callee to be used in the session. >>> >>> See Section 5.3 for more information and >>> discussion. >>> >>> --end of first change---- >>> >>> ---second change---- >>> In 5.3 >>> ----old text--- >>> >>> >>> 5.3. No Language in Common >>> >>> A consideration with the ability to negotiate language is if the >>> call >>> proceeds or fails if the callee does not support any of the >>> languages >>> requested by the caller. This document does not mandate either >>> behavior, although it does provide a way for the caller to >>> indicate a >>> preference for the call succeeding when there is no language in >>> common. It is OPTIONAL for the callee to honor this >>> preference. For >>> example, a PSAP is likely to attempt the call even without an >>> indicated preference when there is no language in common, while a >>> call center might choose to fail the call. >>> >>> The mechanism for indicating this preference is that, in an >>> offer, if >>> the last value of either 'hlang-recv' or 'hlang-send' is an >>> asterisk, >>> this indicates a request to not fail the call. The called party >>> MAY >>> ignore the indication, e.g., for the emergency services use case, >>> regardless of the absence of an asterisk, a PSAP will likely not >>> fail >>> the call; some call centers might reject a call even if the offer >>> contains an asterisk. >>> >>> ---New text ---- >>> >>> >>> 5.3. Preferred modality and action if no match >>> >>> A user may have a clear preference to use one specific modality >>> in a >>> direction, while use of other modalities may be acceptable but >>> lower in >>> preference. This condition MAY be indicated by appending an >>> asterisk >>> as the last parameter in the corresponding humlang- value. This >>> indication should also be seen as a preference to not have the call >>> denied even if no indicated languages are in common. >>> >>> When negotiating language use for a direction, languages and >>> modalities >>> specified together with the asterisk should be given preference >>> to be selected for use. >>> No specific preference between modalities in the same direction >>> should >>> be indicated by appending an asterisk on all or no humlang- >>> values for that direction. >>> >>> If there is a preference for denying the call when no languages >>> match, >>> then it is not possible to indicate any preferred modality at >>> the same time. >>> >>> It is OPTIONAL for the callee to honor the preference for >>> denying the call at no match. >>> For example, a PSAP is likely to attempt the call even without an >>> indicated preference when there is no language in common, while a >>> call center might choose to fail the call. >>> >>> The called party MAY ignore the indication for denying the call, >>> e.g., >>> for the emergency services use case, >>> regardless of the absence of an asterisk, a PSAP will likely not >>> fail >>> the call; some call centers might reject a call in case of no >>> matching language >>> even if the offer contains an asterisk. >>> >>> -----end of change ------------------ >>> >>> ---Change in 5.5---- >>> >>> ---Add this text as a separate example e.g. last in 5.5--- >>> An offer requesting the following media streams: audio for the >>> caller >>> to send using spoken English (most preferred modality) or American >>> Sign Language (less preferred modality), >>> audio for the caller to receive spoken English (most preferred >>> modality) or >>> American Sign Language (less preferred modality), >>> supplemental text. The offer also requests that the >>> call proceed even if the callee does not support any of the >>> languages. The offer is likely from a hearing person with >>> knowledge in sign language: >>> >>> m=text 45020 RTP/AVP 103 104 >>> >>> m=audio 49250 RTP/AVP 20 >>> a=hlang-recv:en * >>> a=hlang-send:en * >>> >>> m=video 51372 RTP/AVP 31 32 >>> a=hlang-recv: ase >>> a=hlang-send: ase >>> >>> An answer for the above offer, indicating video in which the >>> callee will send and receive American Sign Language, because that >>> callee had no capability for spoken English. The text and audio >>> streams are opened as supplementary streams. >>> >>> m=text 45020 RTP/AVP 103 104 >>> m=audio 49250 RTP/AVP 20 >>> >>> >>> m=video 51372 RTP/AVP 31 32 >>> a=hlang-send: ase >>> a=hlang-recv: ase >>> ---end of change--- >>> >>> >>> >>> >>> >>> -- >>> ----------------------------------------- >>> 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 From nobody Mon Jun 5 10:20:04 2017 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 43ECA129412 for ; Mon, 5 Jun 2017 10:20:03 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -0.852 X-Spam-Level: X-Spam-Status: No, score=-0.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, RP_MATCHES_RCVD=-0.001] autolearn=no 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 z0DOLraNLI1a for ; Mon, 5 Jun 2017 10:20:02 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 9506D129411 for ; Mon, 5 Jun 2017 10:20:02 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Mon, 5 Jun 2017 10:22:39 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <149609884905.14640.4714137651572553743@ietfa.amsl.com> <54839aba-7ac8-79e4-74f8-927eb455d8af@omnitor.se> <8ca64f00-b1d1-e4da-05cf-0e4663178d85@omnitor.se> X-Mailer: Eudora for Mac OS X Date: Sun, 4 Jun 2017 14:51:48 -0700 To: Gunnar =?iso-8859-1?Q?Hellstr=F6m?= , slim@ietf.org From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Archived-At: Subject: Re: [Slim] New wording for the use of the asterisk 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, 05 Jun 2017 17:20:03 -0000 Hi Gunnar, What I'd suggest is that we include an informational reference to the draft, although that requires that at least an initial version of the draft be published pretty quickly. So, my suggestion is that you publish at least a skeleton draft right away (which you can revise and extend quickly), and we add text along the lines of the following, perhaps after the second paragraph of Section 5.3: Note that separate work [draft-xxx] proposes to use the asterisk (or lack thereof) to convey information between endpoints. This alerts implementers to the other draft. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Weiner's Law of Libraries: There are no answers, only cross references. From nobody Mon Jun 5 13:21:53 2017 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 B077412953F for ; Mon, 5 Jun 2017 13:21:50 -0700 (PDT) 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, 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 XuHvp9Wz7znw for ; Mon, 5 Jun 2017 13:21:48 -0700 (PDT) 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 E0906129C2B for ; Mon, 5 Jun 2017 13:21:47 -0700 (PDT) X-Halon-ID: 96efd18d-4a2c-11e7-bcc7-005056917f90 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [77.53.231.21]) by bin-vsp-out-02.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Mon, 5 Jun 2017 22:21:42 +0200 (CEST) To: Randall Gellens , slim@ietf.org References: <149609884905.14640.4714137651572553743@ietfa.amsl.com> <54839aba-7ac8-79e4-74f8-927eb455d8af@omnitor.se> <8ca64f00-b1d1-e4da-05cf-0e4663178d85@omnitor.se> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: Date: Mon, 5 Jun 2017 22:21:41 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Slim] New wording for the use of the asterisk 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, 05 Jun 2017 20:21:51 -0000 Den 2017-06-04 kl. 23:51, skrev Randall Gellens: > Hi Gunnar, > > What I'd suggest is that we include an informational reference to the > draft, although that requires that at least an initial version of the > draft be published pretty quickly. So, my suggestion is that you > publish at least a skeleton draft right away (which you can revise and > extend quickly), and we add text along the lines of the following, > perhaps after the second paragraph of Section 5.3: > > Note that separate work [draft-xxx] proposes to use the asterisk (or > lack thereof) to convey information between endpoints. > > This alerts implementers to the other draft. This might be a possible way ahead, if others also think it is feasible. The wording and placement of the text requires more tuning. E.g. it should not say "proposes", but rather "specifies". Gunnar -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 From nobody Tue Jun 6 05:52:30 2017 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 A50E3128DE7 for ; Tue, 6 Jun 2017 05:52:28 -0700 (PDT) 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 wfhpk2eqj8VT for ; Tue, 6 Jun 2017 05:52:25 -0700 (PDT) Received: from bin-vsp-out-01.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 5D118127B73 for ; Tue, 6 Jun 2017 05:52:25 -0700 (PDT) X-Halon-ID: f988d9ac-4ab6-11e7-b758-005056917a89 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [77.53.231.21]) by bin-vsp-out-01.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Tue, 6 Jun 2017 14:52:18 +0200 (CEST) From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= To: "slim@ietf.org" , Randall Gellens Message-ID: Date: Tue, 6 Jun 2017 14:52:16 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Slim] New Version Notification for draft-hellstrom-slim-modalitypref-00.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, 06 Jun 2017 12:52:29 -0000 I have uploaded an initial draft specifying the modality preference indication and negotiation as an extension to draft-ietf-slim-negotiating-human-language. Since it relates to the protocol for language and call denial negotiation, I marked it as a standard track document rather than informational that had been proposed. The draft is in initial state, still missing a couple of sections. /Gunnar ---------------------------------------------------------------- A new version of I-D, draft-hellstrom-slim-modalitypref-00.txt has been successfully submitted by Gunnar Hellstrom and posted to the IETF repository. Name: draft-hellstrom-slim-modalitypref Revision: 00 Title: Negotiating Modality in Real-Time Communications Document date: 2017-06-05 Group: Individual Submission Pages: 6 URL: https://www.ietf.org/internet-drafts/draft-hellstrom-slim-modalitypref-00.txt Status: https://datatracker.ietf.org/doc/draft-hellstrom-slim-modalitypref/ Htmlized: https://tools.ietf.org/html/draft-hellstrom-slim-modalitypref-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-hellstrom-slim-modalitypref-00 Abstract: When negotiating language for a real-time session, users may have very specific preferences for using one modality (spoken, written or signed) over other possible but less preferred modalities. This specification introduces indication of modality preference to be used in session negotiation in combination with an earlier speified mechanism for language preference negotiation. 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. The IETF Secretariat From nobody Tue Jun 6 14:51:27 2017 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 D25AE1271FD for ; Tue, 6 Jun 2017 14:51:25 -0700 (PDT) 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 ELmrcm6KDFIs for ; Tue, 6 Jun 2017 14:51:23 -0700 (PDT) Received: from bin-vsp-out-03.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 618C5128CD5 for ; Tue, 6 Jun 2017 14:51:23 -0700 (PDT) X-Halon-ID: 441c7279-4b02-11e7-bca7-0050569116f7 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [77.53.231.21]) by bin-vsp-out-03.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Tue, 6 Jun 2017 23:51:16 +0200 (CEST) From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= To: "slim@ietf.org" Message-ID: Date: Tue, 6 Jun 2017 23:51:15 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Slim] I-D Action: draft-hellstrom-slim-modalitypref-01.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, 06 Jun 2017 21:51:26 -0000 A new version of the modality preference draft is available. This version has all sections, although I need guidance for how to express IANA considerations for extending the semantics of just one parameter of an SDP attribute registered by another specification. /Gunnar ------------------------------------ A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Negotiating Modality in Real-Time Communications Author : Gunnar Hellstrom Filename : draft-hellstrom-slim-modalitypref-01.txt Pages : 8 Date : 2017-06-06 Abstract: When negotiating language for a real-time session, users may have very specific preferences for using one modality (spoken, written or signed) over other possible but less preferred modalities. This specification introduces indication of modality preference to be used in session negotiation in combination with an earlier speified mechanism for language preference negotiation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-hellstrom-slim-modalitypref/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-hellstrom-slim-modalitypref-01 https://datatracker.ietf.org/doc/html/draft-hellstrom-slim-modalitypref-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-hellstrom-slim-modalitypref-01 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/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Wed Jun 7 04:36:33 2017 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 36828127843 for ; Wed, 7 Jun 2017 04:36:31 -0700 (PDT) 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, 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 zkLj5CaIYf8d for ; Wed, 7 Jun 2017 04:36:29 -0700 (PDT) Received: from bin-vsp-out-03.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 F2A011275C5 for ; Wed, 7 Jun 2017 04:36:28 -0700 (PDT) X-Halon-ID: 88489c7b-4b75-11e7-bca7-0050569116f7 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [77.53.231.21]) by bin-vsp-out-03.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Wed, 7 Jun 2017 13:36:22 +0200 (CEST) From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= To: "slim@ietf.org" Message-ID: <33a3da56-427b-5e86-f6f7-ea53a5d7a7ad@omnitor.se> Date: Wed, 7 Jun 2017 13:36:22 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Slim] I-D Action: draft-hellstrom-slim-simultaneous-modalities-00.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: Wed, 07 Jun 2017 11:36:31 -0000 An initial draft for identifying simultaneous modalities in real-time communication is available. I would like to get acceptance of the draft as a working group draft. Regards Gunnar A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Negotiating Simultaneous Modalities in Real-Time Communications Author : Gunnar Hellstrom Filename : draft-hellstrom-slim-simultaneous-modalities-00.txt Pages : 6 Date : 2017-06-07 Abstract: In a real-time communication session, there may be a need or preference for receiving the same content in two or more simultaneous modalities. This specification extends a mechanism for human language negotiation with a mechanism for indication of preference for, or the availability of, simultaneously provided transformations of original contents. This indication enables negotiation of simultaneous modalities in real-time sessions. Applications are for example provision of both spoken and written content in a real-time call (captioning), or provision of both spoken language original and sign language interpretation of the original language in a real-time session. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-hellstrom-slim-simultaneous-modalities/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-hellstrom-slim-simultaneous-modalities-00 https://datatracker.ietf.org/doc/html/draft-hellstrom-slim-simultaneous-modalities-00 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/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Wed Jun 7 11:23:17 2017 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 36BED129B33 for ; Wed, 7 Jun 2017 11:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 bUYVzlnVEdk3 for ; Wed, 7 Jun 2017 11:23:13 -0700 (PDT) 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 ADBCB129B3C for ; Wed, 7 Jun 2017 11:21:06 -0700 (PDT) X-Halon-ID: 0ed36779-4bae-11e7-bcc7-005056917f90 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [77.53.230.196]) by bin-vsp-out-02.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Wed, 7 Jun 2017 20:21:00 +0200 (CEST) To: Randall Gellens , "slim@ietf.org" References: <149609884905.14640.4714137651572553743@ietfa.amsl.com> <54839aba-7ac8-79e4-74f8-927eb455d8af@omnitor.se> <8ca64f00-b1d1-e4da-05cf-0e4663178d85@omnitor.se> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <11fef8a5-8ed3-5e70-4ccd-66e7613b22fc@omnitor.se> Date: Wed, 7 Jun 2017 20:20:55 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------F2AA3AE456EAC8341E39B3F0" Archived-At: Subject: Re: [Slim] New wording for the use of the asterisk 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: Wed, 07 Jun 2017 18:23:16 -0000 This is a multi-part message in MIME format. --------------F2AA3AE456EAC8341E39B3F0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Den 2017-06-06 kl. 03:00, skrev Randall Gellens: > At 10:21 PM +0200 6/5/17, Gunnar Hellström wrote: > >> Den 2017-06-04 kl. 23:51, skrev Randall Gellens: >>> Hi Gunnar, >>> >>> What I'd suggest is that we include an informational reference to >>> the draft, although that requires that at least an initial version >>> of the draft be published pretty quickly. So, my suggestion is that >>> you publish at least a skeleton draft right away (which you can >>> revise and extend quickly), and we add text along the lines of the >>> following, perhaps after the second paragraph of Section 5.3: >>> >>> Note that separate work [draft-xxx] proposes to use the asterisk >>> (or >>> lack thereof) to convey information between endpoints. >>> >>> This alerts implementers to the other draft. >> This might be a possible way ahead, if others also think it is >> feasible. > > Gunnar, please upload at least a skeleton version of the draft right > away, and let me know the title. If you need help with that, I can > create one. > >> The wording and placement of the text requires more tuning. E.g. it >> should not say "proposes", but rather "specifies". > > I was reluctant to say "specifies" until we have a more solid draft > (we don't yet have anything). How about if the text says "uses" rather > than "proposes to use"? I think that covers it. Yes, the drafts for the two functionality extensions are uploaded. I would think that it would be more logical to insert the note about the added meaning of the asterisk in section 5.2, because 5.3 is for the current interpretation case only. I propose a change to this current text in 5.2 ------old text---- In an offer, each value MAY have an asterisk appended as the final value. An asterisk appended to either value in an offer indicates a request by the caller to the callee to not fail the call if there is no language in common. See Section 5.3 for more information and discussion. -----new text could be---- In an offer or answer, each value MAY have an asterisk appended as the final token. An asterisk appended to either value in an offer indicates a request by the caller to the callee to not fail the call if there is no language in common. See Section 5.3 for more information and discussion. Note that separate work [draft-hellstrom-slim-modalitypref] extends the use of the asterisk with a media level indication. ---end of change----------------- The other draft, about simultaneous modality may also need to be announced. I suggest this change: ----old text in 5.2------ BCP 47 describes mechanisms for matching language tags. Note that [RFC5646] Section 4.1 advises to "tag content wisely" and not include unnecessary subtags. ----new text----- BCP 47 describes mechanisms for matching language tags. Note that [RFC5646] Section 4.1 advises to "tag content wisely" and not include unnecessary subtags. Note also that separate work in [draft-hellstrom-slim-simultaneous-modality] uses a notation with a subtag for extended functionality. It is therefore of importance to use the mechanisms from BCP 47 for matching languages correctly. ----end of change----- This all builds on that we can at least get WG draft status soon on the new drafts. Gunnar > > -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 --------------F2AA3AE456EAC8341E39B3F0 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Den 2017-06-06 kl. 03:00, skrev Randall Gellens:
At 10:21 PM +0200 6/5/17, Gunnar Hellström wrote:

 Den 2017-06-04 kl. 23:51, skrev Randall Gellens:
 Hi Gunnar,

 What I'd suggest is that we include an informational reference to the draft, although that requires that at least an initial version of the draft be published pretty quickly.  So, my suggestion is that you publish at least a skeleton draft right away (which you can revise and extend quickly), and we add text along the lines of the following, perhaps after the second paragraph of Section 5.3:

    Note that separate work [draft-xxx] proposes to use the asterisk (or
    lack thereof) to convey information between endpoints.

 This alerts implementers to the other draft.
 This might be a possible way ahead, if others also think it is feasible.

Gunnar, please upload at least a skeleton version of the draft right away, and let me know the title.  If you need help with that, I can create one.

 The wording and placement of the text requires more tuning. E.g. it should not say "proposes", but rather "specifies".

I was reluctant to say "specifies" until we have a more solid draft (we don't yet have anything). How about if the text says "uses" rather than "proposes to use"?  I think that covers it.
Yes, the drafts for the two functionality extensions are uploaded.

I would think that it would be more logical to insert the note about the added meaning of the asterisk in section 5.2, because 5.3 is for the current interpretation case only.

I propose a change to this current text in 5.2

------old text----

   In an offer, each value MAY have an asterisk appended as the final
   value.  An asterisk appended to either value in an offer indicates a
   request by the caller to the callee to not fail the call if there is
   no language in common.  See Section 5.3 for more information and
   discussion.
-----new text could be----
   In an offer or answer, each value MAY have an asterisk appended as the final
   token.  An asterisk appended to either value in an offer indicates a
   request by the caller to the callee to not fail the call if there is
   no language in common.  See Section 5.3 for more information and
   discussion. 

   Note that separate work [draft-hellstrom-slim-modalitypref] extends the use of the 
   asterisk with a media level indication.


---end of change----------------- 

 


The other draft, about simultaneous modality may also need to be announced.
I suggest this change:

----old text in 5.2------
 
 BCP 47 describes mechanisms for
   matching language tags.  Note that [RFC5646] Section 4.1 advises to
   "tag content wisely" and not include unnecessary subtags.
 ----new text-----
 
 BCP 47 describes mechanisms for
   matching language tags.  Note that [RFC5646] Section 4.1 advises to
   "tag content wisely" and not include unnecessary subtags.

 
 Note also that separate work in [draft-hellstrom-slim-simultaneous-modality] uses a 
 notation with a subtag for extended functionality. It is therefore of importance to 
 use the mechanisms from BCP 47 for matching languages correctly.

----end of change-----
This all builds on that we can at least get WG draft status soon on the new drafts.

Gunnar



-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288
--------------F2AA3AE456EAC8341E39B3F0-- From nobody Wed Jun 7 12:43:27 2017 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 75CA112EBF9 for ; Wed, 7 Jun 2017 12:43:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 Jg7Ol7YhMmvn for ; Wed, 7 Jun 2017 12:43:25 -0700 (PDT) Received: from resqmta-ch2-11v.sys.comcast.net (resqmta-ch2-11v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:43]) (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 DA615129B40 for ; Wed, 7 Jun 2017 12:43:24 -0700 (PDT) Received: from resomta-ch2-04v.sys.comcast.net ([69.252.207.100]) by resqmta-ch2-11v.sys.comcast.net with SMTP id IgqDdtYMIT4XXIgrUdTmTM; Wed, 07 Jun 2017 19:43:24 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1496864604; bh=XM+xHtxpBqcSAcy/fhzn/3ltHgUTAeGIwcqnwGhO7/k=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=BsmiYOpNPaNu7JH/qUzh9Y0LOzgJP5vsxot2K9vF0ykiYH5HyK3SGDk+w69j43S6E mY6sxOJQWC/Ff1KNK7xgdH9LWRmqquCmXs8w414OIzV+F2tNx1yB8EaJuqKNOkCxEW fePqXpKRwzCNvjCMzFeKqA3IXNsWrhJJvLjUvUOBpqF4RZho4lMMYDz/yyRxgMCZK0 ZW05+TQrr/x8gwknZ0p5oznthXLWyUQ/iLzM9ioMoyI27dqz/+8wSRhpuSH56grkFr f/M2232UcpBALpgQMkXAyKuf+CSfgmL9Bj7tR2TvR4UNnmGUgASBbuIJIcNyfnMWsu Hw6cGHmjNGZ9Q== Received: from [192.168.1.110] ([24.62.227.142]) by resomta-ch2-04v.sys.comcast.net with SMTP id IgrTdyi83FcZ2IgrTddHVj; Wed, 07 Jun 2017 19:43:24 +0000 To: slim@ietf.org References: <33a3da56-427b-5e86-f6f7-ea53a5d7a7ad@omnitor.se> From: Paul Kyzivat Message-ID: <9016202e-3c8d-4ed0-192c-a4f2c198771a@comcast.net> Date: Wed, 7 Jun 2017 15:43:23 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <33a3da56-427b-5e86-f6f7-ea53a5d7a7ad@omnitor.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfMNHl1AcmzzWfIbvJ041sxUqp7XGsUtu+VkrBOgxXL48/Lc2EFg4VDioNmKMrmTVCi2OpUPC58V+4yCAAjkoiWy9Q93rniIRVmPQuCikZIK4gWp7dBY1 sRGFohBNf6UbvU1KTPZwROZb4PL1JlQwpfjBDIbHBlxUOOBo4FlZU6aQ Archived-At: Subject: Re: [Slim] draft-hellstrom-slim-simultaneous-modalities & modalitypref X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 19:43:26 -0000 I did a quick review of these documents. My feeling is that these have moved to quickly to specific solution syntax without first sorting out exactly what the needs are. I am sympathetic to what I think the goals are, but am concerned that the proposed solutions are not ideal. For instance, simultaneous-modalities indicates the languages of the source form and the transformed form. But it does not indicate precisely which media stream contains the source form. I guess the assumption is that there will only be one other media stream with the appropriate language indication. But that is just an assumption. It may well apply in a number of common cases, but I'm sure we can come up with more complex cases where that isn't true. ISTM that it would be better to come up with a syntax that explicitly links the source and transformed media streams. (E.g. a new usage of the grouping framework.) In the modalitypref document if find the semantics fuzzy, and the relationship of the use of "*" for this to be even more fuzzy when related to its use in draft-ietf-slim-negotiating-human-language. For instance, I see a potential conflict between need to express degree of competence with a modality with preference for that modality. It may be that those should be handles as two distinct indicators. Further discussion is needed. Thanks, Paul From nobody Wed Jun 7 13:44:43 2017 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 BE875131486 for ; Wed, 7 Jun 2017 13:44:42 -0700 (PDT) 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, 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 0ul2qHIHjIkJ for ; Wed, 7 Jun 2017 13:44:40 -0700 (PDT) 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 4A962124BE8 for ; Wed, 7 Jun 2017 13:44:40 -0700 (PDT) X-Halon-ID: 1cbdfadc-4bc2-11e7-bca7-0050569116f7 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [77.53.230.196]) by bin-vsp-out-03.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Wed, 7 Jun 2017 22:44:33 +0200 (CEST) To: slim@ietf.org References: <33a3da56-427b-5e86-f6f7-ea53a5d7a7ad@omnitor.se> <9016202e-3c8d-4ed0-192c-a4f2c198771a@comcast.net> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: Date: Wed, 7 Jun 2017 22:44:32 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <9016202e-3c8d-4ed0-192c-a4f2c198771a@comcast.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Slim] draft-hellstrom-slim-simultaneous-modalities & modalitypref X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 20:44:42 -0000 Paul, thanks for reviewing and commenting, Den 2017-06-07 kl. 21:43, skrev Paul Kyzivat: > I did a quick review of these documents. My feeling is that these have > moved to quickly to specific solution syntax without first sorting out > exactly what the needs are. I am sympathetic to what I think the goals > are, but am concerned that the proposed solutions are not ideal. During the lengthy discussions about the functionality that these two drafts add to the human-language-negotiation draft, low complexity has always been a strong argument for keeping notation very simple and rather make functionality shortcuts than allow parameters that add complexity. That explains why the proposals look as they do, but of course decisions can be made to change this approach. > > > For instance, simultaneous-modalities indicates the languages of the > source form and the transformed form. But it does not indicate > precisely which media stream contains the source form. I guess the > assumption is that there will only be one other media stream with the > appropriate language indication. But that is just an assumption. It > may well apply in a number of common cases, but I'm sure we can come > up with more complex cases where that isn't true. I think it will be straightforward to find the original. It must be in another media than the one with the "t" extension, because the human-language-negotiation draft does not allow more than one language negotiated per stream. If the original is a sign language, then it is to be found in the video stream. If it is not a sign language the original is to be searched in the audio specification if the "t"-extended language is in a written media and the opposite. Only if we start using more than one media stream per media we get more complications to find the original. But it is still doable and we have not at all discussed multiple streams of the same media kind for our base draft. > ISTM that it would be better to come up with a syntax that explicitly > links the source and transformed media streams. (E.g. a new usage of > the grouping framework.) We have discussed the use of the grouping framework a long time ago, and it was not a popular solution because of the complexity it causes. An alternative I have proposed is q-values with the extra rule that q-values less than 0.1 apart implies request for simultaneous languages/modality. But q-values have been rejected. > > > In the modalitypref document if find the semantics fuzzy, and the > relationship of the use of "*" for this to be even more fuzzy when > related to its use in draft-ietf-slim-negotiating-human-language. For > instance, I see a potential conflict between need to express degree of > competence with a modality with preference for that modality. It may > be that those should be handles as two distinct indicators. Further > discussion is needed. I think it is often the degree of competence that causes the grade of preference. But sometimes it may be the feasability of using a modality in the conversational setting, e.g. a noisy place. The current coding with the * makes a shortcut in that all languages specified for that media gets the same preference. So the following reasoning cannot be coded: "I can use spoken English well, but my French is so bad that I prefer to use that in written modality" . I think the preference put on the modality rather than on language level is a good and realistic simplification. I agree that the co-use of the asterisk with the preference for non-denial of the session is not elegant. But its effects are mild and described in the modality-preference draft. Alternatives are q-values with scope over the whole SDP or separate a=modalitypreference:HI attributes. Q-value proposals have been rejected. Thanks, Gunnar > > Thanks, > Paul > > _______________________________________________ > 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 Wed Jun 7 14:50:28 2017 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 9D1E412EB53 for ; Wed, 7 Jun 2017 14:50:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 9BjAqbWxtaEW for ; Wed, 7 Jun 2017 14:50:25 -0700 (PDT) Received: from resqmta-ch2-11v.sys.comcast.net (resqmta-ch2-11v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:43]) (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 DDA311293EC for ; Wed, 7 Jun 2017 14:50:24 -0700 (PDT) Received: from resomta-ch2-12v.sys.comcast.net ([69.252.207.108]) by resqmta-ch2-11v.sys.comcast.net with SMTP id IiovdtjG5T4XXIiqOdUA4U; Wed, 07 Jun 2017 21:50:24 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1496872224; bh=Jpuqa2NTE685TrwoE+m3OhWgjZpzS6mqDvlJ+ML0swE=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=G6g1lNmRX2+l8rxLjKU1CH5i3y7COmWCRCm/7XClh1WWUBnz3ZNqsSgPhQLky9OA/ 0UH2oLxL8MevE3Di/h5ETCANldmuShbSw/WFh/HC5ESBtze9Fz3a0zcNB5uJyg8riD Kj7H9UNxLZErJvKxe1wlUGBFoIg3XLLa/wYcE2Wi4Nh6jg0PmCD926TYQqPFE/9m6T b+tBRsl56JQ5+ise7P9MQ2hw/Fivr4WMFNOFdCrGKfk49vKYLtO9l/9hs1Qj0trTaB JK9BU3AcpizgMgY1mQPp7wM+80AD1xYT4qPiSCq/CSQ8hRZiv8XVT1CXglNYwpwWtC 4W0iCxv0P8QeA== Received: from [192.168.1.110] ([24.62.227.142]) by resomta-ch2-12v.sys.comcast.net with SMTP id IiqNdv8AFqoNEIiqNdFA6f; Wed, 07 Jun 2017 21:50:24 +0000 To: slim@ietf.org References: <33a3da56-427b-5e86-f6f7-ea53a5d7a7ad@omnitor.se> <9016202e-3c8d-4ed0-192c-a4f2c198771a@comcast.net> From: Paul Kyzivat Message-ID: <9c27e91c-37c5-3e2c-3ed2-cde31f3dc73f@comcast.net> Date: Wed, 7 Jun 2017 17:50:22 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfF5AUmNyt3UD4srcCSBbbqCkl9R3TItHEL4zzBuOvJfB6plvZECFdrThOhHe2OXh76n61qzVCwxO8f9zAXokFvWBFImOgKUM1DoxhiofiojHrov2sys6 IHqHt4vQaHaiS9WJKYTd62cmaUBXGBe4qO9udwD0rnWrxpDt2L1Q6ORR Archived-At: Subject: Re: [Slim] draft-hellstrom-slim-simultaneous-modalities & modalitypref X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 21:50:27 -0000 On 6/7/17 4:44 PM, Gunnar Hellström wrote: > Paul, thanks for reviewing and commenting, > > Den 2017-06-07 kl. 21:43, skrev Paul Kyzivat: >> I did a quick review of these documents. My feeling is that these have >> moved to quickly to specific solution syntax without first sorting out >> exactly what the needs are. I am sympathetic to what I think the goals >> are, but am concerned that the proposed solutions are not ideal. > During the lengthy discussions about the functionality that these > two drafts add to the human-language-negotiation draft, low complexity > has always been a strong argument for keeping notation very simple and > rather make functionality shortcuts than allow parameters that add > complexity. That explains why the proposals look as they do, but of > course decisions can be made to change this approach. >> >> >> For instance, simultaneous-modalities indicates the languages of the >> source form and the transformed form. But it does not indicate >> precisely which media stream contains the source form. I guess the >> assumption is that there will only be one other media stream with the >> appropriate language indication. But that is just an assumption. It >> may well apply in a number of common cases, but I'm sure we can come >> up with more complex cases where that isn't true. > I think it will be straightforward to find the original. It must be > in another media than the one with the "t" extension, because the > human-language-negotiation draft does not allow more than one language > negotiated per stream. If the original is a sign language, then it is to > be found in the video stream. If it is not a sign language the original > is to be searched in the audio specification if the "t"-extended > language is in a written media and the opposite. Only if we start using > more than one media stream per media we get more complications to find > the original. But it is still doable and we have not at all discussed > multiple streams of the same media kind for our base draft. AFAIK we have not discussed it because there has been no need to. Not discussing doesn't mean that such usage has been excluded or that it needs more consideration before it can be used. But once we start linking two streams together then it gets important. Leaving it to ad hoc implementation without specification is asking for trouble. >> ISTM that it would be better to come up with a syntax that explicitly >> links the source and transformed media streams. (E.g. a new usage of >> the grouping framework.) > We have discussed the use of the grouping framework a long time ago, > and it was not a popular solution because of the complexity it causes. I only threw that out as one possibility. But it directly fits the use case, and whatever complexity it brings is mitigated because it is an existing mechanism. > An alternative I have proposed is q-values with the extra rule that > q-values less than 0.1 apart implies request for simultaneous > languages/modality. But q-values have been rejected. That addresses an entirely different problem. >> In the modalitypref document if find the semantics fuzzy, and the >> relationship of the use of "*" for this to be even more fuzzy when >> related to its use in draft-ietf-slim-negotiating-human-language. For >> instance, I see a potential conflict between need to express degree of >> competence with a modality with preference for that modality. It may >> be that those should be handles as two distinct indicators. Further >> discussion is needed. > I think it is often the degree of competence that causes the grade > of preference. But sometimes it may be the > feasability of using a modality in the conversational setting, e.g. a > noisy place. > The current coding with the * makes a shortcut in that all languages > specified for that media gets the same preference. So the following > reasoning cannot be coded: "I can use spoken English well, but my French > is so bad that I prefer to use that in written modality" . > I think the preference put on the modality rather than on language level > is a good and realistic simplification. I agree that the co-use of the > asterisk with the preference for non-denial of the session is not > elegant. But its effects are mild and described in the > modality-preference draft. > > Alternatives are q-values with scope over the whole SDP or separate > a=modalitypreference:HI attributes. Q-value proposals have been rejected. ISTM that the rejections were because these were perceived as making the base mechanism more complex. Once this is split off as a separate mechanism then I think we get to revisit those discussions. Thanks, Paul From nobody Wed Jun 7 15:20:42 2017 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 C375F129453 for ; Wed, 7 Jun 2017 15:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 RUKqBc_xKRcl for ; Wed, 7 Jun 2017 15:20:39 -0700 (PDT) Received: from resqmta-ch2-06v.sys.comcast.net (resqmta-ch2-06v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:38]) (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 198331270A7 for ; Wed, 7 Jun 2017 15:20:38 -0700 (PDT) Received: from resomta-ch2-04v.sys.comcast.net ([69.252.207.100]) by resqmta-ch2-06v.sys.comcast.net with SMTP id IjJcdGtz6l4eqIjJedBaKt; Wed, 07 Jun 2017 22:20:38 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1496874038; bh=SbUkjVTFtCDDNKGtVJNwxUsPL8XF4+m0Cm5LWnp9LLk=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=YXw45mCmvWBJC8UgC/Q7XnvkHqSoRwBclKdlQqM/sYGoc5FhQv3CVIVQeBlNgCuAd EVkTrTQ7RhtEHYnIfNfhfHF0fTLDRvxnwuECkKEYpsrJA/Qs890NBj7s+HFUL+UZr7 jvXsRFKbUnJ9du6o9fC/wEgr+xehHDS7RfFK0YllBH5E4zYSD6pU+I7FAfOrr6tIZ5 RtvwyGwE7N813PIsHwdX+2jB9X0s/XcrMJ2sIgImLnLxOU0g/ASOQ3nTUIlzP1t7b1 RqQoXmsUit0GZxr0ZRmLmclCGc8xS0jMFBmt7tqXqcq6kc5yQ0Rn4LZgploZeJGTCl aqjpbX1VStgxg== Received: from [192.168.1.110] ([24.62.227.142]) by resomta-ch2-04v.sys.comcast.net with SMTP id IjJddzJmiFcZ2IjJdddfpg; Wed, 07 Jun 2017 22:20:38 +0000 To: slim@ietf.org References: <64D68B73-256D-4478-A970-5037B0187D73@brianrosen.net> From: Paul Kyzivat Message-ID: <70ea7743-7d6a-16ae-f975-72284ff12dfb@comcast.net> Date: Wed, 7 Jun 2017 18:20:37 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfKMOauv3SBb1NNrc1sb5EfVXkpSfgqhuMEVP5ZAQqGaEPsvtpil52f8s04KbIYdvnC6JfBlCCoasOAt52uUDLuOyaK5fPsKrINnkayLf/bljRRugvr+t xRFRaEKNjQucvtaW4rm+QKafF5H2Z+QnV+tsYc7Wi33Lu+76FJyIs0qr Archived-At: Subject: Re: [Slim] draft-ietf-slim-negotiating-human-language-10: extensibility X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 22:20:41 -0000 I posted the message below a week ago but I never saw any responses to it: On 6/1/17 2:23 PM, Paul Kyzivat wrote: > On 6/1/17 2:10 PM, Brian Rosen wrote: [snip] >> I would prefer the current syntax, and not Accept-Language syntax. > > How about enhancing the syntax to support parameters for the values, but > only as a future extension mechanism? Unknown parameters to be ignored. > Then at least the hooks will be there to introduce something later if > desired. I think this would be the wise thing to do in any case. But especially so since we have have some issues pending that have been postponed as potential future work. Here is a specific proposal so we have something concrete to discuss: hlang-value-list = hlang-value *("," hlang-value) hlang-value = (Language-Tag / asterisk) *(";" hlang-param) hlang-param = hlang-param-name ["=" hlang-param-value] hlang-param-name = token hlang-param-value = token asterisk = "*" ; an asterisk (ASCII %2A) character Language-Tag = token = (I am *not* particularly attached to the specifics, but rather just to the general notion of having an extensibility hook. If you have issues with the syntax details I'm happy to discuss alternatives.) No specific hlang-params are to be defined in this draft. The semantics are that unknown hlang-params are to be ignored, and specific ones can be defined in extension drafts. Thanks, Paul From nobody Wed Jun 7 15:28:38 2017 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 881EE12EB62 for ; Wed, 7 Jun 2017 15:28:35 -0700 (PDT) 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 CyERIe4e2KvN for ; Wed, 7 Jun 2017 15:28:33 -0700 (PDT) Received: from mail-ua0-x234.google.com (mail-ua0-x234.google.com [IPv6:2607:f8b0:400c:c08::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 49C5A1270A7 for ; Wed, 7 Jun 2017 15:28:33 -0700 (PDT) Received: by mail-ua0-x234.google.com with SMTP id m31so12400433uam.1 for ; Wed, 07 Jun 2017 15:28:33 -0700 (PDT) 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=GpOPVhCTqm71M77rKiZlySwTcZB3aMwmT37CB0Ex3HE=; b=jGSss2szYVqDh5tj1ybDQxmwLd50qHf9PvAwcKvCKxWUcsp9NZm8vCTMNq2Izwgijj zEgJyVmnFsJeJjODyBv1tAUIeK1+OvJd/i4ed6rpm1WbhYwAU3a/9KMozKZ6gBk7ECt/ ZfkMcTn9vV3owSBgWB+v6WkeU+TNJpH8QXBmSxo9olu9wh78iEKqM5QynIG6V9cnyll4 NHONgi7W4ro6AgMfFId1T7qaJrtb5Dstns+GrNPGjxsvuERGa/zj5zVc4+loATNYXV/E eeX0PB1C549zimbe5h6E8wK1t2LAgPAetJxhfDYTmLun6rz+B3myzK/WOqJTV/w6Q0vg iPDQ== 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=GpOPVhCTqm71M77rKiZlySwTcZB3aMwmT37CB0Ex3HE=; b=jGJBDc5lpq7cmvp/7mk5T4JnfX4TbtlowPHruSzkA/4UMYbeQpxYLrYveUKmNd8APN ljVEF+HKBb/s1FgaXjYn3xn/B2NL5DmkbvNwL6ZWrIbFWW3or0z8wpCHBn+2D/N5OKlx uEuWMtIppcXfK1caJC1qMSZHAGoPB74FO8rCFiqI0v75fzsKHkMfzPba/UaUHx2dOHdp Nq9jW8DG5qETNlJnPVS9skzRJ0QVGD1VJDy02bSJUMa3h5Vt9i6jotpRlFkvxCaA1BOW 2/IkaEChDci/OkUvx8hSA5OQq0vD+xLjA4p4UCcjmq5OyCduLAAVjJ3atYBcrTmg/xia 6YQg== X-Gm-Message-State: AODbwcC8LPun+88qkioxvd01m5eJS1AyBhr8erdQj30mAxp3/sD6oDGl HUShoeV7jwhBz2pPt2ikGTj4NM759g== X-Received: by 10.159.48.132 with SMTP id j4mr12573815uab.42.1496874512368; Wed, 07 Jun 2017 15:28:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.52.218 with HTTP; Wed, 7 Jun 2017 15:28:12 -0700 (PDT) In-Reply-To: <70ea7743-7d6a-16ae-f975-72284ff12dfb@comcast.net> References: <64D68B73-256D-4478-A970-5037B0187D73@brianrosen.net> <70ea7743-7d6a-16ae-f975-72284ff12dfb@comcast.net> From: Bernard Aboba Date: Wed, 7 Jun 2017 15:28:12 -0700 Message-ID: To: Paul Kyzivat Cc: slim@ietf.org, Randall Gellens Content-Type: multipart/alternative; boundary="f403045e3ede954a9c0551664103" Archived-At: Subject: Re: [Slim] draft-ietf-slim-negotiating-human-language-10: extensibility X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 22:28:35 -0000 --f403045e3ede954a9c0551664103 Content-Type: text/plain; charset="UTF-8" Filed as Ticket #40: https://trac.ietf.org/trac/slim/ticket/40#ticket On Wed, Jun 7, 2017 at 3:20 PM, Paul Kyzivat wrote: > I posted the message below a week ago but I never saw any responses to it: > > On 6/1/17 2:23 PM, Paul Kyzivat wrote: > >> On 6/1/17 2:10 PM, Brian Rosen wrote: >> > > [snip] > > I would prefer the current syntax, and not Accept-Language syntax. >>> >> >> How about enhancing the syntax to support parameters for the values, but >> only as a future extension mechanism? Unknown parameters to be ignored. >> Then at least the hooks will be there to introduce something later if >> desired. >> > > I think this would be the wise thing to do in any case. But especially so > since we have have some issues pending that have been postponed as > potential future work. > > Here is a specific proposal so we have something concrete to discuss: > > hlang-value-list = hlang-value *("," hlang-value) > > hlang-value = (Language-Tag / asterisk) *(";" hlang-param) > > hlang-param = hlang-param-name ["=" hlang-param-value] > > hlang-param-name = token > > hlang-param-value = token > > asterisk = "*" ; an asterisk (ASCII %2A) character > > Language-Tag = > > token = > > (I am *not* particularly attached to the specifics, but rather just to the > general notion of having an extensibility hook. If you have issues with the > syntax details I'm happy to discuss alternatives.) > > No specific hlang-params are to be defined in this draft. The semantics > are that unknown hlang-params are to be ignored, and specific ones can be > defined in extension drafts. > > Thanks, > Paul > > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim > --f403045e3ede954a9c0551664103 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On W= ed, Jun 7, 2017 at 3:20 PM, Paul Kyzivat <paul.kyzivat@comcast.net<= /a>> wrote:
I posted the messag= e below a week ago but I never saw any responses to it:

On 6/1/17 2:23 PM, Paul Kyzivat wrote:
On 6/1/17 2:10 PM, Brian Rosen wrote:

[snip]

I would prefer the current syntax, and not Accept-Language syntax.

How about enhancing the syntax to support parameters for the values, but on= ly as a future extension mechanism? Unknown parameters to be ignored. Then = at least the hooks will be there to introduce something later if desired.

I think this would be the wise thing to do in any case. But especially so s= ince we have have some issues pending that have been postponed as potential= future work.

Here is a specific proposal so we have something concrete to discuss:

=C2=A0 =C2=A0 =C2=A0 hlang-value-list =3D hlang-value *("," hlang= -value)

=C2=A0 =C2=A0 =C2=A0 hlang-value =3D=C2=A0 (Language-Tag / asterisk) *(&quo= t;;" hlang-param)

=C2=A0 =C2=A0 =C2=A0 hlang-param =3D hlang-param-name ["=3D" hlan= g-param-value]

=C2=A0 =C2=A0 =C2=A0 hlang-param-name =3D token

=C2=A0 =C2=A0 =C2=A0 hlang-param-value =3D token

=C2=A0 =C2=A0 =C2=A0 asterisk=C2=A0 =C2=A0 =3D=C2=A0 "*"=C2=A0 = =C2=A0; an asterisk (ASCII %2A) character

=C2=A0 =C2=A0 =C2=A0 Language-Tag =3D <Defined in BCP 47>

=C2=A0 =C2=A0 =C2=A0 token =3D <Defined in RFC4566>

(I am *not* particularly attached to the specifics, but rather just to the = general notion of having an extensibility hook. If you have issues with the= syntax details I'm happy to discuss alternatives.)

No specific hlang-params are to be defined in this draft. The semantics are= that unknown hlang-params are to be ignored, and specific ones can be defi= ned in extension drafts.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Paul

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

--f403045e3ede954a9c0551664103-- From nobody Wed Jun 7 15:47:59 2017 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 588101270B4 for ; Wed, 7 Jun 2017 15:47:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=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 80ijJnXV9l8b for ; Wed, 7 Jun 2017 15:47:56 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 E49081270A7 for ; Wed, 7 Jun 2017 15:47:56 -0700 (PDT) Received: from Svantevit.roach.at (cpe-70-122-154-80.tx.res.rr.com [70.122.154.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v57MlsaS011582 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 7 Jun 2017 17:47:55 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-154-80.tx.res.rr.com [70.122.154.80] claimed to be Svantevit.roach.at To: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= , slim@ietf.org References: From: Adam Roach Message-ID: <7b4df8c5-4249-7799-79d3-0dd954b82dd3@nostrum.com> Date: Wed, 7 Jun 2017 17:47:54 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Slim] Collapse attribute syntax to one line 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: Wed, 07 Jun 2017 22:47:58 -0000 On 6/1/17 9:33 AM, Gunnar Hellström wrote: > Maybe the main question is: Will our own one-line syntax really be > less complex to parse than the Accept-Language syntax that we might be > able to find ready library routines for? > Adam Roach had views on complexity to parse different solutions. Maybe > you, Adam can have a view on this? As long as it is a space-delimited list of tokens, it should be trivial. That's a pretty common SDP pattern. The prospect of bolting a parser from some other protocol (e.g. Accept-Language) onto an SDP parsing library seems like it would be quite complex. The libraries I've worked with would almost certainly find it easier to write such a parser from scratch. /a From nobody Wed Jun 7 21:55:10 2017 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 9F10E129B52 for ; Wed, 7 Jun 2017 21:55:08 -0700 (PDT) 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 jzZFkpe7NBA3 for ; Wed, 7 Jun 2017 21:55:06 -0700 (PDT) Received: from bin-vsp-out-01.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 82FD1129B51 for ; Wed, 7 Jun 2017 21:55:06 -0700 (PDT) X-Halon-ID: a0eadb10-4c06-11e7-b75a-005056917a89 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [77.53.230.196]) by bin-vsp-out-01.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Thu, 8 Jun 2017 06:55:00 +0200 (CEST) To: Adam Roach , slim@ietf.org References: <7b4df8c5-4249-7799-79d3-0dd954b82dd3@nostrum.com> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: Date: Thu, 8 Jun 2017 06:54:56 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <7b4df8c5-4249-7799-79d3-0dd954b82dd3@nostrum.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Slim] Collapse attribute syntax to one line 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, 08 Jun 2017 04:55:09 -0000 Den 2017-06-08 kl. 00:47, skrev Adam Roach: > On 6/1/17 9:33 AM, Gunnar Hellström wrote: >> Maybe the main question is: Will our own one-line syntax really be >> less complex to parse than the Accept-Language syntax that we might >> be able to find ready library routines for? >> Adam Roach had views on complexity to parse different solutions. >> Maybe you, Adam can have a view on this? > > > As long as it is a space-delimited list of tokens, it should be > trivial. That's a pretty common SDP pattern. Thanks for your view on this, How about the semicolon and comma delimited syntax proposal just submitted by Paul? Also trivial? > > The prospect of bolting a parser from some other protocol (e.g. > Accept-Language) onto an SDP parsing library seems like it would be > quite complex. The libraries I've worked with would almost certainly > find it easier to write such a parser from scratch. > > /a > Thanks Gunnar -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 From nobody Thu Jun 8 09:58:55 2017 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 5483312EAF7; Thu, 8 Jun 2017 09:58:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: slim@ietf.org, nrooney@gsma.com, slim-chairs@ietf.org, aamelnikov@fastmail.fm X-Test-IDTracker: no X-IETF-IDTracker: 6.54.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149694113325.15087.16643503872415274483.idtracker@ietfa.amsl.com> Date: Thu, 08 Jun 2017 09:58:53 -0700 Archived-At: Subject: [Slim] slim - New Meeting Session Request for IETF 99 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: Thu, 08 Jun 2017 16:58:53 -0000 A new meeting session request has just been submitted by Natasha Rooney, a Chair of the slim working group. --------------------------------------------------------- Working Group Name: Selection of Language for Internet Media Area Name: Applications and Real-Time Area Session Requester: Natasha Rooney Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 15 Conflicts to Avoid: First Priority: mmusic ecrit ice rtcweb People who must be present: Dr. Bernard D. Aboba Ph.D. Alexey Melnikov Natasha Rooney Resources Requested: Experimental Room Setup (U-Shape and classroom, subject to availability) Special Requests: Many apologies on being late with this request. Anything you can do will be great. --------------------------------------------------------- From nobody Thu Jun 8 10:20:07 2017 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 030ED128D64 for ; Thu, 8 Jun 2017 10:20:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.911 X-Spam-Level: X-Spam-Status: No, score=-2.911 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] 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 QCrdc4xcIiBQ for ; Thu, 8 Jun 2017 10:20:01 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0066.outbound.protection.outlook.com [104.47.2.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FE59128990 for ; Thu, 8 Jun 2017 10:20:01 -0700 (PDT) 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=mm+rCPFx/nqZrNBSGhgbZyeEATcgOOAkPxCSitqjdCE=; b=VbAZqPzPbS7MEjXm1Dnjrzpa8gBA6B3cuRcN3XjlMN1K+rOswJneGOfj6lj34S8rBb7tZwT5RmdjZvkDH6h8IIT7DhPjKZ9gIO/KdwkXRKXn5G48zJBlr2LJ6Lagb5FZJfdTtx3BUeoyo1eNmBcAIArASFNzeKcM1ur6EXFUO8g= Received: from DB4PR04MB0813.eurprd04.prod.outlook.com (10.242.223.151) by DB4PR04MB0815.eurprd04.prod.outlook.com (10.242.223.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1143.10; Thu, 8 Jun 2017 17:19:59 +0000 Received: from DB4PR04MB0813.eurprd04.prod.outlook.com ([fe80::a18a:b128:2e95:210a]) by DB4PR04MB0813.eurprd04.prod.outlook.com ([fe80::a18a:b128:2e95:210a%17]) with mapi id 15.01.1143.018; Thu, 8 Jun 2017 17:19:59 +0000 From: Natasha Rooney To: "slim@ietf.org" Thread-Topic: Ticket #35 Have an attribute to abbreviate the bidirectionally-symmetric case Thread-Index: AQHS4Ht094T3pRLWR06yJbuA6g1XWQ== Date: Thu, 8 Jun 2017 17:19:59 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=gsma.com; x-originating-ip: [146.198.144.58] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB4PR04MB0815; 7:7yLOQf/EEfUqKtLhjL6GJgpfa6wwa1GZJfPw+Eouiy7nOvTpFeGevKTB5ZhR1ESoiKVTOu80ZnPLBz+GrFsw6eqU0PaX+oFANySlycDMpNJ2iA0Z/JZph63PsuUWK7S1vsShLA9/hW5McLal6AbLxTqWpVtjisT520oVQfhgLG+3wXmZbFR+MURbVKJomZXjHqZHH3XKc9H+RidJmWJ0oKq9B3tE5nRd6mpq6hiANiyEsxvCkYsfdqIg2lHF1c3Vgcb+vY94Jw9U+MqKbmMihYUnLWp6yA4VrbhHgi9n9ylkqs2XBTi5I4cWfkVIWIU1IA8F3tx8giQmjx2U3GcT5g== x-ms-traffictypediagnostic: DB4PR04MB0815: x-ms-office365-filtering-correlation-id: 7f81a23d-4fcc-4f86-9e53-08d4ae92976d x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:DB4PR04MB0815; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(10201501046)(3002001)(93006095)(93001095)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123555025)(20161123558100)(20161123564025)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB4PR04MB0815; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB4PR04MB0815; x-forefront-prvs: 0332AACBC3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39450400003)(39830400002)(39400400002)(39410400002)(53754006)(66066001)(5250100002)(606005)(6916009)(2900100001)(7906003)(25786009)(6436002)(8936002)(5640700003)(86362001)(14454004)(2351001)(50986999)(6506006)(33656002)(6486002)(6512007)(5660300001)(50226002)(3660700001)(189998001)(82746002)(83716003)(110136004)(38730400002)(102836003)(8676002)(3280700002)(7736002)(57306001)(99286003)(81166006)(236005)(966005)(6306002)(53936002)(1730700003)(3846002)(2906002)(2501003)(5890100001)(478600001)(36756003)(54896002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR04MB0815; H:DB4PR04MB0813.eurprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_FC6768245D4B4E96A9454AFD3BDECB87gsmacom_" MIME-Version: 1.0 X-OriginatorOrg: gsma.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jun 2017 17:19:59.2812 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72a4ff82-fec3-469d-aafb-ac8276216699 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR04MB0815 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: DB4PR04MB0813.eurprd04.prod.outlook.com X-MS-Exchange-CrossPremises-TransportTrafficType: Email X-MS-Exchange-CrossPremises-TransportTrafficSubType: 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.58 X-MS-Exchange-CrossPremises-transporttraffictype: Email X-MS-Exchange-CrossPremises-transporttrafficsubtype: 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: DB4PR04MB0815.eurprd04.prod.outlook.com Archived-At: Subject: [Slim] Ticket #35 Have an attribute to abbreviate the bidirectionally-symmetric case 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, 08 Jun 2017 17:20:05 -0000 --_000_FC6768245D4B4E96A9454AFD3BDECB87gsmacom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Related draft: https://datatracker.ietf.org/doc/draft-ietf-slim-negotiating= -human-language/ Hi all, Please review the below ticket and respond on-list to comments. We are work= ing through our final tickets before progressing the draft. https://trac.ietf.org/trac/slim/ticket/35 Natasha Natasha Rooney | Internet Engineering Director | Internet and Web Team | Te= chnology | GSMA | nrooney@gsma.com | +44 (0) 7730 = 219 765 | @thisNatasha | Skype: nrooney@gsm.org This email and its attachments are intended for the above named only and ma= y be confidential. If they have come to you in error you must take no actio= n 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. --_000_FC6768245D4B4E96A9454AFD3BDECB87gsmacom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Related draft: https://datatracker.ietf.org/doc/draft-ietf-slim-negotiating-human-langu= age/

Hi all,

Please review the below ticket and respond on-list to comme= nts. We are working through our final tickets before progressing the draft.=
https://trac.ietf.org/trac/slim/ticket/35

Natasha

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

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 ba= sed 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.

--_000_FC6768245D4B4E96A9454AFD3BDECB87gsmacom_-- From nobody Thu Jun 8 10:20:37 2017 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 A64341294BC for ; Thu, 8 Jun 2017 10:20:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-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 rZGUqUV8aDqZ for ; Thu, 8 Jun 2017 10:20:34 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0056.outbound.protection.outlook.com [104.47.2.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2468F1294F5 for ; Thu, 8 Jun 2017 10:20:30 -0700 (PDT) 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=lns0PLfQGoc9SWNvAWsD6FEIZfTd1E/EhnH9wTyyjEU=; b=OqlFygv5TMfFXpMshUUgnUrEMM+wGLUDsOqrhD7e+lAUWFkKbwtH1A0aGlCbkP/ZDy2JJxk9NN6FgBURnxwDGOIYB7YPsxFWRLUThQ9cKhQ4GUKrFBsoJ6DErGY2A52yNsfSIhPlNr7vTCxz6nJAjQ4DTEG0jxOO2Vj9/8KxLPM= Received: from DB4PR04MB0813.eurprd04.prod.outlook.com (10.242.223.151) by DB4PR04MB0815.eurprd04.prod.outlook.com (10.242.223.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1143.10; Thu, 8 Jun 2017 17:20:28 +0000 Received: from DB4PR04MB0813.eurprd04.prod.outlook.com ([fe80::a18a:b128:2e95:210a]) by DB4PR04MB0813.eurprd04.prod.outlook.com ([fe80::a18a:b128:2e95:210a%17]) with mapi id 15.01.1143.018; Thu, 8 Jun 2017 17:20:28 +0000 From: Natasha Rooney To: "slim@ietf.org" Thread-Topic: Ticket #34 Use the Accept-Language syntax Thread-Index: AQHS4HuGNSYVWhlH102u0D4jGGvkew== Date: Thu, 8 Jun 2017 17:20:28 +0000 Message-ID: <7DC33052-E4D1-4352-B4F8-8C8A416B0DF8@gsma.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=gsma.com; x-originating-ip: [146.198.144.58] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB4PR04MB0815; 7:7Kg/DWb1CBjgO9kajCmvOcTxtVGgfeX1Sejk0XQdp8y9PZfOD2dtAYQJssg0vPgO3WoTzgeFFPQXHT/82Q940BA9KMh471gR6Q4D72GeZnUrXHkeK/X6l+Dp3fNzcy1/vorbog/bzyiaOx8JlP8wtBJgo71HqEtKgoNgglHo8YJ9oBi8Tolqpl90baB939/u01LO9SwG3viI4LxUK5MZNt4KQc+z2uquXufLcuocGR1iEwYVCJZoO40Y4TDBMVPsEe/FZq0OOxEib/UWfCEMBkD6hPCq+XdZdBwQBHtZ11FQjEKB9lFPO8KBMjmywPg6j9uX/aEy02Fvpc4+1m7NLQ== x-ms-traffictypediagnostic: DB4PR04MB0815: x-ms-office365-filtering-correlation-id: 3edaca38-2fc1-42fe-63df-08d4ae92a8a4 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:DB4PR04MB0815; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(10201501046)(3002001)(93006095)(93001095)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123555025)(20161123558100)(20161123564025)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB4PR04MB0815; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB4PR04MB0815; x-forefront-prvs: 0332AACBC3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39450400003)(39830400002)(39400400002)(39410400002)(53754006)(66066001)(5250100002)(606005)(6916009)(2900100001)(7906003)(25786009)(6436002)(8936002)(5640700003)(86362001)(14454004)(2351001)(50986999)(6506006)(33656002)(6486002)(6512007)(5660300001)(50226002)(3660700001)(189998001)(82746002)(83716003)(110136004)(38730400002)(102836003)(8676002)(3280700002)(7736002)(57306001)(99286003)(81166006)(236005)(966005)(6306002)(53936002)(1730700003)(3846002)(2906002)(2501003)(5890100001)(478600001)(36756003)(54896002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR04MB0815; H:DB4PR04MB0813.eurprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_7DC33052E4D14352B4F88C8A416B0DF8gsmacom_" MIME-Version: 1.0 X-OriginatorOrg: gsma.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jun 2017 17:20:28.1654 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72a4ff82-fec3-469d-aafb-ac8276216699 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR04MB0815 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: DB4PR04MB0813.eurprd04.prod.outlook.com X-MS-Exchange-CrossPremises-TransportTrafficType: Email X-MS-Exchange-CrossPremises-TransportTrafficSubType: 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.58 X-MS-Exchange-CrossPremises-transporttraffictype: Email X-MS-Exchange-CrossPremises-transporttrafficsubtype: 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: DB4PR04MB0815.eurprd04.prod.outlook.com Archived-At: Subject: [Slim] Ticket #34 Use the Accept-Language syntax 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, 08 Jun 2017 17:20:37 -0000 --_000_7DC33052E4D14352B4F88C8A416B0DF8gsmacom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Related draft: https://datatracker.ietf.org/doc/draft-ietf-slim-negotiating= -human-language/ Hi all, Please review the below ticket and respond on-list to comments. We are work= ing through our final tickets before progressing the draft. https://trac.ietf.org/trac/slim/ticket/34 Natasha Natasha Rooney | Internet Engineering Director | Internet and Web Team | Te= chnology | GSMA | nrooney@gsma.com | +44 (0) 7730 = 219 765 | @thisNatasha | Skype: nrooney@gsm.org This email and its attachments are intended for the above named only and ma= y be confidential. If they have come to you in error you must take no actio= n 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. --_000_7DC33052E4D14352B4F88C8A416B0DF8gsmacom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Related draft: https://datatracker.ietf.org/doc/draft-ietf-slim-negotiating-human-langu= age/

Hi all,

Please review the below ticket and respond on-list to comme= nts. We are working through our final tickets before progressing the draft.=
https://trac.ietf.org/trac/slim/ticket/34

Natasha

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

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 ba= sed 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.

--_000_7DC33052E4D14352B4F88C8A416B0DF8gsmacom_-- From nobody Thu Jun 8 10:27:18 2017 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 02126129649 for ; Thu, 8 Jun 2017 10:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 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_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-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 KaY6ptaaSVN9 for ; Thu, 8 Jun 2017 10:27:14 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30054.outbound.protection.outlook.com [40.107.3.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D67212EB0C for ; Thu, 8 Jun 2017 10:27:14 -0700 (PDT) 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=ZXKoqlTxKKXuMtIzKLg/jdVXwk2nptW5GuaBUe8pwTA=; b=tB8G0axdGSaD5ii1EUFz5SGwSdITfDAVYJoIrhekl1eHHDqWXnPJXzkHMshiNL6dO1TjevrvjN3iu/kkXgKayi1s0/nWU74wkEO5M/5rudn1Mb029N0jnpap0OJMPKURMqd9xbZHK1Ad6hriAFr2adIpVLT8Xm5p4UId0JElV7I= Received: from DB4PR04MB0813.eurprd04.prod.outlook.com (10.242.223.151) by DB4PR04MB0814.eurprd04.prod.outlook.com (10.242.223.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1143.10; Thu, 8 Jun 2017 17:27:11 +0000 Received: from DB4PR04MB0813.eurprd04.prod.outlook.com ([fe80::a18a:b128:2e95:210a]) by DB4PR04MB0813.eurprd04.prod.outlook.com ([fe80::a18a:b128:2e95:210a%17]) with mapi id 15.01.1143.018; Thu, 8 Jun 2017 17:27:11 +0000 From: Natasha Rooney To: "slim@ietf.org" Thread-Topic: #40 Syntax Extensibility Thread-Index: AQHS4Hx2FoOX4MMJA0OKZD7edxB+9g== Date: Thu, 8 Jun 2017 17:27:11 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=gsma.com; x-originating-ip: [146.198.144.58] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB4PR04MB0814; 7:Z5EzqBWfgX/SWWgVe4n8RoF23sKLi3BMuq2BvXAQXfdh9iF8Ue4PzEw2hSc1PtMsCLyukH+IuVpeeTUIItLfWgQl7GJjvAr2Z9gc40QzBlRgSaD/ks2LsJnTDdQmibpvUJ9zhedf/fZVNfnlBTdPHpbXLYBXq+VCckT6DFOTAbgSAyJoaBZHW0OXWC5jLp0TVn6qogb/v4m0ujwNbV2SHjh3e+H4lyIeUJQllpAePQRQKXTvKqsWxoXHm538Y/KsFM2g4SacxZaJ7bdITaEq1IyT+7i5HXMGQFxwTcyBTyR6OeZxYpAyTRYlxbF2LJbDLOw+9jRWhR4ZtAdav1emWA== x-ms-traffictypediagnostic: DB4PR04MB0814: x-ms-office365-filtering-correlation-id: 79974160-f91e-4527-5228-08d4ae9398c3 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:DB4PR04MB0814; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(100000703101)(100105400095)(6041248)(20161123555025)(20161123562025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB4PR04MB0814; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB4PR04MB0814; x-forefront-prvs: 0332AACBC3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39850400002)(39840400002)(39450400003)(39400400002)(39410400002)(53754006)(50226002)(102836003)(50986999)(3280700002)(2906002)(3660700001)(189998001)(1730700003)(8676002)(8936002)(81166006)(83716003)(2501003)(3846002)(5890100001)(561944003)(5660300001)(86362001)(82746002)(7116003)(33656002)(2351001)(6506006)(6916009)(2900100001)(36756003)(7736002)(478600001)(236005)(25786009)(5640700003)(606005)(6306002)(53936002)(54896002)(6512007)(6486002)(99286003)(14454004)(966005)(110136004)(38730400002)(6436002)(7906003)(57306001)(5250100002)(66066001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR04MB0814; H:DB4PR04MB0813.eurprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CC889E857518459AA666865CD4203397gsmacom_" MIME-Version: 1.0 X-OriginatorOrg: gsma.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jun 2017 17:27:11.0884 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72a4ff82-fec3-469d-aafb-ac8276216699 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR04MB0814 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: DB4PR04MB0813.eurprd04.prod.outlook.com X-MS-Exchange-CrossPremises-TransportTrafficType: Email X-MS-Exchange-CrossPremises-TransportTrafficSubType: 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.58 X-MS-Exchange-CrossPremises-transporttraffictype: Email X-MS-Exchange-CrossPremises-transporttrafficsubtype: 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: DB4PR04MB0814.eurprd04.prod.outlook.com Archived-At: Subject: [Slim] #40 Syntax Extensibility 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, 08 Jun 2017 17:27:17 -0000 --_000_CC889E857518459AA666865CD4203397gsmacom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, https://trac.ietf.org/trac/slim/ticket/40 Ticket #40 discusses enhancing the syntax for the benefit of extensibility.= Please review this and respond (author and all WG attendees). Please see t= he original text from Paul Kyzivat: -------------------------------------------------------- How about enhancing the syntax to support parameters for the values, but on= ly as a future extension mechanism? Unknown parameters to be ignored. Then = at least the hooks will be there to introduce something later if desired. I think this would be the wise thing to do in any case. But especially so s= ince we have have some issues pending that have been postponed as potential= future work. Here is a specific proposal so we have something concrete to discuss: hlang-value-list =3D hlang-value *("," hlang-value) hlang-value =3D (Language-Tag / asterisk) *(";" hlang-param) hlang-param =3D hlang-param-name hlang-param-value? hlang-param-name =3D token hlang-param-value =3D token asterisk =3D "*" ; an asterisk (ASCII %2A) character Language-Tag =3D token =3D (I am *not* particularly attached to the specifics, but rather just to the = general notion of having an extensibility hook. If you have issues with the= syntax details I'm happy to discuss alternatives.) No specific hlang-params are to be defined in this draft. The semantics are= that unknown hlang-params are to be ignored, and specific ones can be defi= ned in extension drafts. Natasha Rooney | Internet Engineering Director | Internet and Web Team | Te= chnology | GSMA | nrooney@gsma.com | +44 (0) 7730 = 219 765 | @thisNatasha | Skype: nrooney@gsm.org This email and its attachments are intended for the above named only and ma= y be confidential. If they have come to you in error you must take no actio= n 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. --_000_CC889E857518459AA666865CD4203397gsmacom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable Hi all,

https://trac.ietf.org/trac/slim/ticket/40

Ticket #40 discusses enhancing the syntax for the benefit o= f extensibility. Please review this and respond (author and all WG attendee= s). Please see the original text from Paul Kyzivat:

--------------------------------------------------------

How about enhancing the syntax to support parameters for the values, but on= ly as a future extension mechanism? Unknown parameters to be ignored. = Then at least the hooks will be there to introduce something later if = desired.

I think this would be the wise thing to do in any case. But especially so s= ince we have have some issues pending that have been postponed as pote= ntial future work.

Here is a specific proposal so we have something concrete to discuss:

hlang-value-list =3D hlang-value *("," hlang-value)

hlang-value =3D (Language-Tag / asterisk) *(";" hlang-param)

hlang-param =3D hlang-param-name hlang-param-value?

hlang-param-name =3D token

hlang-param-value =3D token

asterisk =3D "*" ; an asterisk (ASCII %2A) character

Language-Tag =3D <Defined in BCP 47>

token =3D <Defined in RFC4566>

(I am *not* particularly attached to the specifics, but rather just to the = general notion of having an extensibility hook. If you have issues wit= h the syntax details I'm happy to discuss alternatives.)

No specific hlang-params are to be defined in this draft. The semantics are= that unknown hlang-params are to be ignored, and specific ones can be= defined in extension drafts.

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

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 ba= sed 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.

--_000_CC889E857518459AA666865CD4203397gsmacom_-- From nobody Thu Jun 8 10:40:19 2017 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 0ED46129434 for ; Thu, 8 Jun 2017 10:40:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-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 SqYtfu-Q_Bgg for ; Thu, 8 Jun 2017 10:40:15 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0073.outbound.protection.outlook.com [104.47.2.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DF071270AC for ; Thu, 8 Jun 2017 10:40:15 -0700 (PDT) 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=yFzY/gVSvpUKGH88Y9vw14p00c2EpgBSryk2odWDAIE=; b=hAsCRct34Ouq3iC7fDQtuq33WDqhgceB8K/CCFeV7XNvkrAXJWvWJlyNVZmEr3VKXBRvqkdU778VPFPu4Xb1mOyBeEZ8mzW7Qnl+ChRYbNAt32Cqt3YU26yeReU4/LeXth3EF7c2knFM2CbBD6SB5BxRRcTENICY3egaJ2u/r/o= Received: from DB4PR04MB0813.eurprd04.prod.outlook.com (10.242.223.151) by DB4PR04MB0816.eurprd04.prod.outlook.com (10.242.223.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1157.12; Thu, 8 Jun 2017 17:40:13 +0000 Received: from DB4PR04MB0813.eurprd04.prod.outlook.com ([fe80::a18a:b128:2e95:210a]) by DB4PR04MB0813.eurprd04.prod.outlook.com ([fe80::a18a:b128:2e95:210a%17]) with mapi id 15.01.1143.018; Thu, 8 Jun 2017 17:40:13 +0000 From: Natasha Rooney To: "slim@ietf.org" Thread-Topic: Ticket #26 Make use of the asterisk modifier on media level with session scope also for media level purposes Thread-Index: AQHS4H5I/mzqUSiAekGj0cxSykt72Q== Date: Thu, 8 Jun 2017 17:40:13 +0000 Message-ID: <34B284D1-F393-48B3-94E8-5BC8F272E7E9@gsma.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=gsma.com; x-originating-ip: [146.198.144.58] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB4PR04MB0816; 7:xgXWpTrFEejMt4193psGF3exLW9k1jqhhHm/kZuEhfoRrb3cae2kuorPaStOA+iQ3L3lctukIc2gCvz+eKdL3gwLwZw/VinU2DLOieJG2uV5J05bCpGDKZp5FNSaXpOj0VxOhAIqwANyd9dd5cqTy2RCfWUKQ7cNH7s68uxH8F9MI/yenivvW2t6uo4ONzEpjSIF3cAUskpAg8nEkaEUFZgt47T9icKYIrocOli5FbCLWnGDOSUBG2OUb6ovlslyVFwFrSN1tmTMJ6mcdhF2S0pDvSmRTNQbezsGKFF9oapdjqEnuOxOtEk5eQMSH4bfIuXLEvrUA8GJpU7Ao3qF6w== x-ms-traffictypediagnostic: DB4PR04MB0816: x-ms-office365-filtering-correlation-id: 96ad3d10-6841-4bd1-5a75-08d4ae956ae4 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:DB4PR04MB0816; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(3002001)(10201501046)(93006095)(93001095)(6041248)(20161123562025)(20161123564025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123555025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB4PR04MB0816; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB4PR04MB0816; x-forefront-prvs: 0332AACBC3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39410400002)(39400400002)(39830400002)(39450400003)(6306002)(6436002)(54896002)(6486002)(66066001)(6506006)(606005)(3846002)(82746002)(53936002)(102836003)(14454004)(7906003)(99286003)(7736002)(5640700003)(38730400002)(83716003)(57306001)(478600001)(966005)(110136004)(2906002)(5660300001)(3280700002)(3660700001)(36756003)(86362001)(6916009)(50986999)(25786009)(2900100001)(189998001)(6512007)(236005)(50226002)(5890100001)(5250100002)(2501003)(8676002)(81166006)(8936002)(1730700003)(33656002)(2351001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR04MB0816; H:DB4PR04MB0813.eurprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_34B284D1F39348B394E85BC8F272E7E9gsmacom_" MIME-Version: 1.0 X-OriginatorOrg: gsma.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jun 2017 17:40:13.0631 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72a4ff82-fec3-469d-aafb-ac8276216699 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR04MB0816 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: DB4PR04MB0813.eurprd04.prod.outlook.com X-MS-Exchange-CrossPremises-TransportTrafficType: Email X-MS-Exchange-CrossPremises-TransportTrafficSubType: 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.58 X-MS-Exchange-CrossPremises-transporttraffictype: Email X-MS-Exchange-CrossPremises-transporttrafficsubtype: 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: DB4PR04MB0816.eurprd04.prod.outlook.com Archived-At: Subject: [Slim] Ticket #26 Make use of the asterisk modifier on media level with session scope also for media level purposes 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, 08 Jun 2017 17:40:18 -0000 --_000_34B284D1F39348B394E85BC8F272E7E9gsmacom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Randall, The additional text describing the * has not been added and myself and Bern= ard are unsure of how the current text is sufficient. Can you add some text= or let us know how this is already covered? Thanks! See comment 8 and 9 to see the request in the ticket. https://trac.ietf.org/trac/slim/ticket/26 Thanks! Natasha Rooney | Internet Engineering Director | Internet and Web Team | Te= chnology | GSMA | nrooney@gsma.com | +44 (0) 7730 = 219 765 | @thisNatasha | Skype: nrooney@gsm.org This email and its attachments are intended for the above named only and ma= y be confidential. If they have come to you in error you must take no actio= n 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. --_000_34B284D1F39348B394E85BC8F272E7E9gsmacom_ Content-Type: text/html; charset="us-ascii" Content-ID: <78F0D4176AA417459CABD41E611B6581@eurprd04.prod.outlook.com> Content-Transfer-Encoding: quoted-printable Hi Randall,

The additional text describing the * has not been added and= myself and Bernard are unsure of how the current text is sufficient. Can y= ou add some text or let us know how this is already covered? Thanks!

See comment 8 and 9 to see the request in the ticket.

https://trac.ietf.org/trac/slim/ticket/26

Thanks!

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

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 ba= sed 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.

--_000_34B284D1F39348B394E85BC8F272E7E9gsmacom_-- From nobody Thu Jun 8 11:38:52 2017 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 52B1C12EB58 for ; Thu, 8 Jun 2017 11:38:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.34 X-Spam-Level: X-Spam-Status: No, score=-2.34 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, 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 e7X9Qk8DMiAm for ; Thu, 8 Jun 2017 11:38:48 -0700 (PDT) Received: from bin-vsp-out-01.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 6EED712EB47 for ; Thu, 8 Jun 2017 11:38:38 -0700 (PDT) X-Halon-ID: acb6c20e-4c79-11e7-b75a-005056917a89 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [77.53.230.196]) by bin-vsp-out-01.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Thu, 8 Jun 2017 20:38:32 +0200 (CEST) To: slim@ietf.org References: From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: Date: Thu, 8 Jun 2017 20:38:34 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------95C333E55357B7C5BB709682" Archived-At: Subject: Re: [Slim] Ticket #35 Have an attribute to abbreviate the bidirectionally-symmetric case 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, 08 Jun 2017 18:38:51 -0000 This is a multi-part message in MIME format. --------------95C333E55357B7C5BB709682 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Den 2017-06-08 kl. 19:19, skrev Natasha Rooney: > Related draft: > https://datatracker.ietf.org/doc/draft-ietf-slim-negotiating-human-language/ > > > Hi all, > > Please review the below ticket and respond on-list to comments. We are > working through our final tickets before progressing the draft. > https://trac.ietf.org/trac/slim/ticket/35 It is a good goal and a good proposal. But it causes complications and increased complexity, so sadly, I propose to reject it. The complications are: 1. We would need to introduce a rule to not use hlang-send and hlang-recv in a media description where the symmetric hlang is used. That would cause undefined preference situations between languages. 2. If the offer contains the symmetric hlang, and the answering party has settings for different preferences in the different directions, the answering party needs to make a logical analysis and respond with the asymmetric attributes. The offering party then also needs to analyze this answer in asymmetric attributes and compare to what it originally sent in symmetric to find out how to start the call. These operations add complexity in an undesirable way. Maybe not super complex, but anyway added complexity. /Gunnar > > Natasha > > Natasha Rooney | Internet Engineering Director | Internet and Web Team > | Technology | GSMA | nrooney@gsma.com | +44 > (0) 7730 219 765 | @thisNatasha | Skype: nrooney@gsm.org > > > 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. > > > > _______________________________________________ > 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 --------------95C333E55357B7C5BB709682 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Den 2017-06-08 kl. 19:19, skrev Natasha Rooney:

Hi all,

Please review the below ticket and respond on-list to comments. We are working through our final tickets before progressing the draft.

It is a good goal and a good proposal. But it causes complications and increased complexity, so sadly, I propose to reject it.

The complications are:
1. We would need to introduce a rule to not use hlang-send and hlang-recv in a media description where the symmetric hlang is used. That would cause undefined preference situations between languages.

2. If the offer contains the symmetric hlang, and the answering party has settings for different preferences in the different directions, the answering party needs to make a logical analysis and respond with the asymmetric attributes. The offering party then also needs to analyze this answer in asymmetric attributes and compare to what it originally sent in symmetric to find out how to start the call.  These operations add complexity in an undesirable way.  Maybe not super complex, but anyway added complexity.

/Gunnar

 

Natasha

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

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. 



_______________________________________________
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
--------------95C333E55357B7C5BB709682-- From nobody Thu Jun 8 14:29:38 2017 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 D46D5129463 for ; Thu, 8 Jun 2017 14:29:36 -0700 (PDT) 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 7KrwPg_PtXcQ for ; Thu, 8 Jun 2017 14:29:34 -0700 (PDT) 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 3DC6A129461 for ; Thu, 8 Jun 2017 14:29:34 -0700 (PDT) X-Halon-ID: 8be6a083-4c91-11e7-bca7-0050569116f7 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [77.53.230.196]) by bin-vsp-out-03.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Thu, 8 Jun 2017 23:29:25 +0200 (CEST) To: Natasha Rooney , "slim@ietf.org" References: <34B284D1-F393-48B3-94E8-5BC8F272E7E9@gsma.com> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <36b0c9cd-94b7-e44c-2775-b95876daa40d@omnitor.se> Date: Thu, 8 Jun 2017 23:29:29 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <34B284D1-F393-48B3-94E8-5BC8F272E7E9@gsma.com> Content-Type: multipart/alternative; boundary="------------7B9DF488609AC88B7B25740C" Archived-At: Subject: Re: [Slim] Ticket #26 Make use of the asterisk modifier on media level with session scope also for media level purposes 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, 08 Jun 2017 21:29:37 -0000 This is a multi-part message in MIME format. --------------7B9DF488609AC88B7B25740C Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Den 2017-06-08 kl. 19:40, skrev Natasha Rooney: > Hi Randall, > > The additional text describing the * has not been added and myself and > Bernard are unsure of how the current text is sufficient. Can you add > some text or let us know how this is already covered? Thanks! > > See comment 8 and 9 to see the request in the ticket. > > https://trac.ietf.org/trac/slim/ticket/26 > > Thanks! I realize that a way to satisfy this request, and also prepare for a smooth extension widening the use of the asterisk is to now make the change shown below in section 5.2 By this, we get a firm description on where to append the asterisk. And we get no interworking problems when extending the use of the asterisk. I agree that it may look odd to talk about positioning the asterisk on the attribute for the most preferred modality, when we do not describe how we use this position. But it is a fixed rule anyway that makes the asterisk a media level parameter and it would satisfy comments 8 and 9 of Ticket #26. Another solution is to create a separate session level attribute for the indication of non-denial at no match. a=hlang-nomatch:deny (or keep) Change proposal in section 5.3 ------old text---- In an offer, each value MAY have an asterisk appended as the final value. An asterisk appended to either value in an offer indicates a request by the caller to the callee to not fail the call if there is no language in common. See Section 5.3 for more information and discussion. -----new text ---- In an offer or answer, the attribute value MAY have an asterisk appended as the final token. An asterisk appended to a value in an offer indicates a request by the caller to the callee to not fail the call if there is no language in common. The asterisk should be appended for at least one direction. If 'hlang-' attributes are provided for more than one media in a direction selected to have the asterisk appended, then the asterisk should be appended to the attribute for the most preferred modality in that direction. If no modality can be identified as the most preferred for that direction, then an asterisk should be appended on each 'hlang' attribute for that direction. See Section 5.3 for more information and discussion. Note that separate work [draft-hellstrom-slim-modalitypref] extends the use of the asterisk. ---end of change----------------- Gunnar > > Natasha Rooney | Internet Engineering Director | Internet and Web Team > | Technology | GSMA | nrooney@gsma.com | +44 > (0) 7730 219 765 | @thisNatasha | Skype: nrooney@gsm.org > > > 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. > > > > _______________________________________________ > 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 --------------7B9DF488609AC88B7B25740C Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Den 2017-06-08 kl. 19:40, skrev Natasha Rooney:
Hi Randall,

The additional text describing the * has not been added and myself and Bernard are unsure of how the current text is sufficient. Can you add some text or let us know how this is already covered? Thanks!

See comment 8 and 9 to see the request in the ticket.


Thanks!
I realize that a way to satisfy this request, and also prepare for a smooth extension widening the use of the asterisk is to now make the change shown below in section 5.2

By this, we get a firm description on where to append the asterisk. And we get no interworking problems when extending the use of the asterisk.

I agree that it may look odd to talk about positioning the asterisk on the attribute for the most preferred modality, when we do not describe how we use this position. But it is a fixed rule anyway that makes the asterisk a media level parameter and it would satisfy comments 8 and 9 of Ticket #26.

Another solution is to create a separate session level attribute for the indication of non-denial at no match.
a=hlang-nomatch:deny   (or keep)

Change proposal in section 5.3 

------old text----
   In an offer, each value MAY have an asterisk appended as the final
   value.  An asterisk appended to either value in an offer indicates a
   request by the caller to the callee to not fail the call if there is
   no language in common.  See Section 5.3 for more information and
   discussion.
-----new text ----
   In an offer or answer, the attribute value MAY have an asterisk appended as the final
   token. An asterisk appended to a value in an offer indicates a request by the caller to the 
   callee to not fail the call if there is no language in common. The asterisk should be appended
   for at least one direction. If 'hlang-' attributes are provided for more than one media
   in a direction selected to have the asterisk appended, then the asterisk should be appended 
   to the attribute for the most preferred modality in that direction. If no modality can be 
   identified as the most preferred for that direction, then an asterisk should be appended 
   on each 'hlang' attribute for that direction. See Section 5.3 for more information and discussion. 

   Note that separate work [draft-hellstrom-slim-modalitypref] extends the use of the 
   asterisk.


---end of change----------------- 

Gunnar


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

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. 



_______________________________________________
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
--------------7B9DF488609AC88B7B25740C-- From nobody Thu Jun 8 14:31:43 2017 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 DBF82129459 for ; Thu, 8 Jun 2017 14:31:42 -0700 (PDT) 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 8fZ1XeBIpRxA for ; Thu, 8 Jun 2017 14:31:40 -0700 (PDT) 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 711DD1252BA for ; Thu, 8 Jun 2017 14:31:40 -0700 (PDT) X-Halon-ID: d81d14b8-4c91-11e7-bca7-0050569116f7 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [77.53.230.196]) by bin-vsp-out-03.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Thu, 8 Jun 2017 23:31:33 +0200 (CEST) From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= To: Natasha Rooney , "slim@ietf.org" References: <34B284D1-F393-48B3-94E8-5BC8F272E7E9@gsma.com> Message-ID: <40872e6d-def0-94e5-bbfc-41559061f3fd@omnitor.se> Date: Thu, 8 Jun 2017 23:31:37 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <34B284D1-F393-48B3-94E8-5BC8F272E7E9@gsma.com> Content-Type: multipart/alternative; boundary="------------252DE5C2464FDAF995467359" Archived-At: Subject: Re: [Slim] Ticket #26 Make use of the asterisk modifier on media level with session scope also for media level purposes REPLACEMENT 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, 08 Jun 2017 21:31:43 -0000 This is a multi-part message in MIME format. --------------252DE5C2464FDAF995467359 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit This mail replaces the one I just sent. There was an error in the section number for the change proposal. Corrected now. Den 2017-06-08 kl. 19:40, skrev Natasha Rooney: > Hi Randall, > > The additional text describing the * has not been added and myself and > Bernard are unsure of how the current text is sufficient. Can you add > some text or let us know how this is already covered? Thanks! > > See comment 8 and 9 to see the request in the ticket. > > https://trac.ietf.org/trac/slim/ticket/26 > > Thanks! I realize that a way to satisfy this request, and also prepare for a smooth extension widening the use of the asterisk is to now make the change shown below in section 5.2 By this, we get a firm description on where to append the asterisk. And we get no interworking problems when extending the use of the asterisk. I agree that it may look odd to talk about positioning the asterisk on the attribute for the most preferred modality, when we do not describe how we use this position. But it is a fixed rule anyway that makes the asterisk a media level parameter and it would satisfy comments 8 and 9 of Ticket #26. Another solution is to create a separate session level attribute for the indication of non-denial at no match. a=hlang-nomatch:deny (or keep) Change proposal in section 5.2 ------old text---- In an offer, each value MAY have an asterisk appended as the final value. An asterisk appended to either value in an offer indicates a request by the caller to the callee to not fail the call if there is no language in common. See Section 5.3 for more information and discussion. -----new text ---- In an offer or answer, the attribute value MAY have an asterisk appended as the final token. An asterisk appended to a value in an offer indicates a request by the caller to the callee to not fail the call if there is no language in common. The asterisk should be appended for at least one direction. If 'hlang-' attributes are provided for more than one media in a direction selected to have the asterisk appended, then the asterisk should be appended to the attribute for the most preferred modality in that direction. If no modality can be identified as the most preferred for that direction, then an asterisk should be appended on each 'hlang' attribute for that direction. See Section 5.3 for more information and discussion. Note that separate work [draft-hellstrom-slim-modalitypref] extends the use of the asterisk. ---end of change----------------- Gunnar > > Natasha Rooney | Internet Engineering Director | Internet and Web Team > | Technology | GSMA | nrooney@gsma.com | +44 > (0) 7730 219 765 | @thisNatasha | Skype: nrooney@gsm.org > > > 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. > > > > _______________________________________________ > 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 --------------252DE5C2464FDAF995467359 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit This mail replaces the one I just sent. There was an error in the section number for the change proposal. Corrected now.
Den 2017-06-08 kl. 19:40, skrev Natasha Rooney:
Hi Randall,

The additional text describing the * has not been added and myself and Bernard are unsure of how the current text is sufficient. Can you add some text or let us know how this is already covered? Thanks!

See comment 8 and 9 to see the request in the ticket.


Thanks!
I realize that a way to satisfy this request, and also prepare for a smooth extension widening the use of the asterisk is to now make the change shown below in section 5.2

By this, we get a firm description on where to append the asterisk. And we get no interworking problems when extending the use of the asterisk.

I agree that it may look odd to talk about positioning the asterisk on the attribute for the most preferred modality, when we do not describe how we use this position. But it is a fixed rule anyway that makes the asterisk a media level parameter and it would satisfy comments 8 and 9 of Ticket #26.

Another solution is to create a separate session level attribute for the indication of non-denial at no match.
a=hlang-nomatch:deny   (or keep)

Change proposal in section 5.2 

------old text----
   In an offer, each value MAY have an asterisk appended as the final
   value.  An asterisk appended to either value in an offer indicates a
   request by the caller to the callee to not fail the call if there is
   no language in common.  See Section 5.3 for more information and
   discussion.
-----new text ----
   In an offer or answer, the attribute value MAY have an asterisk appended as the final
   token. An asterisk appended to a value in an offer indicates a request by the caller to the 
   callee to not fail the call if there is no language in common. The asterisk should be appended
   for at least one direction. If 'hlang-' attributes are provided for more than one media
   in a direction selected to have the asterisk appended, then the asterisk should be appended 
   to the attribute for the most preferred modality in that direction. If no modality can be 
   identified as the most preferred for that direction, then an asterisk should be appended 
   on each 'hlang' attribute for that direction. See Section 5.3 for more information and discussion. 

   Note that separate work [draft-hellstrom-slim-modalitypref] extends the use of the 
   asterisk.


---end of change----------------- 

Gunnar


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

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. 



_______________________________________________
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
--------------252DE5C2464FDAF995467359-- From nobody Fri Jun 9 11:28:40 2017 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 B904712871F for ; Fri, 9 Jun 2017 11:28:37 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 yzI1dYBGUC3z for ; Fri, 9 Jun 2017 11:28:36 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 0FBE112708C for ; Fri, 9 Jun 2017 11:28:36 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Fri, 9 Jun 2017 11:31:15 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <11fef8a5-8ed3-5e70-4ccd-66e7613b22fc@omnitor.se> References: <149609884905.14640.4714137651572553743@ietfa.amsl.com> <54839aba-7ac8-79e4-74f8-927eb455d8af@omnitor.se> <8ca64f00-b1d1-e4da-05cf-0e4663178d85@omnitor.se> <11fef8a5-8ed3-5e70-4ccd-66e7613b22fc@omnitor.se> X-Mailer: Eudora for Mac OS X Date: Fri, 9 Jun 2017 11:28:32 -0700 To: Gunnar =?iso-8859-1?Q?Hellstr=F6m?= , "slim@ietf.org" From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Slim] New wording for the use of the asterisk 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, 09 Jun 2017 18:28:38 -0000 At 8:20 PM +0200 6/7/17, Gunnar Hellstr=F6m wrote: > Den 2017-06-06 kl. 03:00, skrev Randall Gellens: > >> At 10:21 PM +0200 6/5/17, Gunnar Hellstr=F6m wrote: >> >>> Den 2017-06-04 kl. 23:51, skrev Randall Gellens: >>> >>>> Hi Gunnar, >>>> >>>> What I'd suggest is that we include an=20 >>>> informational reference to the draft,=20 >>>> although that requires that at least an=20 >>>> initial version of the draft be published=20 >>>> pretty quickly. So, my suggestion is that=20 >>>> you publish at least a skeleton draft right=20 >>>> away (which you can revise and extend=20 >>>> quickly), and we add text along the lines of=20 >>>> the following, perhaps after the second=20 >>>> paragraph of Section 5.3: >>>> >>>> Note that separate work [draft-xxx] proposes to use the asterisk (or >>>> lack thereof) to convey information between endpoints. >>>> >>>> This alerts implementers to the other draft. >>>> >>> This might be a possible way ahead, if others also think it is feasible= =2E >>> >> >> Gunnar, please upload at least a skeleton=20 >> version of the draft right away, and let me=20 >> know the title. If you need help with that, I=20 >> can create one. >> >>> The wording and placement of the text=20 >>> requires more tuning. E.g. it should not say=20 >>> "proposes", but rather "specifies". >>> >> >> I was reluctant to say "specifies" until we=20 >> have a more solid draft (we don't yet have=20 >> anything). How about if the text says "uses"=20 >> rather than "proposes to use"? I think that=20 >> covers it. >> > Yes, the drafts for the two functionality extensions are uploaded. > > I would think that it would be more logical to=20 > insert the note about the added meaning of the=20 > asterisk in section 5.2, because 5.3 is for the=20 > current interpretation case only. > > I propose a change to this current text in 5.2 > > ------old text---- > > > In an offer, each value MAY have an asterisk appended as the final > value. An asterisk appended to either value in an offer indicates a > request by the caller to the callee to not fail the call if there is > no language in common. See Section 5.3 for more information and > discussion. > > -----new text could be---- > In an offer or answer, each value MAY have=20 > an asterisk appended as the final > token. An asterisk appended to either value in an offer indicates a > request by the caller to the callee to not fail the call if there is > no language in common. See Section 5.3 for more information and > discussion. > > Note that separate work=20 > [draft-hellstrom-slim-modalitypref] extends the=20 > use of the > asterisk with a media level indication. > > > ---end of change----------------- I moved the note from 5.3 to 5.2 and reworded to=20 say "extends the use of the asterisk to convey=20 information between endpoints": In an offer, each list of language tags MAY have an asterisk appended at the end. An asterisk appended to any value in any media in an offer indicates a request by the caller to the callee to not fail the call if there is no language in common. See Section 5.3 for more information and discussion. Note that separate work [I-D.hellstrom-slim-modalitypref] extends the use of the asterisk to convey information between endpoints. > The other draft, about simultaneous modality may also need to be announce= d. > I suggest this change: > > ----old text in 5.2------ > > BCP 47 describes mechanisms for > matching language tags. Note that [RFC5646] Section 4.1 advises to > "tag content wisely" and not include unnecessary subtags. > > ----new text----- > > BCP 47 describes mechanisms for > matching language tags. Note that [RFC5646] Section 4.1 advises to > "tag content wisely" and not include unnecessary subtags. > > > Note also that separate work in=20 > [draft-hellstrom-slim-simultaneous-modality]=20 > uses a > notation with a subtag for extended=20 > functionality. It is therefore of importance to > use the mechanisms from BCP 47 for matching languages correctly. > > ----end of change----- I am not sure we need to reference the other=20 draft, since it doesn't directly affect the usage=20 of this draft. > > This all builds on that we can at least get WG=20 > draft status soon on the new drafts. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- "SFPD Homicide: Our Day Begins when Yours End" --Slogan seen on back of San Francisco Police Jacket, as reported by Herb Caen in SF Chronicle From nobody Fri Jun 9 11:49:00 2017 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 7058B129405 for ; Fri, 9 Jun 2017 11:48:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 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, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.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 svaTPIDFIr9E for ; Fri, 9 Jun 2017 11:48:56 -0700 (PDT) Received: from mail-pf0-x244.google.com (mail-pf0-x244.google.com [IPv6:2607:f8b0:400e:c00::244]) (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 CE4841200C5 for ; Fri, 9 Jun 2017 11:48:55 -0700 (PDT) Received: by mail-pf0-x244.google.com with SMTP id f27so9397398pfe.0 for ; Fri, 09 Jun 2017 11:48:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=SPVIdEHlIWhCd9QHdZ0EJjMJNvQ7gddtf0RrHFOyxfY=; b=uOqST3uGSBaOKGnrN0Zd7bCsoOSMGhzGRz8Wk+brQERUcQVmncQPDXICR5FQQg84hq voyDn2Pv0LEeza92qL/0wkmvI74ZtExriygRqrNepKk560ufYLBiniFEpOxc+uFBawpo +aQTcGgQLb8iwgF031etbeA2SlVWQOVJXANNg0ytpKOrsyZeI77SID9xRVQ//n/sIsCH 0OrQaVCE9XReOMMpzdpAwDgYkM+tCLO1ioh+GgSGXFVztiiDSVSM9h6t0yIe3fDMoBJ0 iviIGH6e8BfLZ5RIQDGTbyg9dAHWCLG43dNowLeiaWGRKXmXwRkaw3Ph0m4u188Kl+zI pclw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=SPVIdEHlIWhCd9QHdZ0EJjMJNvQ7gddtf0RrHFOyxfY=; b=ft06eCme2Itpntfl7vYvVxMOnfDFM0SZ3j+ktLeRqOjIYTYTJi1W4uQhvPfCtDUueP kiXlqI1QANqJ4PXWdE5yVg2FWU8NDmjiwLBh3bHiDPL3J4s+MarYED+3nbpI3VDDNDdD XVlOHVc4Fy3PCT1arUR3vIrTKXuJTqa+xDiVsM3Hvnwy3UyjsgJhOvDXP9sc3eDJfyro spbZfamJFltS4Kq2zH9E93SxQSvmDoTAz4gOa+4fD5AeFEKjP4nbGgLm3ebUALCfhljJ P4uwZZcF9wKayM0oJ0fFvNKtsjNBqXsYC9JGx+bmZYUbSD4ZFCMAkYxKXztNyaH30FOL /x1A== X-Gm-Message-State: AODbwcCAGnqVkTAQ32PtReARSXwQSYcoQroFO9hF93drPq4fm6UfDmxv l/5RpPIXiwlvzLBy7MtboQ== X-Received: by 10.84.224.74 with SMTP id a10mr43307138plt.173.1497034135351; Fri, 09 Jun 2017 11:48:55 -0700 (PDT) Received: from [10.96.43.74] (neustar-sthide-nat1.neustar.biz. [156.154.81.54]) by smtp.gmail.com with ESMTPSA id y2sm5039169pfk.1.2017.06.09.11.48.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Jun 2017 11:48:54 -0700 (PDT) From: Brian Rosen Message-Id: <7669593F-0B97-4AFA-8294-A69684436AD6@brianrosen.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_6B3E5FDF-05C0-4B16-BB1D-37D156A62BD0" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 9 Jun 2017 14:48:52 -0400 In-Reply-To: Cc: =?utf-8?Q?Gunnar_Hellstr=C3=B6m?= , "slim@ietf.org" To: Randall Gellens References: <149609884905.14640.4714137651572553743@ietfa.amsl.com> <54839aba-7ac8-79e4-74f8-927eb455d8af@omnitor.se> <8ca64f00-b1d1-e4da-05cf-0e4663178d85@omnitor.se> <11fef8a5-8ed3-5e70-4ccd-66e7613b22fc@omnitor.se> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Slim] New wording for the use of the asterisk 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, 09 Jun 2017 18:48:58 -0000 --Apple-Mail=_6B3E5FDF-05C0-4B16-BB1D-37D156A62BD0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Generally, I like the wording here. I=E2=80=99d make a minor suggestion = to change "extends the use of the asterisk with a media level = indication=E2=80=9D to =E2=80=9Cextends the use of the asterisk convey = additional information=E2=80=9D or even "extends the use of the = asterisk convey additional information about languages preferences among = multiple media sessions=E2=80=9D Brian > On Jun 9, 2017, at 2:28 PM, Randall Gellens = wrote: >=20 > At 8:20 PM +0200 6/7/17, Gunnar Hellstr=C3=B6m wrote: >=20 >> Den 2017-06-06 kl. 03:00, skrev Randall Gellens: >>=20 >>> At 10:21 PM +0200 6/5/17, Gunnar Hellstr=C3=B6m wrote: >>>=20 >>>> Den 2017-06-04 kl. 23:51, skrev Randall Gellens: >>>>=20 >>>>> Hi Gunnar, >>>>>=20 >>>>> What I'd suggest is that we include an informational reference to = the draft, although that requires that at least an initial version of = the draft be published pretty quickly. So, my suggestion is that you = publish at least a skeleton draft right away (which you can revise and = extend quickly), and we add text along the lines of the following, = perhaps after the second paragraph of Section 5.3: >>>>>=20 >>>>> Note that separate work [draft-xxx] proposes to use the asterisk = (or >>>>> lack thereof) to convey information between endpoints. >>>>>=20 >>>>> This alerts implementers to the other draft. >>>>>=20 >>>> This might be a possible way ahead, if others also think it is = feasible. >>>>=20 >>>=20 >>> Gunnar, please upload at least a skeleton version of the draft right = away, and let me know the title. If you need help with that, I can = create one. >>>=20 >>>> The wording and placement of the text requires more tuning. E.g. it = should not say "proposes", but rather "specifies". >>>>=20 >>>=20 >>> I was reluctant to say "specifies" until we have a more solid draft = (we don't yet have anything). How about if the text says "uses" rather = than "proposes to use"? I think that covers it. >>>=20 >> Yes, the drafts for the two functionality extensions are uploaded. >>=20 >> I would think that it would be more logical to insert the note about = the added meaning of the asterisk in section 5.2, because 5.3 is for the = current interpretation case only. >>=20 >> I propose a change to this current text in 5.2 >>=20 >> ------old text---- >>=20 >>=20 >> In an offer, each value MAY have an asterisk appended as the final >> value. An asterisk appended to either value in an offer indicates = a >> request by the caller to the callee to not fail the call if there = is >> no language in common. See Section 5.3 for more information and >> discussion. >>=20 >> -----new text could be---- >> In an offer or answer, each value MAY have an asterisk appended as = the final >> token. An asterisk appended to either value in an offer indicates = a >> request by the caller to the callee to not fail the call if there = is >> no language in common. See Section 5.3 for more information and >> discussion. >>=20 >> Note that separate work [draft-hellstrom-slim-modalitypref] = extends the use of the >> asterisk with a media level indication. >>=20 >>=20 >> ---end of change----------------- >=20 > I moved the note from 5.3 to 5.2 and reworded to say "extends the use = of the asterisk to convey information between endpoints": >=20 > In an offer, each list of language tags MAY have an asterisk = appended > at the end. An asterisk appended to any value in any media in an > offer indicates a request by the caller to the callee to not fail = the > call if there is no language in common. See Section 5.3 for more > information and discussion. Note that separate work > [I-D.hellstrom-slim-modalitypref] extends the use of the asterisk to > convey information between endpoints. >=20 >> The other draft, about simultaneous modality may also need to be = announced. >> I suggest this change: >>=20 >> ----old text in 5.2------ >>=20 >> BCP 47 describes mechanisms for >> matching language tags. Note that [RFC5646] Section 4.1 advises = to >> "tag content wisely" and not include unnecessary subtags. >>=20 >> ----new text----- >>=20 >> BCP 47 describes mechanisms for >> matching language tags. Note that [RFC5646] Section 4.1 advises = to >> "tag content wisely" and not include unnecessary subtags. >>=20 >>=20 >> Note also that separate work in = [draft-hellstrom-slim-simultaneous-modality] uses a >> notation with a subtag for extended functionality. It is therefore = of importance to >> use the mechanisms from BCP 47 for matching languages correctly. >>=20 >> ----end of change----- >=20 > I am not sure we need to reference the other draft, since it doesn't = directly affect the usage of this draft. >=20 >>=20 >> This all builds on that we can at least get WG draft status soon on = the new drafts. >=20 > --=20 > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself = only > -------------- Randomly selected tag: --------------- > "SFPD Homicide: Our Day Begins when Yours End" --Slogan seen on back = of > San Francisco Police Jacket, as reported by Herb Caen in SF Chronicle >=20 > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim = --Apple-Mail=_6B3E5FDF-05C0-4B16-BB1D-37D156A62BD0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Generally, I like the wording here.  I=E2=80=99d make a = minor suggestion to change "extends the use of the asterisk with a = media level indication=E2=80=9D to =E2=80=9Cextends the use of = the asterisk convey additional information=E2=80=9D  or even = "extends the use of the asterisk convey additional information = about languages preferences among multiple media sessions=E2=80=9D

Brian

On Jun 9, 2017, at 2:28 PM, Randall Gellens <rg+ietf@randy.pensive.org> wrote:

At 8:20 PM +0200 6/7/17, Gunnar = Hellstr=C3=B6m wrote:

Den 2017-06-06 kl. 03:00, = skrev Randall Gellens:

At 10:21 PM +0200 6/5/17, Gunnar Hellstr=C3=B6m = wrote:

Den 2017-06-04 kl. 23:51, skrev Randall Gellens:

Hi = Gunnar,

What I'd suggest is that we include = an informational reference to the draft, although that requires that at = least an initial version of the draft be published pretty quickly. So, = my suggestion is that you publish at least a skeleton draft right away = (which you can revise and extend quickly), and we add text along the = lines of the following, perhaps after the second paragraph of Section = 5.3:

Note that separate work [draft-xxx] = proposes to use the asterisk (or
lack thereof) to convey = information between endpoints.

This alerts = implementers to the other draft.

This might be a possible way ahead, if others = also think it is feasible.


Gunnar, please upload at least a skeleton version of the = draft right away, and let me know the title. If you need help with that, = I can create one.

The wording and placement of the text requires more tuning. = E.g. it should not say "proposes", but rather "specifies".


I was reluctant to = say "specifies" until we have a more solid draft (we don't yet have = anything). How about if the text says "uses" rather than "proposes to = use"? I think that covers it.

Yes, the drafts for the two functionality = extensions are uploaded.

I would think that = it would be more logical to insert the note about the added meaning of = the asterisk in section 5.2, because 5.3 is for the current = interpretation case only.

I propose a = change to this current text in 5.2

------old = text----


   In = an offer, each value MAY have an asterisk appended as the final
   value.  An asterisk appended to either = value in an offer indicates a
   request by = the caller to the callee to not fail the call if there is
   no language in common.  See Section = 5.3 for more information and
   discussion.

 -----new text could be----
   In an offer or answer, each value MAY have = an asterisk appended as the final
   token. =  An asterisk appended to either value in an offer indicates a
   request by the caller to the callee to not = fail the call if there is
   no language in = common.  See Section 5.3 for more information and
   discussion.

   Note that separate work = [draft-hellstrom-slim-modalitypref] extends the use of the
   asterisk with a media level indication.


---end of = change-----------------

I moved the note from 5.3 to 5.2 and reworded to = say "extends the use of the asterisk to convey information between = endpoints":

  In an offer, each = list of language tags MAY have an asterisk appended
  at the end.  An asterisk = appended to any value in any media in an
  offer indicates a = request by the caller to the callee to not fail the
  call if there is no language in = common.  See Section 5.3 for more
  information and = discussion.  Note that separate work
  [I-D.hellstrom-slim-modalitypref] extends the use = of the asterisk to
  convey information between = endpoints.

The other draft, about = simultaneous modality may also need to be announced.
I = suggest this change:

----old text in = 5.2------

 BCP 47 describes mechanisms = for
   matching language tags.  Note = that [RFC5646] Section 4.1 advises to
   "tag= content wisely" and not include unnecessary subtags.

 ----new text-----

 BCP = 47 describes mechanisms for
   matching = language tags.  Note that [RFC5646] Section 4.1 advises to
   "tag content wisely" and not include = unnecessary subtags.


 Note also that separate work in = [draft-hellstrom-slim-simultaneous-modality] uses a
 notation with a subtag for extended functionality. It = is therefore of importance to
 use the mechanisms = from BCP 47 for matching languages correctly.

----end of change-----

I am not sure we need to reference the other = draft, since it doesn't directly affect the usage of this = draft.


 This = all builds on that we can at least get WG draft status soon on the new = drafts.

-- 
Randall Gellens
Opinions are personal; =    facts are suspect;    I speak for = myself only
-------------- Randomly selected tag: = ---------------
"SFPD Homicide: Our Day Begins when Yours = End" --Slogan seen on back of
San Francisco Police Jacket, as = reported by Herb Caen in SF Chronicle

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

= --Apple-Mail=_6B3E5FDF-05C0-4B16-BB1D-37D156A62BD0-- From nobody Fri Jun 9 11:59:14 2017 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 D3C481293E0 for ; Fri, 9 Jun 2017 11:59:12 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -1.177 X-Spam-Level: X-Spam-Status: No, score=-1.177 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RP_MATCHES_RCVD=-0.001] autolearn=no 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 R9aGlNRR2TWP for ; Fri, 9 Jun 2017 11:59:11 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 4D226127369 for ; Fri, 9 Jun 2017 11:59:11 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Fri, 9 Jun 2017 12:01:50 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <70ea7743-7d6a-16ae-f975-72284ff12dfb@comcast.net> References: <64D68B73-256D-4478-A970-5037B0187D73@brianrosen.net> <70ea7743-7d6a-16ae-f975-72284ff12dfb@comcast.net> X-Mailer: Eudora for Mac OS X Date: Fri, 9 Jun 2017 11:59:06 -0700 To: Paul Kyzivat , slim@ietf.org From: Randall Gellens Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Archived-At: Subject: Re: [Slim] draft-ietf-slim-negotiating-human-language-10: extensibility 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, 09 Jun 2017 18:59:13 -0000 Re: [Slim] draft-ietf-slim-negotiating-human-language-10:
At 6:20 PM -0400 6/7/17, Paul Kyzivat wrote:

I posted the message below a week ago but I never saw any responses to it:

On 6/1/17 2:23 PM, Paul Kyzivat wrote:
On 6/1/17 2:10 PM, Brian Rosen wrote:

[snip]
I would prefer the current syntax, and not Accept-Language syntax.

How about enhancing the syntax to support parameters for the values, but only as a future extension mechanism? Unknown parameters to be ignored. Then at least the hooks will be there to introduce something later if desired.

I think this would be the wise thing to do in any case. But especially so since we have have some issues pending that have been postponed as potential future work.

Here is a specific proposal so we have something concrete to discuss:

      hlang-value-list = hlang-value *("," hlang-value)

      hlang-value =  (Language-Tag / asterisk) *(";" hlang-param)

      hlang-param = hlang-param-name ["=" hlang-param-value]

      hlang-param-name = token

      hlang-param-value = token

      asterisk    =  "*"   ; an asterisk (ASCII %2A) character

      Language-Tag = <Defined in BCP 47>

      token = <Defined in RFC4566>

(I am *not* particularly attached to the specifics, but rather just to the general notion of having an extensibility hook. If you have issues with the syntax details I'm happy to discuss alternatives.)

No specific hlang-params are to be defined in this draft. The semantics are that unknown hlang-params are to be ignored, and specific ones can be defined in extension drafts.

I'm not opposed to allowing future extension parameters in the syntax, but I'm not convinced we need to be so explicit as to their syntax here (specifying that they consist of a token, an equal sign, and another token).  I'd be more comfortable saying something more generic, such as:

      hlang-value =  lang *( "," *" " lang )
      lang        =  ( Language-Tag [extend] ) / asterisk
                  ; Language-Tag defined in BCP 47
      extend      =  ";" 1*( %x21-2B / %x2D-3A / %x3C-7E )
                  ; semicolon followed by printable chars not "," ";" " "
                  ; ignored in this document; defined for future extensibility
      asterisk    =  "*"   ; an asterisk (0x2A) character

This permits a semicolon and a series of characters that don't include comma, semicolon, or space to be appended to a BCP47 Language-Tag.  The specific syntax of such extensions can then be defined in a future document.

--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
I must have a prodigious quantity of mind; it takes me as much as a
week sometimes to make it up.   --Mark Twain, _The Innocents Abroad_
From nobody Fri Jun 9 12:02:22 2017 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 21F061250B8 for ; Fri, 9 Jun 2017 12:02:20 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 uFeoTZ-MTzrx for ; Fri, 9 Jun 2017 12:02:18 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 60120128896 for ; Fri, 9 Jun 2017 12:02:18 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Fri, 9 Jun 2017 12:04:58 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <7b4df8c5-4249-7799-79d3-0dd954b82dd3@nostrum.com> References: <7b4df8c5-4249-7799-79d3-0dd954b82dd3@nostrum.com> X-Mailer: Eudora for Mac OS X Date: Fri, 9 Jun 2017 12:02:15 -0700 To: Adam Roach , Gunnar =?iso-8859-1?Q?Hellstr=F6m?= , slim@ietf.org From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Slim] Collapse attribute syntax to one line 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, 09 Jun 2017 19:02:20 -0000 At 5:47 PM -0500 6/7/17, Adam Roach wrote: > On 6/1/17 9:33 AM, Gunnar Hellstr=F6m wrote: >> Maybe the main question is: Will our own=20 >> one-line syntax really be less complex to=20 >> parse than the Accept-Language syntax that we=20 >> might be able to find ready library routines=20 >> for? >> Adam Roach had views on complexity to parse=20 >> different solutions. Maybe you, Adam can have=20 >> a view on this? > > > As long as it is a space-delimited list of=20 > tokens, it should be trivial. That's a pretty=20 > common SDP pattern. That's what's in the draft now (based on your earlier suggestion). Paul has proposed a syntax using semicolons=20 instead of spaces. If that will make the parsing=20 even slightly more complicated, I'd be inclined=20 to stick with the simple space-delimited list we=20 have now, and if we find that we do need to add=20 parameters, we introduce new attributes at that=20 time. > The prospect of bolting a parser from some=20 > other protocol (e.g. Accept-Language) onto an=20 > SDP parsing library seems like it would be=20 > quite complex. The libraries I've worked with=20 > would almost certainly find it easier to write=20 > such a parser from scratch. > > /a > > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Nothing is illegal if one hundred businessmen decide to do it. --Andrew Young From nobody Fri Jun 9 12:03:25 2017 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 A1E15128BA2 for ; Fri, 9 Jun 2017 12:03:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 SABjsC5QjIf6 for ; Fri, 9 Jun 2017 12:03:13 -0700 (PDT) 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 50A25128896 for ; Fri, 9 Jun 2017 12:03:13 -0700 (PDT) X-Halon-ID: 462e1ea8-4d46-11e7-b75a-005056917a89 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [77.53.230.196]) by bin-vsp-out-01.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Fri, 9 Jun 2017 21:03:07 +0200 (CEST) To: slim@ietf.org References: <149609884905.14640.4714137651572553743@ietfa.amsl.com> <54839aba-7ac8-79e4-74f8-927eb455d8af@omnitor.se> <8ca64f00-b1d1-e4da-05cf-0e4663178d85@omnitor.se> <11fef8a5-8ed3-5e70-4ccd-66e7613b22fc@omnitor.se> <7669593F-0B97-4AFA-8294-A69684436AD6@brianrosen.net> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <0dbd57b1-280d-6b72-ef42-e661f57b581b@omnitor.se> Date: Fri, 9 Jun 2017 21:03:08 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <7669593F-0B97-4AFA-8294-A69684436AD6@brianrosen.net> Content-Type: multipart/alternative; boundary="------------51E59C4F3F5F8B398A42270A" Archived-At: Subject: Re: [Slim] New wording for the use of the asterisk 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, 09 Jun 2017 19:03:24 -0000 This is a multi-part message in MIME format. --------------51E59C4F3F5F8B398A42270A Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Den 2017-06-09 kl. 20:48, skrev Brian Rosen: > Generally, I like the wording here. I’d make a minor suggestion to > change "extends the use of the asterisk with a media level indication” > to “extends the use of the asterisk convey additional information” or > even "extends the use of the asterisk convey additional information > about languages preferences among multiple media sessions” > I like the last one best. (I think 'to' is missing after 'asterisk') /Gunnar > Brian > >> On Jun 9, 2017, at 2:28 PM, Randall Gellens >> > wrote: >> >> At 8:20 PM +0200 6/7/17, Gunnar Hellström wrote: >> >>> Den 2017-06-06 kl. 03:00, skrev Randall Gellens: >>> >>>> At 10:21 PM +0200 6/5/17, Gunnar Hellström wrote: >>>> >>>>> Den 2017-06-04 kl. 23:51, skrev Randall Gellens: >>>>> >>>>>> Hi Gunnar, >>>>>> >>>>>> What I'd suggest is that we include an informational reference to >>>>>> the draft, although that requires that at least an initial >>>>>> version of the draft be published pretty quickly. So, my >>>>>> suggestion is that you publish at least a skeleton draft right >>>>>> away (which you can revise and extend quickly), and we add text >>>>>> along the lines of the following, perhaps after the second >>>>>> paragraph of Section 5.3: >>>>>> >>>>>> Note that separate work [draft-xxx] proposes to use the asterisk (or >>>>>> lack thereof) to convey information between endpoints. >>>>>> >>>>>> This alerts implementers to the other draft. >>>>>> >>>>> This might be a possible way ahead, if others also think it is >>>>> feasible. >>>>> >>>> >>>> Gunnar, please upload at least a skeleton version of the draft >>>> right away, and let me know the title. If you need help with that, >>>> I can create one. >>>> >>>>> The wording and placement of the text requires more tuning. E.g. >>>>> it should not say "proposes", but rather "specifies". >>>>> >>>> >>>> I was reluctant to say "specifies" until we have a more solid draft >>>> (we don't yet have anything). How about if the text says "uses" >>>> rather than "proposes to use"? I think that covers it. >>>> >>> Yes, the drafts for the two functionality extensions are uploaded. >>> >>> I would think that it would be more logical to insert the note about >>> the added meaning of the asterisk in section 5.2, because 5.3 is for >>> the current interpretation case only. >>> >>> I propose a change to this current text in 5.2 >>> >>> ------old text---- >>> >>> >>> In an offer, each value MAY have an asterisk appended as the final >>> value. An asterisk appended to either value in an offer indicates a >>> request by the caller to the callee to not fail the call if there is >>> no language in common. See Section 5.3 for more information and >>> discussion. >>> >>> -----new text could be---- >>> In an offer or answer, each value MAY have an asterisk appended >>> as the final >>> token. An asterisk appended to either value in an offer indicates a >>> request by the caller to the callee to not fail the call if there is >>> no language in common. See Section 5.3 for more information and >>> discussion. >>> >>> Note that separate work [draft-hellstrom-slim-modalitypref] >>> extends the use of the >>> asterisk with a media level indication. >>> >>> >>> ---end of change----------------- >> >> I moved the note from 5.3 to 5.2 and reworded to say "extends the use >> of the asterisk to convey information between endpoints": >> >> In an offer, each list of language tags MAY have an asterisk appended >> at the end. An asterisk appended to any value in any media in an >> offer indicates a request by the caller to the callee to not fail the >> call if there is no language in common. See Section 5.3 for more >> information and discussion. Note that separate work >> [I-D.hellstrom-slim-modalitypref] extends the use of the asterisk to >> convey information between endpoints. >> >>> The other draft, about simultaneous modality may also need to be >>> announced. >>> I suggest this change: >>> >>> ----old text in 5.2------ >>> >>> BCP 47 describes mechanisms for >>> matching language tags. Note that [RFC5646] Section 4.1 advises to >>> "tag content wisely" and not include unnecessary subtags. >>> >>> ----new text----- >>> >>> BCP 47 describes mechanisms for >>> matching language tags. Note that [RFC5646] Section 4.1 advises to >>> "tag content wisely" and not include unnecessary subtags. >>> >>> >>> Note also that separate work in >>> [draft-hellstrom-slim-simultaneous-modality] uses a >>> notation with a subtag for extended functionality. It is therefore >>> of importance to >>> use the mechanisms from BCP 47 for matching languages correctly. >>> >>> ----end of change----- >> >> I am not sure we need to reference the other draft, since it doesn't >> directly affect the usage of this draft. >> >>> >>> This all builds on that we can at least get WG draft status soon on >>> the new drafts. >> >> -- >> Randall Gellens >> Opinions are personal; facts are suspect; I speak for myself only >> -------------- Randomly selected tag: --------------- >> "SFPD Homicide: Our Day Begins when Yours End" --Slogan seen on back of >> San Francisco Police Jacket, as reported by Herb Caen in SF Chronicle >> >> _______________________________________________ >> SLIM mailing list >> SLIM@ietf.org >> https://www.ietf.org/mailman/listinfo/slim > > > > _______________________________________________ > 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 --------------51E59C4F3F5F8B398A42270A Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Den 2017-06-09 kl. 20:48, skrev Brian Rosen:
Generally, I like the wording here.  I’d make a minor suggestion to change "extends the use of the asterisk with a media level indication” to “extends the use of the asterisk convey additional information”  or even "extends the use of the asterisk convey additional information about languages preferences among multiple media sessions”

I like the last one best.
(I think 'to' is missing after 'asterisk')

/Gunnar
Brian

On Jun 9, 2017, at 2:28 PM, Randall Gellens <rg+ietf@randy.pensive.org> wrote:

At 8:20 PM +0200 6/7/17, Gunnar Hellström wrote:

Den 2017-06-06 kl. 03:00, skrev Randall Gellens:

At 10:21 PM +0200 6/5/17, Gunnar Hellström wrote:

Den 2017-06-04 kl. 23:51, skrev Randall Gellens:

Hi Gunnar,

What I'd suggest is that we include an informational reference to the draft, although that requires that at least an initial version of the draft be published pretty quickly. So, my suggestion is that you publish at least a skeleton draft right away (which you can revise and extend quickly), and we add text along the lines of the following, perhaps after the second paragraph of Section 5.3:

Note that separate work [draft-xxx] proposes to use the asterisk (or
lack thereof) to convey information between endpoints.

This alerts implementers to the other draft.

This might be a possible way ahead, if others also think it is feasible.


Gunnar, please upload at least a skeleton version of the draft right away, and let me know the title. If you need help with that, I can create one.

The wording and placement of the text requires more tuning. E.g. it should not say "proposes", but rather "specifies".


I was reluctant to say "specifies" until we have a more solid draft (we don't yet have anything). How about if the text says "uses" rather than "proposes to use"? I think that covers it.

Yes, the drafts for the two functionality extensions are uploaded.

I would think that it would be more logical to insert the note about the added meaning of the asterisk in section 5.2, because 5.3 is for the current interpretation case only.

I propose a change to this current text in 5.2

------old text----


   In an offer, each value MAY have an asterisk appended as the final
   value.  An asterisk appended to either value in an offer indicates a
   request by the caller to the callee to not fail the call if there is
   no language in common.  See Section 5.3 for more information and
   discussion.

 -----new text could be----
   In an offer or answer, each value MAY have an asterisk appended as the final
   token.  An asterisk appended to either value in an offer indicates a
   request by the caller to the callee to not fail the call if there is
   no language in common.  See Section 5.3 for more information and
   discussion.

   Note that separate work [draft-hellstrom-slim-modalitypref] extends the use of the
   asterisk with a media level indication.


---end of change-----------------

I moved the note from 5.3 to 5.2 and reworded to say "extends the use of the asterisk to convey information between endpoints":

  In an offer, each list of language tags MAY have an asterisk appended
  at the end.  An asterisk appended to any value in any media in an
  offer indicates a request by the caller to the callee to not fail the
  call if there is no language in common.  See Section 5.3 for more
  information and discussion.  Note that separate work
  [I-D.hellstrom-slim-modalitypref] extends the use of the asterisk to
  convey information between endpoints.

The other draft, about simultaneous modality may also need to be announced.
I suggest this change:

----old text in 5.2------

 BCP 47 describes mechanisms for
   matching language tags.  Note that [RFC5646] Section 4.1 advises to
   "tag content wisely" and not include unnecessary subtags.

 ----new text-----

 BCP 47 describes mechanisms for
   matching language tags.  Note that [RFC5646] Section 4.1 advises to
   "tag content wisely" and not include unnecessary subtags.


 Note also that separate work in [draft-hellstrom-slim-simultaneous-modality] uses a
 notation with a subtag for extended functionality. It is therefore of importance to
 use the mechanisms from BCP 47 for matching languages correctly.

----end of change-----

I am not sure we need to reference the other draft, since it doesn't directly affect the usage of this draft.


 This all builds on that we can at least get WG draft status soon on the new drafts.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
"SFPD Homicide: Our Day Begins when Yours End" --Slogan seen on back of
San Francisco Police Jacket, as reported by Herb Caen in SF Chronicle

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



_______________________________________________
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
--------------51E59C4F3F5F8B398A42270A-- From nobody Fri Jun 9 12:40:22 2017 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 4B12F126D85 for ; Fri, 9 Jun 2017 12:40:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 TMsSXO2SvWGI for ; Fri, 9 Jun 2017 12:40:19 -0700 (PDT) Received: from resqmta-ch2-10v.sys.comcast.net (resqmta-ch2-10v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:42]) (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 C5664128D69 for ; Fri, 9 Jun 2017 12:40:19 -0700 (PDT) Received: from resomta-ch2-08v.sys.comcast.net ([69.252.207.104]) by resqmta-ch2-10v.sys.comcast.net with SMTP id JPl4dCqMA61D9JPladr7hF; Fri, 09 Jun 2017 19:40:18 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1497037218; bh=GrGKYPXc2ktG1dMQN2csyoh7hp3hbWi/PEphNm7hE+Y=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=nnS70RtUHFJmsdZ16Y/LX6WbfCkYvuTS7ICDEbDS1XDtUCQoCCJO/ZvfUzjsazbgN CLHX4LcYIbyH25difns/UJu2lGBQrSXWff2USX4U/V+CkMhtHko7BuJfyncShI6OLq 5fYPu1GqsZ7KB6x7TD+Mh8k62kFndDxTyCVHMOjVLt0jAKSg8Ar6oFScEY2Tt483Yu pegZf17uwU0X7c5TuIynpqvODmGsir+rBYkIbI2Cm/yoCrTDruwnxTED8MPbJDlrBm JN2Rf31mqdgVkgBRYeIRTRe2P/IF24E63Ta/RKQbiu2dqqrTONkJCQpr2CMYQafT6w qZjRabcQ0uQzw== Received: from [192.168.1.110] ([24.62.227.142]) by resomta-ch2-08v.sys.comcast.net with SMTP id JPlZdySEitZO6JPladTcxv; Fri, 09 Jun 2017 19:40:18 +0000 To: Randall Gellens , slim@ietf.org References: <64D68B73-256D-4478-A970-5037B0187D73@brianrosen.net> <70ea7743-7d6a-16ae-f975-72284ff12dfb@comcast.net> From: Paul Kyzivat Message-ID: Date: Fri, 9 Jun 2017 15:40:17 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfJyZCHATCLi0ppUiljInGkPR8IAZQGLraVR1T2u1YQno0mQrcM6T0omWrloiGfkPCVlcEsntEdhWYQcvn+ezZhowC1pTI0cmZhFuhNO1Txlz2d0dUxM/ mNg/JB3cxX42HEIDuALxxzoBOB7IRltHf0ctfM71gmeQGHPaK/1mh28r1AP9DqyF83FrHCLPh5yzxk3Jfql+8HdZjptYbiS0Tnc= Archived-At: Subject: Re: [Slim] draft-ietf-slim-negotiating-human-language-10: extensibility 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, 09 Jun 2017 19:40:21 -0000 On 6/9/17 2:59 PM, Randall Gellens wrote: > At 6:20 PM -0400 6/7/17, Paul Kyzivat wrote: > >> I posted the message below a week ago but I never saw any responses to it: >> >> On 6/1/17 2:23 PM, Paul Kyzivat wrote: >>> On 6/1/17 2:10 PM, Brian Rosen wrote: >> >> [snip] >>>> I would prefer the current syntax, and not Accept-Language syntax. >>> >>> How about enhancing the syntax to support parameters for the values, >>> but only as a future extension mechanism? Unknown parameters to be >>> ignored. Then at least the hooks will be there to introduce something >>> later if desired. >> >> I think this would be the wise thing to do in any case. But especially >> so since we have have some issues pending that have been postponed as >> potential future work. >> >> Here is a specific proposal so we have something concrete to discuss: >> >> hlang-value-list = hlang-value *("," hlang-value) >> >> hlang-value = (Language-Tag / asterisk) *(";" hlang-param) >> >> hlang-param = hlang-param-name ["=" hlang-param-value] >> >> hlang-param-name = token >> >> hlang-param-value = token >> >> asterisk = "*" ; an asterisk (ASCII %2A) character >> >> Language-Tag = >> >> token = >> >> (I am *not* particularly attached to the specifics, but rather just to >> the general notion of having an extensibility hook. If you have issues >> with the syntax details I'm happy to discuss alternatives.) >> >> No specific hlang-params are to be defined in this draft. The >> semantics are that unknown hlang-params are to be ignored, and >> specific ones can be defined in extension drafts. > > I'm not opposed to allowing future extension parameters in the syntax, > but I'm not convinced we need to be so explicit as to their syntax here > (specifying that they consist of a token, an equal sign, and another > token). I'd be more comfortable saying something more generic, such as: > > hlang-value = lang *( "," *" " lang ) > lang = ( Language-Tag [extend] ) / asterisk > ; Language-Tag defined in BCP 47 > extend = ";" 1*( %x21-2B / %x2D-3A / %x3C-7E ) > ; semicolon followed by printable chars not "," ";" " " > ; ignored in this document; defined for future extensibility > asterisk = "*" ; an asterisk (0x2A) character > > This permits a semicolon and a series of characters that don't include > comma, semicolon, or space to be appended to a BCP47 Language-Tag. The > specific syntax of such extensions can then be defined in a future document. I don't quite follow the details above. But I am not opposed to using a more generic format as a placeholder for future parameters. Thanks, Paul From nobody Fri Jun 9 14:42:13 2017 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 3D3A1129415 for ; Fri, 9 Jun 2017 14:42:12 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 UBccl4Bt52si for ; Fri, 9 Jun 2017 14:42:08 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 2119012932A for ; Fri, 9 Jun 2017 14:42:08 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Fri, 9 Jun 2017 14:44:46 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <7669593F-0B97-4AFA-8294-A69684436AD6@brianrosen.net> References: <149609884905.14640.4714137651572553743@ietfa.amsl.com> <54839aba-7ac8-79e4-74f8-927eb455d8af@omnitor.se> <8ca64f00-b1d1-e4da-05cf-0e4663178d85@omnitor.se> <11fef8a5-8ed3-5e70-4ccd-66e7613b22fc@omnitor.se> <7669593F-0B97-4AFA-8294-A69684436AD6@brianrosen.net> X-Mailer: Eudora for Mac OS X Date: Fri, 9 Jun 2017 14:42:02 -0700 To: Brian Rosen From: Randall Gellens Cc: Gunnar =?iso-8859-1?Q?Hellstr=F6m?= , "slim@ietf.org" Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Slim] New wording for the use of the asterisk 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, 09 Jun 2017 21:42:12 -0000 The wording I proposed earlier today is "extends=20 the use of the asterisk to convey information=20 between endpoints" but I like adding "additional"=20 to "information". At 2:48 PM -0400 6/9/17, Brian Rosen wrote: > Generally, I like the wording here. I'd make a=20 > minor suggestion to change "extends the use of=20 > the asterisk with a media level indication" to=20 > "extends the use of the asterisk convey=20 > additional information" or even "extends the=20 > use of the asterisk convey additional=20 > information about languages preferences among=20 > multiple media sessions" > > Brian > >> On Jun 9, 2017, at 2:28 PM, Randall Gellens=20 >> <rg+ietf@randy.pensive.org>=20 >> wrote: >> >> At 8:20 PM +0200 6/7/17, Gunnar Hellstr=F6m wrote: >> >>> Den 2017-06-06 kl. 03:00, skrev Randall Gellens: >>> >>>> At 10:21 PM +0200 6/5/17, Gunnar Hellstr=F6m wrote: >>>> >>>>> Den 2017-06-04 kl. 23:51, skrev Randall Gellens: >>>>> >>>>>> Hi Gunnar, >>>>>> >>>>>> What I'd suggest is that we include an=20 >>>>>> informational reference to the draft,=20 >>>>>> although that requires that at least an=20 >>>>>> initial version of the draft be published=20 >>>>>> pretty quickly. So, my suggestion is that=20 >>>>>> you publish at least a skeleton draft=20 >>>>>> right away (which you can revise and=20 >>>>>> extend quickly), and we add text along the=20 >>>>>> lines of the following, perhaps after the=20 >>>>>> second paragraph of Section 5.3: >>>>>> >>>>>> Note that separate work [draft-xxx] proposes to use the asterisk (or >>>>>> lack thereof) to convey information between endpoints. >>>>>> >>>>>> This alerts implementers to the other draft. >>>>>> >>>>> This might be a possible way ahead, if others also think it is feasib= le. >>>>> >>>> >>>> Gunnar, please upload at least a skeleton=20 >>>> version of the draft right away, and let me=20 >>>> know the title. If you need help with that,=20 >>>> I can create one. >>>> >>>>> The wording and placement of the text=20 >>>>> requires more tuning. E.g. it should not=20 >>>>> say "proposes", but rather "specifies". >>>>> >>>> >>>> I was reluctant to say "specifies" until we=20 >>>> have a more solid draft (we don't yet have=20 >>>> anything). How about if the text says "uses"=20 >>>> rather than "proposes to use"? I think that=20 >>>> covers it. >>>> >>> Yes, the drafts for the two functionality extensions are uploaded. >>> >>> I would think that it would be more logical=20 >>> to insert the note about the added meaning of=20 >>> the asterisk in section 5.2, because 5.3 is=20 >>> for the current interpretation case only. >>> >>> I propose a change to this current text in 5.2 >>> >>> ------old text---- >>> >>> >>> In an offer, each value MAY have an asterisk appended as the final >>> value. An asterisk appended to either value in an offer indicates a >>> request by the caller to the callee to not fail the call if there is >>> no language in common. See Section 5.3 for more information and >>> discussion. >>> >>> -----new text could be---- >>> In an offer or answer, each value MAY have=20 >>> an asterisk appended as the final >>> token. An asterisk appended to either value in an offer indicates a >>> request by the caller to the callee to not fail the call if there is >>> no language in common. See Section 5.3 for more information and >>> discussion. >>> >>> Note that separate work=20 >>> [draft-hellstrom-slim-modalitypref] extends=20 >>> the use of the >>> asterisk with a media level indication. >>> >>> >>> ---end of change----------------- >>> >> >> I moved the note from 5.3 to 5.2 and reworded=20 >> to say "extends the use of the asterisk to=20 >> convey information between endpoints": >> >> In an offer, each list of language tags MAY have an asterisk appended >> at the end. An asterisk appended to any value in any media in an >> offer indicates a request by the caller to the callee to not fail the >> call if there is no language in common. See Section 5.3 for more >> information and discussion. Note that separate work >> [I-D.hellstrom-slim-modalitypref] extends the use of the asterisk to >> convey information between endpoints. >> >>> The other draft, about simultaneous modality may also need to be announ= ced. >>> I suggest this change: >>> >>> ----old text in 5.2------ >>> >>> BCP 47 describes mechanisms for >>> matching language tags. Note that [RFC5646] Section 4.1 advises to >>> "tag content wisely" and not include unnecessary subtags. >>> >>> ----new text----- >>> >>> BCP 47 describes mechanisms for >>> matching language tags. Note that [RFC5646] Section 4.1 advises to >>> "tag content wisely" and not include unnecessary subtags. >>> >>> >>> Note also that separate work in=20 >>> [draft-hellstrom-slim-simultaneous-modality]=20 >>> uses a >>> notation with a subtag for extended=20 >>> functionality. It is therefore of importance=20 >>> to >>> use the mechanisms from BCP 47 for matching languages correctly. >>> >>> ----end of change----- >>> >> >> I am not sure we need to reference the other=20 >> draft, since it doesn't directly affect the=20 >> usage of this draft. >> >>> >>> This all builds on that we can at least get=20 >>> WG draft status soon on the new drafts. >>> >> >> -- >> Randall Gellens >> Opinions are personal; facts are suspect; I speak for myself only >> -------------- Randomly selected tag: --------------- >> "SFPD Homicide: Our Day Begins when Yours End" --Slogan seen on back of >> San Francisco Police Jacket, as reported by Herb Caen in SF Chronicle >> >> _______________________________________________ >> SLIM mailing list >> SLIM@ietf.org >>=20 >> https://www.ietf.org/mailman/= listinfo/slim -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Anarchy may not be the best form of government, but it's better than no government at all. From nobody Fri Jun 9 14:48:06 2017 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 5EE77129478 for ; Fri, 9 Jun 2017 14:48:05 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 oKQR0svyUrqK for ; Fri, 9 Jun 2017 14:48:04 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id D916F12946A for ; Fri, 9 Jun 2017 14:48:03 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Fri, 9 Jun 2017 14:50:43 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <64D68B73-256D-4478-A970-5037B0187D73@brianrosen.net> <70ea7743-7d6a-16ae-f975-72284ff12dfb@comcast.net> X-Mailer: Eudora for Mac OS X Date: Fri, 9 Jun 2017 14:47:56 -0700 To: Paul Kyzivat , slim@ietf.org From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Archived-At: Subject: Re: [Slim] draft-ietf-slim-negotiating-human-language-10: extensibility 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, 09 Jun 2017 21:48:05 -0000 At 3:40 PM -0400 6/9/17, Paul Kyzivat wrote: > On 6/9/17 2:59 PM, Randall Gellens wrote: >> At 6:20 PM -0400 6/7/17, Paul Kyzivat wrote: >> >>> I posted the message below a week ago but I never saw any responses to it: >>> >>> On 6/1/17 2:23 PM, Paul Kyzivat wrote: >>>> On 6/1/17 2:10 PM, Brian Rosen wrote: >>> >>> [snip] >>>>> I would prefer the current syntax, and not Accept-Language syntax. >>>> >>>> How about enhancing the syntax to support parameters for the >>>> values, but only as a future extension mechanism? Unknown >>>> parameters to be ignored. Then at least the hooks will be there >>>> to introduce something later if desired. >>> >>> I think this would be the wise thing to do in any case. But >>> especially so since we have have some issues pending that have >>> been postponed as potential future work. >>> >>> Here is a specific proposal so we have something concrete to discuss: >>> >>> hlang-value-list = hlang-value *("," hlang-value) >>> >>> hlang-value = (Language-Tag / asterisk) *(";" hlang-param) >>> >>> hlang-param = hlang-param-name ["=" hlang-param-value] >>> >>> hlang-param-name = token >>> >>> hlang-param-value = token >>> >>> asterisk = "*" ; an asterisk (ASCII %2A) character >>> >>> Language-Tag = >>> >>> token = >>> >>> (I am *not* particularly attached to the specifics, but rather >>> just to the general notion of having an extensibility hook. If >>> you have issues with the syntax details I'm happy to discuss >>> alternatives.) >>> >>> No specific hlang-params are to be defined in this draft. The >>> semantics are that unknown hlang-params are to be ignored, and >>> specific ones can be defined in extension drafts. >> >> I'm not opposed to allowing future extension parameters in the >> syntax, but I'm not convinced we need to be so explicit as to >> their syntax here (specifying that they consist of a token, an >> equal sign, and another token). I'd be more comfortable saying >> something more generic, such as: >> >> hlang-value = lang *( "," *" " lang ) >> lang = ( Language-Tag [extend] ) / asterisk >> ; Language-Tag defined in BCP 47 >> extend = ";" 1*( %x21-2B / %x2D-3A / %x3C-7E ) >> ; semicolon followed by printable chars not "," ";" " " >> ; ignored in this document; defined for future extensibility >> asterisk = "*" ; an asterisk (0x2A) character >> >> This permits a semicolon and a series of characters that don't >> include comma, semicolon, or space to be appended to a BCP47 >> Language-Tag. The specific syntax of such extensions can then be >> defined in a future document. > > I don't quite follow the details above. It says: (1) The attribute value is an "hlang-value" followed by zero or more sets of comma, optional spaces, and another "hlang-value" (2) An "hlang-value" is a BCP 47 Language-Tag optionally followed by an "extend", or an asterisk (3) An "extend" is a semicolon followed by one or more printable characters other than comma, semicolon and space > But I am not opposed to using a more generic format as a > placeholder for future parameters. > > Thanks, > Paul -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- komorebi (n, Japanese): the scene produced by interplay of sunlight and trees From nobody Fri Jun 9 14:51:47 2017 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 551931275AB for ; Fri, 9 Jun 2017 14:51:45 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 TB1zaEvna9NO for ; Fri, 9 Jun 2017 14:51:44 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id F411912717E for ; Fri, 9 Jun 2017 14:51:43 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Fri, 9 Jun 2017 14:54:24 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Mailer: Eudora for Mac OS X Date: Fri, 9 Jun 2017 14:51:40 -0700 To: Natasha Rooney , "slim@ietf.org" From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Archived-At: Subject: Re: [Slim] Ticket #35 Have an attribute to abbreviate the bidirectionally-symmetric case 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, 09 Jun 2017 21:51:45 -0000 At 5:19 PM +0000 6/8/17, Natasha Rooney wrote: > Related > draft: https://datatracker.ietf.org/doc/draft-ietf-slim-negotiating-human-language/ > > Hi all, > > Please review the below ticket and respond on-list to comments. We > are working through our final tickets before progressing the draft. > > https://trac.ietf.org/trac/slim/ticket/35 > I think it's a bit late in the process for a change as large as this, because I am afraid we might have unanticipated consequences if we add a third attribute whose use precludes the other two. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- During Republican administrations since Hoover, unemployment increased in more years (19) than it decreased (12). By contrast, joblessness declined in the vast majority of Democratic administration years--31 of 40. --Michael Hout, L.A. Times op-ed, March 28, 2004. From nobody Fri Jun 9 14:52:28 2017 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 07DA4128854 for ; Fri, 9 Jun 2017 14:52:28 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 XECv9ywG1_12 for ; Fri, 9 Jun 2017 14:52:26 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 6274812717E for ; Fri, 9 Jun 2017 14:52:26 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Fri, 9 Jun 2017 14:55:06 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <7DC33052-E4D1-4352-B4F8-8C8A416B0DF8@gsma.com> References: <7DC33052-E4D1-4352-B4F8-8C8A416B0DF8@gsma.com> X-Mailer: Eudora for Mac OS X Date: Fri, 9 Jun 2017 14:52:23 -0700 To: Natasha Rooney , "slim@ietf.org" From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Archived-At: Subject: Re: [Slim] Ticket #34 Use the Accept-Language syntax 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, 09 Jun 2017 21:52:28 -0000 At 5:20 PM +0000 6/8/17, Natasha Rooney wrote: > Related > draft: https://datatracker.ietf.org/doc/draft-ietf-slim-negotiating-human-language/ > > Hi all, > > Please review the below ticket and respond on-list to comments. We > are working through our final tickets before progressing the draft. > > https://trac.ietf.org/trac/slim/ticket/34 I object to this, and note that it has been repeatedly discussed by the group and rejected in favor of a simpler approach. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- There is a cult of ignorance in the United States, and there always has been. The strain of anti-intellectualism has been a constant thread winding its way through our political and cultural life, nurtured by the false notion that democracy means that "my ignorance is just as good as your knowledge. --Isaac Asimov, quoted in Newsweek magazine, January 1980. From nobody Fri Jun 9 14:54:48 2017 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 F324212717E for ; Fri, 9 Jun 2017 14:54:46 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 V6SNm_lBeQMJ for ; Fri, 9 Jun 2017 14:54:45 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 7F4C11205F0 for ; Fri, 9 Jun 2017 14:54:45 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Fri, 9 Jun 2017 14:57:25 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Mailer: Eudora for Mac OS X Date: Fri, 9 Jun 2017 14:54:41 -0700 To: Natasha Rooney , "slim@ietf.org" From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Archived-At: Subject: Re: [Slim] #40 Syntax Extensibility 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, 09 Jun 2017 21:54:47 -0000 At 5:27 PM +0000 6/8/17, Natasha Rooney wrote: > Hi all, > > > https://trac.ietf.org/trac/slim/ticket/40 > > Ticket #40 discusses enhancing the syntax for the benefit of > extensibility. Please review this and respond (author and all WG > attendees). Please see the original text from Paul Kyzivat: I proposed a more general version of the ABNF earlier today; however, Adam's comment that a space-delimited list of values is the easiest to parse and most consistent with other SDP attributes makes me reluctant to switch to a more complex syntax absent assurances that it wouldn't add extra complexity. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- There is not much to say about most airplane journeys. Anything remarkable must be disastrous, so you define a good flight by negatives: you didn't get hijacked, you didn't crash, you didn't throw up, you weren't late, you weren't nauseated by the food. So you're grateful. --Paul Theroux, The Old Patagonian Express, 1979 From nobody Fri Jun 9 15:02:03 2017 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 45D84127337 for ; Fri, 9 Jun 2017 15:02:01 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 PEfMmx9eS8ku for ; Fri, 9 Jun 2017 15:01:59 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 787611205F0 for ; Fri, 9 Jun 2017 15:01:59 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Fri, 9 Jun 2017 15:04:39 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <34B284D1-F393-48B3-94E8-5BC8F272E7E9@gsma.com> References: <34B284D1-F393-48B3-94E8-5BC8F272E7E9@gsma.com> X-Mailer: Eudora for Mac OS X Date: Fri, 9 Jun 2017 15:01:55 -0700 To: Natasha Rooney , "slim@ietf.org" From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Archived-At: Subject: Re: [Slim] Ticket #26 Make use of the asterisk modifier on media level with session scope also for media level purposes 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, 09 Jun 2017 22:02:01 -0000 At 5:40 PM +0000 6/8/17, Natasha Rooney wrote: > The additional text describing the * has not been added and myself > and Bernard are unsure of how the current text is sufficient. Can > you add some text or let us know how this is already covered? > Thanks! > > See comment 8 and 9 to see the request in the ticket. > > > https://trac.ietf.org/trac/slim/ticket/26 The text describing the use of asterisk was modified in the more recent updates of the draft. I am not aware of any remaining ambiguity. Specifically, Section 5.2 contains: In an offer, each list of language tags MAY have an asterisk appended at the end. An asterisk appended to any value in any media in an offer indicates a request by the caller to the callee to not fail the call if there is no language in common. See Section 5.3 for more information and discussion. While Section 5.3 contains: A consideration with the ability to negotiate language is if the call proceeds or fails if the callee does not support any of the languages requested by the caller. This document does not mandate either behavior, although it does provide a way for the caller to indicate a preference for the call succeeding when there is no language in common. It is OPTIONAL for the callee to honor this preference. For example, a PSAP is likely to attempt the call even without an indicated preference when there is no language in common, while a call center might choose to fail the call. The mechanism for indicating this preference is that, in an offer, if the last token of any 'hlang-recv' or 'hlang-send' value for any media is an asterisk, this indicates a request to not fail the call. The called party MAY ignore the indication, e.g., for the emergency services use case, regardless of the absence of an asterisk, a PSAP will likely not fail the call; some call centers might reject a call even if the offer contains an asterisk. The examples in Section 5.5 show an asterisk used in some cases. Additionally, Section 6.1 contains: Attribute Syntax: hlang-value = Language-Tag *( SP Language-tag ) [ SP asterisk ] ; Language-Tag as defined in BCP 47 asterisk = "*" ; an asterisk (0x2A) character SP = 1*" " ; one or more space (0x20) characters Which makes it clear that an asterisk may be appended to the list of language tags, and that it can only appear at the end. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Virtue has never been as respectable as money. --Mark Twain From nobody Fri Jun 9 15:04:10 2017 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 1B5F6126DCA for ; Fri, 9 Jun 2017 15:04:09 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 B395uTfPt3zn for ; Fri, 9 Jun 2017 15:04:07 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 4C4041205F0 for ; Fri, 9 Jun 2017 15:04:07 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Fri, 9 Jun 2017 15:06:47 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <36b0c9cd-94b7-e44c-2775-b95876daa40d@omnitor.se> References: <34B284D1-F393-48B3-94E8-5BC8F272E7E9@gsma.com> <36b0c9cd-94b7-e44c-2775-b95876daa40d@omnitor.se> X-Mailer: Eudora for Mac OS X Date: Fri, 9 Jun 2017 15:04:02 -0700 To: Gunnar =?iso-8859-1?Q?Hellstr=F6m?= , Natasha Rooney , "slim@ietf.org" From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Slim] Ticket #26 Make use of the asterisk modifier on media level with session scope also for media level purposes 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, 09 Jun 2017 22:04:09 -0000 At 11:29 PM +0200 6/8/17, Gunnar Hellstr=F6m wrote: > Den 2017-06-08 kl. 19:40, skrev Natasha Rooney: > >> Hi Randall, >> >> The additional text describing the * has not=20 >> been added and myself and Bernard are unsure=20 >> of how the current text is sufficient. Can you=20 >> add some text or let us know how this is=20 >> already covered? Thanks! >> >> See comment 8 and 9 to see the request in the ticket. >> >>=20 >> https://trac.ietf.org/trac/sli= m/ticket/26 >> >> Thanks! >> > I realize that a way to satisfy this request,=20 > and also prepare for a smooth extension=20 > widening the use of the asterisk is to now make=20 > the change shown below in section 5.2 > > By this, we get a firm description on where to=20 > append the asterisk. And we get no interworking=20 > problems when extending the use of the asterisk. > > I agree that it may look odd to talk about=20 > positioning the asterisk on the attribute for=20 > the most preferred modality, when we do not=20 > describe how we use this position. But it is a=20 > fixed rule anyway that makes the asterisk a=20 > media level parameter and it would satisfy=20 > comments 8 and 9 of Ticket #26. > > Another solution is to create a separate=20 > session level attribute for the indication of=20 > non-denial at no match. > a=3Dhlang-nomatch:deny (or keep) > > Change proposal in section 5.3 > > ------old text---- > In an offer, each value MAY have an asterisk appended as the final > value. An asterisk appended to either value in an offer indicates a > request by the caller to the callee to not fail the call if there is > no language in common. See Section 5.3 for more information and > discussion. > > -----new text ---- > In an offer or answer, the attribute value=20 > MAY have an asterisk appended as the final > token. An asterisk appended to a value in an=20 > offer indicates a request by the caller to the > callee to not fail the call if there is no=20 > language in common. The asterisk should be=20 > appended > for at least one direction. If 'hlang-'=20 > attributes are provided for more than one media > in a direction selected to have the asterisk=20 > appended, then the asterisk should be appended > to the attribute for the most preferred=20 > modality in that direction. If no modality can=20 > be > identified as the most preferred for that=20 > direction, then an asterisk should be appended > on each 'hlang' attribute for that=20 > direction. See Section 5.3 for more information=20 > and discussion. > > Note that separate work=20 > [draft-hellstrom-slim-modalitypref] extends the=20 > use of the > asterisk. > > > ---end of change----------------- This proposed text goes beyond what we've agreed to say regarding preference= s. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- A fail-safe circuit will destroy others. A transistor protected by a fast-acting fuse will protect the fuse by blowing first. After the last of 16 mounting screws has been removed from an access cover, it will be discovered that the wrong access cover has been removed. From nobody Fri Jun 9 15:12:18 2017 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 ECEE412717E; Fri, 9 Jun 2017 15:12:16 -0700 (PDT) X-Quarantine-ID: <4gPcya4mYT0n> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 4gPcya4mYT0n; Fri, 9 Jun 2017 15:12:15 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id BDD121252BA; Fri, 9 Jun 2017 15:12:15 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Fri, 9 Jun 2017 15:14:55 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <149694113325.15087.16643503872415274483.idtracker@ietfa.amsl.com> References: <149694113325.15087.16643503872415274483.idtracker@ietfa.amsl.com> X-Mailer: Eudora for Mac OS X Date: Fri, 9 Jun 2017 15:12:13 -0700 To: slim@ietf.org, nrooney@gsma.com, slim-chairs@ietf.org, aamelnikov@fastmail.fm From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Archived-At: Subject: Re: [Slim] slim - New Meeting Session Request for IETF 99 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, 09 Jun 2017 22:12:17 -0000 I will not be able to be in Prague for IETF 99. (I'll be in the air Monday and Tuesday.) -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- The Macintosh uses an experimental pointing device called a "mouse." There is no evidence that people want to use these things. --John C. Dvorak (well-known computer pundit), Feb 1984 From nobody Sat Jun 10 01:44:14 2017 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 5E7C5127077 for ; Sat, 10 Jun 2017 01:44:13 -0700 (PDT) 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 hPhAoyIQPdUJ for ; Sat, 10 Jun 2017 01:44:10 -0700 (PDT) Received: from bin-vsp-out-02.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 3364D1200F3 for ; Sat, 10 Jun 2017 01:44:09 -0700 (PDT) X-Halon-ID: f4985249-4db8-11e7-bcc8-005056917f90 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [77.53.230.196]) by bin-vsp-out-02.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Sat, 10 Jun 2017 10:44:02 +0200 (CEST) To: "slim@ietf.org" From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <8c3bb9d1-b446-446a-29ce-40092f3f649d@omnitor.se> Date: Sat, 10 Jun 2017 10:44:03 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [Slim] Requirements for the real-time case 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, 10 Jun 2017 08:44:13 -0000 I have tried to express the requirements for the SLIM real-time case, and grade them. It is expressed as a chapter that can be inserted in the use case document. I hope it can help to assess what kind of extensibility we need, and also if we need to adjust for any missing functionality. Excuse the length of this mail. I hope to provide this in a document form soon. --------------------------Requirements---------------------------- 3. Requirements Requirements are expressed broadly in this document, both within scope and out-of-scope. They are expressed for the whole concept of negotiating language, regardless of the current scope of the drafts. An indication is provided if the requirement is regarded to be within scope for the initial document or of interest for possible extensions. This indication is shown by an initial capital letter before the requirement. The indications are: B = basic, included in initial specification (version -10) X = urgent extension P = of interest for further extensions O = Not foreseen to be of high interest 3.1. High Level Requirements X. The specified mechanism shall enable smooth initiation of a conversational call with the opportunity for the participants to start their language expressions in the call in a language and modality (or a combination of languages in different modalities) that has best opportunities for them to be convenient to use and for the other participants to understand well. P. The mechanism shall also make it possible for the participants to be informed about in which language and modality the other participants will start their language expression in the call, so that they can tune their expectations accordingly. B. The mechanism shall also enable the participants or their service providers to take decisions on invoking extra resources into the call to handle the language combination well or assign the most suitable call-taker to the call. The mechanisms for taking these decisions and making these actions are however out-of-scope. B. Once the session has started, the participants are free to use whatever language and modality that they together may find useful during the conversation. 3.2. Session Types B. Conversational person-to-person call B. Conversational multi-party call. (Note: The basic functionality is sufficient for providing simple indications suitable for most multi-party calls. It is negotiation that may be complicated, but the details about how to negotiate is out of scope.) B. Conversational person-to-multimedia anwering-machine call B. Multimedia conference. (Note: The basic functionality is sufficient for providing simple indications suitable for most multi- party calls. It is negotiation that may be complicated, but the details about how to negotiate is out of scope.) X. Conversational call supported by captioned telephony relay service. B. Conversational call supported by text relay service B. Conversational call supported by video relay service (for sign language) P. Conversational call supported by speech-to-speech relay service. (no coding defined for service requirements) B. Conversational call supported by spoken language interpretation. (translation may be invoked by either party as a result of language and modality matching) O. Streaming media session. (Nothing blocks from using the same mechanism for streaming sessions, however, extensions may be needed, e.g. for text in video overlay) 3.3. Modalities B. Spoken B. Written B. Signed P. Text messaging X. Spoken and written simultaneously in same direction X. Spoken and signed simultaneously in same direction X. Written and spoken simultaneously in same direction O. Written and signed simultaneously in same direction 3.4. Directions B. Sent B. Received O. Both sent and received in same attribute ( for simplifying SDP) 3.5. Languages B. Languages shall be specified by Language tags of BCP 47 [RFC5646] B. It shall be possible to select from alternative single languages per media and direction. O. Range of possible languages per media and direction indicated by language tag ranges as specified in BCP 47. (may be of use for streaming media with spoken and signed languages simultaneously in video, or possibly for more reliable language matching) X. Combination of simultaneous languages in different media and same direction. (Required for captioned telephony and for persons with limited language capabilities who need to combine perceptions of two modalities) B. Language details by adding subtags wisely, thus using subtags when they really add anything of value for the language selection. Language matching shall be made according to the mechanisms described in BCP 47. 3.6. Media B. Audio B. Text B. Video P. Message B. Multiple alternative media B. Single media streams of each type B. Multiple media streams of same type ( may need combination with a=Content attribute) 3.7. Modality and Media Relations B. Written in Text B. Spoken in Audio B. Signed in Video P. Text messaging in Message B. Spoken in video = view of speaker O. Written in video = text overlay in video (may be of interest for streaming) 3.8. Preferences and capabilities 3.8.1. Preference by offering party for sending language B. Preference between sending languages in same modality X. Preference between different modalities for sending language P. Preference between languages for sending in different modalities (this level of detail is not of high interest) 3.8.2. Preference by offering party for receiving language B. Preference between languages to receive in same modality X. Preference between different modalities for receiving language P. Preference between languages for receiving in different modalities (this level of detail is not of high interest) 3.8.3. Preference by answering party for sending language B. Preference between languages to send in same modality X. Preference between different modalities for sending language P. Preference between sending language in different modalities (this level of detail is not of high interest) 3.8.4. Preference by answering party for receiving language B. Preference between receiving different languages in same modality X. Preference between different modalities for receiving language modalities P. Preference between different languages for receiving in different modalities (this level of detail is not of high interest) 3.8.5. Preference detail level B. Detailed preference per language, direction and modality - no preference between modalities P. Detailed preference per language and direction in different modalities P. Coarse preference Hi/Lo per language and direction in different modalities X. Coarse preference Hi/Lo per modality and direction P. Preference only for modality, without specifying language at all. (May e.g. be of interest for invocation of relay service.) 3.9. Call Denial B. Preference from caller to get the call denied if no languages match. (May cause unwanted denials because language matching may be hard to do reliably) B. Preference of the caller to not get the call denied if no languages match 3.10. Information to users 3.10.1. Information to answering party about negotiation result B. Information to answering party about selected languages in negotiation result B. Information to answering party about both common capabilities and selected languages in negotiation result 3.10.2. Information to offering party about negotiation result B. Information to offering party about selected languages in negotiation result P. Information to offering party about both common capabilities and selected languages in negotiation result 3.11. Technical Base B. The mechanism shall be based on SDP [RFC4566] but may be adaptable to other environments. ------------------------------------------------------------------------------ Evaluation: The B-marked requirements are as specified in draft-ietf-slim-negotiating-human-language-10 The X-marked are the often discussed urgently required extensions for: - Preference indication between different modalities. (note that I regard it sufficient to indicate preference per modality, not language. An indication of preference per language and modality is however also feasible if that is what we end up in. ) - Preference for receiving two modalities simultaneously. (note that I regard it sufficient to indicate preference per modality, not language. An indication of preference per language is however also feasible if that is what we end up in. ) Among the P- and O-marked requirements, there are some worth considering for early inclusion: -3.2 Use in streaming. (no real change needed except possibly to include text overlay in video) -3.3, 3.6, 3.8 Text Messaging (discussed before but dropped) -3.7 Text overlay in video (mainly for streaming, so not in our main focus) -3.10.2 Information to offering party about both common language capabilities and language selected to be used initially in the session. (the current draft is fuzzy about this, it may provide information about the language to actually use, or it may provide information about a range of suitable languages in different modalities. It has no notation for difference between actually decided language and language possible to use.) Of these, I only feel a bit strong about the information to the offering party in 3.10.2. I hope this can be helpful for finalizing the basic draft and the extension mechanism. /Gunnar -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 From nobody Sat Jun 10 02:08:45 2017 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 B5C02124D37 for ; Sat, 10 Jun 2017 02:08:43 -0700 (PDT) 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 kjK0sDuO3puc for ; Sat, 10 Jun 2017 02:08:41 -0700 (PDT) Received: from bin-vsp-out-02.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 8E1301201F2 for ; Sat, 10 Jun 2017 02:08:41 -0700 (PDT) X-Halon-ID: 62d01350-4dbc-11e7-bcc8-005056917f90 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [77.53.230.196]) by bin-vsp-out-02.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Sat, 10 Jun 2017 11:08:35 +0200 (CEST) To: Randall Gellens , Natasha Rooney , "slim@ietf.org" References: <34B284D1-F393-48B3-94E8-5BC8F272E7E9@gsma.com> <36b0c9cd-94b7-e44c-2775-b95876daa40d@omnitor.se> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <23133afa-4d06-2de8-b559-43386ce78a25@omnitor.se> Date: Sat, 10 Jun 2017 11:08:37 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Slim] Ticket #26 Make use of the asterisk modifier on media level with session scope also for media level purposes 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, 10 Jun 2017 09:08:44 -0000 Den 2017-06-10 kl. 00:04, skrev Randall Gellens: > At 11:29 PM +0200 6/8/17, Gunnar Hellström wrote: > >> Den 2017-06-08 kl. 19:40, skrev Natasha Rooney: >> >>> Hi Randall, >>> >>> The additional text describing the * has not been added and myself >>> and Bernard are unsure of how the current text is sufficient. Can >>> you add some text or let us know how this is already covered? Thanks! >>> >>> See comment 8 and 9 to see the request in the ticket. >>> >>> >>> https://trac.ietf.org/trac/slim/ticket/26 >>> >>> >>> Thanks! >>> >> I realize that a way to satisfy this request, and also prepare for a >> smooth extension widening the use of the asterisk is to now make the >> change shown below in section 5.2 >> >> By this, we get a firm description on where to append the asterisk. >> And we get no interworking problems when extending the use of the >> asterisk. >> >> I agree that it may look odd to talk about positioning the asterisk >> on the attribute for the most preferred modality, when we do not >> describe how we use this position. But it is a fixed rule anyway that >> makes the asterisk a media level parameter and it would satisfy >> comments 8 and 9 of Ticket #26. >> >> Another solution is to create a separate session level attribute for >> the indication of non-denial at no match. >> a=hlang-nomatch:deny (or keep) >> >> Change proposal in section 5.3 >> >> ------old text---- >> In an offer, each value MAY have an asterisk appended as the final >> value. An asterisk appended to either value in an offer indicates a >> request by the caller to the callee to not fail the call if there is >> no language in common. See Section 5.3 for more information and >> discussion. >> >> -----new text ---- >> In an offer or answer, the attribute value MAY have an asterisk >> appended as the final >> token. An asterisk appended to a value in an offer indicates a >> request by the caller to the >> callee to not fail the call if there is no language in common. >> The asterisk should be appended >> for at least one direction. If 'hlang-' attributes are provided >> for more than one media >> in a direction selected to have the asterisk appended, then the >> asterisk should be appended >> to the attribute for the most preferred modality in that >> direction. If no modality can be >> identified as the most preferred for that direction, then an >> asterisk should be appended >> on each 'hlang' attribute for that direction. See Section 5.3 for >> more information and discussion. >> >> Note that separate work [draft-hellstrom-slim-modalitypref] >> extends the use of the >> asterisk. >> >> >> ---end of change----------------- > > This proposed text goes beyond what we've agreed to say regarding > preferences. Yes, I realize that. But it does not specify any specific action regarding preference by the receiver of the indication. It is just a clean way to specify the placement of the asterisk, so that future readers do not get as confused as our reviewers got. And, it prepares for smooth introduction of the low comlexity addition of modality preference indication by the asterisk. Without this, we cannot really say that we are totally backwards compatible if we start from the current draft and add the modality preferece as an extension. An offering party attaching the asterisk on any modality may cause an answering party knowing about the extension to take the placement of the asterisk as a base for decision on which modality to start the call in. And that can be a modality that is not really the best for the offering party. That makes it doubtful if we can use this simple mechanism for modality preference indication and instead maybe need to introduce the more complex one with extension parameters per language as proposed by Paul. Or can we aim at joint IANA registration and see the reference to the modality-preference specification as a normative requirement for the implementor to consider? /Gunnar > > -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 From nobody Sat Jun 10 10:58:18 2017 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 3376E127735 for ; Sat, 10 Jun 2017 10:58:16 -0700 (PDT) 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 CnyOgy-5rNwW for ; Sat, 10 Jun 2017 10:58:13 -0700 (PDT) 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 249C2128768 for ; Sat, 10 Jun 2017 10:58:12 -0700 (PDT) X-Halon-ID: 597f6281-4e06-11e7-bca7-0050569116f7 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [77.53.230.196]) by bin-vsp-out-03.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Sat, 10 Jun 2017 19:58:03 +0200 (CEST) To: Randall Gellens , Natasha Rooney , "slim@ietf.org" References: <34B284D1-F393-48B3-94E8-5BC8F272E7E9@gsma.com> <36b0c9cd-94b7-e44c-2775-b95876daa40d@omnitor.se> <23133afa-4d06-2de8-b559-43386ce78a25@omnitor.se> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <702091da-fcae-00a5-a2cd-3cad05c1565c@omnitor.se> Date: Sat, 10 Jun 2017 19:58:06 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <23133afa-4d06-2de8-b559-43386ce78a25@omnitor.se> Content-Type: multipart/alternative; boundary="------------1553849FA788E1F131EF43E4" Archived-At: Subject: Re: [Slim] Ticket #26 Make use of the asterisk modifier on media level with session scope also for media level purposes 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, 10 Jun 2017 17:58:16 -0000 This is a multi-part message in MIME format. --------------1553849FA788E1F131EF43E4 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit I like Brian's wording for the note about reuse of the asterisk in 5.2, and think that that can be sufficient for allowing reuse of the asterisk. "Note that separate work [I-D.hellstrom-slim-modalitypref] extends the use of the asterisk to convey additional information about language preferences among multiple media sessions." If this is acceptable, and also the use of the "t" extension to indicate simultaneous modalities, then I do not see any urgent need to complicate syntax with extension possibilities. But these two conditions need to be checked. Gunnar Den 2017-06-10 kl. 11:08, skrev Gunnar Hellström: > Den 2017-06-10 kl. 00:04, skrev Randall Gellens: >> At 11:29 PM +0200 6/8/17, Gunnar Hellström wrote: >> >>> Den 2017-06-08 kl. 19:40, skrev Natasha Rooney: >>> >>>> Hi Randall, >>>> >>>> The additional text describing the * has not been added and myself >>>> and Bernard are unsure of how the current text is sufficient. Can >>>> you add some text or let us know how this is already covered? Thanks! >>>> >>>> See comment 8 and 9 to see the request in the ticket. >>>> >>>> >>>> https://trac.ietf.org/trac/slim/ticket/26 >>>> >>>> >>>> Thanks! >>>> >>> I realize that a way to satisfy this request, and also prepare for >>> a smooth extension widening the use of the asterisk is to now make >>> the change shown below in section 5.2 >>> >>> By this, we get a firm description on where to append the asterisk. >>> And we get no interworking problems when extending the use of the >>> asterisk. >>> >>> I agree that it may look odd to talk about positioning the asterisk >>> on the attribute for the most preferred modality, when we do not >>> describe how we use this position. But it is a fixed rule anyway >>> that makes the asterisk a media level parameter and it would satisfy >>> comments 8 and 9 of Ticket #26. >>> >>> Another solution is to create a separate session level attribute >>> for the indication of non-denial at no match. >>> a=hlang-nomatch:deny (or keep) >>> >>> Change proposal in section 5.3 >>> >>> ------old text---- >>> In an offer, each value MAY have an asterisk appended as the final >>> value. An asterisk appended to either value in an offer >>> indicates a >>> request by the caller to the callee to not fail the call if >>> there is >>> no language in common. See Section 5.3 for more information and >>> discussion. >>> >>> -----new text ---- >>> In an offer or answer, the attribute value MAY have an asterisk >>> appended as the final >>> token. An asterisk appended to a value in an offer indicates a >>> request by the caller to the >>> callee to not fail the call if there is no language in common. >>> The asterisk should be appended >>> for at least one direction. If 'hlang-' attributes are provided >>> for more than one media >>> in a direction selected to have the asterisk appended, then the >>> asterisk should be appended >>> to the attribute for the most preferred modality in that >>> direction. If no modality can be >>> identified as the most preferred for that direction, then an >>> asterisk should be appended >>> on each 'hlang' attribute for that direction. See Section 5.3 >>> for more information and discussion. >>> >>> Note that separate work [draft-hellstrom-slim-modalitypref] >>> extends the use of the >>> asterisk. >>> >>> >>> ---end of change----------------- >> >> This proposed text goes beyond what we've agreed to say regarding >> preferences. > Yes, I realize that. But it does not specify any specific action > regarding preference by the receiver of the indication. > It is just a clean way to specify the placement of the asterisk, so > that future readers do not get as confused as our reviewers got. > > And, it prepares for smooth introduction of the low comlexity addition > of modality preference indication by the asterisk. Without this, we > cannot really say that we are totally backwards compatible if we start > from the current draft and add the modality preferece as an extension. > An offering party attaching the asterisk on any modality may cause an > answering party knowing about the extension to take the placement of > the asterisk as a base for decision on which modality to start the > call in. And that can be a modality that is not really the best for > the offering party. > > That makes it doubtful if we can use this simple mechanism for > modality preference indication and instead maybe need to introduce the > more complex one with extension parameters per language as proposed by > Paul. > > Or can we aim at joint IANA registration and see the reference to the > modality-preference specification as a normative requirement for the > implementor to consider? > > /Gunnar >> >> > -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 --------------1553849FA788E1F131EF43E4 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

I like Brian's wording for the note about reuse of the asterisk in 5.2, and think that that can be sufficient for allowing reuse of the asterisk.

"Note that separate work  [I-D.hellstrom-slim-modalitypref] extends the use of the asterisk to convey additional information about language preferences among multiple media sessions."

If this is acceptable, and also the use of the "t" extension to indicate simultaneous modalities, then I do not see any urgent need to complicate syntax with extension possibilities.  But these two conditions need to be checked.

Gunnar


Den 2017-06-10 kl. 11:08, skrev Gunnar Hellström:
Den 2017-06-10 kl. 00:04, skrev Randall Gellens:
At 11:29 PM +0200 6/8/17, Gunnar Hellström wrote:

 Den 2017-06-08 kl. 19:40, skrev Natasha Rooney:

 Hi Randall,

 The additional text describing the * has not been added and myself and Bernard are unsure of how the current text is sufficient. Can you add some text or let us know how this is already covered? Thanks!

 See comment 8 and 9 to see the request in the ticket.


<https://trac.ietf.org/trac/slim/ticket/26>https://trac.ietf.org/trac/slim/ticket/26

 Thanks!

 I realize that a way to satisfy this request, and also prepare for a smooth extension widening the use of the asterisk is to now make the change shown below in section 5.2

 By this, we get a firm description on where to append the asterisk. And we get no interworking problems when extending the use of the asterisk.

 I agree that it may look odd to talk about positioning the asterisk on the attribute for the most preferred modality, when we do not describe how we use this position. But it is a fixed rule anyway that makes the asterisk a media level parameter and it would satisfy comments 8 and 9 of Ticket #26.

 Another solution is to create a separate session level attribute for the indication of non-denial at no match.
 a=hlang-nomatch:deny (or keep)

 Change proposal in section 5.3

 ------old text----
    In an offer, each value MAY have an asterisk appended as the final
    value.  An asterisk appended to either value in an offer indicates a
    request by the caller to the callee to not fail the call if there is
    no language in common.  See Section 5.3 for more information and
    discussion.

  -----new text ----
    In an offer or answer, the attribute value MAY have an asterisk appended as the final
    token. An asterisk appended to a value in an offer indicates a request by the caller to the
    callee to not fail the call if there is no language in common. The asterisk should be appended
    for at least one direction. If 'hlang-' attributes are provided for more than one media
    in a direction selected to have the asterisk appended, then the asterisk should be appended
    to the attribute for the most preferred modality in that direction. If no modality can be
    identified as the most preferred for that direction, then an asterisk should be appended
    on each 'hlang' attribute for that direction. See Section 5.3 for more information and discussion.

    Note that separate work [draft-hellstrom-slim-modalitypref] extends the use of the
    asterisk.


 ---end of change-----------------

This proposed text goes beyond what we've agreed to say regarding preferences.
Yes, I realize that. But it does not specify any specific action regarding preference by the receiver of the indication.
It is just a clean way to specify the placement of the asterisk, so that future readers do not get as confused as our reviewers got.

And, it prepares for smooth introduction of the low comlexity addition of modality preference indication by the asterisk. Without this, we cannot really say that we are totally backwards compatible if we start from the current draft and add the modality preferece as an extension. An offering party attaching the asterisk on any modality may cause an answering party knowing about the extension to take the placement of the asterisk as a base for decision on which modality to start the call in. And that can be a modality that is not really the best for the offering party.

That makes it doubtful if we can use this simple mechanism for modality preference indication and instead maybe need to introduce the more complex one with extension parameters per language as proposed by Paul.

Or can we aim at joint IANA registration and see the reference to the modality-preference specification as a normative requirement for the implementor to consider?

/Gunnar 




-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288
--------------1553849FA788E1F131EF43E4-- From nobody Sat Jun 10 12:26:48 2017 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 72B371270AC for ; Sat, 10 Jun 2017 12:26:46 -0700 (PDT) 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 D_JdIHcrI4Oc for ; Sat, 10 Jun 2017 12:26:44 -0700 (PDT) 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 290CF1267BB for ; Sat, 10 Jun 2017 12:26:43 -0700 (PDT) X-Halon-ID: b93d0d98-4e12-11e7-bcc8-005056917f90 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [77.53.230.196]) by bin-vsp-out-02.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Sat, 10 Jun 2017 21:26:38 +0200 (CEST) From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= To: "slim@ietf.org" Message-ID: Date: Sat, 10 Jun 2017 21:26:39 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Slim] I-D Action: draft-hellstrom-slim-modalitypref-02.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: Sat, 10 Jun 2017 19:26:46 -0000 A new version of the slim modality preference draft is available. The only change is adjustment of the IANA considerations to a format required for drafts updating earlier registered attributes (it is documented in RFC456bis how to do it.) With Brian's note about the interrelation in draft-ietf-slim-negotiating-human-language, I hope we can continue on this low complexity track. /Gunnar --------------------------------------------------------------- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Negotiating Modality in Real-Time Communications Author : Gunnar Hellstrom Filename : draft-hellstrom-slim-modalitypref-02.txt Pages : 7 Date : 2017-06-10 Abstract: When negotiating language for a real-time session, users may have very specific preferences for using one modality (spoken, written or signed) over other possible but less preferred modalities. This specification introduces indication of modality preference to be used in session negotiation in combination with an earlier speified mechanism for language preference negotiation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-hellstrom-slim-modalitypref/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-hellstrom-slim-modalitypref-02 https://datatracker.ietf.org/doc/html/draft-hellstrom-slim-modalitypref-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-hellstrom-slim-modalitypref-02 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/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Sat Jun 10 12:30:18 2017 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 B06091267BB for ; Sat, 10 Jun 2017 12:30:17 -0700 (PDT) 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 9DkQouhjjK6y for ; Sat, 10 Jun 2017 12:30:15 -0700 (PDT) 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 5BC9B127369 for ; Sat, 10 Jun 2017 12:30:15 -0700 (PDT) X-Halon-ID: 364b37c1-4e13-11e7-bca7-0050569116f7 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [77.53.230.196]) by bin-vsp-out-03.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Sat, 10 Jun 2017 21:30:07 +0200 (CEST) From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= To: "slim@ietf.org" , "Phillips, Addison" Message-ID: <691cd547-c8ce-a848-bbd8-800f44760f16@omnitor.se> Date: Sat, 10 Jun 2017 21:30:11 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Slim] I-D Action: draft-hellstrom-slim-simultaneous-modalities-01.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: Sat, 10 Jun 2017 19:30:18 -0000 A new version of the draft for simultaneous modality is available. I have tried to make the logic more clear and readable. I hope we can get comments from language experts telling that this is a feasible use of the "t" extension in BCP 47. /Gunnar ------------------------------------------------------------------------ A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Negotiating Simultaneous Modalities in Real-Time Communications Author : Gunnar Hellstrom Filename : draft-hellstrom-slim-simultaneous-modalities-01.txt Pages : 7 Date : 2017-06-10 Abstract: In a real-time communication session, there may be a need or preference for receiving the same content in two or more simultaneous modalities. This specification extends a mechanism for human language negotiation with a mechanism for indication of preference for, or the availability of, simultaneously provided transformations of original contents. This indication enables negotiation of simultaneous modalities in real-time sessions. Applications are for example provision of both spoken and written content in a real-time call (captioning), or provision of both spoken language original and sign language interpretation of the original language in a real-time session. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-hellstrom-slim-simultaneous-modalities/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-hellstrom-slim-simultaneous-modalities-01 https://datatracker.ietf.org/doc/html/draft-hellstrom-slim-simultaneous-modalities-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-hellstrom-slim-simultaneous-modalities-01 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/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Sun Jun 11 15:11:48 2017 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 73FF6127599 for ; Sun, 11 Jun 2017 15:11:47 -0700 (PDT) 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, 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 W4rloIPfOiG8 for ; Sun, 11 Jun 2017 15:11:45 -0700 (PDT) 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 BFCBD126557 for ; Sun, 11 Jun 2017 15:11:44 -0700 (PDT) X-Halon-ID: eea4c61e-4ef2-11e7-bca7-0050569116f7 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [77.53.230.196]) by bin-vsp-out-03.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Mon, 12 Jun 2017 00:11:34 +0200 (CEST) From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= To: "slim@ietf.org" , Brian Rosen Message-ID: <5b18dfa4-09b7-cd89-b6e0-8031745c261a@omnitor.se> Date: Mon, 12 Jun 2017 00:11:38 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Slim] I-D Action: draft-hellstrom-language-grouping-00.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: Sun, 11 Jun 2017 22:11:47 -0000 I made a new effort to use the SDP grouping semantics ( RFC 5888) for the preference and simultaneous modality indications, and found it quite feasible. ( Yes, Brian, I agree that you have claimed so a number of times. I am afraid that I imagined complexity like when applying sdpneg or so. This was simple. ) So, here is an alternative draft solution for both the simultaneous modalities and the modality preference functions. The draft is quite independent of the way languages are indicated, but the draft-ietf-slim-negotiating-human-language is referenced anyway as an example of what can be used. I am of course interested in getting comments on this approach. (I guess I should also involve mmusic if we find that the approach is feasible. ) /Gunnar --------------------------------- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Human Language Modality Grouping Semantics in Session Description Protocol Author : Gunnar Hellstrom Filename : draft-hellstrom-language-grouping-00.txt Pages : 10 Date : 2017-06-11 Abstract: In a real-time communication session, there may be a need or preference for receiving the same content in two or more simultaneous modalities. There may also be a need to prioritize which media to use for language communications. This document defines the semantics for grouping media in the Session Description Protocol (SDP) containing human languages in order to assign their relative priority and also grouping media that are desired to be received together. The semantics defined in this document are to be used with the SDP Grouping Framework. Applications are for example a possibility to indicate when a sign language is most desired, but written language an acceptable lower rated alternative, offered for the other party to select between. Applications are also for indication of need for both spoken and written content in a real-time call (captioning) together, or provision of both spoken language original and sign language interpretation of the original language together in a real- time session. These indications are specified for the sending and receiving direction separately. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-hellstrom-language-grouping/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-hellstrom-language-grouping-00 https://datatracker.ietf.org/doc/html/draft-hellstrom-language-grouping-00 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/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Mon Jun 12 02:05:23 2017 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 4DAE11270AC; Mon, 12 Jun 2017 02:05:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 TDv2CdQrNdHz; Mon, 12 Jun 2017 02:05:20 -0700 (PDT) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::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 6A9D9126579; Mon, 12 Jun 2017 02:05:20 -0700 (PDT) Received: by mail-lf0-x236.google.com with SMTP id p189so48280304lfe.2; Mon, 12 Jun 2017 02:05:20 -0700 (PDT) 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=N0287gPduPm0gHsrDS8GMCackL6r/Zynh/qCphDRH+o=; b=dyDaxL1i1eRSydhb2mEBi0VxLrZotiwLxBogIbKBm8CIyQQQa6Sz2t71J3X97NqUI7 PUbrWyaYPJI0s+HCaWWkXP3mZJhHZvIgoHwFq8xObyaSvVKwdy3tNZFYVrO32Y+n4W9A zPgGY4mYySo8zWZi4fyp+XuNE4WnCg1DCwdn26YUlQxtgAyzc4xrMjAM1a830obaXoIF bkbpFnawbqH7dL8S0Ym/VbKwAkJsQKx4Mc9+Up/IlMNuTyBdQ1iqUz8L36S9o2GEJ21u psLeV90u78oe7Lgj2dRYKcNRzHnYuxjYxJv1HiftGN+wpqbOOm6bQjegximxdYsSl94D MCBQ== 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=N0287gPduPm0gHsrDS8GMCackL6r/Zynh/qCphDRH+o=; b=oHjiF9Ga5NsJM3ntjdi9zFns6nvx0tem7UVeFagm26wiLejvdiN9q3GclwWFfhtGyy DQckzFTdaIMWqqNXsKio3L2UMUER8bncbuxCZ6bi0bBkGR0DUwgmpsQ8z4yvN2yUWAmR 0OUaT6I9scDidqqo1gK7MEL0p2tfF/1V9+92At2LPjq6b1oW7YlqEqBdNo+cCTRnnx6m AsJthEgGcLPG9v0D96QvjXdl9byW/S6LuPy7q0tDPcyAqsAA2d88dnp5F9DbZ5zc5PlA hho8pn3O1SX6wqcd2DY3YMJ3SFCLkn8sQFWUnvbzGp4DhGKdHTrWLEngKClNud1+Nqgi rFcA== X-Gm-Message-State: AODbwcB0FT+YFFvK/UZCuTVA9oyx7hbMyAr0oWOs87X0ZbURuEArqY1U kuQOUtdX5CF8rOrAa6QI8N/t4fqxBw== X-Received: by 10.25.199.7 with SMTP id x7mr13165460lff.170.1497258318781; Mon, 12 Jun 2017 02:05:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.209.139 with HTTP; Mon, 12 Jun 2017 02:05:18 -0700 (PDT) In-Reply-To: References: <149694113325.15087.16643503872415274483.idtracker@ietfa.amsl.com> From: Nik Tomkinson Date: Mon, 12 Jun 2017 10:05:18 +0100 Message-ID: To: Randall Gellens Cc: slim@ietf.org, Natasha Rooney , slim-chairs@ietf.org, Alexey Melnikov Content-Type: multipart/alternative; boundary="94eb2c1a1f043a66580551bf9eac" Archived-At: Subject: Re: [Slim] slim - New Meeting Session Request for IETF 99 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, 12 Jun 2017 09:05:22 -0000 --94eb2c1a1f043a66580551bf9eac Content-Type: text/plain; charset="UTF-8" Hi All, I can't be there in person either, but I don't think there is much to discuss on my draft. Nik. On 9 June 2017 at 23:12, Randall Gellens wrote: > I will not be able to be in Prague for IETF 99. (I'll be in the air > Monday and Tuesday.) > > > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- > The Macintosh uses an experimental pointing device called a "mouse." > There is no evidence that people want to use these things. > --John C. Dvorak (well-known computer pundit), Feb 1984 > > > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim > -- ----------------------------------------------------------------- Multiple Language Content Type Internet Draft: https://datatracker.ietf.org/doc/draft-ietf-slim-multilangcontent/ ----------------------------------------------------------------- --94eb2c1a1f043a66580551bf9eac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All,

I can't be there in person = either, but I don't think there is much to discuss on my draft.

Nik.

On 9 June 2017 at 23:12, Randall Gellens <rg+ietf= @randy.pensive.org> wrote:
= I will not be able to be in Prague for IETF 99.=C2=A0 (I'll be in the a= ir Monday and Tuesday.)


--
Randall Gellens
Opinions are personal;=C2=A0 =C2=A0 facts are suspect;=C2=A0 =C2=A0 I speak= for myself only
-------------- Randomly selected tag: ---------------
The Macintosh uses an experimental pointing device called a "mouse.&qu= ot;
There is no evidence that people want to use these things.
=C2=A0 =C2=A0--John C. Dvorak (well-known computer pundit), Feb 1984=


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



--
= 
-----------=
------------------------------------------------------
Multiple Language=
 Content Type Internet Draft:
https:=
//datatracker.ietf.org/doc/draft-ietf-slim-multilangcontent/
=
-------------------------=
----------------------------------------

--94eb2c1a1f043a66580551bf9eac-- From nobody Mon Jun 12 06:38:53 2017 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 46F5E1292CE for ; Mon, 12 Jun 2017 06:38:51 -0700 (PDT) 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 AHawDs5MZYIJ for ; Mon, 12 Jun 2017 06:38:49 -0700 (PDT) Received: from bin-vsp-out-01.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 E138C127876 for ; Mon, 12 Jun 2017 06:38:48 -0700 (PDT) X-Halon-ID: 74e6e49b-4f74-11e7-b75a-005056917a89 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [77.53.230.196]) by bin-vsp-out-01.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Mon, 12 Jun 2017 15:38:45 +0200 (CEST) To: Randall Gellens , Natasha Rooney , "slim@ietf.org" References: From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <997ec582-e710-467f-bf8b-1e121a3324da@omnitor.se> Date: Mon, 12 Jun 2017 15:38:42 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Slim] #40 Syntax Extensibility 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, 12 Jun 2017 13:38:51 -0000 Den 2017-06-09 kl. 23:54, skrev Randall Gellens: > At 5:27 PM +0000 6/8/17, Natasha Rooney wrote: > >> Hi all, >> >> >> https://trac.ietf.org/trac/slim/ticket/40 >> >> >> Ticket #40 discusses enhancing the syntax for the benefit of >> extensibility. Please review this and respond (author and all WG >> attendees). Please see the original text from Paul Kyzivat: > > I proposed a more general version of the ABNF earlier today; however, > Adam's comment that a space-delimited list of values is the easiest to > parse and most consistent with other SDP attributes makes me reluctant > to switch to a more complex syntax absent assurances that it wouldn't > add extra complexity. > We also do not know that it is exactly new parameters on the language tags that will be the desired extensions. It could just as well be alternatives to the asterisk, valid for the whole media description. Or other features. My efforts to make a requirements overview show some features that could be solved by new language tag parameters: 1) in 3.10.2 : P. Information to offering party about both common capabilities and selected languages in negotiation result 2) In 3.8.5: P. Coarse preference Hi/Lo per language and direction in different modalities 3) In 3.5 X. Combination of simultaneous languages in different media and same direction. I hope that 2 and 3 can be solved either by the current ideas of using the asterisk and the "t" extension, or the new SDP grouping semantics. That would leave us with item 1 as a feature that could use new language tag parameters. Is it worth the efforts? Do others see other extension needs than the ones identified through my Requirements collection under subject "[Slim] Requirements for the real-time case!. /Gunnar Gunnar -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 From nobody Mon Jun 12 06:57:25 2017 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 5E95612EAAD for ; Mon, 12 Jun 2017 06:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 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, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.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 NKX3FJQNeJNz for ; Mon, 12 Jun 2017 06:57:22 -0700 (PDT) Received: from mail-qt0-x242.google.com (mail-qt0-x242.google.com [IPv6:2607:f8b0:400d:c0d::242]) (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 4697E129511 for ; Mon, 12 Jun 2017 06:57:22 -0700 (PDT) Received: by mail-qt0-x242.google.com with SMTP id x58so26559775qtc.2 for ; Mon, 12 Jun 2017 06:57:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=ZA1944vkJjFmw5EEyS3vnJ3J7Ezr6Qz3fqRnPGmLQ/c=; b=KyRW4grEucTcOCdWfkKjS8xW48SHSvjdfQVptQWGlR50QZB80d/BHyVCTIY8nRy6N7 78EYiisYJXBm69Ltsr4Hkm6NKEGrPvIv5HH54J0gVKD/X3xBRydynPPltA5ZUTLlzMVQ gcqA7pPfXetb9SUHFau7sbl/sHzJYmrjLLxolWKhQXtxVtSuBCdmgTzg6ZYhGVyT9umz PwFph/4lDvWkXK+7Nam+AVGzzUhu7YdjF62fCsm1D+gvW0xdWycKajv74cq8LDtC3nJb BRW0myR815WB8kTXWUXG2mFtgYaH7QCVBE+o0lCIwKqC4FTW9T4saVxT2G+8bFylRtTf dn1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=ZA1944vkJjFmw5EEyS3vnJ3J7Ezr6Qz3fqRnPGmLQ/c=; b=S1Zh2o+t2O63Z6wQitsGq5MByMGC9feWIjbOqdMJRNJjko/g3K1uUBonzHsV7FnCpW IQRK8E81UDM6LgsKFklzUtTxrIq8TuZ4LDiOvJsiKoABUnuYdZBSN3R9/Qd6VrfS1bU+ scDGWvMsIDNCzCE0z62WRPna3RkG+maeitEDk8zPGcQkQVEWk+i6bFRR/Rv8Krh/QoaP mkvBJzPkfzZeXTIKQsaAaBLrTXIOxZbDrhWA2dE0nDpzLoIdF8yvB/HaugazCH5p2bgG FJftIGaJEC5FS4Qw8BdPhyfWKEfSIDbfX1PA8f9eN1aMgmOeQzhjKudoArVnMQFd5LYm s0Fw== X-Gm-Message-State: AKS2vOyiXURZdAbjEVifuxTn33SwjAhMLtlpKLVacXbuWHEPMcyG7mpU 76g3jUyV44dA5mcU X-Received: by 10.200.45.206 with SMTP id q14mr21051589qta.177.1497275841370; Mon, 12 Jun 2017 06:57:21 -0700 (PDT) Received: from [10.96.43.74] (neustar-sthide-nat1.neustar.biz. [156.154.81.54]) by smtp.gmail.com with ESMTPSA id 101sm6989498qkx.28.2017.06.12.06.57.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Jun 2017 06:57:20 -0700 (PDT) From: Brian Rosen Message-Id: <436CA7C1-7358-4673-9D0D-5DB64E6150CA@brianrosen.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_55791DFE-A00B-48A1-8332-7A637D9ACCA0" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 12 Jun 2017 09:57:19 -0400 In-Reply-To: Cc: Randall Gellens , slim@ietf.org, Natasha Rooney , slim-chairs@ietf.org, Alexey Melnikov To: Nik Tomkinson References: <149694113325.15087.16643503872415274483.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Slim] slim - New Meeting Session Request for IETF 99 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, 12 Jun 2017 13:57:24 -0000 --Apple-Mail=_55791DFE-A00B-48A1-8332-7A637D9ACCA0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I will be there, and can help with the negotiating draft. Brian > On Jun 12, 2017, at 5:05 AM, Nik Tomkinson = wrote: >=20 > Hi All, >=20 > I can't be there in person either, but I don't think there is much to = discuss on my draft. >=20 > Nik. >=20 > On 9 June 2017 at 23:12, Randall Gellens > wrote: > I will not be able to be in Prague for IETF 99. (I'll be in the air = Monday and Tuesday.) >=20 >=20 > --=20 > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself = only > -------------- Randomly selected tag: --------------- > The Macintosh uses an experimental pointing device called a "mouse." > There is no evidence that people want to use these things. > --John C. Dvorak (well-known computer pundit), Feb 1984 >=20 >=20 > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim = >=20 >=20 >=20 > --=20 > ----------------------------------------------------------------- > Multiple Language Content Type Internet Draft: > https://datatracker.ietf.org/doc/draft-ietf-slim-multilangcontent/ = > ----------------------------------------------------------------- >=20 > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim --Apple-Mail=_55791DFE-A00B-48A1-8332-7A637D9ACCA0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I will be there, and can help with the negotiating draft.

Brian

On Jun 12, 2017, at 5:05 AM, Nik Tomkinson <rfc.nik.tomkinson@gmail.com> wrote:

Hi All,

I = can't be there in person either, but I don't think there is much to = discuss on my draft.

Nik.

On 9 June 2017 at 23:12, Randall Gellens <rg+ietf@randy.pensive.org> = wrote:
I will not be able = to be in Prague for IETF 99.  (I'll be in the air Monday and = Tuesday.)


--
Randall Gellens
Opinions are personal;    facts are suspect;    I = speak for myself only
-------------- Randomly selected tag: ---------------
The Macintosh uses an experimental pointing device called a "mouse."
There is no evidence that people want to use these things.
   --John C. Dvorak (well-known computer pundit), Feb = 1984


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



-- 
---------------------------------------------------------------=
--
Multiple Language Content Type Internet =
Draft:
https://datatracker.ietf.org/doc/draft-ietf-slim-multilangconte=
nt/
---------------------------------------------------------------=
--

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

= --Apple-Mail=_55791DFE-A00B-48A1-8332-7A637D9ACCA0-- From nobody Mon Jun 12 14:43:47 2017 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 9EE4512EB64; Mon, 12 Jun 2017 14:43:39 -0700 (PDT) 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.54.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149730381963.10281.16993382316277401445@ietfa.amsl.com> Date: Mon, 12 Jun 2017 14:43:39 -0700 Archived-At: Subject: [Slim] I-D Action: draft-ietf-slim-multilangcontent-08.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: Mon, 12 Jun 2017 21:43:40 -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 of the IETF. Title : Multiple Language Content Type Authors : Nik Tomkinson Nathaniel Borenstein Filename : draft-ietf-slim-multilangcontent-08.txt Pages : 19 Date : 2017-06-12 Abstract: This document defines an addition to the Multipurpose Internet Mail Extensions (MIME) standard to make it possible to send one message that contains multiple language versions of the same information. The translations would be identified by a language tag and selected by the email client based on a user's language settings. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-slim-multilangcontent/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-slim-multilangcontent-08 https://datatracker.ietf.org/doc/html/draft-ietf-slim-multilangcontent-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-slim-multilangcontent-08 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 Mon Jun 12 22:51:18 2017 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 395EA1286B2 for ; Mon, 12 Jun 2017 22:51:17 -0700 (PDT) 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, 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 NEJWL67ILwJb for ; Mon, 12 Jun 2017 22:51:15 -0700 (PDT) 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 08831127977 for ; Mon, 12 Jun 2017 22:51:14 -0700 (PDT) X-Halon-ID: 4d71e5e9-4ffc-11e7-b75a-005056917a89 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [77.53.230.196]) by bin-vsp-out-01.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Tue, 13 Jun 2017 07:51:10 +0200 (CEST) To: "slim@ietf.org" , Randall Gellens From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <1a17f909-8980-0b47-0170-199be1cdc8cc@omnitor.se> Date: Tue, 13 Jun 2017 07:51:08 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [Slim] Multi-lines and offer/answer questions on 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: Tue, 13 Jun 2017 05:51:17 -0000 A couple of questions on draft-ietf-slim-negotiating-human-language. 1. How would inclusion of more than one hlang attribute of the same kind in a media description be handled. a) should it be seen as an addition, so the language tags are collected and any asterisk governs. b) should it replace earlier attributes of same kind in same media description c) should it be "illegal" I have a slight preference for a). Some applications might find it easier to insert a number of complete attributes. 2. How would inclusion of hlang attributes in an answer be handled if no one was included in the offer. This assumes that the offering party supports hlang attributes bu did not bother to add any. a) The offering party would act on the attributes in the answer as usual. (A re-Invite would be needed to get full negotiation in place if that was desired.) b) The offering party would ignore it. c) It would be seen as "illegal" I think a) is the natural choice and is also how the current draft can be interpreted. In 5.2, there is a paragraph starting "In an answer..", not exactly requiring that attributes were included in an offer (but anyway talking about what was in the offer) I suggest that some wording is included for clarification of these cases. /Gunnar -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 From nobody Tue Jun 13 06:46:33 2017 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 EA4B112EABC for ; Tue, 13 Jun 2017 06:46:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.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 qqbUpUg5WudE for ; Tue, 13 Jun 2017 06:46:29 -0700 (PDT) Received: from mail-qt0-x242.google.com (mail-qt0-x242.google.com [IPv6:2607:f8b0:400d:c0d::242]) (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 A8E4E126CBF for ; Tue, 13 Jun 2017 06:46:29 -0700 (PDT) Received: by mail-qt0-x242.google.com with SMTP id o21so34344610qtb.1 for ; Tue, 13 Jun 2017 06:46:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=U+KeRvyb1gC7fpCM92DIiy9nLjXgk6o4+ms13x0mftU=; b=eWKtxMnWVdmS+0FP/rNk7dQc3az0HmtELqVQeZ6VhXC6u1AhKPZgB1Id52hL0qd/Hy eL2DUTsWHXQOYTJusDMMTjsWTX9c0Hr6AoS5IBuVrsH7jJZV+gJ8VfmqzvlABxK9o9qV o2OKCTBrHVg3ygrVLqitPNyoBhHIQoJbnND9JpT4upjzj7F5/ToqId9BJIVp6krPwqgd sduofmzu49dv1q2BbmCtNhbcLTm9YCkRFabVnzJooF4p5z6xq10lpgAR7cdz8xWdcNFe qSq9QtVIK9rZuSLF0LPZ882DdXByXqZL0hWENZeqiinUo5L6/jlCzPtjGeUNt9LlEEq5 4nRw== 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=U+KeRvyb1gC7fpCM92DIiy9nLjXgk6o4+ms13x0mftU=; b=ioR+IcGl62ABcuLoxbfGtcjwFNZBFnImGYyh+k9qRqlD3QNlWawn0r5Is8HVfevwAF 4ysyJuKM9On9pjcQAXWYA+4ocJHEmZcbfd6Y/Vl01/Nsz6Orl644d19TdSO97tLvyHII 6xiuyWc0GWkAcmtfNsvhCTHW+fR1HcuZsBYkD95SW2Wc6IfPWhaULv3j92QXKNGXv149 inCwlsrpFY8Ldz2b7MBcJ4RIbrdniAosg9J0NGPHAHOJTHWlhwyTVO2pbYAVt5Bg04rH cfXIRT0Outx1TrFISyD8eGXYVxU+WTrrng7fwG6fvVuxZTkf072qgl54U55u1q5m0Meo vxAQ== X-Gm-Message-State: AKS2vOxAILn4Gnt3ZmZDwAyn6h5cU7aOt/vRI1Cx1LKR7K5mfC17yxF5 kQBU2NEslDjbSwfJimcUBg== X-Received: by 10.55.101.202 with SMTP id z193mr6969387qkb.28.1497361588863; Tue, 13 Jun 2017 06:46:28 -0700 (PDT) Received: from [10.96.43.74] (neustar-sthide-nat1.neustar.biz. [156.154.81.54]) by smtp.gmail.com with ESMTPSA id t15sm8968057qke.50.2017.06.13.06.46.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Jun 2017 06:46:28 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Brian Rosen In-Reply-To: <1a17f909-8980-0b47-0170-199be1cdc8cc@omnitor.se> Date: Tue, 13 Jun 2017 09:46:25 -0400 Cc: "slim@ietf.org" , Randall Gellens Content-Transfer-Encoding: quoted-printable Message-Id: References: <1a17f909-8980-0b47-0170-199be1cdc8cc@omnitor.se> To: =?utf-8?Q?Gunnar_Hellstr=C3=B6m?= X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Slim] Multi-lines and offer/answer questions on 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: Tue, 13 Jun 2017 13:46:32 -0000 This has to have occurred in the SDP parameters. We should do what is = usually done for a similar circumstance. > On Jun 13, 2017, at 1:51 AM, Gunnar Hellstr=C3=B6m = wrote: >=20 > A couple of questions on draft-ietf-slim-negotiating-human-language. >=20 > 1. How would inclusion of more than one hlang attribute of the same = kind in a media description be handled. >=20 > a) should it be seen as an addition, so the language tags are = collected and any asterisk governs. >=20 > b) should it replace earlier attributes of same kind in same media = description >=20 > c) should it be "illegal" >=20 > I have a slight preference for a). Some applications might find it = easier to insert a number of complete attributes. >=20 >=20 > 2. How would inclusion of hlang attributes in an answer be handled if = no one was included in the offer. >=20 > This assumes that the offering party supports hlang attributes bu did = not bother to add any. >=20 > a) The offering party would act on the attributes in the answer as = usual. (A re-Invite would be needed to get full negotiation in place if = that was desired.) >=20 > b) The offering party would ignore it. >=20 > c) It would be seen as "illegal" >=20 > I think a) is the natural choice and is also how the current draft can = be interpreted. In 5.2, there is a paragraph starting "In an answer..", = not exactly requiring that attributes were included in an offer (but = anyway talking about what was in the offer) >=20 >=20 > I suggest that some wording is included for clarification of these = cases. >=20 >=20 > /Gunnar >=20 >=20 > --=20 > ----------------------------------------- > Gunnar Hellstr=C3=B6m > Omnitor > gunnar.hellstrom@omnitor.se > +46 708 204 288 >=20 > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim From nobody Tue Jun 13 09:04:17 2017 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 9A8001318E9 for ; Tue, 13 Jun 2017 09:04:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 pZqMjn7ITOeK for ; Tue, 13 Jun 2017 09:04:09 -0700 (PDT) Received: from alum-mailsec-scanner-5.mit.edu (alum-mailsec-scanner-5.mit.edu [18.7.68.17]) by ietfa.amsl.com (Postfix) with ESMTP id 75D93131889 for ; Tue, 13 Jun 2017 08:53:50 -0700 (PDT) X-AuditID: 12074411-f47ff70000007ac9-b7-59400a8bbd20 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id C5.1A.31433.B8A00495; Tue, 13 Jun 2017 11:53:49 -0400 (EDT) Received: from [192.168.1.110] (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id v5DFrkOW002840 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 13 Jun 2017 11:53:47 -0400 To: slim@ietf.org References: <1a17f909-8980-0b47-0170-199be1cdc8cc@omnitor.se> From: Paul Kyzivat Message-ID: <356fcae3-ffbd-d86f-9cf4-9e4dba36fc58@alum.mit.edu> Date: Tue, 13 Jun 2017 11:53:46 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <1a17f909-8980-0b47-0170-199be1cdc8cc@omnitor.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHIsWRmVeSWpSXmKPExsUixO6iqNvL5RBpMO2UicXMD51sDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKOLNhJnPBev6KL1ckGxifc3cxcnJICJhItCyeyd7FyMUhJLCD SWLpnmVsEM5LJon1vx+ygFQJC2RJ3Pj6nRXEFhEQlPjeM4MJxBYSsJV4/3EVO4jNJqAlMefQ f7B6XgF7ifePZrOB2CwCqhIrO9aA2aICaRJ/Lt1ghqgRlDg58wlYPaeAncSV1mawGmagmXfm 7maGsMUlbj2ZzwRhy0s0b53NPIGRfxaS9llIWmYhaZmFpGUBI8sqRrnEnNJc3dzEzJzi1GTd 4uTEvLzUIl1TvdzMEr3UlNJNjJCgFNzBOOOk3CFGAQ5GJR7eB+/tI4VYE8uKK3MPMUpyMCmJ 8m65YhMpxJeUn1KZkVicEV9UmpNafIhRgoNZSYTXit0hUog3JbGyKrUoHyYlzcGiJM7Lt0Td T0ggPbEkNTs1tSC1CCYrw8GhJMHbwwnUKFiUmp5akZaZU4KQZuLgBBnOAzT8PgvI8OKCxNzi zHSI/ClGXY5fM7d+YRJiycvPS5US573GAVQkAFKUUZoHNweWTF4xigO9Jcx7BGQdDzARwU16 BbSECWjJdZDveItLEhFSUg2Mhp+l7ixatob97RRX4ZNOBxvfFlw8JCFxKn3316KqNNvJ6hyn bYO2TFXU78/LKkne/NPKzfTUmoBpH11zflsq6uW+4Xt0Psvlyv7IT9OUcuLXKb1YPHPS/ugv bDrJvRXSHZJrxdm5uUOUG2q+n9a8VJDL/ejXzoU7cwIbj+e21Ac5/HxQ9Oq5EktxRqKhFnNR cSIAHNlKKAEDAAA= Archived-At: Subject: Re: [Slim] Multi-lines and offer/answer questions on 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: Tue, 13 Jun 2017 16:04:15 -0000 On 6/13/17 1:51 AM, Gunnar Hellström wrote: > A couple of questions on draft-ietf-slim-negotiating-human-language. > > 1. How would inclusion of more than one hlang attribute of the same kind > in a media description be handled. > > a) should it be seen as an addition, so the language tags are collected > and any asterisk governs. > > b) should it replace earlier attributes of same kind in same media > description > > c) should it be "illegal" > > I have a slight preference for a). Some applications might find it > easier to insert a number of complete attributes. I think I also slightly prefer (a). I would also be ok with (c). As things stand I think any plausible usage will be able to fit all on one line and still have something that still works ok in published examples where line length can be limited. But if later extended with parameters there then might be an advantage to breaking things out for examples. > 2. How would inclusion of hlang attributes in an answer be handled if no > one was included in the offer. > > This assumes that the offering party supports hlang attributes bu did > not bother to add any. > > a) The offering party would act on the attributes in the answer as > usual. (A re-Invite would be needed to get full negotiation in place if > that was desired.) > > b) The offering party would ignore it. > > c) It would be seen as "illegal" > > I think a) is the natural choice and is also how the current draft can > be interpreted. In 5.2, there is a paragraph starting "In an answer..", > not exactly requiring that attributes were included in an offer (but > anyway talking about what was in the offer) I agree that (a) is fine. As long as it is considered a legal answer then how it is used is really out of scope anyway. Thanks, Paul > I suggest that some wording is included for clarification of these cases. > > > /Gunnar > > From nobody Tue Jun 13 10:16:39 2017 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 8504E13194B for ; Tue, 13 Jun 2017 10:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 uH-0gUBQyyfY for ; Tue, 13 Jun 2017 10:16:35 -0700 (PDT) Received: from bin-vsp-out-01.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 55162131941 for ; Tue, 13 Jun 2017 10:16:35 -0700 (PDT) X-Halon-ID: 0a1d0eab-505c-11e7-b75a-005056917a89 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [77.53.230.196]) by bin-vsp-out-01.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Tue, 13 Jun 2017 19:16:28 +0200 (CEST) To: Brian Rosen References: <1a17f909-8980-0b47-0170-199be1cdc8cc@omnitor.se> Cc: "slim@ietf.org" , Randall Gellens From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <2682aacf-35a5-a625-0623-1a5fd8ef6482@omnitor.se> Date: Tue, 13 Jun 2017 19:16:27 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------44E81405DDC4451E2212AF11" Archived-At: Subject: Re: [Slim] Multi-lines and offer/answer questions on 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: Tue, 13 Jun 2017 17:16:39 -0000 This is a multi-part message in MIME format. --------------44E81405DDC4451E2212AF11 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Den 2017-06-13 kl. 15:46, skrev Brian Rosen: > This has to have occurred in the SDP parameters. We should do what is usually done for a similar circumstance. You are right. For both cases we can find good advice in previous work. The Lang attribute is additive ( also c= and t= ) For Lang, there is the following description: " Multiple lang attributes can be provided either at session or media level if the session or media has capabilities in more than one language, in which case the order of the attributes indicates the order of preference of the various languages in the session or media, from most preferred to least preferred. " Most attribute specifications do not tell what happens if they occur multiple times in the same media description. I suggest that we include wording inspired by 'Lang' e.g. --------------------text proposal------------------------ Multiple hlang attributes for the same media and direction can be provided in which case the specified languages in these attributes are added to specify the total language capability per media and direction. -------------------------------------------------------- > >> On Jun 13, 2017, at 1:51 AM, Gunnar Hellström wrote: >> >> A couple of questions on draft-ietf-slim-negotiating-human-language. >> >> 1. How would inclusion of more than one hlang attribute of the same kind in a media description be handled. >> >> a) should it be seen as an addition, so the language tags are collected and any asterisk governs. >> >> b) should it replace earlier attributes of same kind in same media description >> >> c) should it be "illegal" >> >> I have a slight preference for a). Some applications might find it easier to insert a number of complete attributes. >> >> >> 2. How would inclusion of hlang attributes in an answer be handled if no one was included in the offer. The Content attribute specified in RFC 4796 that we have a lot in common with in the way it influences the session, , has in chapter 6 the following paragraph: " The 'content' attribute describes the data that the application generating the SDP session description intends to send over a particular media stream. The 'content' values for both directions of a media stream do not need to be the same.*Therefore, an SDP answer MAY contain 'content' attributes even if none were present in the offer. * Similarly, the answer MAY contain no 'content' attributes even if they were present in the offer. Furthermore, the values of 'content' attributes do not need to match in an offer and an answer. " Following that pattern I suggest that we add: ---------proposed text--------------------------- An SDP answer MAY contain 'hlang-' attributes even if none were present in the offer. ---------end of proposal-------------------------- Other SDP attributes, such as the group attribute specified in RFC 5888, have more strict requirements that say that they MUST NOT appear in an answer if they do not appear in the offer. But we do not have the same strict protocol requirements on us. >> >> This assumes that the offering party supports hlang attributes bu did not bother to add any. >> >> a) The offering party would act on the attributes in the answer as usual. (A re-Invite would be needed to get full negotiation in place if that was desired.) >> >> b) The offering party would ignore it. >> >> c) It would be seen as "illegal" >> >> I think a) is the natural choice and is also how the current draft can be interpreted. In 5.2, there is a paragraph starting "In an answer..", not exactly requiring that attributes were included in an offer (but anyway talking about what was in the offer) >> >> >> I suggest that some wording is included for clarification of these cases. >> >> >> /Gunnar >> >> >> -- >> ----------------------------------------- >> 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 --------------44E81405DDC4451E2212AF11 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Den 2017-06-13 kl. 15:46, skrev Brian Rosen:
This has to have occurred in the SDP parameters.  We should do what is usually done for a similar circumstance.
You are right.   For both cases we can find good advice in previous work.

The Lang attribute is additive   ( also c= and t= )
For Lang, there is the following description:
"
   Multiple lang attributes can be provided either at session or media
   level if the session or media has capabilities in more than one
   language, in which case the order of the attributes indicates the
   order of preference of the various languages in the session or media,
   from most preferred to least preferred.
"

Most attribute specifications do not tell what happens if they occur multiple times in the same media description.

I suggest that we include wording inspired by 'Lang'

e.g.

--------------------text proposal------------------------
   Multiple hlang attributes for the same media and direction can be provided in which case the specified 
languages in these attributes are added to specify the total language capability per media and direction.
--------------------------------------------------------



On Jun 13, 2017, at 1:51 AM, Gunnar Hellström <gunnar.hellstrom@omnitor.se> wrote:

A couple of questions on draft-ietf-slim-negotiating-human-language.

1. How would inclusion of more than one hlang attribute of the same kind in a media description be handled.

a) should it be seen as an addition, so the language tags are collected and any asterisk governs.

b) should it replace earlier attributes of same kind in same media description

c) should it be "illegal"

I have a slight preference for a). Some applications might find it easier to insert a number of complete attributes.


2. How would inclusion of hlang attributes in an answer be handled if no one was included in the offer.
The Content attribute specified in RFC 4796 that we have a lot in common with in the way it influences the session, , has in chapter 6 the following paragraph:
"
   The 'content' attribute describes the data that the application
   generating the SDP session description intends to send over a
   particular media stream.  The 'content' values for both directions of
   a media stream do not need to be the same.  Therefore, an SDP answer
   MAY contain 'content' attributes even if none were present in the
   offer.  Similarly, the answer MAY contain no 'content' attributes
   even if they were present in the offer.  Furthermore, the values of
   'content' attributes do not need to match in an offer and an answer.
"

Following that pattern I suggest that we add:

---------proposed text---------------------------

An SDP answer MAY contain 'hlang-' attributes even if none were present in the offer.
---------end of proposal--------------------------

Other SDP attributes, such as the group attribute specified in RFC 5888, have more strict requirements
that say that they MUST NOT appear in an answer if they do not appear 
in the offer. But we do not have the same strict protocol requirements on us.





This assumes that the offering party supports hlang attributes bu did not bother to add any.

a) The offering party would act on the attributes in the answer as usual. (A re-Invite would be needed to get full negotiation in place if that was desired.)

b) The offering party would ignore it.

c) It would be seen as "illegal"

I think a) is the natural choice and is also how the current draft can be interpreted. In 5.2, there is a paragraph starting "In an answer..", not exactly requiring that attributes were included in an offer (but anyway talking about what was in the offer)


I suggest that some wording is included for clarification of these cases.


/Gunnar


-- 
-----------------------------------------
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

  


--------------44E81405DDC4451E2212AF11--


From nobody Tue Jun 13 11:53:31 2017
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 D012F129409 for ; Tue, 13 Jun 2017 11:53:30 -0700 (PDT)
X-Quarantine-ID: 
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 T7_cxtSnQ4C4 for ; Tue, 13 Jun 2017 11:53:29 -0700 (PDT)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 7C71B128B44 for ; Tue, 13 Jun 2017 11:53:29 -0700 (PDT)
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Tue, 13 Jun 2017 11:56:11 -0700
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <2682aacf-35a5-a625-0623-1a5fd8ef6482@omnitor.se>
References: <1a17f909-8980-0b47-0170-199be1cdc8cc@omnitor.se>  <2682aacf-35a5-a625-0623-1a5fd8ef6482@omnitor.se>
X-Mailer: Eudora for Mac OS X
Date: Tue, 13 Jun 2017 11:53:26 -0700
To: Gunnar =?iso-8859-1?Q?Hellstr=F6m?=  , Brian Rosen 
From: Randall Gellens 
Cc: "slim@ietf.org" , Randall Gellens 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Archived-At: 
Subject: Re: [Slim] Multi-lines and offer/answer questions on 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: Tue, 13 Jun 2017 18:53:31 -0000

I'm not sure we should model anything on the 'lang' attribute, since 
as discussed it is not used in offer/answer.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
The only normal people are the ones you don't know very well.
    --Joe Ancis


From nobody Tue Jun 13 13:34:53 2017
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 75547129A8D for ; Tue, 13 Jun 2017 13:34:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 06Z6SkK7MGFY for ; Tue, 13 Jun 2017 13:34:49 -0700 (PDT)
Received: from bin-vsp-out-01.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 981E6127B57 for ; Tue, 13 Jun 2017 13:34:49 -0700 (PDT)
X-Halon-ID: bc05acfe-5077-11e7-b75a-005056917a89
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [77.53.230.196]) by bin-vsp-out-01.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Tue, 13 Jun 2017 22:34:44 +0200 (CEST)
To: slim@ietf.org
References: <1a17f909-8980-0b47-0170-199be1cdc8cc@omnitor.se>  <2682aacf-35a5-a625-0623-1a5fd8ef6482@omnitor.se> 
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: <1a054fe4-d092-7d3e-a4ca-67fbaefcbe41@omnitor.se>
Date: Tue, 13 Jun 2017 22:34:42 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------3BC0868314C50CC67DA29345"
Archived-At: 
Subject: Re: [Slim] Multi-lines and offer/answer questions on 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: Tue, 13 Jun 2017 20:34:51 -0000

This is a multi-part message in MIME format.
--------------3BC0868314C50CC67DA29345
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

Den 2017-06-13 kl. 20:53, skrev Randall Gellens:
> I'm not sure we should model anything on the 'lang' attribute, since 
> as discussed it is not used in offer/answer.
I don't think that it matters.
Our use of the offer/answer model is very flexible and without any real 
requirements. We may answer with languages that are not mentioned in the 
offer etc.
So it matches Lang quite closely even if you think that Lang is only 
declarative.

Another example of additive attribute values is the t=
"

t= 

    The "t=" lines specify the start and stop times for a session.
    Multiple "t=" lines MAY be used if a session is active at multiple
    irregularly spaced times; each additional "t=" line specifies an
    additional period of time for which the session will be active. "

Most other attributes are of a form where it is not of interest with more than one line.
And then it is not mentioned what happens if more than one is specified.


Conclusion: additive use exists, and we can use it.
But if you feel strong about not being specific about it, you can do as it is done
  for most other attributes and not mention the use in multiple lines.

/Gunnar

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


--------------3BC0868314C50CC67DA29345
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    Den 2017-06-13 kl. 20:53, skrev Randall Gellens:

    
I'm not sure we should model anything on the 'lang'
      attribute, since as discussed it is not used in offer/answer.
      

    

    I don't think that it matters. 

    Our use of the offer/answer model is very flexible and without any
    real requirements. We may answer with languages that are not
    mentioned in the offer etc. 

    So it matches Lang quite closely even if you think that Lang is only
    declarative.  

    

    Another example of additive attribute values is the t=

    "
    
t=<start-time> <stop-time>

   The "t=" lines specify the start and stop times for a session.
   Multiple "t=" lines MAY be used if a session is active at multiple
   irregularly spaced times; each additional "t=" line specifies an
   additional period of time for which the session will be active. "

Most other attributes are of a form where it is not of interest with more than one line. 
And then it is not mentioned what happens if more than one is specified.


Conclusion: additive use exists, and we can use it. 
But if you feel strong about not being specific about it, you can do as it is done
 for most other attributes and not mention the use in multiple lines.

/Gunnar


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

  


--------------3BC0868314C50CC67DA29345--


From filip.asplund@omnitor.se  Mon Jun 19 04:44:19 2017
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 9C47112EAFE for ; Mon, 19 Jun 2017 04:44:19 -0700 (PDT)
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, 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 lJbTDWAORw9L for ; Mon, 19 Jun 2017 04:44:17 -0700 (PDT)
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 9C16F12EB07 for ; Mon, 19 Jun 2017 04:43:10 -0700 (PDT)
X-Halon-ID: 764ce55b-54e4-11e7-bca7-0050569116f7
Authorized-sender: filip.asplund@omnitor.se
Received: from [192.168.0.160] (unknown [217.13.240.136]) by bin-vsp-out-03.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Mon, 19 Jun 2017 13:43:07 +0200 (CEST)
To: slim@ietf.org
From: Filip Asplund 
Message-ID: 
Date: Mon, 19 Jun 2017 13:43:06 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: [Slim] Modality preference
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 Jun 2017 11:55:47 -0000

In development of emergency services the need of modality preference has 
been identified.

It seems to me that the functions specified in 
draft-hellstrom-language-grouping is what we need for emergency services.

-- 
Best regards

Filip Asplund
Developer
filip.asplund@omnitor.se
Omnitor AB


From nobody Mon Jun 19 06:31:55 2017
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 7C029129534 for ; Mon, 19 Jun 2017 06:31:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level: 
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.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 ZFox-pPhtt8b for ; Mon, 19 Jun 2017 06:31:52 -0700 (PDT)
Received: from mail-pf0-x243.google.com (mail-pf0-x243.google.com [IPv6:2607:f8b0:400e:c00::243]) (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 23F1E131453 for ; Mon, 19 Jun 2017 06:31:52 -0700 (PDT)
Received: by mail-pf0-x243.google.com with SMTP id w12so16975792pfk.0 for ; Mon, 19 Jun 2017 06:31:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/U8o23s3oSu64Ebb32AffDfCZe8kFtD/dKdp52fGTOs=; b=rfsSNA0gIr4RELoV0WEbdWfp9SXmpHQr5h90tebHZDQK1DkvlmBAAYfaX1UfK4Ouq9 QZ2wZnQdBoi8AVDw1MHC3UwzVswEOugStVyw4hqHEWR2lQWwu0S0QLR/y0qoeNThss6t 4HKAGxmACGS6YByHYpkDVRIX7/9dXDXnpXF+lZ36HhGTRwJ2XltOzUHSo7a1GLTkndY3 ePHCr+ydzaelaX6ZBDRXSgnj/w7aqyEL9zoi3tWRCNPY16dEU0v1baQ1GNtZ5QICXsUZ Ys/PybcjoVov2FDBWeU6C3Gr6eLqMf/vsoN5lPnfRhqwQTK3eVbajH86bQDo5TKNqmkK Z3mA==
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=/U8o23s3oSu64Ebb32AffDfCZe8kFtD/dKdp52fGTOs=; b=PhHVVFrkDqCC+rB4ljeJy1TQ11KY3PVqFm4qr/oqSrXeNCqkP9h2BHid9DyCMr1wW6 hm4oj+LmdEOBcaLSTpHuq3NFUvbY8sq6YH5bQxXEB3W5tYT6gUd2lqWfSQtjWmHwzKSz 8G4KugVAt75NUmdztJsffQuWSdrQtijNPZNdyHTnc0Vj9VTsnG2SKnT96lJ9wFVysghZ 3mk610mC3lUR2Ria0dnmdyV9C2ZsAp85q9P5K+vjCZpHeUmZAaUz1HLMlPRcfNfeTFoZ DEtZvsAm91dG5FZxj9cqCm2imAN2DmBLD0ULG48712md0sHnlIDMJpXhCm0pd6oqGhbt mIZw==
X-Gm-Message-State: AKS2vOyNS9DUv7+Coanum4hzH4tUHnwFykrNhC25t1zIubVmg81Lh+dx ue57SUxtIG8Kx95sNIIwCA==
X-Received: by 10.84.140.3 with SMTP id 3mr29910105pls.220.1497879111774; Mon, 19 Jun 2017 06:31:51 -0700 (PDT)
Received: from [10.96.43.74] (neustar-sthide-nat1.neustar.biz. [156.154.81.54]) by smtp.gmail.com with ESMTPSA id n9sm7068532pgf.50.2017.06.19.06.31.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Jun 2017 06:31:51 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Brian Rosen 
In-Reply-To: 
Date: Mon, 19 Jun 2017 09:31:48 -0400
Cc: slim@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <1F3F53F9-35E7-46A9-B083-24BECC6C5B82@brianrosen.net>
References: 
To: Filip Asplund 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [Slim] Modality preference
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 Jun 2017 13:31:54 -0000

We=E2=80=99ve been working on supporting emergency services with =
multiple media for some time in the NENA Next Generation 9-1-1 project.

At least in the U.S., all media offered should be accepted.  The =
language preference will be negotiated, and based on the result, an =
interpreting service may be bridged into the call.
As such, a modality preference is not seen as valuable, and in fact, =
could be considered harmful, as the call taker should be trained to =
provide an initial answer in all media negotiated and react to the =
user=E2=80=99s actions thereafter.  An important characteristic of =
emergency services when viewed from the lens of the slim work is that =
the mechanisms have to work for the small percentage of cases where the =
normal mechanisms fail.  In this case, it would be use of a device with =
language and media preferences labeled by a user who isn=E2=80=99t the =
usual user of the device when an emergency call is placed.  You do NOT =
want to assume that the labeled preferences are actually the real =
preferences.  You bias your responses by the preferences, but you have =
to allow for variation when the call is actually answered.  So, =
answering in all offered media is something we would do, regardless of =
what the highest media preference was.=20

Another reason why media preference is not really wanted is that =
emergency services can use other media even when the user doesn=E2=80=99t =
prefer to use them.  An audio feed for a deaf caller can be helpful to =
identify what is happening around the caller.  A video feed for a blind =
caller (if the device really made the offer) could similarly be useful.

So, I think this is not a useful capability for emergency services and =
if it was in the offer, I=E2=80=99d tend to want to ignore it and accept =
all media, with an initial greeting in the preferred language.

Brian

> On Jun 19, 2017, at 7:43 AM, Filip Asplund  =
wrote:
>=20
> In development of emergency services the need of modality preference =
has been identified.
>=20
> It seems to me that the functions specified in =
draft-hellstrom-language-grouping is what we need for emergency =
services.
>=20
> --=20
> Best regards
>=20
> Filip Asplund
> Developer
> filip.asplund@omnitor.se
> Omnitor AB
>=20
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim


From nobody Mon Jun 19 12:54:25 2017
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 563F21317DC for ; Mon, 19 Jun 2017 12:54:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 BeNnSNb1QwZ8 for ; Mon, 19 Jun 2017 12:54:20 -0700 (PDT)
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 7C469127B52 for ; Mon, 19 Jun 2017 12:54:19 -0700 (PDT)
X-Halon-ID: 11c5f806-5529-11e7-ad4a-0050569116f7
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [77.53.230.196]) by bin-vsp-out-03.atm.binero.net (Halon) with ESMTPSA id 11c5f806-5529-11e7-ad4a-0050569116f7; Mon, 19 Jun 2017 21:54:15 +0200 (CEST)
To: Brian Rosen , Filip Asplund 
References:  <1F3F53F9-35E7-46A9-B083-24BECC6C5B82@brianrosen.net>
Cc: slim@ietf.org
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: 
Date: Mon, 19 Jun 2017 21:54:11 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <1F3F53F9-35E7-46A9-B083-24BECC6C5B82@brianrosen.net>
Content-Type: multipart/alternative; boundary="------------0811FB240BDEF4F1569D144A"
Archived-At: 
Subject: Re: [Slim] Modality preference
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 Jun 2017 19:54:23 -0000

This is a multi-part message in MIME format.
--------------0811FB240BDEF4F1569D144A
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Brian,

You are right, that neither the hlang negotiation, nor the language 
grouping negotiation should influence decisions to enable a media stream 
or not.

The draft-hellstrom-language-grouping specification says: "

The grouping semantics defined in this document are only informing
    about language contents disposition in media and SHOULD not be taken
    as reasons to enable or reject media streams.
"

So, let us avoid discussion on the influence on enabling media of the 
specified mechanisms.

Den 2017-06-19 kl. 15:31, skrev Brian Rosen:
> We’ve been working on supporting emergency services with multiple media for some time in the NENA Next Generation 9-1-1 project.
>
> At least in the U.S., all media offered should be accepted.  The language preference will be negotiated, and based on the result, an interpreting service may be bridged into the call.
> As such, a modality preference is not seen as valuable, and in fact, could be considered harmful, as the call taker should be trained to provide an initial answer in all media negotiated and react to the user’s actions thereafter.  An important characteristic of emergency services when viewed from the lens of the slim work is that the mechanisms have to work for the small percentage of cases where the normal mechanisms fail.  In this case, it would be use of a device with language and media preferences labeled by a user who isn’t the usual user of the device when an emergency call is placed.  You do NOT want to assume that the labeled preferences are actually the real preferences.  You bias your responses by the preferences, but you have to allow for variation when the call is actually answered.  So, answering in all offered media is something we would do, regardless of what the highest media preference was.
[GH]That sounds good as a theory, but may turn out to be equally harmful 
as you think that obeying modality
preference would be.
Answering in all modalities may cause an uncertainty of the caller for 
which modality to best continue the conversation.
And it can cause delays and resource waste if you want to answer with 
sign language in all calls indicating sign language competence. The 
indication of sign language competence can be for the case I have 
repeated many times: A hearing person competent in sign language but 
preferring spoken language. In order to not get everyday calls with deaf 
signing persons to invoke a video relay service, it is of value to 
specify sign laguage competence, but on a lower preference level that 
spoken language for this person.
Having that sign language competence indication cause a PSAP to answer 
with sign language will cause delays and resource usage if not the first 
sign language answer is only a recording.

If you had the opportunity to use modality preference I would think that 
you got better success rate and satisfied users if you first answered in 
the most preferred modality, and be prepared to retry with less favoured 
modalities a few seconds later in order to cater for the few cases with 
a borrowed phone.
>   
>
> Another reason why media preference is not really wanted is that emergency services can use other media even when the user doesn’t prefer to use them.  An audio feed for a deaf caller can be helpful to identify what is happening around the caller.  A video feed for a blind caller (if the device really made the offer) could similarly be useful.
[GH]This is not a reason to not want modality preference.
As said initially, we are not discussing negotiating the enabling of 
media. We are only specifying guidance for which language and modality 
to use initially in the call.
(we have a good parallell in RFC 4796, the SDP Content attribute, where 
it is said: "

'content' values are just informative at the offer/answer model [8 ] level." Maybe we should include a clear
  statement like that in the SLIM real-time drafts.

>
> So, I think this is not a useful capability for emergency services and if it was in the offer, I’d tend to want to ignore it and accept all media, with an initial greeting in the preferred language.
Even if that would be feasible for the emergency service case, you need 
to consider that the communicationn device needs also be useful in the 
everyday call situation. In that situation, the answering part will not 
normally have the capability to answer in three modalities in parallell. 
A modality preference indication is essential for the call to start 
smoothly with an answer in a modality and language that the caller is 
willing to receive, and a modality preference indication to the caller 
is essential for the caller to start using the most suitable modality.

So, please accept that there are good motivations for a modality 
preference indication. You promised me a review of a separate draft for 
this functionality.
As you may have seen, I first created two drafts for indications 
integrated with draft-ietf-slim-negotiating-human-language, and then an 
alternative more self-sustained, based on the SDP grouping framework. I 
would also appreciate your assessment of which alternative to prefer and 
proceed with. I prefer
draft-hellstrom-language-grouping; it is more consistent and has no 
known interop problems.

Regards
Gunnar
>
> Brian
>
>> On Jun 19, 2017, at 7:43 AM, Filip Asplund  wrote:
>>
>> In development of emergency services the need of modality preference has been identified.
>>
>> It seems to me that the functions specified in draft-hellstrom-language-grouping is what we need for emergency services.
>>
>> -- 
>> Best regards
>>
>> Filip Asplund
>> Developer
>> filip.asplund@omnitor.se
>> Omnitor AB
>>
>> _______________________________________________
>> SLIM mailing list
>> SLIM@ietf.org
>> https://www.ietf.org/mailman/listinfo/slim
> _______________________________________________
> 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


--------------0811FB240BDEF4F1569D144A
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Brian,

    
You are right, that neither the hlang negotiation, nor the
      language grouping negotiation should influence decisions to enable
      a media stream or not. 

    

    
The draft-hellstrom-language-grouping specification says: "

    

    
The grouping semantics defined in this document are only informing
   about language contents disposition in media and SHOULD not be taken
   as reasons to enable or reject media streams.
"


    So, let us avoid discussion on the influence on enabling media of
    the specified mechanisms. 

    

    
Den 2017-06-19 kl. 15:31, skrev Brian
      Rosen:

    

    

      
We’ve been working on supporting emergency services with multiple media for some time in the NENA Next Generation 9-1-1 project.

At least in the U.S., all media offered should be accepted.  The language preference will be negotiated, and based on the result, an interpreting service may be bridged into the call.
As such, a modality preference is not seen as valuable, and in fact, could be considered harmful, as the call taker should be trained to provide an initial answer in all media negotiated and react to the user’s actions thereafter.  An important characteristic of emergency services when viewed from the lens of the slim work is that the mechanisms have to work for the small percentage of cases where the normal mechanisms fail.  In this case, it would be use of a device with language and media preferences labeled by a user who isn’t the usual user of the device when an emergency call is placed.  You do NOT want to assume that the labeled preferences are actually the real preferences.  You bias your responses by the preferences, but you have to allow for variation when the call is actually answered.  So, answering in all offered media is something we would do, regardless of what the highest media preference was.

    

    [GH]That sounds good as a theory, but may turn out to be equally
    harmful as you think that obeying modality

    preference would be. 

    Answering in all modalities may cause an uncertainty of the caller
    for which modality to best continue the conversation. 

    And it can cause delays and resource waste if you want to answer
    with sign language in all calls indicating sign language competence.
    The indication of sign language competence can be for the case I
    have repeated many times: A hearing person competent in sign
    language but preferring spoken language. In order to not get
    everyday calls with deaf signing persons to invoke a video relay
    service, it is of value to specify sign laguage competence, but on a
    lower preference level that spoken language for this person.

    Having that sign language competence indication cause a PSAP to
    answer with sign language will cause delays and resource usage if
    not the first sign language answer is only a recording.

    

    If you had the opportunity to use modality preference I would think
    that you got better success rate and satisfied users if you first
    answered in the most preferred modality, and be prepared to retry
    with less favoured modalities a few seconds later in order to cater
    for the few cases with a borrowed phone.

    

      
 

Another reason why media preference is not really wanted is that emergency services can use other media even when the user doesn’t prefer to use them.  An audio feed for a deaf caller can be helpful to identify what is happening around the caller.  A video feed for a blind caller (if the device really made the offer) could similarly be useful.

    

    [GH]This is not a reason to not want modality preference.

    As said initially, we are not discussing negotiating the enabling of
    media. We are only specifying guidance for which language and
    modality to use initially in the call.

    (we have a good parallell in RFC 4796, the SDP Content attribute,
    where it is said: "

    
'content' values are just informative at the offer/answer model [8] level." Maybe we should include a clear
 statement like that in the SLIM real-time drafts.

    

      

So, I think this is not a useful capability for emergency services and if it was in the offer, I’d tend to want to ignore it and accept all media, with an initial greeting in the preferred language.

    

    Even if that would be feasible for the emergency service case, you
    need to consider that the communicationn device needs also be useful
    in the everyday call situation. In that situation, the answering
    part will not normally have the capability to answer in three
    modalities in parallell. A modality preference indication is
    essential for the call to start smoothly with an answer in a
    modality and language that the caller is willing to receive, and a
    modality preference indication to the caller is essential for the
    caller to start using the most suitable modality. 

    

    So, please accept that there are good motivations for a modality
    preference indication. You promised me a review of a separate draft
    for this functionality. 

    As you may have seen, I first created two drafts for indications
    integrated with draft-ietf-slim-negotiating-human-language, and then
    an alternative more self-sustained, based on the SDP grouping
    framework. I would also appreciate your assessment of which
    alternative to prefer and proceed with. I prefer 

    draft-hellstrom-language-grouping; it is more consistent and has no
    known interop problems.

    

    Regards

    Gunnar

    

      

Brian



      

        
On Jun 19, 2017, at 7:43 AM, Filip Asplund <filip.asplund@omnitor.se> wrote:

In development of emergency services the need of modality preference has been identified.

It seems to me that the functions specified in draft-hellstrom-language-grouping is what we need for emergency services.

-- 
Best regards

Filip Asplund
Developer
filip.asplund@omnitor.se
Omnitor AB

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


      

      
_______________________________________________
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

  


--------------0811FB240BDEF4F1569D144A--


From nobody Mon Jun 19 13:29:59 2017
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 86C41126C22 for ; Mon, 19 Jun 2017 13:29:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.588
X-Spam-Level: 
X-Spam-Status: No, score=-2.588 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_LOW=-0.7, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.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 4XsaVvwF1JS5 for ; Mon, 19 Jun 2017 13:29:42 -0700 (PDT)
Received: from mail-yw0-x241.google.com (mail-yw0-x241.google.com [IPv6:2607:f8b0:4002:c05::241]) (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 600FB1294FA for ; Mon, 19 Jun 2017 13:29:42 -0700 (PDT)
Received: by mail-yw0-x241.google.com with SMTP id w143so7082741yww.1 for ; Mon, 19 Jun 2017 13:29:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=P2x2GM1MADbVBZs19CnnE+2W7SwjJ5SWiOReCackA3Y=; b=DshGKGCyfFFe6PPWe1kmQoxbGkAdD9UWY1qgHXTNSwQ5J/ipk+dWWrcAz3aUWBxW2t 1W9E2l0h+NG8S08EU5XUbxH7bs9JLRKGCfzgetzoD00yY4j9wMoAo8JlwG8fCvtw6+Df T768XCvJEcYMjrENsmUIyatiEyF4MPT2Bxi2Y12QBEHD53RMo5IMwbcLyafNmPEsJmeT Pu3JcEz2J6iTmieMWHIBQT9SGzs9taGLJFEZYqbuyFNGkzdpCQNOXCbXZS7JZDDRVUQy aIzQJA/Xg+VA9vrbrNuWxO1iuaQw3iqOeX/uL2gGVdcrY1sBwJgzM/D6FuUUjaSH9BFG VkUA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=P2x2GM1MADbVBZs19CnnE+2W7SwjJ5SWiOReCackA3Y=; b=CGGHwdbFB+qCQXE2XX/8qfbb2YSNo67G7qR1JXiBdONeE6pE6wKAMpjBFU2bEGMpf1 iiGK2T6HisXRI6vncduw/nvxql4DHgF2CBd0wILTWun9+s+8mJDt6wriaoKY8Suh63XA 4S4l2ZTWp/MSXl1rvzCkTmDct5ztwopLyYVXr77flECcBfx1bZPpyNdUZ7o0pgZg5bwM Axu+paeWcG8PE02C0aimVOEnJ/ctMTkFzBGvcJ3BoCsVeUGAejA6cKOL7tP0ouh8KxOm pJwUqlXfaf+1SEGH61IgVquYtNHB9upDc0JUuihsqjsBOZfpS2rWrp5rZrxjmDevayOw Fx7w==
X-Gm-Message-State: AKS2vOwY48z533OkS21j/TyuvHVI4GncWrIpvsiF4xiJLWoe81bRHrFP FkBPONfmxh0mAeONePgUFA==
X-Received: by 10.129.120.142 with SMTP id t136mr19227983ywc.127.1497904181452;  Mon, 19 Jun 2017 13:29:41 -0700 (PDT)
Received: from [10.96.43.74] (neustar-sthide-nat1.neustar.biz. [156.154.81.54]) by smtp.gmail.com with ESMTPSA id e185sm4885384ywa.74.2017.06.19.13.29.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Jun 2017 13:29:40 -0700 (PDT)
From: Brian Rosen 
Message-Id: <19378F69-07AF-4790-9F98-8BD956E8755A@brianrosen.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_2B1A39C5-C4B1-467F-B044-EBE4B933AFF9"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Mon, 19 Jun 2017 16:29:38 -0400
In-Reply-To: 
Cc: Filip Asplund , slim@ietf.org
To: =?utf-8?Q?Gunnar_Hellstr=C3=B6m?= 
References:  <1F3F53F9-35E7-46A9-B083-24BECC6C5B82@brianrosen.net> 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [Slim] Modality preference
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 Jun 2017 20:29:46 -0000

--Apple-Mail=_2B1A39C5-C4B1-467F-B044-EBE4B933AFF9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On Jun 19, 2017, at 3:54 PM, Gunnar Hellstr=C3=B6m =
 wrote:
>=20
> Brian,
>=20
> You are right, that neither the hlang negotiation, nor the language =
grouping negotiation should influence decisions to enable a media stream =
or not.=20
> The draft-hellstrom-language-grouping specification says: "
> The grouping semantics defined in this document are only informing
>    about language contents disposition in media and SHOULD not be =
taken
>    as reasons to enable or reject media streams.
> "
> So, let us avoid discussion on the influence on enabling media of the =
specified mechanisms.=20
>=20
Okay, my mistake.

> Den 2017-06-19 kl. 15:31, skrev Brian Rosen:
>> We=E2=80=99ve been working on supporting emergency services with =
multiple media for some time in the NENA Next Generation 9-1-1 project.
>>=20
>> At least in the U.S., all media offered should be accepted.  The =
language preference will be negotiated, and based on the result, an =
interpreting service may be bridged into the call.
>> As such, a modality preference is not seen as valuable, and in fact, =
could be considered harmful, as the call taker should be trained to =
provide an initial answer in all media negotiated and react to the =
user=E2=80=99s actions thereafter.  An important characteristic of =
emergency services when viewed from the lens of the slim work is that =
the mechanisms have to work for the small percentage of cases where the =
normal mechanisms fail.  In this case, it would be use of a device with =
language and media preferences labeled by a user who isn=E2=80=99t the =
usual user of the device when an emergency call is placed.  You do NOT =
want to assume that the labeled preferences are actually the real =
preferences.  You bias your responses by the preferences, but you have =
to allow for variation when the call is actually answered.  So, =
answering in all offered media is something we would do, regardless of =
what the highest media preference was.
> [GH]That sounds good as a theory, but may turn out to be equally =
harmful as you think that obeying modality
> preference would be.=20
> Answering in all modalities may cause an uncertainty of the caller for =
which modality to best continue the conversation.=20
> And it can cause delays and resource waste if you want to answer with =
sign language in all calls indicating sign language competence. The =
indication of sign language competence can be for the case I have =
repeated many times: A hearing person competent in sign language but =
preferring spoken language. In order to not get everyday calls with deaf =
signing persons to invoke a video relay service, it is of value to =
specify sign laguage competence, but on a lower preference level that =
spoken language for this person.
> Having that sign language competence indication cause a PSAP to answer =
with sign language will cause delays and resource usage if not the first =
sign language answer is only a recording.
You put English first and ASL second on the video stream.   The right =
thing happens. =20

>=20
> If you had the opportunity to use modality preference I would think =
that you got better success rate and satisfied users if you first =
answered in the most preferred modality, and be prepared to retry     =
with less favoured modalities a few seconds later in order to cater for =
the few cases with a borrowed phone.
I don=E2=80=99t think so.  Please try to find a better example.  I =
can=E2=80=99t think of one.
>> =20
>>=20
>> Another reason why media preference is not really wanted is that =
emergency services can use other media even when the user doesn=E2=80=99t =
prefer to use them.  An audio feed for a deaf caller can be helpful to =
identify what is happening around the caller.  A video feed for a blind =
caller (if the device really made the offer) could similarly be useful.
> [GH]This is not a reason to not want modality preference.
> As said initially, we are not discussing negotiating the enabling of =
media. We are only specifying guidance for which language and modality =
to use initially in the call.
> (we have a good parallell in RFC 4796, the SDP Content attribute, =
where it is said: "
> 'content' values are just informative at the offer/answer model [8 =
] level." Maybe we should =
include a clear
>  statement like that in the SLIM real-time drafts.
>>=20
>> So, I think this is not a useful capability for emergency services =
and if it was in the offer, I=E2=80=99d tend to want to ignore it and =
accept all media, with an initial greeting in the preferred language.
> Even if that would be feasible for the emergency service case, you =
need to consider that the communicationn device needs also be useful in =
the everyday call situation. In that situation, the answering part will =
not normally have the capability to answer in three modalities in =
parallell. A modality preference indication is essential for the call to =
start smoothly with an answer in a modality and language that the caller =
is willing to receive, and a modality preference indication to the =
caller is essential for the caller to start using the most suitable =
modality.=20
First of all, this thread is specifically about emergency services.  =
I=E2=80=99m not objecting to the follow on work you are proposing.  I =
just don=E2=80=99t think it=E2=80=99s useful or even desirable for =
emergency services.
I also think that if you offer 3 modalities, you can handle all 3 =
simultaneously.  That is the way real systems actually work,  My video =
conference systems are now all 3 modality systems,  They offer video, =
audio and text at answering time.  It=E2=80=99s normal to start with =
audio, but some people actually announce themselves with text if they =
join late.  Everything seems to work fine,  If an ASL caller joins, they =
might be initially be greeted via audio but the response in ASL would =
happen immediately, with smooth transitions by all parties.
>=20
> So, please accept that there are good motivations for a modality =
preference indication. You promised me a review of a separate draft for =
this functionality.=20
> As you may have seen, I first created two drafts for indications =
integrated with draft-ietf-slim-negotiating-human-language, and then an =
alternative more self-sustained, based on the SDP grouping     =
framework. I would also appreciate your assessment of which alternative =
to prefer and proceed with. I prefer=20
> draft-hellstrom-language-grouping; it is more consistent and has no =
known interop problems.
I will review the drafts soon.



--Apple-Mail=_2B1A39C5-C4B1-467F-B044-EBE4B933AFF9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


On Jun 19, 2017, at 3:54 PM, Gunnar Hellstr=C3=B6m <gunnar.hellstrom@omnitor.se> wrote:


 =20
    
 =20
  
Brian,
You are right, that neither the hlang =
negotiation, nor the
      language grouping negotiation should influence decisions to enable
      a media stream or not. 

    
The draft-hellstrom-language-grouping =
specification says: "

    

    
The grouping semantics =
defined in this document are only informing
   about language contents disposition in media and SHOULD not be taken
   as reasons to enable or reject media streams.
"


    So, let us avoid discussion on the influence on enabling media of
    the specified mechanisms. 

    
Okay, my =
mistake.


    
Den 2017-06-19 kl. 15:31, skrev Brian
      Rosen:

    

    

      
We=E2=80=99ve been working on supporting =
emergency services with multiple media for some time in the NENA Next =
Generation 9-1-1 project.

At least in the U.S., all media offered should be accepted.  The =
language preference will be negotiated, and based on the result, an =
interpreting service may be bridged into the call.
As such, a modality preference is not seen as valuable, and in fact, =
could be considered harmful, as the call taker should be trained to =
provide an initial answer in all media negotiated and react to the =
user=E2=80=99s actions thereafter.  An important characteristic of =
emergency services when viewed from the lens of the slim work is that =
the mechanisms have to work for the small percentage of cases where the =
normal mechanisms fail.  In this case, it would be use of a device with =
language and media preferences labeled by a user who isn=E2=80=99t the =
usual user of the device when an emergency call is placed.  You do NOT =
want to assume that the labeled preferences are actually the real =
preferences.  You bias your responses by the preferences, but you have =
to allow for variation when the call is actually answered.  So, =
answering in all offered media is something we would do, regardless of =
what the highest media preference was.

    

    [GH]That sounds good as a theory, but may turn out to be equally
    harmful as you think that obeying modality

    preference would be. 

    Answering in all modalities may cause an uncertainty of the caller
    for which modality to best continue the conversation. 

    And it can cause delays and resource waste if you want to answer
    with sign language in all calls indicating sign language competence.
    The indication of sign language competence can be for the case I
    have repeated many times: A hearing person competent in sign
    language but preferring spoken language. In order to not get
    everyday calls with deaf signing persons to invoke a video relay
    service, it is of value to specify sign laguage competence, but on a
    lower preference level that spoken language for this person.

    Having that sign language competence indication cause a PSAP to
    answer with sign language will cause delays and resource usage if
    not the first sign language answer is only a recording.
You put English first and ASL second =
on the video stream.   The right thing happens. =
 


    

    If you had the opportunity to use modality preference I would think
    that you got better success rate and satisfied users if you first
    answered in the most preferred modality, and be prepared to retry
    with less favoured modalities a few seconds later in order to cater
    for the few cases with a borrowed phone.
I don=E2=80=99t think so. =
 Please try to find a better example.  I can=E2=80=99t think =
of one.

    

      
=20

Another reason why media preference is not really wanted is that =
emergency services can use other media even when the user doesn=E2=80=99t =
prefer to use them.  An audio feed for a deaf caller can be helpful to =
identify what is happening around the caller.  A video feed for a blind =
caller (if the device really made the offer) could similarly be =
useful.

    

    [GH]This is not a reason to not want modality preference.

    As said initially, we are not discussing negotiating the enabling of
    media. We are only specifying guidance for which language and
    modality to use initially in the call.

    (we have a good parallell in RFC 4796, the SDP Content attribute,
    where it is said: "

    
'content' values are just informative =
at the offer/answer model [8] level." Maybe we should include a clear
 statement like that in the SLIM real-time drafts.

    

      
So, I think this is not a useful capability for emergency services and =
if it was in the offer, I=E2=80=99d tend to want to ignore it and accept =
all media, with an initial greeting in the preferred language.

    

    Even if that would be feasible for the emergency service case, you
    need to consider that the communicationn device needs also be useful
    in the everyday call situation. In that situation, the answering
    part will not normally have the capability to answer in three
    modalities in parallell. A modality preference indication is
    essential for the call to start smoothly with an answer in a
    modality and language that the caller is willing to receive, and a
    modality preference indication to the caller is essential for the
    caller to start using the most suitable modality. 
First of all, this thread is =
specifically about emergency services.  I=E2=80=99m not objecting =
to the follow on work you are proposing.  I just don=E2=80=99t =
think it=E2=80=99s useful or even desirable for emergency =
services.
I also think that if you offer 3 modalities, you can =
handle all 3 simultaneously.  That is the way real systems actually =
work,  My video conference systems are now all 3 modality systems, =
 They offer video, audio and text at answering time.  It=E2=80=99=
s normal to start with audio, but some people actually announce =
themselves with text if they join late.  Everything seems to work =
fine,  If an ASL caller joins, they might be initially be greeted =
via audio but the response in ASL would happen immediately, with smooth =
transitions by all parties.

    

    So, please accept that there are good motivations for a modality
    preference indication. You promised me a review of a separate draft
    for this functionality. 

    As you may have seen, I first created two drafts for indications
    integrated with draft-ietf-slim-negotiating-human-language, and then
    an alternative more self-sustained, based on the SDP grouping
    framework. I would also appreciate your assessment of which
    alternative to prefer and proceed with. I prefer 

    draft-hellstrom-language-grouping; it is more consistent and has no
    known interop problems.
I =
will review the drafts soon.


=

--Apple-Mail=_2B1A39C5-C4B1-467F-B044-EBE4B933AFF9--


From nobody Tue Jun 20 05:32:52 2017
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 696F712EAF0 for ; Tue, 20 Jun 2017 05:32:50 -0700 (PDT)
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 hCWT-dKE2c42 for ; Tue, 20 Jun 2017 05:32:47 -0700 (PDT)
Received: from bin-vsp-out-01.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 1FAA512EAB8 for ; Tue, 20 Jun 2017 05:32:36 -0700 (PDT)
X-Halon-ID: 8782678f-55b4-11e7-9ab8-005056917a89
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [77.53.230.196]) by bin-vsp-out-01.atm.binero.net (Halon) with ESMTPSA id 8782678f-55b4-11e7-9ab8-005056917a89; Tue, 20 Jun 2017 14:32:32 +0200 (CEST)
To: Brian Rosen , slim@ietf.org
References:  <1F3F53F9-35E7-46A9-B083-24BECC6C5B82@brianrosen.net>  <19378F69-07AF-4790-9F98-8BD956E8755A@brianrosen.net>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: <93848d1e-d8b0-fa78-241f-5ecf412256fc@omnitor.se>
Date: Tue, 20 Jun 2017 14:32:28 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <19378F69-07AF-4790-9F98-8BD956E8755A@brianrosen.net>
Content-Type: multipart/alternative; boundary="------------2FB0C0E31AFC4F463B692C13"
Archived-At: 
Subject: Re: [Slim] Modality preference
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 Jun 2017 12:32:50 -0000

This is a multi-part message in MIME format.
--------------2FB0C0E31AFC4F463B692C13
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Den 2017-06-19 kl. 22:29, skrev Brian Rosen:

>
>> Den 2017-06-19 kl. 15:31, skrev Brian Rosen:
>>> We’ve been working on supporting emergency services with multiple media for some time in the NENA Next Generation 9-1-1 project.
>>>
>>> At least in the U.S., all media offered should be accepted.  The language preference will be negotiated, and based on the result, an interpreting service may be bridged into the call.
You have no base for that decision if you do not have a preference 
grading between media. Then you do not see which language is the really 
preferred one.
>>> As such, a modality preference is not seen as valuable, and in fact, could be considered harmful, as the call taker should be trained to provide an initial answer in all media negotiated and react to the user’s actions thereafter.  An important characteristic of emergency services when viewed from the lens of the slim work is that the mechanisms have to work for the small percentage of cases where the normal mechanisms fail.  In this case, it would be use of a device with language and media preferences labeled by a user who isn’t the usual user of the device when an emergency call is placed.  You do NOT want to assume that the labeled preferences are actually the real preferences.  You bias your responses by the preferences, but you have to allow for variation when the call is actually answered.  So, answering in all offered media is something we would do, regardless of what the highest media preference was.
>> [GH]That sounds good as a theory, but may turn out to be equally 
>> harmful as you think that obeying modality
>> preference would be.
>> Answering in all modalities may cause an uncertainty of the caller 
>> for which modality to best continue the conversation.
>> And it can cause delays and resource waste if you want to answer with 
>> sign language in all calls indicating sign language competence. The 
>> indication of sign language competence can be for the case I have 
>> repeated many times: A hearing person competent in sign language but 
>> preferring spoken language. In order to not get everyday calls with 
>> deaf signing persons to invoke a video relay service, it is of value 
>> to specify sign laguage competence, but on a lower preference level 
>> that spoken language for this person.
>> Having that sign language competence indication cause a PSAP to 
>> answer with sign language will cause delays and resource usage if not 
>> the first sign language answer is only a recording.
> You put English first and ASL second on the video stream.   The right 
> thing happens.
Putting spoken English first in the video media specification would 
indicate that you regard it to be important for you to see the speaker 
and be seen yourself when you talk English. That is rarely the case, so 
this would be a faked way to specify modality preference, because what 
you would really want to specify is that you can do very well with 
spoken English in the audio media and ASL in video is a usable 
alternative on lower preference if the other party want to use it.

And if written English were your first preference and ASL second, then 
this trick does not work, because we cannot express written language in 
video. We have agreed that non-signed language in video means spoken.

>
>
>>
>> If you had the opportunity to use modality preference I would think 
>> that you got better success rate and satisfied users if you first 
>> answered in the most preferred modality, and be prepared to retry 
>> with less favoured modalities a few seconds later in order to cater 
>> for the few cases with a borrowed phone.
> I don’t think so.  Please try to find a better example.  I can’t think 
> of one.
A person who want to speak and receive written language would like to 
get an answer that clearly shows that
the other party selected to receive spoken and send text. Without the 
modality preference indication, the answering party does not have any 
base for such information.
>>>   
>>>
>>> Another reason why media preference is not really wanted is that emergency services can use other media even when the user doesn’t prefer to use them.  An audio feed for a deaf caller can be helpful to identify what is happening around the caller.  A video feed for a blind caller (if the device really made the offer) could similarly be useful.
>> [GH]This is not a reason to not want modality preference.
>> As said initially, we are not discussing negotiating the enabling of 
>> media. We are only specifying guidance for which language and 
>> modality to use initially in the call.
>> (we have a good parallell in RFC 4796, the SDP Content attribute, 
>> where it is said: "
>> 'content' values are just informative at the offer/answer model [8 ] level." Maybe we should include a clear
>>   statement like that in the SLIM real-time drafts.
>>> So, I think this is not a useful capability for emergency services and if it was in the offer, I’d tend to want to ignore it and accept all media, with an initial greeting in the preferred language.
>> Even if that would be feasible for the emergency service case, you 
>> need to consider that the communicationn device needs also be useful 
>> in the everyday call situation. In that situation, the answering part 
>> will not normally have the capability to answer in three modalities 
>> in parallell. A modality preference indication is essential for the 
>> call to start smoothly with an answer in a modality and language that 
>> the caller is willing to receive, and a modality preference 
>> indication to the caller is essential for the caller to start using 
>> the most suitable modality.
> First of all, this thread is specifically about emergency services. 
>  I’m not objecting to the follow on work you are proposing.
Good, I hope we can find sufficient interest to complete it.
>  I just don’t think it’s useful or even desirable for emergency services.
In the Emergency Service projects I have participated in, we have seen 
the modality preference negotiation as useful and needed, and we have 
been sorry to not have any comleted standard to implement.

So, we just see this differently. I do not see all parts of 
draft-ietf-slim-negotiating-human-language as important, but I have 
participated and contributed with the goal to make the whole draft in 
shape for approval.
> I also think that if you offer 3 modalities, you can handle all 3 
> simultaneously.  That is the way real systems actually work,  My video 
> conference systems are now all 3 modality systems,  They offer video, 
> audio and text at answering time.  It’s normal to start with audio, 
> but some people actually announce themselves with text if they join 
> late.  Everything seems to work fine,  If an ASL caller joins, they 
> might be initially be greeted via audio but the response in ASL would 
> happen immediately, with smooth transitions by all parties.
>>
>> So, please accept that there are good motivations for a modality 
>> preference indication. You promised me a review of a separate draft 
>> for this functionality.
>> As you may have seen, I first created two drafts for indications 
>> integrated with draft-ietf-slim-negotiating-human-language, and then 
>> an alternative more self-sustained, based on the SDP grouping 
>> framework. I would also appreciate your assessment of which 
>> alternative to prefer and proceed with. I prefer
>> draft-hellstrom-language-grouping; it is more consistent and has no 
>> known interop problems.
> I will review the drafts soon.
>
>
Thanks,
Gunnar

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


--------------2FB0C0E31AFC4F463B692C13
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Den 2017-06-19 kl. 22:29, skrev Brian Rosen:

    

    

      


        

          

            

              
Den 2017-06-19 kl. 15:31,
                skrev Brian Rosen:

              

              

                
We’ve been working on supporting emergency services with multiple media for some time in the NENA Next Generation 9-1-1 project.

At least in the U.S., all media offered should be accepted.  The language preference will be negotiated, and based on the result, an interpreting service may be bridged into the call.

              

            

          

        

      

    

    You have no base for that decision if you do not have a preference
    grading between media. Then you do not see which language is the
    really preferred one. 

    

      

        

          

            

              

                
As such, a modality preference is not seen as valuable, and in fact, could be considered harmful, as the call taker should be trained to provide an initial answer in all media negotiated and react to the user’s actions thereafter.  An important characteristic of emergency services when viewed from the lens of the slim work is that the mechanisms have to work for the small percentage of cases where the normal mechanisms fail.  In this case, it would be use of a device with language and media preferences labeled by a user who isn’t the usual user of the device when an emergency call is placed.  You do NOT want to assume that the labeled preferences are actually the real preferences.  You bias your responses by the preferences, but you have to allow for variation when the call is actually answered.  So, answering in all offered media is something we would do, regardless of what the highest media preference was.

              

              [GH]That sounds good as a theory, but may turn out to be
              equally harmful as you think that obeying modality

              preference would be. 

              Answering in all modalities may cause an uncertainty of
              the caller for which modality to best continue the
              conversation. 

              And it can cause delays and resource waste if you want to
              answer with sign language in all calls indicating sign
              language competence. The indication of sign language
              competence can be for the case I have repeated many times:
              A hearing person competent in sign language but preferring
              spoken language. In order to not get everyday calls with
              deaf signing persons to invoke a video relay service, it
              is of value to specify sign laguage competence, but on a
              lower preference level that spoken language for this
              person.

              Having that sign language competence indication cause a
              PSAP to answer with sign language will cause delays and
              resource usage if not the first sign language answer is
              only a recording.

            

          

        

        You put English first and ASL second on the video stream.   The
        right thing happens.  

      

    

    Putting spoken English first in the video media specification would
    indicate that you regard it to be important for you to see the
    speaker and be seen yourself when you talk English. That is rarely
    the case, so this would be a faked way to specify modality
    preference, because what you would really want to specify is that
    you can do very well with spoken English in the audio media and ASL
    in video is a usable alternative on lower preference if the other
    party want to use it.

    

    And if written English were your first preference and ASL second,
    then this trick does not work, because we cannot express written
    language in video. We have agreed that non-signed language in video
    means spoken.

    

    


      


      

      

        

          

            
 

              If you had the opportunity to use modality preference I
              would think that you got better success rate and satisfied
              users if you first answered in the most preferred
              modality, and be prepared to retry with less favoured
              modalities a few seconds later in order to cater for the
              few cases with a borrowed phone.

            

          

        

        I don’t think so.  Please try to find a better example.  I can’t
        think of one.

      

    

    A person who want to speak and receive written language would like
    to get an answer that clearly shows that 

    the other party selected to receive spoken and send text. Without
    the modality preference indication, the answering party does not
    have any base for such information. 

    

      

        

          

            

              

                
 

Another reason why media preference is not really wanted is that emergency services can use other media even when the user doesn’t prefer to use them.  An audio feed for a deaf caller can be helpful to identify what is happening around the caller.  A video feed for a blind caller (if the device really made the offer) could similarly be useful.

              

              [GH]This is not a reason to not want modality preference.

              As said initially, we are not discussing negotiating the
              enabling of media. We are only specifying guidance for
              which language and modality to use initially in the call.

              (we have a good parallell in RFC 4796, the SDP Content
              attribute, where it is said: "

              
'content' values are just informative at the offer/answer model [8] level." Maybe we should include a clear
 statement like that in the SLIM real-time drafts.

              

                
So, I think this is not a useful capability for emergency services and if it was in the offer, I’d tend to want to ignore it and accept all media, with an initial greeting in the preferred language.

              

              Even if that would be feasible for the emergency service
              case, you need to consider that the communicationn device
              needs also be useful in the everyday call situation. In
              that situation, the answering part will not normally have
              the capability to answer in three modalities in parallell.
              A modality preference indication is essential for the call
              to start smoothly with an answer in a modality and
              language that the caller is willing to receive, and a
              modality preference indication to the caller is essential
              for the caller to start using the most suitable modality.
              

            

          

        

        First of all, this thread is specifically about emergency
        services.  I’m not objecting to the follow on work you are
        proposing.

    

    Good, I hope we can find sufficient interest to complete it.

    

      
  I just don’t think it’s useful or even desirable for
        emergency services.

    

    In the Emergency Service projects I have participated in, we have
    seen the modality preference negotiation as useful and needed, and
    we have been sorry to not have any comleted standard to implement. 

    

    So, we just see this differently. I do not see all parts of
    draft-ietf-slim-negotiating-human-language as important, but I have
    participated and contributed with the goal to make the whole draft
    in shape for approval.

    

      
I also think that if you offer 3 modalities, you can handle
        all 3 simultaneously.  That is the way real systems actually
        work,  My video conference systems are now all 3 modality
        systems,  They offer video, audio and text at answering time.
         It’s normal to start with audio, but some people actually
        announce themselves with text if they join late.  Everything
        seems to work fine,  If an ASL caller joins, they might be
        initially be greeted via audio but the response in ASL would
        happen immediately, with smooth transitions by all parties.

      

        

          

            
 

              So, please accept that there are good motivations for a
              modality preference indication. You promised me a review
              of a separate draft for this functionality. 

              As you may have seen, I first created two drafts for
              indications integrated with
              draft-ietf-slim-negotiating-human-language, and then an
              alternative more self-sustained, based on the SDP grouping
              framework. I would also appreciate your assessment of
              which alternative to prefer and proceed with. I prefer 

              draft-hellstrom-language-grouping; it is more consistent
              and has no known interop problems.

            

          

        

        I will review the drafts soon.

      


      

      


      

    

    Thanks,

    Gunnar

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

  


--------------2FB0C0E31AFC4F463B692C13--


From nobody Thu Jun 22 15:01:09 2017
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 212711294AB; Thu, 22 Jun 2017 15:01:08 -0700 (PDT)
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 DQyQqvUDGZPO; Thu, 22 Jun 2017 15:01:06 -0700 (PDT)
Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7166E129B8B; Thu, 22 Jun 2017 15:01:03 -0700 (PDT)
Received: by mail-ua0-x230.google.com with SMTP id j53so26818778uaa.2; Thu, 22 Jun 2017 15:01:03 -0700 (PDT)
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=dAcxh12Ct38098ics8dYtwib/Z2bgdkv/uDWF0XR8R4=; b=Li5xJwCrANIDLnS4/wJbdTdYlzhyddYtyr+oPhV0cuNgtoGSysDL+JQ5B6Ib+PvjVA 5V254u+aC+J7hakUpkjhYx+T2UtRXyiRJfLLW4Lltg6znK94TS/c6ll6GnO6K7glYikv 2oruDhNEgUGQFdXZXwwPkkrbt5LD4dN4V3//jw/DHKAGLcgQs2Ei7HU9LI5LgYFHX/yT //fCXHZJH2euIW5UnUmcOpPgvj7sMFVJCmHP66laeoPA1XQo0VzGR7aOCTSqliKbmCfy oqIP+qtvtqHGB4JKmSkAu6PcY33xk5KQ9xF+28pbS16EkTeokSKPha+C/d08TcSkOH+1 ZASA==
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=dAcxh12Ct38098ics8dYtwib/Z2bgdkv/uDWF0XR8R4=; b=ITn6syL4skTq9NJjlrpAU6TgTIK/RTdpFOulKO6IccD2tduLk2hv90fNp9s5IzLIMi jSXf/Bj5Thq4jgYEBtIXeSlkXqDlVdN5K4KrqjZcQY0U0e/G0YaPeLZ9h20ZwgiAC2qR lBo4AL32ALeDK5j3giIXtAW3Ej9cAy1dUPW5fPNubuITz+DI1NbbW5Huol3kzCcDH/Yc foNXPgScGpq4kMsx+qplkrVcSZHwO6B884oxb6g3Vn6V3rxAT/DuqQuQLafnvspPlDGb EqknWykaAPRn1W+ZPbQ5xceYzH3UYdwC0+Vs4iLlrRayYOOsoViM12q659vzYHyvwUxo sbLA==
X-Gm-Message-State: AKS2vOxZ05clj06v5ZxX2ldUgE3TbOD09Pbn9UOldhhXkoMnqIHyzNl3 A5DEt/eVDaNFOtTWbMCid0nZJDZIH13ENIo=
X-Received: by 10.159.59.21 with SMTP id i21mr3501305uah.62.1498168861782; Thu, 22 Jun 2017 15:01:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.159.52.218 with HTTP; Thu, 22 Jun 2017 15:00:41 -0700 (PDT)
From: Bernard Aboba 
Date: Thu, 22 Jun 2017 15:00:41 -0700
Message-ID: 
To: slim@ietf.org, draft-ietf-slim-multilangcontent@ietf.org
Content-Type: multipart/alternative; boundary="f403043c6458d1f8350552939e83"
Archived-At: 
Subject: [Slim] IPR policy conformance statement for draft-ietf-slim-multilangcontent
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, 22 Jun 2017 22:01:08 -0000

--f403043c6458d1f8350552939e83
Content-Type: text/plain; charset="UTF-8"

Dear Authors:

The SLIM WG is considering requesting that the IESG publish
draft-ietf-slim-multilangcontent-08 as a Proposed Standard RFC.

So far, no IPR statements have been submitted relating to
draft-ietf-slim-multilangcontent.  This email represents a final IPR check
on this document.

Are you aware of any IPR that applies to this draft?  A reply is required
from each author before a publication request can be considered.

Thank you,

Bernard Aboba
(on behalf of the SLIM WG)

--f403043c6458d1f8350552939e83
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Dear Authors:=C2=A0

The SLIM WG is cons=
idering requesting that the IESG publish draft-ietf-slim-multilangcontent-0=
8 as a Proposed Standard RFC.=C2=A0

So far, no IPR=
 statements have been submitted relating to draft-ietf-slim-multilangconten=
t.=C2=A0 This email represents a final IPR check on this document.=C2=A0

Are you aware of any IPR that applies to this draft?=
=C2=A0 A reply is required from each author before a publication request ca=
n be considered.

Thank you,

Bernard Aboba
(on behalf of the SLIM WG)

<=
/div>

--f403043c6458d1f8350552939e83--


From nobody Thu Jun 22 15:05:08 2017
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 E276D129B89; Thu, 22 Jun 2017 15:05:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level: 
X-Spam-Status: No, score=-2.698 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, HTML_NONELEMENT_30_40=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 TpmVS_5NRVXn; Thu, 22 Jun 2017 15:05:03 -0700 (PDT)
Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::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 4A5041294A2; Thu, 22 Jun 2017 15:05:03 -0700 (PDT)
Received: by mail-vk0-x236.google.com with SMTP id y70so6054967vky.3; Thu, 22 Jun 2017 15:05:03 -0700 (PDT)
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;  bh=1HqznW+fhZSvzWrtlghL2zv3Erue7DchY14rUCNdQ6s=; b=eiCO/M2ROqyiA4oMC3nJLHaqCPjt1fkHeXFGA569z9RKZLEiRXOPEhVNxNBjQWSlBO M2e9wakHg53NIhcAYSWZyeNCySkdOC9DATCtV4aoOECyuLNqr9J4Qzl52Py0b4KLm1tS lxz9KhuznoOAhOYIjALfDEDI6yzU2STV/luOkA4dFHGMbkk871fXG32Nd1Dl/MEmKDC+ 0HgOUD1QuvepGT1k+SjLdAEJ9W7JQo3/BIKv3j9UqVfEAdmpua2rWeXMHcQHsGynnmu1 a4r0T51Lt1iFV9HIg333TIVlk70skxP+xXyHq9xNZH2xZqo3gyiGDhhz5Bu2un3JiDkL sZHQ==
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; bh=1HqznW+fhZSvzWrtlghL2zv3Erue7DchY14rUCNdQ6s=; b=IkqWUiYm3LR4ZMsPdxYhSpig+8Iwkyax6GoT4p8PCzpMbtxQ5OBFV/XXdNMLSDyqs5 2MVqjgJfaaP68ayDIQNfUft1id/j7MQqd5W07CQRBiuFOd3vVMi3gyvXn81zheckphbh p9hwbQopuISNqV7zypXCYYvb3n+37b03ZfG1E47/mynQV7zvDKjr18coDaFjRF4eebRe Yxb3NUoWb8t7c+SAiuMekIU5HoJm1AwHLJFy4xUShdESOS5dGNteGFen62u6VGTPZn5t MDYQ6gZ5KACS3eVCaWgGRbCS71VeTNsgbsuuZWWLbao0G82CMUg6V2ogL29lxBBYyj3t 2LqQ==
X-Gm-Message-State: AKS2vOyhG7B//OA2fgccSsJclmHpKgPGuNF3V/QKT53ZVT+hTMCy/JSP Vz4EyQGLJxIz9DoQ3TvtSkX0QUhfMbXq
X-Received: by 10.31.193.145 with SMTP id r139mr1036636vkf.146.1498169102215;  Thu, 22 Jun 2017 15:05:02 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.159.52.218 with HTTP; Thu, 22 Jun 2017 15:04:41 -0700 (PDT)
In-Reply-To: 
References: 
From: Bernard Aboba 
Date: Thu, 22 Jun 2017 15:04:41 -0700
Message-ID: 
To: slim@ietf.org, draft-ietf-slim-negotiating-human-language@ietf.org
Content-Type: multipart/alternative; boundary="001a114d9b5e26ba3a055293ad05"
Archived-At: 
Subject: [Slim] Fwd: IPR policy conformance statement for draft-ietf-slim-multilangcontent
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, 22 Jun 2017 22:05:08 -0000

--001a114d9b5e26ba3a055293ad05
Content-Type: text/plain; charset="UTF-8"

Dear Authors:

The SLIM WG is working toward resolving open issues so as to enable
re-submission of draft-ietf-slim-negotiating-human-language to the IESG for
publication as a Proposed Standard RFC.

So far, no IPR statements have been submitted relating to
draft-ietf-slim-negotiating-human-language.
This email represents a final IPR check on this document.

Are you aware of any IPR that applies to this draft?  A reply is required
from each author before a publication request can be considered.

Thank you,

Bernard Aboba
(on behalf of the SLIM WG)

--001a114d9b5e26ba3a055293ad05
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Dear Authors:=
=C2=A0

The SLIM WG is working toward resolving open issu=
es so as to enable re-submission of draft-ietf-slim-negotiating-human-=
language to the IESG for publication as a Proposed Standard RFC.=C2=A0

So far, no IPR statements have been submitted relating=
 to draft-ietf-slim-negotiating-human-language.=C2=A0 This email repre=
sents a final IPR check on this document.=C2=A0

Ar=
e you aware of any IPR that applies to this draft?=C2=A0 A reply is require=
d from each author before a publication request can be considered.

Thank you,

Bernard Aboba
(on behalf of the SLIM WG)






--001a114d9b5e26ba3a055293ad05--


From nobody Thu Jun 22 16:41:33 2017
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 2BDF9129BA2; Thu, 22 Jun 2017 16:41:31 -0700 (PDT)
X-Quarantine-ID: <1-cEu9OnUhyX>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 1-cEu9OnUhyX; Thu, 22 Jun 2017 16:41:29 -0700 (PDT)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id C40E2129B0A; Thu, 22 Jun 2017 16:41:29 -0700 (PDT)
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Thu, 22 Jun 2017 16:44:18 -0700
Mime-Version: 1.0
Message-Id: 
In-Reply-To: 
References:  
X-Mailer: Eudora for Mac OS X
Date: Thu, 22 Jun 2017 16:41:26 -0700
To: Bernard Aboba , slim@ietf.org, draft-ietf-slim-negotiating-human-language@ietf.org
From: Randall Gellens 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Archived-At: 
Subject: Re: [Slim] Fwd: IPR policy conformance statement for draft-ietf-slim-multilangcontent
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, 22 Jun 2017 23:41:31 -0000

I am not aware of any IPR that applies to this draft.

--Randall

At 3:04 PM -0700 6/22/17, Bernard Aboba wrote:

>  Dear Authors:
>
>  The SLIM WG is working toward resolving open issues so as to enable 
> re-submission of draft-ietf-slim-negotiating-human-language to the 
> IESG for publication as a Proposed Standard RFC.
>
>  So far, no IPR statements have been submitted relating to 
> draft-ietf-slim-negotiating-human-language.  This email represents 
> a final IPR check on this document.
>
>  Are you aware of any IPR that applies to this draft?  A reply is 
> required from each author before a publication request can be 
> considered.
>
>  Thank you,
>
>  Bernard Aboba
>  (on behalf of the SLIM WG)


-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Safety Experts Say School Bus Passengers Should Be Belted
--Newspaper headline


From nobody Fri Jun 23 05:26:32 2017
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 6A9AC127735 for ; Fri, 23 Jun 2017 05:26:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level: 
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.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 dlPN699TzAUU for ; Fri, 23 Jun 2017 05:26:28 -0700 (PDT)
Received: from mail-qk0-x243.google.com (mail-qk0-x243.google.com [IPv6:2607:f8b0:400d:c09::243]) (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 1A7E4127342 for ; Fri, 23 Jun 2017 05:26:28 -0700 (PDT)
Received: by mail-qk0-x243.google.com with SMTP id r62so5931185qkf.3 for ; Fri, 23 Jun 2017 05:26:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=6qduo8j2H3sWxSlqv5kZIDEUXdQG5b8R3I8IC+hvyCM=; b=LQANmgLfuQQccS30eq8cS+TDA6L1KfDmJvkGqv5adtS0LeZRadke6bOxeNrjzHB7s9 VHFjvyhjqVe+UnHv7Itz0awAkbl+4xiJ3QzrWUFudYVWIWVL1nGaGJVTFIuUpsDIFPRF j/qtkMRknRYaInQtCGlyQS4mVeWg/gwGtSC2KWBFGqTRPXBj7gkb7oc66HFjCWEseKVU pd+1hmsr5iHZoQVVCkycA1CuqepYaAwFzJJ7g17fQHXQEy65bgt7+nzbgbaf9sYRJSgg YikBtQwmYdyb+fXkq5UVvjha2sTNaxP+Clnk+BxYWyLvWmiDs76vnqSHqkQzKE1IdaMa qWmg==
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=6qduo8j2H3sWxSlqv5kZIDEUXdQG5b8R3I8IC+hvyCM=; b=S4DNb8FnlaurhPpvn4gMeDbFA1uk4kXSnx8m+zwFd315LzgQ9g6vRuRw/MBANfhtIL 3YYtpb9agdaSjv2X9uxmtGvjO1goeO09YKmJdAWbLJT9kThM3AE6XcsL1muxOG+tlVad c/euUR+daWdQ5z1YFocjXZY9SF+V4Ly6qEWxpjTFZXKok9sESySvMejTbRa7gP66a0Zx wqtrMsIoAmsqKDd2IzcYpnNPeNxMhIYXDYP/ex2amUmtccvx54ZukLp1ntQRVykvYgeP l8BBJgI7wwrXJ1ftgY5wHqkmK1wibC9SRfG6JjUMbFMfVywBuebLeZZpC9VbLLLdEt4F bMMQ==
X-Gm-Message-State: AKS2vOxt1UF/81TdN4BxDkXVvDA4de1GBO9/91pkx2chzqF//Zl8qgY4 3lcy3brcbJYAX9K0
X-Received: by 10.55.182.135 with SMTP id g129mr9055425qkf.111.1498220787251;  Fri, 23 Jun 2017 05:26:27 -0700 (PDT)
Received: from [10.96.9.30] (neustar-sthide-nat1.neustar.biz. [156.154.81.54]) by smtp.gmail.com with ESMTPSA id o50sm3273505qto.55.2017.06.23.05.26.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 23 Jun 2017 05:26:26 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Brian Rosen 
In-Reply-To: 
Date: Fri, 23 Jun 2017 08:26:24 -0400
Cc: slim@ietf.org, draft-ietf-slim-negotiating-human-language@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <62BD9817-AE66-48C2-95B1-5B28CF8A708B@brianrosen.net>
References:  
To: Bernard Aboba 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [Slim] Fwd: IPR policy conformance statement for draft-ietf-slim-multilangcontent
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, 23 Jun 2017 12:26:30 -0000

I am not aware of any IPR that applies to this draft

Brian

> On Jun 22, 2017, at 6:04 PM, Bernard Aboba  =
wrote:
>=20
> Dear Authors:=20
>=20
> The SLIM WG is working toward resolving open issues so as to enable =
re-submission of draft-ietf-slim-negotiating-human-language to the IESG =
for publication as a Proposed Standard RFC.=20
>=20
> So far, no IPR statements have been submitted relating to =
draft-ietf-slim-negotiating-human-language.  This email represents a =
final IPR check on this document.=20
>=20
> Are you aware of any IPR that applies to this draft?  A reply is =
required from each author before a publication request can be =
considered.
>=20
> Thank you,
>=20
> Bernard Aboba
> (on behalf of the SLIM WG)
>=20
>=20
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim


From nobody Fri Jun 23 16:47:02 2017
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 A76D3124B0A; Fri, 23 Jun 2017 16:46:53 -0700 (PDT)
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.55.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149826161364.7680.4546115441019121579@ietfa.amsl.com>
Date: Fri, 23 Jun 2017 16:46:53 -0700
Archived-At: 
Subject: [Slim] I-D Action: draft-ietf-slim-negotiating-human-language-11.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: Fri, 23 Jun 2017 23:46:54 -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 of the IETF.

        Title           : Negotiating Human Language in Real-Time Communications
        Author          : Randall Gellens
	Filename        : draft-ietf-slim-negotiating-human-language-11.txt
	Pages           : 18
	Date            : 2017-06-23

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 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-11
https://datatracker.ietf.org/doc/html/draft-ietf-slim-negotiating-human-language-11

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-slim-negotiating-human-language-11


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 Fri Jun 23 17:17:58 2017
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 8924C12EBA2; Fri, 23 Jun 2017 17:07:18 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "\"IETF Secretariat\"" 
To: , 
Cc: slim@ietf.org, aamelnikov@fastmail.fm
X-Test-IDTracker: no
X-IETF-IDTracker: 6.55.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149826283855.7840.15290007344056007583.idtracker@ietfa.amsl.com>
Date: Fri, 23 Jun 2017 17:07:18 -0700
Archived-At: 
Subject: [Slim] slim - Requested session has been scheduled for IETF 99
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: Sat, 24 Jun 2017 00:07:21 -0000

Dear Natasha Rooney,

The session(s) that you have requested have been scheduled.
Below is the scheduled session information followed by
the original request. 

slim Session 1 (1:00:00)
    Monday, Afternoon Session III 1740-1840
    Room Name: Berlin/Brussels size: 100
    ---------------------------------------------
    


Request Information:


---------------------------------------------------------
Working Group Name: Selection of Language for Internet Media
Area Name: Applications and Real-Time Area
Session Requester: Natasha Rooney

Number of Sessions: 1
Length of Session(s):  1 Hour
Number of Attendees: 15
Conflicts to Avoid: 
 First Priority: mmusic ecrit ice rtcweb




People who must be present:
  Dr. Bernard D. Aboba Ph.D.
  Alexey Melnikov
  Natasha Rooney

Resources Requested:
  Experimental Room Setup (U-Shape and classroom, subject to availability)

Special Requests:
  Many apologies on being late with this request. Anything you can do will be great. 
---------------------------------------------------------


From nobody Mon Jun 26 02:30:47 2017
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 34CB2126D73 for ; Mon, 26 Jun 2017 02:30:45 -0700 (PDT)
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 XWTBPpoSxqqm for ; Mon, 26 Jun 2017 02:30:41 -0700 (PDT)
Received: from bin-vsp-out-03.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 35DF7129AB8 for ; Mon, 26 Jun 2017 02:30:41 -0700 (PDT)
X-Halon-ID: 18bba784-5a52-11e7-ad4a-0050569116f7
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [77.53.230.196]) by bin-vsp-out-03.atm.binero.net (Halon) with ESMTPSA id 18bba784-5a52-11e7-ad4a-0050569116f7; Mon, 26 Jun 2017 11:30:32 +0200 (CEST)
To: slim@ietf.org
References: <149826161364.7680.4546115441019121579@ietfa.amsl.com>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: <8cbb2083-b02f-20eb-ab7f-a03c85cb95f8@omnitor.se>
Date: Mon, 26 Jun 2017 11:30:33 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <149826161364.7680.4546115441019121579@ietfa.amsl.com>
Content-Type: multipart/alternative; boundary="------------5A4FDDCF36C02C671BB1D9F6"
Archived-At: 
Subject: Re: [Slim] I-D Action: draft-ietf-slim-negotiating-human-language-11.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: Mon, 26 Jun 2017 09:30:45 -0000

This is a multi-part message in MIME format.
--------------5A4FDDCF36C02C671BB1D9F6
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

Good to see progress.

I checked the numbered change proposals I submitted earlier under 
subject " I-D Action: draft-ietf-slim-negotiating-human-language-10.txt" 
and found that most of them were solved or agreed to be ignored. Only 
proposal 2.2 was not acted on, so I repeat it here together with a few 
new findings:

-----Issue 1, old 2.2 The attributes can appear in both offers and 
answers -----------
  -------Old text 2.2 at end of first paragraph of 5.2---------


     Each can appear in an offer for a media
     stream.
  --New text 2.2---
     Each can appear in an offer and answer for a media
     stream.
---Reasoning:----------

This paragraph is an introduction to the attributes. It should mention 
the full use, in both offer and answer. The following paragraphs tell 
about specifics for offer vs answer.
  --End of change 2.2---

---End of Issue 1----------

------Issue 2 , reduce info on possible extensions to not be solution 
specific----------

In section 5.2, middle:

-----Old text------------

   See Section 5.3 for more
    information and discussion.  Note that separate work
    [I-D.hellstrom-slim-modalitypref] extends the use of the asterisk to
    convey additional information regarding language/modality preferences
    among media.

-----New text proposal for Issue 2-----------

     See Section 5.3 for more information and discussion.

    Note that separate work may introduce additional information regarding language/modality
    preferences among media.

---Reasoning: ---------
Two ways to convey language/modality preferences among media have been proposed, one based on the asterisk (draft-hellstrom-slim-modalitypref), and another based on the SDP gouping framework (draft-hellstrom-language-grouping). There are drafts for both. The clean one seems to be the method based on SDP grouping. It has no known interoperability problems.
**The proposed wording of the note (as a separate paragraph) is intended to cover both methods, but has less effect as a warning against interoperabitlity problems caused by the asterisk based solution.

*A decision is needed for which alternative to continue with, I prefer 
the one based on SDP grouping.*  



-----End of issue 2-----------------------

------Issue 3  - typo in 5.5------------

Typo in section 5.5, at the end of page 9

-------old text-----
       An offer of answer
-----new text----

    An offer or answer
-----end of issue 3------

----Issue 4  allow asterisks also in answers, but do not assign a meaning---------
The second example in 5.5 has asterisks last in the attributes and says that the example can be either an offer or an answer.

But section 5.2, fourth paragraph currently only says that the asterisk can appear in an offer.

I suggest to amend this by allowing the asterisk to appear in an answer, but not assign any meaning to it.
This is more future proof and may make implementation of the answering part easier than keeping the currect restriction.

------New paragraph after paragraph four in 5.2-------
The asterisk token MAY also be appended last in a 'hlang' attribute in an answer, but this specification does not define any meaning to an asterisk in that position.
------End of proposal for Issue 4...........
-----End of Issue 4----------------

----Issue 5 correct SDP syntax in answer example on page 10 
-------------------
In the answer example in section 5.5 on page 10, the answer shows no 
video m-line. There was an m-lne for video in the offer, then one must 
be included in the aswer.

---old text in 5.5----

    An answer for the above offer, indicating text in which the callee
    will receive written Spanish, and audio in which the callee will send
    spoken Spanish:

       m=text 45020 RTP/AVP 103 104
       a=hlang-recv:sp

       m=audio 49250 RTP/AVP 20
       a=hlang-send:sp


-------new text-----------

    An answer for the above offer, indicating text in which the callee
    will receive written Spanish, and audio in which the callee will send
    spoken Spanish. The answering party had no video capability:

       m=video 0 RTP/AVP 31 32
       m=text 45020 RTP/AVP 103 104
       a=hlang-recv:sp

       m=audio 49250 RTP/AVP 20
       a=hlang-send:sp



---------end of proposal------------
--------end of Issue 5---------------

--------Issue 6 - most examples have asterisks on all attributes, reduce 
number of asterisks -------
In section 5.5 Examples, nearly all examples including the use of the 
asterisk has the asterisk on all attribute lines in the whole SDP, even 
if it is sufficient to have it on one attribute. I think this might have 
confused the reviewers and caused some of the thoughts about assumed 
grouping and linking and wondering about semantic rules around the 
asterisk that was not intended by the draft.
--------Proposed action for Issue 6------------
Delete some of the asterisks in the examples in section 5.5, so that 
only one example has asterisks on all attributes and the others have 
just one or a varying number of asterisks.
--------End of issue 6-----------------------------------

--------Issue 7  Missing link to 'hlang-value' in the syntax section 
6.1-------------------

I suggest to insert a line in two places to link the attribute to the 
'hlang-value' syntax description, matching the format used in rfc4566bis.

------Old text in two places in section 6.1--------

  Attribute Syntax:


--------New text in two places in section 6.1-----

   Value: hlang-value
   Attribute Syntax:

---------End of Issue 7.----------------


Regards
Gunnar







Den 2017-06-24 kl. 01:46, skrev internet-drafts@ietf.org:
> 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 of the IETF.
>
>          Title           : Negotiating Human Language in Real-Time Communications
>          Author          : Randall Gellens
> 	Filename        : draft-ietf-slim-negotiating-human-language-11.txt
> 	Pages           : 18
> 	Date            : 2017-06-23
>
> 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 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-11
> https://datatracker.ietf.org/doc/html/draft-ietf-slim-negotiating-human-language-11
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-slim-negotiating-human-language-11
>
>
> 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/
>
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim

-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se


--------------5A4FDDCF36C02C671BB1D9F6
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Good to see progress.

    

    
I checked the numbered change proposals I submitted earlier under
      subject " I-D Action:
      draft-ietf-slim-negotiating-human-language-10.txt" and found that
      most of them were solved or agreed to be ignored. Only proposal
      2.2 was not acted on, so I repeat it here together with a few new
      findings:

    

    
-----Issue 1, old 2.2 The attributes can appear in both offers
      and answers -----------

       -------Old text 2.2 at end of first paragraph of 5.2---------

    
 

          Each can appear in an offer for a media 

          stream. 

       --New text 2.2--- 

          Each can appear in an offer and answer for a media 

          stream. 

      ---Reasoning:----------

    
This paragraph is an introduction to the attributes. It should
      mention the full use, in both offer and answer. The following
      paragraphs tell about specifics for offer vs answer. 

       --End of change 2.2--- 

    

    
---End of Issue 1----------

    

    
------Issue 2 , reduce info on possible extensions to not be
      solution specific----------

    
In section 5.2, middle: 

    

    
-----Old text------------

    
  See Section 5.3 for more
   information and discussion.  Note that separate work
   [I-D.hellstrom-slim-modalitypref] extends the use of the asterisk to
   convey additional information regarding language/modality preferences
   among media.

-----New text proposal for Issue 2-----------

    See Section 5.3 for more information and discussion.
<paragraph separator>
   Note that separate work may introduce additional information regarding language/modality
   preferences among media.

---Reasoning: ---------
Two ways to convey language/modality preferences among media have been proposed, one based on the asterisk (draft-hellstrom-slim-modalitypref), and another based on the SDP gouping framework (draft-hellstrom-language-grouping). There are drafts for both. The clean one seems to be the method based on SDP grouping. It has no known interoperability problems. 
 The proposed wording of the note (as a separate paragraph) is intended to cover both methods, but has less effect as a warning against interoperabitlity problems caused by the asterisk based solution. 

A decision is needed for which alternative to continue with, I prefer the one based on SDP grouping. 



-----End of issue 2-----------------------


    
------Issue 3  - typo in 5.5------------

    

    
Typo in section 5.5, at the end of page 9

    
-------old text-----

            An offer of answer

      -----new text----

    

    
   An offer or answer
-----end of issue 3------

----Issue 4  allow asterisks also in answers, but do not assign a meaning---------
The second example in 5.5 has asterisks last in the attributes and says that the example can be either an offer or an answer.

But section 5.2, fourth paragraph currently only says that the asterisk can appear in an offer.

I suggest to amend this by allowing the asterisk to appear in an answer, but not assign any meaning to it.
This is more future proof and may make implementation of the answering part easier than keeping the currect restriction. 

------New paragraph after paragraph four in 5.2-------
The asterisk token MAY also be appended last in a 'hlang' attribute in an answer, but this specification does not define any meaning to an asterisk in that position.
------End of proposal for Issue 4...........
-----End of Issue 4----------------


    ----Issue 5 correct SDP syntax in answer example on page 10
    -------------------

    In the answer example in section 5.5 on page 10, the answer shows no
    video m-line. There was an m-lne for video in the offer, then one
    must be included in the aswer. 

    

    ---old text in 5.5----

    
   An answer for the above offer, indicating text in which the callee
   will receive written Spanish, and audio in which the callee will send
   spoken Spanish:

      m=text 45020 RTP/AVP 103 104
      a=hlang-recv:sp

      m=audio 49250 RTP/AVP 20
      a=hlang-send:sp


    

    -------new text-----------

    
   An answer for the above offer, indicating text in which the callee
   will receive written Spanish, and audio in which the callee will send
   spoken Spanish. The answering party had no video capability:

      m=video 0 RTP/AVP 31 32
      m=text 45020 RTP/AVP 103 104
      a=hlang-recv:sp

      m=audio 49250 RTP/AVP 20
      a=hlang-send:sp


    

    

    ---------end of proposal------------

    --------end of Issue 5---------------

    

    --------Issue 6 - most examples have asterisks on all attributes,
    reduce number of asterisks -------

    In section 5.5 Examples, nearly all examples including the use of
    the asterisk has the asterisk on all attribute lines in the whole
    SDP, even if it is sufficient to have it on one attribute. I think
    this might have confused the reviewers and caused some of the
    thoughts about assumed grouping and linking and wondering about
    semantic rules around the asterisk that was not intended by the
    draft.

    --------Proposed action for Issue 6------------

    Delete some of the asterisks in the examples in section 5.5, so that
    only one example has asterisks on all attributes and the others have
    just one or a varying number of asterisks.

    --------End of issue 6-----------------------------------

    

    --------Issue 7  Missing link to 'hlang-value' in the syntax section
    6.1-------------------

    

    I suggest to insert a line in two places to link the attribute to
    the 'hlang-value' syntax description, matching the format used in
    rfc4566bis.

    

    ------Old text in two places in section 6.1--------

    
 Attribute Syntax:


    

    --------New text in two places in section 6.1-----

    
  Value: hlang-value
  Attribute Syntax:

---------End of Issue 7.---------------- 


    

    Regards

    Gunnar

    

    

    

    

    

    

    

    
Den 2017-06-24 kl. 01:46, skrev
      internet-drafts@ietf.org:

    

    

      
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 of the IETF.

        Title           : Negotiating Human Language in Real-Time Communications
        Author          : Randall Gellens
	Filename        : draft-ietf-slim-negotiating-human-language-11.txt
	Pages           : 18
	Date            : 2017-06-23

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 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-11
https://datatracker.ietf.org/doc/html/draft-ietf-slim-negotiating-human-language-11

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-slim-negotiating-human-language-11


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/

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


    

    

    
-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se


  


--------------5A4FDDCF36C02C671BB1D9F6--


From nobody Wed Jun 28 09:00:38 2017
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 C4DC012EC5E; Wed, 28 Jun 2017 09:00:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 UPAj2jwHSAYd; Wed, 28 Jun 2017 09:00:31 -0700 (PDT)
Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (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 A9FA4129B6A; Wed, 28 Jun 2017 09:00:26 -0700 (PDT)
Received: by mail-lf0-x22e.google.com with SMTP id b207so37674068lfg.2; Wed, 28 Jun 2017 09:00:26 -0700 (PDT)
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=QENZxcIWzYf9vTqKD9BtTnSqRu9b2hGAwg4HOwyMf2E=; b=tKfovO9eBF7RvWgCo4jx5pBPgRPacWCjai0RPI4347E1w4AAUzzPUACXP1RBtFZnDv Avm2cONKoyraz8DhNOEys2DnugsytHVLcbtQJ4AjhC5fIiluzgmbNrWmZxUNwIU1sTmf ESjkwa2OLDExlgQ2ZsX2/qSjfHJwzqECymScs1MpT569/i5GwdAGYpY2p5Q53ShHdtxa oGtyPkVzJiq1zJH7hijhGs2PFln2kNPhZu8412W4yurM/t9SNRlzwzE4uB5adkh3KG3a aNPGCdASXjSyc0aBMPI7GYlGHs/RilHQ5kai3zOJJLnIEVSEXmkygAlRDr931imwuLat +sag==
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=QENZxcIWzYf9vTqKD9BtTnSqRu9b2hGAwg4HOwyMf2E=; b=e6/kVhBQbsTxTGHkE1QZh33k+H4qtgp7QU9XOm/jvfuzITCBvlbnn1UaMYTG19ER+/ 9T0JJkbc0Cw6Q8RYywMsyGUktYT49SWENsTTSFTVGd9H65rWp5jjz8zvG74zkAXK685v 8PETSBT/lKhHn1kXdz9sgV6PKay34Dx84TQeZJEEkaAm3PdUY4rfo4VAWb5wB0hncdQo TvBtQnMJq/9aZ/zBcByuVfASdN1bZoWDn8mr/H14yVJxo/I7sDBVRS9hOsWC2bpaqsQ6 MAwybj9KDD+SnpCmQqwGHuwRgQU3xGvFOM1lJ1cC5daRTpxNW9EBGGsO2CeK6hn5y6zl d2tw==
X-Gm-Message-State: AKS2vOxQoH5A92mlswgcWw/6ZZHRh4b0cm1IPV4AQB+7zIlc/uryVyDl myRkYS+6+FiIyNOKdGbFqN4TdL359w==
X-Received: by 10.25.16.67 with SMTP id f64mr4191314lfi.100.1498665624989; Wed, 28 Jun 2017 09:00:24 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.160.204 with HTTP; Wed, 28 Jun 2017 09:00:24 -0700 (PDT)
In-Reply-To: 
References: 
From: Nik Tomkinson 
Date: Wed, 28 Jun 2017 17:00:24 +0100
Message-ID: 
To: Bernard Aboba 
Cc: slim@ietf.org, draft-ietf-slim-multilangcontent@ietf.org
Content-Type: multipart/alternative; boundary="001a113f89ea36f5fe055307482c"
Archived-At: 
Subject: Re: [Slim] IPR policy conformance statement for draft-ietf-slim-multilangcontent
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Jun 2017 16:00:34 -0000

--001a113f89ea36f5fe055307482c
Content-Type: text/plain; charset="UTF-8"

I am not aware of any IPR that applies to this draft.

Thanks,

Nik.

On 22 June 2017 at 23:00, Bernard Aboba  wrote:

> Dear Authors:
>
> The SLIM WG is considering requesting that the IESG publish
> draft-ietf-slim-multilangcontent-08 as a Proposed Standard RFC.
>
> So far, no IPR statements have been submitted relating to draft-ietf-slim-multilangcontent.
> This email represents a final IPR check on this document.
>
> Are you aware of any IPR that applies to this draft?  A reply is required
> from each author before a publication request can be considered.
>
> Thank you,
>
> Bernard Aboba
> (on behalf of the SLIM WG)
>
>


-- 

-----------------------------------------------------------------
Multiple Language Content Type Internet Draft:

https://datatracker.ietf.org/doc/draft-ietf-slim-multilangcontent/

-----------------------------------------------------------------

--001a113f89ea36f5fe055307482c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I am not aware of any IPR that applies to this draft.
=

Thanks,

Nik.

On 22 June 2017 at 23:00, B=
ernard Aboba <bernard.aboba@gmail.com> wrote:
Dear Authors:=C2=A0

The SLIM WG is considering requesting that the IESG publish draft-ie=
tf-slim-multilangcontent-08 as a Proposed Standard RFC.=C2=A0

So far, no IPR statements have been submitted relating to =
draft-ietf-slim-multilangcontent.=C2=A0 This email represents a final =
IPR check on this document.=C2=A0

Are you aware of=
 any IPR that applies to this draft?=C2=A0 A reply is required from each au=
thor before a publication request can be considered.

Thank you,

Bernard Aboba
(on behalf o=
f the SLIM WG)






-- 
------------------------=
-----------------------------------------
Multiple Language Content Type=
 Internet Draft:
https://datatracker=
.ietf.org/doc/draft-ietf-slim-multilangcontent/
------------------------------------=
-----------------------------

<=
/div>




--001a113f89ea36f5fe055307482c--


From nobody Wed Jun 28 09:28:34 2017
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 3DA18129B73 for ; Wed, 28 Jun 2017 09:22:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level: 
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mimecast.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 x4tGwNvFIo3v for ; Wed, 28 Jun 2017 09:22:08 -0700 (PDT)
Received: from eu-smtp-1.mimecast.com (service-alpha-outbound1.mimecast.com [195.130.217.223]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0C1B129B6A for ; Wed, 28 Jun 2017 09:22:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mimecast.com; s=20130419; t=1498666926; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references; bh=HwRUTFsfuwL7e+d/QpjsZ1fNfcwIkOaZR3XLuOSbLZ4=; b=CqP1CXQWZh5MvsiBsyzp9tEIh0ZHLS5BCOQa5RCGMIDDu7sNMJ/DoEMMTKplQdEJQ7gOShwAis7wKhLGNNCAzisDwIx7PVY1iPUjyrDiBOazagmRLftexEt0fonNl67exAZioQRaKlmvv9ZeL+fgU0aXTknBuGz+Zhg3NWmrfo0=
Received: from remote.mimecast.com (146.101.202.137 [146.101.202.137]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-sl-a-udNo2c5wOVe0S2-B7xDiSA-1; Wed, 28 Jun 2017 17:22:03 +0100
Received: from MC-LHC-EXCH08.mcsltd.internal ([fe80::2459:f4b9:c98f:818c]) by MC-LHC-EXCH07.mcsltd.internal ([fe80::6c49:2c15:7e95:e4e2%16]) with mapi id 14.03.0319.002; Wed, 28 Jun 2017 17:22:03 +0100
From: Nathaniel Borenstein 
To: Bernard Aboba 
CC: "slim@ietf.org" , "draft-ietf-slim-multilangcontent@ietf.org" 
Thread-Topic: [Slim] IPR policy conformance statement for draft-ietf-slim-multilangcontent
Thread-Index: AQHS8Cqsa/EuAtBz9Uyh6uqpoMqyHA==
Date: Wed, 28 Jun 2017 16:22:02 +0000
Message-ID: <14B144C1-B110-429E-B6D9-A158ADE103A3@mimecast.com>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [184.21.151.20]
MIME-Version: 1.0
X-MC-Unique: udNo2c5wOVe0S2-B7xDiSA-1
Content-Type: multipart/alternative; boundary="_000_14B144C1B110429EB6D9A158ADE103A3mimecastcom_"
Archived-At: 
X-Mailman-Approved-At: Wed, 28 Jun 2017 09:28:33 -0700
Subject: Re: [Slim] IPR policy conformance statement for draft-ietf-slim-multilangcontent
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Jun 2017 16:22:12 -0000

--_000_14B144C1B110429EB6D9A158ADE103A3mimecastcom_
Content-Type: text/plain; charset=WINDOWS-1252
Content-Transfer-Encoding: quoted-printable

I am not aware of any IPR that applies to this draft.  -- Nathaniel

On Jun 22, 2017, at 6:00 PM, Bernard Aboba > wrote:

Dear Authors:

The SLIM WG is considering requesting that the IESG publish draft-ietf-slim=
-multilangcontent-08 as a Proposed Standard RFC.

So far, no IPR statements have been submitted relating to draft-ietf-slim-m=
ultilangcontent.  This email represents a final IPR check on this document.

Are you aware of any IPR that applies to this draft?  A reply is required f=
rom each author before a publication request can be considered.

Thank you,

Bernard Aboba
(on behalf of the SLIM WG)

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


--_000_14B144C1B110429EB6D9A158ADE103A3mimecastcom_
Content-Type: text/html; charset=WINDOWS-1252
Content-ID: <42FD17E1CDA3404A83A0C117CA679CC7@mimecast.com>
Content-Transfer-Encoding: quoted-printable






I am not aware of any IPR that=
 applies to this draft.  -- Nathaniel








On Jun 22, 2017, at 6:00 PM, Bernard Aboba <bernard.aboba@gmail.com> w=
rote:






Dear Authors: 






The SLIM WG is considering requesting that the IESG publish=
 draft-ietf-slim-multilangcontent-08 as a Proposed Standard RFC. 






So far, no IPR statements have been submitted relating to d=
raft-ietf-slim-multilangcontent.  This email represents a final IPR ch=
eck on this document. 







Are you aware of any IPR that applies to this draft?  =
A reply is required from each author before a publication request can be co=
nsidered.







Thank you,







Bernard Aboba


(on behalf of the SLIM WG)








_______________________________________________

SLIM mailing list

SLIM@ietf.org

https://www.ietf.org/mailman/listinfo/slim














--_000_14B144C1B110429EB6D9A158ADE103A3mimecastcom_--


From nobody Wed Jun 28 12:05:25 2017
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 0526C12EABD for ; Wed, 28 Jun 2017 12:05:24 -0700 (PDT)
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 yOVR95mIJO3t for ; Wed, 28 Jun 2017 12:05:21 -0700 (PDT)
Received: from bin-vsp-out-03.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 0EF0A128768 for ; Wed, 28 Jun 2017 12:05:20 -0700 (PDT)
X-Halon-ID: b8fedb73-5c34-11e7-8604-0050569116f7
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [77.53.230.196]) by bin-vsp-out-03.atm.binero.net (Halon) with ESMTPSA id b8fedb73-5c34-11e7-8604-0050569116f7; Wed, 28 Jun 2017 21:05:17 +0200 (CEST)
To: "slim@ietf.org" , Steve Slevinski 
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: <01926268-3210-d48e-66a0-fd34b81edb30@omnitor.se>
Date: Wed, 28 Jun 2017 21:05:16 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------1881A7AE3DA5699B0165E360"
Archived-At: 
Subject: [Slim] Sign language in the text stream is a valid combination for real-time communication
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Jun 2017 19:05:24 -0000

This is a multi-part message in MIME format.
--------------1881A7AE3DA5699B0165E360
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

I just got aware of work with specifying sign language in text media.

It was by recent announcement of a new draft about Signwriting.

https://datatracker.ietf.org/doc/draft-slevinski-formal-signwriting/

I suggest that we let this cause a slight change in 
draft-ietf-slim-negotiating-human-language

I am copying to the author, Steve Slevinski.

We discussed earlier the unusual combinations of language and media. I 
told about Signwriting and other script systems for sign language in the 
text stream.
Signwriting in text can be explicitly indicated by combining a language 
subtag for the intended sign language with the script subtag for 
Signwriting -sgnw  ( thus for example    ase-sgnw   for American sign 
language written in text with the Signwriting script). In certain use 
the -sgnw may also be assumed and therefore omitted.

It is not at all common to use Signwriting in real-time conversational 
mode, but I think it is not good that we exclude it by a statement in 
section 5.4

In section 5.4, we say that sign language in written mode is undefined. 
With background from what I just found, I suggest that we at least allow 
it to be defined. We may also explain how sign language can be used in 
the text stream.

Therefore, I suggest this minimal change:
---------------------------old text 1 in 
5.4-------------------------------------

the behavior when specifying a spoken/written language tag for a video media stream, or a signed language tag for an audio or text media stream, is not defined.

--------------------------new text---------------------------------

the behavior when specifying a spoken/written language tag for a video media stream, or a signed language tag for an audio media stream, is not defined.

--------------------------end of change 
1------------------------------------

--------------------possible change 2 in 5.2----------------------------
--------------new paragraph three from end of 
5.2--------------------------------
Sign language in the text stream may occur, e.g. by use of an IANA 
registered script for notation of sign language.
Example: ase-sgnw     for American Sign Language written with 
Signwriting script.
---------------end of new paragraph in 
5.2------------------------------------


Regards
Gunnar



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


--------------1881A7AE3DA5699B0165E360
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  

    
  
  
    
I just got aware of work with specifying sign language in text
      media. 

    

    
It was by recent announcement of a new draft about Signwriting. 

    

    https://datatracker.ietf.org/doc/draft-slevinski-formal-signwriting/

    

    I suggest that we let this cause a slight change in
    draft-ietf-slim-negotiating-human-language

    

    I am copying to the author, Steve Slevinski.

    

    We discussed earlier the unusual combinations of language and media.
    I told about Signwriting and other script systems for sign language
    in the text stream. 

    Signwriting in text can be explicitly indicated by combining a
    language subtag for the intended sign language with the script
    subtag for Signwriting -sgnw  ( thus for example    ase-sgnw   for
    American sign language written in text with the Signwriting script).
    In certain use the -sgnw may also be assumed and therefore omitted.
    

    

    It is not at all common to use Signwriting in real-time
    conversational mode, but I think it is not good that we exclude it
    by a statement in section 5.4 

    

    In section 5.4, we say that sign language in written mode is
    undefined. With background from what I just found, I suggest that we
    at least allow it to be defined. We may also explain how sign
    language can be used in the text stream.

    

    Therefore, I suggest this minimal change:

    ---------------------------old text 1 in
    5.4-------------------------------------

    
the behavior when specifying a spoken/written language tag for a video media stream, or a signed language tag for an audio or text media stream, is not defined.

    --------------------------new text---------------------------------

    

    
the behavior when specifying a spoken/written language tag for a video media stream, or a signed language tag for an audio media stream, is not defined.

    --------------------------end of change
    1------------------------------------

    

    --------------------possible change 2 in
    5.2----------------------------

    --------------new paragraph three from end of
    5.2--------------------------------

    Sign language in the text stream may occur, e.g. by use of an IANA
    registered script for notation of sign language.

    Example: ase-sgnw     for American Sign Language written with
    Signwriting script.

    ---------------end of new paragraph in
    5.2------------------------------------

    

    

    Regards

    Gunnar

    

    

     

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

  


--------------1881A7AE3DA5699B0165E360--


From nobody Wed Jun 28 19:19:10 2017
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 23CB1126C2F for ; Wed, 28 Jun 2017 19:19:09 -0700 (PDT)
X-Quarantine-ID: 
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 rr6yR634ufjd for ; Wed, 28 Jun 2017 19:19:07 -0700 (PDT)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 3980A1201F2 for ; Wed, 28 Jun 2017 19:19:07 -0700 (PDT)
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Wed, 28 Jun 2017 19:21:59 -0700
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <01926268-3210-d48e-66a0-fd34b81edb30@omnitor.se>
References: <01926268-3210-d48e-66a0-fd34b81edb30@omnitor.se>
X-Mailer: Eudora for Mac OS X
Date: Wed, 28 Jun 2017 19:18:55 -0700
To: Gunnar =?iso-8859-1?Q?Hellstr=F6m?=  , "slim@ietf.org" , Steve Slevinski 
From: Randall Gellens 
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [Slim] Sign language in the text stream is a valid combination for real-time communication
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, 29 Jun 2017 02:19:09 -0000

At 9:05 PM +0200 6/28/17, Gunnar Hellstr=F6m wrote:

>  I just got aware of work with specifying sign language in text media.
>
>  It was by recent announcement of a new draft about Signwriting.
>
>=20
> http=
s://datatracker.ietf.org/doc/draft-slevinski-formal-signwriting/
>
>  I suggest that we let this cause a slight=20
> change in=20
> draft-ietf-slim-negotiating-human-language
>
>  I am copying to the author, Steve Slevinski.
>
>  We discussed earlier the unusual combinations=20
> of language and media. I told about Signwriting=20
> and other script systems for sign language in=20
> the text stream.
>  Signwriting in text can be explicitly indicated=20
> by combining a language subtag for the intended=20
> sign language with the script subtag for=20
> Signwriting -sgnw ( thus for example ase-sgnw=20
> for American sign language written in text with=20
> the Signwriting script). In certain use the=20
> -sgnw may also be assumed and therefore omitted.
>
>  It is not at all common to use Signwriting in=20
> real-time conversational mode, but I think it=20
> is not good that we exclude it by a statement=20
> in section 5.4
>
>  In section 5.4, we say that sign language in=20
> written mode is undefined. With background from=20
> what I just found, I suggest that we at least=20
> allow it to be defined. We may also explain how=20
> sign language can be used in the text stream.
>
>  Therefore, I suggest this minimal change:
>  ---------------------------old text 1 in=20
> 5.4-------------------------------------
>  the behavior when specifying a spoken/written=20
> language tag for a video media stream, or a=20
> signed language tag for an audio or text media=20
> stream, is not defined.
>  --------------------------new text---------------------------------
>
>  the behavior when specifying a spoken/written=20
> language tag for a video media stream, or a=20
> signed language tag for an audio media stream,=20
> is not defined.
>  --------------------------end of change 1--------------------------------=
----
>
>  --------------------possible change 2 in 5.2----------------------------
>  --------------new paragraph three from end of=20
> 5.2--------------------------------
>  Sign language in the text stream may occur,=20
> e.g. by use of an IANA registered script for=20
> notation of sign language.
>  Example: ase-sgnw for American Sign Language written with Signwriting scr=
ipt.
>  ---------------end of new paragraph in=20
> 5.2------------------------------------

The draft currently says it is undefined.  This=20
is not the same as prohibited.  A future draft=20
can extend this one by specifying how it is used.=20
I think it's better to keep this draft as simple=20
as possible, so if we don't expect this to be=20
used, let's not add text about it.  If it does=20
seem useful in the future, it can be added with=20
minimal fuss.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Never doubt that a small group of thoughtful, committed citizens can
change the world.  Indeed, it's the only thing that ever has.
                                                     --Margaret Meed


From nobody Wed Jun 28 22:49:33 2017
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 ED485127867 for ; Wed, 28 Jun 2017 22:49:31 -0700 (PDT)
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, 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 5hO4gwSMgB4Q for ; Wed, 28 Jun 2017 22:49:29 -0700 (PDT)
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 70C9D1275C5 for ; Wed, 28 Jun 2017 22:49:29 -0700 (PDT)
X-Halon-ID: b446fcc8-5c8e-11e7-ba8e-005056917f90
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [77.53.36.99]) by bin-vsp-out-02.atm.binero.net (Halon) with ESMTPSA id b446fcc8-5c8e-11e7-ba8e-005056917f90; Thu, 29 Jun 2017 07:49:24 +0200 (CEST)
To: Randall Gellens , "slim@ietf.org" , Steve Slevinski 
References: <01926268-3210-d48e-66a0-fd34b81edb30@omnitor.se> 
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: 
Date: Thu, 29 Jun 2017 07:49:22 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [Slim] Sign language in the text stream is a valid combination for real-time communication
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, 29 Jun 2017 05:49:32 -0000

Den 2017-06-29 kl. 04:18, skrev Randall Gellens:
> At 9:05 PM +0200 6/28/17, Gunnar Hellström wrote:
>
>>  I just got aware of work with specifying sign language in text media.
>>
>>  It was by recent announcement of a new draft about Signwriting.
>>
>>
>> https://datatracker.ietf.org/doc/draft-slevinski-formal-signwriting/ 
>>
>>
>>  I suggest that we let this cause a slight change in 
>> draft-ietf-slim-negotiating-human-language
>>
>>  I am copying to the author, Steve Slevinski.
>>
>>  We discussed earlier the unusual combinations of language and media. 
>> I told about Signwriting and other script systems for sign language 
>> in the text stream.
>>  Signwriting in text can be explicitly indicated by combining a 
>> language subtag for the intended sign language with the script subtag 
>> for Signwriting -sgnw ( thus for example ase-sgnw for American sign 
>> language written in text with the Signwriting script). In certain use 
>> the -sgnw may also be assumed and therefore omitted.
>>
>>  It is not at all common to use Signwriting in real-time 
>> conversational mode, but I think it is not good that we exclude it by 
>> a statement in section 5.4
>>
>>  In section 5.4, we say that sign language in written mode is 
>> undefined. With background from what I just found, I suggest that we 
>> at least allow it to be defined. We may also explain how sign 
>> language can be used in the text stream.
>>
>>  Therefore, I suggest this minimal change:
>>  ---------------------------old text 1 in 
>> 5.4-------------------------------------
>>  the behavior when specifying a spoken/written language tag for a 
>> video media stream, or a signed language tag for an audio or text 
>> media stream, is not defined.
>>  --------------------------new text---------------------------------
>>
>>  the behavior when specifying a spoken/written language tag for a 
>> video media stream, or a signed language tag for an audio media 
>> stream, is not defined.
>>  --------------------------end of change 
>> 1------------------------------------
>>
>>  --------------------possible change 2 in 
>> 5.2----------------------------
>>  --------------new paragraph three from end of 
>> 5.2--------------------------------
>>  Sign language in the text stream may occur, e.g. by use of an IANA 
>> registered script for notation of sign language.
>>  Example: ase-sgnw for American Sign Language written with 
>> Signwriting script.
>>  ---------------end of new paragraph in 
>> 5.2------------------------------------
>
> The draft currently says it is undefined.  This is not the same as 
> prohibited.
I see "undefined" as a very strong warning to not use it, and as a 
message to implementers that they do not need to cater for the undefined 
case.
> A future draft can extend this one by specifying how it is used. 
OK, I can accept to not add the explanation in change 2.
> I think it's better to keep this draft as simple as possible, so if we 
> don't expect this to be used, let's not add text about it.
OK, that means that you accept change 1, to delete "text" from the 
sentence in 5.4. Good.
> If it does seem useful in the future, it can be added with minimal fuss.
It is not as easy as you claim to add things in the future. When I 
finally tried to move my request for an indication of modality 
preference from the current draft to an extension, it immediately 
created risks for interop problems between implementations made before 
the extension and the ones using the extension. So, I needed to create a 
totally self-sustained solution. (draft-hellstrom-modality-grouping). We 
also discussed to make the syntax extensible, but found that we just 
added complexity without being sure that we would cover any future 
requests for extensions.

Gunnar

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


From nobody Thu Jun 29 07:23:44 2017
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 6881D120724 for ; Thu, 29 Jun 2017 07:23:43 -0700 (PDT)
X-Quarantine-ID: 
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 kqxt4BOi6xLs for ; Thu, 29 Jun 2017 07:23:41 -0700 (PDT)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 0FFC9129B2A for ; Thu, 29 Jun 2017 07:23:41 -0700 (PDT)
Received: from [192.168.1.189] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Thu, 29 Jun 2017 07:26:31 -0700
Mime-Version: 1.0
Message-Id: 
In-Reply-To: 
References: <01926268-3210-d48e-66a0-fd34b81edb30@omnitor.se>  
X-Mailer: Eudora for Mac OS X
Date: Thu, 29 Jun 2017 07:23:23 -0700
To: Gunnar =?iso-8859-1?Q?Hellstr=F6m?=  , "slim@ietf.org" , Steve Slevinski 
From: Randall Gellens 
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [Slim] Sign language in the text stream is a valid combination for real-time communication
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, 29 Jun 2017 14:23:43 -0000

At 7:49 AM +0200 6/29/17, Gunnar Hellstr=F6m wrote:

>  Den 2017-06-29 kl. 04:18, skrev Randall Gellens:
>>  At 9:05 PM +0200 6/28/17, Gunnar Hellstr=F6m wrote:
>>
>>>   I just got aware of work with specifying sign language in text media.
>>>
>>>   It was by recent announcement of a new draft about Signwriting.
>>>
>>>
>>>=20
>>> ht=
tps://datatracker.ietf.org/doc/draft-slevinski-formal-signwriting/
>>>
>>>   I suggest that we let this cause a slight=20
>>> change in=20
>>> draft-ietf-slim-negotiating-human-language
>>>
>>>   I am copying to the author, Steve Slevinski.
>>>
>>>   We discussed earlier the unusual=20
>>> combinations of language and media. I told=20
>>> about Signwriting and other script systems=20
>>> for sign language in the text stream.
>>>   Signwriting in text can be explicitly=20
>>> indicated by combining a language subtag for=20
>>> the intended sign language with the script=20
>>> subtag for Signwriting -sgnw ( thus for=20
>>> example ase-sgnw for American sign language=20
>>> written in text with the Signwriting script).=20
>>> In certain use the -sgnw may also be assumed=20
>>> and therefore omitted.
>>>
>>>   It is not at all common to use Signwriting=20
>>> in real-time conversational mode, but I think=20
>>> it is not good that we exclude it by a=20
>>> statement in section 5.4
>>>
>>>   In section 5.4, we say that sign language in=20
>>> written mode is undefined. With background=20
>>> from what I just found, I suggest that we at=20
>>> least allow it to be defined. We may also=20
>>> explain how sign language can be used in the=20
>>> text stream.
>>>
>>>   Therefore, I suggest this minimal change:
>>>   ---------------------------old text 1 in=20
>>> 5.4-------------------------------------
>>>   the behavior when specifying a=20
>>> spoken/written language tag for a video media=20
>>> stream, or a signed language tag for an audio=20
>>> or text media stream, is not defined.
>>>   --------------------------new text---------------------------------
>>>
>>>   the behavior when specifying a=20
>>> spoken/written language tag for a video media=20
>>> stream, or a signed language tag for an audio=20
>>> media stream, is not defined.
>>>   --------------------------end of change=20
>>> 1------------------------------------
>>>
>>>   --------------------possible change 2 in 5.2--------------------------=
--
>>>   --------------new paragraph three from end=20
>>> of 5.2--------------------------------
>>>   Sign language in the text stream may occur,=20
>>> e.g. by use of an IANA registered script for=20
>>> notation of sign language.
>>>   Example: ase-sgnw for American Sign Language=20
>>> written with Signwriting script.
>>>   ---------------end of new paragraph in=20
>>> 5.2------------------------------------
>>
>>  The draft currently says it is undefined.=20
>> This is not the same as prohibited.
>  I see "undefined" as a very strong warning to=20
> not use it, and as a message to implementers=20
> that they do not need to cater for the=20
> undefined case.
>>  A future draft can extend this one by specifying how it is used.
>  OK, I can accept to not add the explanation in change 2.
>>  I think it's better to keep this draft as=20
>> simple as possible, so if we don't expect this=20
>> to be used, let's not add text about it.
>  OK, that means that you accept change 1, to=20
> delete "text" from the sentence in 5.4. Good.

I'm suggesting we leave this as "undefined" in the current draft.

>>  If it does seem useful in the future, it can be added with minimal fuss.
>  It is not as easy as you claim to add things in=20
> the future. When I finally tried to move my=20
> request for an indication of modality=20
> preference from the current draft to an=20
> extension, it immediately created risks for=20
> interop problems between implementations made=20
> before the extension and the ones using the=20
> extension. So, I needed to create a totally=20
> self-sustained solution.=20
> (draft-hellstrom-modality-grouping). We also=20
> discussed to make the syntax extensible, but=20
> found that we just added complexity without=20
> being sure that we would cover any future=20
> requests for extensions.

It depends on the situation.  In the case of=20
signed languages in text or audio, leaving this=20
as "undefined" in the current draft should make=20
it easy to add in the future, since to an old=20
implementation, such use is not prohibited, and=20
also does not have semantics.  If it is needed in=20
the future (which seems unlikely), a new draft=20
can specify semantics for it.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
I never fail to convince an audience that the best thing they could do
was to go away.


From nobody Thu Jun 29 20:15:20 2017
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 D30F212EB01 for ; Thu, 29 Jun 2017 20:15:18 -0700 (PDT)
X-Quarantine-ID: 
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 moKO1MBFZpnx for ; Thu, 29 Jun 2017 20:15:16 -0700 (PDT)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 40518129B05 for ; Thu, 29 Jun 2017 20:15:16 -0700 (PDT)
Received: from [192.168.1.189] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Thu, 29 Jun 2017 20:18:09 -0700
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <8cbb2083-b02f-20eb-ab7f-a03c85cb95f8@omnitor.se>
References: <149826161364.7680.4546115441019121579@ietfa.amsl.com> <8cbb2083-b02f-20eb-ab7f-a03c85cb95f8@omnitor.se>
X-Mailer: Eudora for Mac OS X
Date: Thu, 29 Jun 2017 20:15:11 -0700
To: Gunnar =?iso-8859-1?Q?Hellstr=F6m?=  , slim@ietf.org
From: Randall Gellens 
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [Slim] I-D Action: draft-ietf-slim-negotiating-human-language-11.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: Fri, 30 Jun 2017 03:15:19 -0000

At 11:30 AM +0200 6/26/17, Gunnar Hellstr=F6m wrote:

>  Good to see progress.
>
>  I checked the numbered change proposals I=20
> submitted earlier under subject " I-D Action:=20
> draft-ietf-slim-negotiating-human-language-10.txt"=20
> and found that most of them were solved or=20
> agreed to be ignored. Only proposal 2.2 was not=20
> acted on, so I repeat it here together with a=20
> few new findings:
>
>  -----Issue 1, old 2.2 The attributes can appear=20
> in both offers and answers -----------
>  -------Old text 2.2 at end of first paragraph of 5.2---------
>
>
>  Each can appear in an offer for a media
>  stream.
>  --New text 2.2---
>  Each can appear in an offer and answer for a media
>  stream.
>  ---Reasoning:----------
>
>  This paragraph is an introduction to the=20
> attributes. It should mention the full use, in=20
> both offer and answer. The following paragraphs=20
> tell about specifics for offer vs answer.
>  --End of change 2.2---
>
>  ---End of Issue 1----------

Yes, I agree.

>
>  ------Issue 2 , reduce info on possible=20
> extensions to not be solution specific----------
>
>  In section 5.2, middle:
>
>  -----Old text------------
>
>    See Section 5.3 for more
>     information and discussion.  Note that separate work
>     [I-D.hellstrom-slim-modalitypref] extends the use of the asterisk to
>     convey additional information regarding language/modality preferences
>     among media.
>
>  -----New text proposal for Issue 2-----------
>
>      See Section 5.3 for more information and discussion.
>  
>     Note that separate work may introduce=20
> additional information regarding=20
> language/modality
>     preferences among media.
>
>  ---Reasoning: ---------
>  Two ways to convey language/modality=20
> preferences among media have been proposed, one=20
> based on the asterisk=20
> (draft-hellstrom-slim-modalitypref), and=20
> another based on the SDP gouping framework=20
> (draft-hellstrom-language-grouping). There are=20
> drafts for both. The clean one seems to be the=20
> method based on SDP grouping. It has no known=20
> interoperability problems.
>   The proposed wording of the note (as a=20
> separate paragraph) is intended to cover both=20
> methods, but has less effect as a warning=20
> against interoperabitlity problems caused by=20
> the asterisk based solution.
>
>  A decision is needed for which alternative to=20
> continue with, I prefer the one based on SDP=20
> grouping.
>
>
>
>  -----End of issue 2-----------------------

I will go back to my original wording, which I=20
think was specific enough to give readers of this=20
document a hint to read yours, and general enough=20
to not constrain your document:

     "uses the asterisk (or lack thereof) to=20
convey additional information between endpoints."

>
>  ------Issue 3 - typo in 5.5------------
>
>  Typo in section 5.5, at the end of page 9
>
>  -------old text-----
>  An offer of answer
>  -----new text----
>
>     An offer or answer
>  -----end of issue 3------

Thanks.

>
>  ----Issue 4  allow asterisks also in answers,=20
> but do not assign a meaning---------
>  The second example in 5.5 has asterisks last in=20
> the attributes and says that the example can be=20
> either an offer or an answer.

That's an error, thanks for catching it.  It should say "an offer".

>
>  But section 5.2, fourth paragraph currently=20
> only says that the asterisk can appear in an=20
> offer.

It doesn't prohibit an asterisk in an answer, but=20
it only defines the meaning of an asterisk in an=20
offer.  I suggest we leave it this way.  Your=20
draft can then define the meaning of an asterisk=20
in an offer.  Note that the ABNF defining the=20
syntax does not differentiate between an offer=20
and an answer, hence, an asterisk is technically=20
permitted in an answer.  For clarity, I will add=20
to 5.2:

     An asterisk appended to any value in any media in an answer is undefine=
d.

>
>  I suggest to amend this by allowing the=20
> asterisk to appear in an answer, but not assign=20
> any meaning to it.
>  This is more future proof and may make=20
> implementation of the answering part easier=20
> than keeping the currect restriction.
>
>  ------New paragraph after paragraph four in 5.2-------
>  The asterisk token MAY also be appended last in=20
> a 'hlang' attribute in an answer, but this=20
> specification does not define any meaning to an=20
> asterisk in that position.
>  ------End of proposal for Issue 4...........
>  -----End of Issue 4----------------
>   ----Issue 5 correct SDP syntax in answer=20
> example on page 10 -------------------
>  In the answer example in section 5.5 on page=20
> 10, the answer shows no video m-line. There was=20
> an m-lne for video in the offer, then one must=20
> be included in the aswer.
>
>  ---old text in 5.5----
>     An answer for the above offer, indicating text in which the callee
>     will receive written Spanish, and audio in which the callee will send
>     spoken Spanish:
>
>        m=3Dtext 45020 RTP/AVP 103 104
>        a=3Dhlang-recv:sp
>
>        m=3Daudio 49250 RTP/AVP 20
>        a=3Dhlang-send:sp
>
>  -------new text-----------
>     An answer for the above offer, indicating text in which the callee
>     will receive written Spanish, and audio in which the callee will send
>     spoken Spanish. The answering party had no video capability:
>
>        m=3Dvideo 0 RTP/AVP 31 32
>        m=3Dtext 45020 RTP/AVP 103 104
>        a=3Dhlang-recv:sp
>
>        m=3Daudio 49250 RTP/AVP 20
>        a=3Dhlang-send:sp
>
>
>  ---------end of proposal------------
>  --------end of Issue 5---------------

Thanks.

>
>  --------Issue 6 - most examples have asterisks=20
> on all attributes, reduce number of asterisks=20
> -------
>  In section 5.5 Examples, nearly all examples=20
> including the use of the asterisk has the=20
> asterisk on all attribute lines in the whole=20
> SDP, even if it is sufficient to have it on one=20
> attribute. I think this might have confused the=20
> reviewers and caused some of the thoughts about=20
> assumed grouping and linking and wondering=20
> about semantic rules around the asterisk that=20
> was not intended by the draft.
>  --------Proposed action for Issue 6------------
>  Delete some of the asterisks in the examples in=20
> section 5.5, so that only one example has=20
> asterisks on all attributes and the others have=20
> just one or a varying number of asterisks.
>  --------End of issue 6-----------------------------------

OK.

>
>  --------Issue 7 Missing link to 'hlang-value'=20
> in the syntax section 6.1-------------------
>
>  I suggest to insert a line in two places to=20
> link the attribute to the 'hlang-value' syntax=20
> description, matching the format used in=20
> rfc4566bis.
>
>  ------Old text in two places in section 6.1--------
>   Attribute Syntax:
>
>  --------New text in two places in section 6.1-----
>    Value: hlang-value
>    Attribute Syntax:
>
>  ---------End of Issue 7.----------------

OK.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Invention is the mother of necessity.       --Thorstein Veblen


From nobody Thu Jun 29 22:44:18 2017
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 2FB17127866 for ; Thu, 29 Jun 2017 22:44:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.934
X-Spam-Level: 
X-Spam-Status: No, score=-1.934 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_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.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 ZtEHNb1NVHMv for ; Thu, 29 Jun 2017 22:44:14 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFEC4127698 for ; Thu, 29 Jun 2017 22:44:13 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 086ED20BA8 for ; Fri, 30 Jun 2017 01:44:13 -0400 (EDT)
Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Fri, 30 Jun 2017 01:44:13 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc :x-sasl-enc; s=fm1; bh=ZhXhy4FfrXLLokRNZai/vUvGyuZZdki/hVnEguybN e0=; b=FsVwnyW5c8NwEWTkbGro/M74rwdU4vE/p+94/9SAaAhrtOchHAN2fIPdQ U4hrEx9m97aYVVaXAJAVSZYOO6l4x2+SDvcY3Cx5+ja9rZuwDZFDtdxz9E7bDppS WeMwRRYDRo/a5NaZHt7JfucMXcBuB8X5v+k9cflxg8+S+K0JqdjW4U1uNtgIJLJ3 mGKANYrZZLlGI5a3vld6fUPWxt/fSIoWektJgDPdfvVSG2b+3gQyu3SWaKN/01sQ /hZg6LUlLyZ435zt4ixkZCw2XoMIsU2WeiU0Mgm4XV7wnN8h0QWdsVgwRvvmOfel l2fC02MqXxbRvfkflmuZ+Lgbv90rA==
X-ME-Sender: 
X-Sasl-enc: mQPCKvePDXYTBlJuPIR6bLIYC+Z7xWwFp6W5ckC59Aec 1498801452
Received: from [192.168.88.71] (unknown [116.236.165.130]) by mail.messagingengine.com (Postfix) with ESMTPA id 5316D7E46B for ; Fri, 30 Jun 2017 01:44:12 -0400 (EDT)
From: Natasha Rooney 
Content-Type: multipart/alternative; boundary="Apple-Mail=_D37FFB93-D100-4B50-94AA-F0086A172E43"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Message-Id: <15BDE051-1F8A-434A-A87C-A9213057B500@gsma.com>
Date: Fri, 30 Jun 2017 13:44:08 +0800
To: slim@ietf.org
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: [Slim] IETf 99 and interim
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, 30 Jun 2017 05:44:16 -0000

--Apple-Mail=_D37FFB93-D100-4B50-94AA-F0086A172E43
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi all,

On reflection, given many people will be absent from IETF99 and the =
issues experienced when running a meeting with a large part of the group =
being on the phone we have decided to cancel our IETF99 meeting slot and =
hold a teleconference interim meeting in August.

Editors (Randall, Nik, Gunnar): are you working during August? Any block =
out dates?

I=E2=80=99ll make the request to cancel the meeting now. When the =
editors respond with their ability for August we will work to find a =
time suitable for as many people as possible for the interim meeting.=20

Many thanks!

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


--Apple-Mail=_D37FFB93-D100-4B50-94AA-F0086A172E43
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Hi all,

On =
reflection, given many people will be absent from IETF99 and the issues =
experienced when running a meeting with a large part of the group being =
on the phone we have decided to cancel our IETF99 meeting slot and hold =
a teleconference interim meeting in August.

Editors (Randall, Nik, Gunnar): are you =
working during August? Any block out dates?

I=E2=80=99ll make the request to cancel =
the meeting now. When the editors respond with their ability for August =
we will work to find a time suitable for as many people as possible for =
the interim meeting. 

Many thanks!



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






=

--Apple-Mail=_D37FFB93-D100-4B50-94AA-F0086A172E43--


From nobody Thu Jun 29 22:51:49 2017
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 7D18C1201F2 for ; Thu, 29 Jun 2017 22:51:48 -0700 (PDT)
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 WyuRAWbMTc51 for ; Thu, 29 Jun 2017 22:51:46 -0700 (PDT)
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 1430D1200CF for ; Thu, 29 Jun 2017 22:51:45 -0700 (PDT)
X-Halon-ID: 2fcc05d6-5d58-11e7-ba8f-005056917f90
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [77.53.36.99]) by bin-vsp-out-02.atm.binero.net (Halon) with ESMTPSA id 2fcc05d6-5d58-11e7-ba8f-005056917f90; Fri, 30 Jun 2017 07:51:40 +0200 (CEST)
To: Natasha Rooney , slim@ietf.org
References: <15BDE051-1F8A-434A-A87C-A9213057B500@gsma.com>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: <0b987d3e-efaf-d020-2438-10f6acc9407f@omnitor.se>
Date: Fri, 30 Jun 2017 07:51:38 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <15BDE051-1F8A-434A-A87C-A9213057B500@gsma.com>
Content-Type: multipart/alternative; boundary="------------F0644CB21A8F150A5A6606AD"
Archived-At: 
Subject: Re: [Slim] IETf 99 and interim
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, 30 Jun 2017 05:51:48 -0000

This is a multi-part message in MIME format.
--------------F0644CB21A8F150A5A6606AD
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

I am available in August.

No specific blocked dates except Aug 30 evening time CET.

/Gunnar


Den 2017-06-30 kl. 07:44, skrev Natasha Rooney:
> Hi all,
>
> On reflection, given many people will be absent from IETF99 and the issues experienced when running a meeting with a large part of the group being on the phone we have decided to cancel our IETF99 meeting slot and hold a teleconference interim meeting in August.
>
> Editors (Randall, Nik, Gunnar): are you working during August? Any block out dates?
>
> I’ll make the request to cancel the meeting now. When the editors respond with their ability for August we will work to find a time suitable for as many people as possible for the interim meeting.
>
> Many thanks!
>
> Natasha Rooney | Internet Engineering Director | Internet and Web Team | Technology | GSMA | nrooney@gsma.com | +44 (0) 7730 219 765 | @thisNatasha | Skype: nrooney@gsm.org
>
>
>
>
> _______________________________________________
> 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


--------------F0644CB21A8F150A5A6606AD
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
I am available in August. 

    

    
No specific blocked dates except Aug 30 evening time CET.

    

    
/Gunnar

    

    

    
Den 2017-06-30 kl. 07:44, skrev Natasha
      Rooney:

    

    

      
Hi all,

On reflection, given many people will be absent from IETF99 and the issues experienced when running a meeting with a large part of the group being on the phone we have decided to cancel our IETF99 meeting slot and hold a teleconference interim meeting in August.

Editors (Randall, Nik, Gunnar): are you working during August? Any block out dates?

I’ll make the request to cancel the meeting now. When the editors respond with their ability for August we will work to find a time suitable for as many people as possible for the interim meeting. 

Many thanks!

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




      

      

      

      
_______________________________________________
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

  


--------------F0644CB21A8F150A5A6606AD--


From nobody Thu Jun 29 23:10:05 2017
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 D3BBD12704A for ; Thu, 29 Jun 2017 23:10:03 -0700 (PDT)
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 c8CB_lxItAXb for ; Thu, 29 Jun 2017 23:10:02 -0700 (PDT)
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 CE6981200CF for ; Thu, 29 Jun 2017 23:10:01 -0700 (PDT)
X-Halon-ID: be067afb-5d5a-11e7-ba8f-005056917f90
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [77.53.36.99]) by bin-vsp-out-02.atm.binero.net (Halon) with ESMTPSA id be067afb-5d5a-11e7-ba8f-005056917f90; Fri, 30 Jun 2017 08:09:58 +0200 (CEST)
To: Randall Gellens , slim@ietf.org
References: <149826161364.7680.4546115441019121579@ietfa.amsl.com> <8cbb2083-b02f-20eb-ab7f-a03c85cb95f8@omnitor.se> 
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: <9c7041be-06ea-106c-90f8-14e2ae4f6abd@omnitor.se>
Date: Fri, 30 Jun 2017 08:09:56 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [Slim] I-D Action: draft-ietf-slim-negotiating-human-language-11.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: Fri, 30 Jun 2017 06:10:04 -0000

Randall,
All your resolutions are fine except for Issue 2. See explanation below.

Den 2017-06-30 kl. 05:15, skrev Randall Gellens:
> At 11:30 AM +0200 6/26/17, Gunnar Hellström wrote:
>
>>  Good to see progress.
>>
>>  I checked the numbered change proposals I submitted earlier under 
>> subject " I-D Action: 
>> draft-ietf-slim-negotiating-human-language-10.txt" and found that 
>> most of them were solved or agreed to be ignored. Only proposal 2.2 
>> was not acted on, so I repeat it here together with a few new findings:
>>
>>  -----Issue 1, old 2.2 The attributes can appear in both offers and 
>> answers -----------
>>  -------Old text 2.2 at end of first paragraph of 5.2---------
>>
>>
>>  Each can appear in an offer for a media
>>  stream.
>>  --New text 2.2---
>>  Each can appear in an offer and answer for a media
>>  stream.
>>  ---Reasoning:----------
>>
>>  This paragraph is an introduction to the attributes. It should 
>> mention the full use, in both offer and answer. The following 
>> paragraphs tell about specifics for offer vs answer.
>>  --End of change 2.2---
>>
>>  ---End of Issue 1----------
>
> Yes, I agree.
>
>>
>>  ------Issue 2 , reduce info on possible extensions to not be 
>> solution specific----------
>>
>>  In section 5.2, middle:
>>
>>  -----Old text------------
>>
>>    See Section 5.3 for more
>>     information and discussion.  Note that separate work
>>     [I-D.hellstrom-slim-modalitypref] extends the use of the asterisk to
>>     convey additional information regarding language/modality 
>> preferences
>>     among media.
>>
>>  -----New text proposal for Issue 2-----------
>>
>>      See Section 5.3 for more information and discussion.
>>  
>>     Note that separate work may introduce additional information 
>> regarding language/modality
>>     preferences among media.
>>
>>  ---Reasoning: ---------
>>  Two ways to convey language/modality preferences among media have 
>> been proposed, one based on the asterisk 
>> (draft-hellstrom-slim-modalitypref), and another based on the SDP 
>> gouping framework (draft-hellstrom-language-grouping). There are 
>> drafts for both. The clean one seems to be the method based on SDP 
>> grouping. It has no known interoperability problems.
>>   The proposed wording of the note (as a separate paragraph) is 
>> intended to cover both methods, but has less effect as a warning 
>> against interoperabitlity problems caused by the asterisk based 
>> solution.
>>
>>  A decision is needed for which alternative to continue with, I 
>> prefer the one based on SDP grouping.
>>
>>
>>
>>  -----End of issue 2-----------------------
>
> I will go back to my original wording, which I think was specific 
> enough to give readers of this document a hint to read yours, and 
> general enough to not constrain your document:
>
>     "uses the asterisk (or lack thereof) to convey additional 
> information between endpoints."
I need the whole sentence to understand the proposal. Do you mean:

"Note that separate work [I-D.hellstrom-slim-modalitypref] extends the 
use of the asterisk (or lack thereof) to
    convey additional information between endpoints."

Or did you mean:

  "Note that separate work extends the use of the asterisk (or lack 
thereof) to
    convey additional information between endpoints."

Anyway, both are currently wrong. I have submitted two alternative 
drafts for the modality preference indication, one adding meaning to the 
asterisk (draft-hellstrom-slim-modalitypref) and the other using SDP 
grouping instead, not touching the asterisk 
(draft-hellstrom-language-grouping). I prefer the SDP grouping proposal, 
but want to hear others' views.  When we have a decision, I will let one 
of them expire and we can sharpen up the note if the draft is still open 
for modifications.

So, at the moment, it is only my proposed wording in a separate note as 
shown above in issue 2 that works.




>
>>
>>  ------Issue 3 - typo in 5.5------------
>>
>>  Typo in section 5.5, at the end of page 9
>>
>>  -------old text-----
>>  An offer of answer
>>  -----new text----
>>
>>     An offer or answer
>>  -----end of issue 3------
>
> Thanks.
>
>>
>>  ----Issue 4  allow asterisks also in answers, but do not assign a 
>> meaning---------
>>  The second example in 5.5 has asterisks last in the attributes and 
>> says that the example can be either an offer or an answer.
>
> That's an error, thanks for catching it.  It should say "an offer".
>
>>
>>  But section 5.2, fourth paragraph currently only says that the 
>> asterisk can appear in an offer.
>
> It doesn't prohibit an asterisk in an answer, but it only defines the 
> meaning of an asterisk in an offer.  I suggest we leave it this way.  
> Your draft can then define the meaning of an asterisk in an offer.  
> Note that the ABNF defining the syntax does not differentiate between 
> an offer and an answer, hence, an asterisk is technically permitted in 
> an answer.  For clarity, I will add to 5.2:
>
>     An asterisk appended to any value in any media in an answer is 
> undefined.
>
>>
>>  I suggest to amend this by allowing the asterisk to appear in an 
>> answer, but not assign any meaning to it.
>>  This is more future proof and may make implementation of the 
>> answering part easier than keeping the currect restriction.
>>
>>  ------New paragraph after paragraph four in 5.2-------
>>  The asterisk token MAY also be appended last in a 'hlang' attribute 
>> in an answer, but this specification does not define any meaning to 
>> an asterisk in that position.
>>  ------End of proposal for Issue 4...........
>>  -----End of Issue 4----------------
>>   ----Issue 5 correct SDP syntax in answer example on page 10 
>> -------------------
>>  In the answer example in section 5.5 on page 10, the answer shows no 
>> video m-line. There was an m-lne for video in the offer, then one 
>> must be included in the aswer.
>>
>>  ---old text in 5.5----
>>     An answer for the above offer, indicating text in which the callee
>>     will receive written Spanish, and audio in which the callee will 
>> send
>>     spoken Spanish:
>>
>>        m=text 45020 RTP/AVP 103 104
>>        a=hlang-recv:sp
>>
>>        m=audio 49250 RTP/AVP 20
>>        a=hlang-send:sp
>>
>>  -------new text-----------
>>     An answer for the above offer, indicating text in which the callee
>>     will receive written Spanish, and audio in which the callee will 
>> send
>>     spoken Spanish. The answering party had no video capability:
>>
>>        m=video 0 RTP/AVP 31 32
>>        m=text 45020 RTP/AVP 103 104
>>        a=hlang-recv:sp
>>
>>        m=audio 49250 RTP/AVP 20
>>        a=hlang-send:sp
>>
>>
>>  ---------end of proposal------------
>>  --------end of Issue 5---------------
>
> Thanks.
>
>>
>>  --------Issue 6 - most examples have asterisks on all attributes, 
>> reduce number of asterisks -------
>>  In section 5.5 Examples, nearly all examples including the use of 
>> the asterisk has the asterisk on all attribute lines in the whole 
>> SDP, even if it is sufficient to have it on one attribute. I think 
>> this might have confused the reviewers and caused some of the 
>> thoughts about assumed grouping and linking and wondering about 
>> semantic rules around the asterisk that was not intended by the draft.
>>  --------Proposed action for Issue 6------------
>>  Delete some of the asterisks in the examples in section 5.5, so that 
>> only one example has asterisks on all attributes and the others have 
>> just one or a varying number of asterisks.
>>  --------End of issue 6-----------------------------------
>
> OK.
>
>>
>>  --------Issue 7 Missing link to 'hlang-value' in the syntax section 
>> 6.1-------------------
>>
>>  I suggest to insert a line in two places to link the attribute to 
>> the 'hlang-value' syntax description, matching the format used in 
>> rfc4566bis.
>>
>>  ------Old text in two places in section 6.1--------
>>   Attribute Syntax:
>>
>>  --------New text in two places in section 6.1-----
>>    Value: hlang-value
>>    Attribute Syntax:
>>
>>  ---------End of Issue 7.----------------
>
> OK.
>
Thanks,
Gunnar

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


From nobody Fri Jun 30 05:09:48 2017
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 71D3512EB13 for ; Fri, 30 Jun 2017 05:09:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 kropt7eJMoOs for ; Fri, 30 Jun 2017 05:09:44 -0700 (PDT)
Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (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 56590127286 for ; Fri, 30 Jun 2017 05:09:44 -0700 (PDT)
Received: by mail-lf0-x231.google.com with SMTP id b207so69009277lfg.2 for ; Fri, 30 Jun 2017 05:09:44 -0700 (PDT)
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=1Fkax7i5OkKYBu2yRrsuO5Qt/iJuGxuRETW5dMh8S0E=; b=gg8zs+zc2Low7RZV+sSm/Ofjr+JhrCJwR2qeUqBP+vRkssMLpdvfOcHZfhU1c02ycr 9d6vzY3i23pDKLSRGD0+VnsvcGf5Jr4Q9TWg3hZoQVfaPZxw+TtY5wvpcaJDLm1/NaS/ jBi8qTx6TEhEJU2VTtE+qoIoTdz2IDucKqzr8aLF5bK9c79ybvc1KkV/T5/Z26subMu7 BP8d5Hd6N6vAfA1FIrqUExyZAfQkZi2RqlMFdML+7gwXgWESPdSKnTtWkpozF9Z+PZXc LZidk3k8q1Jc8wMDAqQchjMzypJTI14b0e3wIzXIziNVf4GfMurWfD8r2EINygXjZLEd 7E4g==
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=1Fkax7i5OkKYBu2yRrsuO5Qt/iJuGxuRETW5dMh8S0E=; b=qcvCx8skyVJO+G4UYMW3tjNAQVA3JKmPCGmdQOVWwegLYXMJmLMq/9IDA7h3iS14qX yDq8yg7hWKuE+lZwrsLqOxWTS9yUTxlFi28C2dgtx0c1EjQNRz9AlR+oDhjqwZb1GgSV Lx0rmWMuiL9bI/kRnhRBQ4VQnbC8WWrc+F0Gsbmtfxt8UfRdhzY4Z0zGbdzafHJ312Wk nLAI0bRwyBXq/Vl4lVcx04mp6lEN8osSkG6ha3Mz9+mRFUYxBNagRC9wJxpkMKetaJa5 +sF4JzezCBjZu3S2EHKl6SiMQP/z1VS3Ldaf/9b2u+HPt+G4IABuHOO9gj9c936EP/Pt sbmA==
X-Gm-Message-State: AKS2vOwl4dzG+HLavb6Iaj7FCxnZxgqbVP23/5BnbuAZtgdnZ9MzX9h5 m9ZOBvaIecZ/1hMJeYH3qlO+sIyfVg==
X-Received: by 10.25.199.11 with SMTP id x11mr7199380lff.170.1498824582384; Fri, 30 Jun 2017 05:09:42 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.160.204 with HTTP; Fri, 30 Jun 2017 05:09:41 -0700 (PDT)
In-Reply-To: <15BDE051-1F8A-434A-A87C-A9213057B500@gsma.com>
References: <15BDE051-1F8A-434A-A87C-A9213057B500@gsma.com>
From: Nik Tomkinson 
Date: Fri, 30 Jun 2017 13:09:41 +0100
Message-ID: 
To: Natasha Rooney 
Cc: slim@ietf.org
Content-Type: multipart/alternative; boundary="94eb2c1a1a94d0569d05532c4a41"
Archived-At: 
Subject: Re: [Slim] IETf 99 and interim
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, 30 Jun 2017 12:09:46 -0000

--94eb2c1a1a94d0569d05532c4a41
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

as long as there are a range of dates it will be fine for me as I should be
able to move anything around to suit.

Nik.

On 30 June 2017 at 06:44, Natasha Rooney  wrote:

> Hi all,
>
> On reflection, given many people will be absent from IETF99 and the issue=
s
> experienced when running a meeting with a large part of the group being o=
n
> the phone we have decided to cancel our IETF99 meeting slot and hold a
> teleconference interim meeting in August.
>
> Editors (Randall, Nik, Gunnar): are you working during August? Any block
> out dates?
>
> I=E2=80=99ll make the request to cancel the meeting now. When the editors=
 respond
> with their ability for August we will work to find a time suitable for as
> many people as possible for the interim meeting.
>
> Many thanks!
>
> Natasha Rooney | Internet Engineering Director | Internet and Web Team
> | Technology | GSMA | nrooney@gsma.com | +44 (0) 7730 219 765
> <+44%207730%20219765> | @thisNatasha | Skype: nrooney@gsm.org
>
>
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim
>
>


--=20

-----------------------------------------------------------------
Multiple Language Content Type Internet Draft:

https://datatracker.ietf.org/doc/draft-ietf-slim-multilangcontent/

-----------------------------------------------------------------

--94eb2c1a1a94d0569d05532c4a41
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi,

as long as there are a range of dat=
es it will be fine for me as I should be able to move anything around to su=
it.

Nik.
On 30 June 2017 at 06:44, Natasha Rooney <nroon=
ey@gsma.com> wrote:
Hi all,

On reflection, give=
n many people will be absent from IETF99 and the issues experienced when ru=
nning a meeting with a large part of the group being on the phone we have d=
ecided to cancel our IETF99 meeting slot and hold a teleconference interim =
meeting in August.

Editors (Randall, Nik, Gunnar):=
 are you working during August? Any block out dates?

I=E2=80=99ll make the request to cancel the meeting now. When the editor=
s respond with their ability for August we will work to find a time suitabl=
e for as many people as possible for the interim meeting.=C2=A0
<=
br>
Many thanks!



Natasha Rooney | Internet Engineering=C2=A0Director | =
Internet and Web Team |=C2=A0Technology | GSMA |=C2=A0nrooney@gsma.com=C2=A0| +44 (0) 773=
0 219=C2=A0765 | @thisNatasha | Skype:=C2=A0nrooney@gsm.org







____________________________________=
___________

SLIM mailing list

SLIM@ietf.org

https://www.ietf.org/mailman/listinfo/slim





-- 
=

----------------------=
-------------------------------------------
Multiple Language Content Ty=
pe Internet Draft:
https://datatrack=
er.ietf.org/doc/draft-ietf-slim-multilangcontent/
------------------------------------=
-----------------------------

<=
/div>




--94eb2c1a1a94d0569d05532c4a41--


From nobody Fri Jun 30 06:15:26 2017
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 D69501204DA for ; Fri, 30 Jun 2017 06:15:24 -0700 (PDT)
X-Quarantine-ID: 
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 ke8U37IVw6IS for ; Fri, 30 Jun 2017 06:15:23 -0700 (PDT)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 08EAF1293E1 for ; Fri, 30 Jun 2017 06:15:23 -0700 (PDT)
Received: from [50.95.104.251] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Fri, 30 Jun 2017 06:18:16 -0700
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <9c7041be-06ea-106c-90f8-14e2ae4f6abd@omnitor.se>
References: <149826161364.7680.4546115441019121579@ietfa.amsl.com> <8cbb2083-b02f-20eb-ab7f-a03c85cb95f8@omnitor.se>  <9c7041be-06ea-106c-90f8-14e2ae4f6abd@omnitor.se>
X-Mailer: Eudora for Mac OS X
Date: Fri, 30 Jun 2017 06:15:19 -0700
To: Gunnar =?iso-8859-1?Q?Hellstr=F6m?=  , slim@ietf.org
From: Randall Gellens 
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [Slim] I-D Action: draft-ietf-slim-negotiating-human-language-11.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: Fri, 30 Jun 2017 13:15:25 -0000

At 8:09 AM +0200 6/30/17, Gunnar Hellstr=F6m wrote:

>  Randall,
>  All your resolutions are fine except for Issue 2. See explanation below.

OK, new wording:

    Note that separate work may introduce additional information
    regarding language/modality preferences among media.

Note that there is no longer a reference to the draft.

>
>  Den 2017-06-30 kl. 05:15, skrev Randall Gellens:
>>  At 11:30 AM +0200 6/26/17, Gunnar Hellstr=F6m wrote:
>>
>>>   Good to see progress.
>>>
>>>   I checked the numbered change proposals I=20
>>> submitted earlier under subject " I-D Action:=20
>>> draft-ietf-slim-negotiating-human-language-10.txt"=20
>>> and found that most of them were solved or=20
>>> agreed to be ignored. Only proposal 2.2 was=20
>>> not acted on, so I repeat it here together=20
>>> with a few new findings:
>>>
>>>   -----Issue 1, old 2.2 The attributes can=20
>>> appear in both offers and answers -----------
>>>   -------Old text 2.2 at end of first paragraph of 5.2---------
>>>
>>>
>>>   Each can appear in an offer for a media
>>>   stream.
>>>   --New text 2.2---
>>>   Each can appear in an offer and answer for a media
>>>   stream.
>>>   ---Reasoning:----------
>>>
>>>   This paragraph is an introduction to the=20
>>> attributes. It should mention the full use,=20
>>> in both offer and answer. The following=20
>>> paragraphs tell about specifics for offer vs=20
>>> answer.
>>>   --End of change 2.2---
>>>
>>>   ---End of Issue 1----------
>>
>>  Yes, I agree.
>>
>>>
>>>   ------Issue 2 , reduce info on possible=20
>>> extensions to not be solution=20
>>> specific----------
>>>
>>>   In section 5.2, middle:
>>>
>>>   -----Old text------------
>>>
>>>     See Section 5.3 for more
>>>      information and discussion.  Note that separate work
>>>      [I-D.hellstrom-slim-modalitypref] extends the use of the asterisk t=
o
>>>      convey additional information regarding language/modality preferenc=
es
>>>      among media.
>>>
>>>   -----New text proposal for Issue 2-----------
>>>
>>>       See Section 5.3 for more information and discussion.
>>>   
>>>      Note that separate work may introduce=20
>>> additional information regarding=20
>>> language/modality
>>>      preferences among media.
>>>
>>>   ---Reasoning: ---------
>>>   Two ways to convey language/modality=20
>>> preferences among media have been proposed,=20
>>> one based on the asterisk=20
>>> (draft-hellstrom-slim-modalitypref), and=20
>>> another based on the SDP gouping framework=20
>>> (draft-hellstrom-language-grouping). There=20
>>> are drafts for both. The clean one seems to=20
>>> be the method based on SDP grouping. It has=20
>>> no known interoperability problems.
>>>    The proposed wording of the note (as a=20
>>> separate paragraph) is intended to cover both=20
>>> methods, but has less effect as a warning=20
>>> against interoperabitlity problems caused by=20
>>> the asterisk based solution.
>>>
>>>   A decision is needed for which alternative=20
>>> to continue with, I prefer the one based on=20
>>> SDP grouping.
>>>
>>>
>>>
>>>   -----End of issue 2-----------------------
>>
>>  I will go back to my original wording, which I=20
>> think was specific enough to give readers of=20
>> this document a hint to read yours, and=20
>> general enough to not constrain your document:
>>
>>      "uses the asterisk (or lack thereof) to=20
>> convey additional information between=20
>> endpoints."
>  I need the whole sentence to understand the proposal. Do you mean:
>
>  "Note that separate work=20
> [I-D.hellstrom-slim-modalitypref] extends the=20
> use of the asterisk (or lack thereof) to
>     convey additional information between endpoints."
>
>  Or did you mean:
>
>   "Note that separate work extends the use of=20
> the asterisk (or lack thereof) to
>     convey additional information between endpoints."
>
>  Anyway, both are currently wrong. I have=20
> submitted two alternative drafts for the=20
> modality preference indication, one adding=20
> meaning to the asterisk=20
> (draft-hellstrom-slim-modalitypref) and the=20
> other using SDP grouping instead, not touching=20
> the asterisk=20
> (draft-hellstrom-language-grouping). I prefer=20
> the SDP grouping proposal, but want to hear=20
> others' views.  When we have a decision, I will=20
> let one of them expire and we can sharpen up=20
> the note if the draft is still open for=20
> modifications.
>
>  So, at the moment, it is only my proposed=20
> wording in a separate note as shown above in=20
> issue 2 that works.
>
>
>
>>
>>>
>>>   ------Issue 3 - typo in 5.5------------
>>>
>>>   Typo in section 5.5, at the end of page 9
>>>
>>>   -------old text-----
>>>   An offer of answer
>>>   -----new text----
>>>
>>>      An offer or answer
>>>   -----end of issue 3------
>>
>>  Thanks.
>>
>>>
>>>   ----Issue 4  allow asterisks also in=20
>>> answers, but do not assign a meaning---------
>>>   The second example in 5.5 has asterisks last=20
>>> in the attributes and says that the example=20
>>> can be either an offer or an answer.
>>
>>  That's an error, thanks for catching it.  It should say "an offer".
>>
>>>
>>>   But section 5.2, fourth paragraph currently=20
>>> only says that the asterisk can appear in an=20
>>> offer.
>>
>>  It doesn't prohibit an asterisk in an answer,=20
>> but it only defines the meaning of an asterisk=20
>> in an offer.  I suggest we leave it this way.=20
>> Your draft can then define the meaning of an=20
>> asterisk in an offer.  Note that the ABNF=20
>> defining the syntax does not differentiate=20
>> between an offer and an answer, hence, an=20
>> asterisk is technically permitted in an=20
>> answer.  For clarity, I will add to 5.2:
>>
>>      An asterisk appended to any value in any=20
>> media in an answer is undefined.
>>
>>>
>>>   I suggest to amend this by allowing the=20
>>> asterisk to appear in an answer, but not=20
>>> assign any meaning to it.
>>>   This is more future proof and may make=20
>>> implementation of the answering part easier=20
>>> than keeping the currect restriction.
>>>
>>>   ------New paragraph after paragraph four in 5.2-------
>>>   The asterisk token MAY also be appended last=20
>>> in a 'hlang' attribute in an answer, but this=20
>>> specification does not define any meaning to=20
>>> an asterisk in that position.
>>>   ------End of proposal for Issue 4...........
>>>   -----End of Issue 4----------------
>>>    ----Issue 5 correct SDP syntax in answer=20
>>> example on page 10 -------------------
>>>   In the answer example in section 5.5 on page=20
>>> 10, the answer shows no video m-line. There=20
>>> was an m-lne for video in the offer, then one=20
>>> must be included in the aswer.
>>>
>>>   ---old text in 5.5----
>>>      An answer for the above offer, indicating text in which the callee
>>>      will receive written Spanish, and audio in which the callee will se=
nd
>>>      spoken Spanish:
>>>
>>>         m=3Dtext 45020 RTP/AVP 103 104
>>>         a=3Dhlang-recv:sp
>>>
>>>         m=3Daudio 49250 RTP/AVP 20
>>>         a=3Dhlang-send:sp
>>>
>>>   -------new text-----------
>>>      An answer for the above offer, indicating text in which the callee
>>>      will receive written Spanish, and audio in which the callee will se=
nd
>>>      spoken Spanish. The answering party had no video capability:
>>>
>>>         m=3Dvideo 0 RTP/AVP 31 32
>>>         m=3Dtext 45020 RTP/AVP 103 104
>>>         a=3Dhlang-recv:sp
>>>
>>>         m=3Daudio 49250 RTP/AVP 20
>>>         a=3Dhlang-send:sp
>>>
>>>
>>>   ---------end of proposal------------
>>>   --------end of Issue 5---------------
>>
>>  Thanks.
>>
>>>
>>>   --------Issue 6 - most examples have=20
>>> asterisks on all attributes, reduce number of=20
>>> asterisks -------
>>>   In section 5.5 Examples, nearly all examples=20
>>> including the use of the asterisk has the=20
>>> asterisk on all attribute lines in the whole=20
>>> SDP, even if it is sufficient to have it on=20
>>> one attribute. I think this might have=20
>>> confused the reviewers and caused some of the=20
>>> thoughts about assumed grouping and linking=20
>>> and wondering about semantic rules around the=20
>>> asterisk that was not intended by the draft.
>>>   --------Proposed action for Issue 6------------
>>>   Delete some of the asterisks in the examples=20
>>> in section 5.5, so that only one example has=20
>>> asterisks on all attributes and the others=20
>>> have just one or a varying number of=20
>>> asterisks.
>>>   --------End of issue 6-----------------------------------
>>
>>  OK.
>>
>>>
>>>   --------Issue 7 Missing link to=20
>>> 'hlang-value' in the syntax section=20
>>> 6.1-------------------
>>>
>>>   I suggest to insert a line in two places to=20
>>> link the attribute to the 'hlang-value'=20
>>> syntax description, matching the format used=20
>>> in rfc4566bis.
>>>
>>>   ------Old text in two places in section 6.1--------
>>>    Attribute Syntax:
>>>
>>>   --------New text in two places in section 6.1-----
>>>     Value: hlang-value
>>>     Attribute Syntax:
>>>
>>>   ---------End of Issue 7.----------------
>>
>>  OK.
>>
>  Thanks,
>  Gunnar
>
>  --
>  -----------------------------------------
>  Gunnar Hellstr=F6m
>  Omnitor
>  gunnar.hellstrom@omnitor.se
>  +46 708 204 288


-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Please ignore previous fortune.


From nobody Fri Jun 30 06:37:54 2017
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 9EB87129B1D for ; Fri, 30 Jun 2017 06:37:51 -0700 (PDT)
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 fSlCxMfJlSHm for ; Fri, 30 Jun 2017 06:37:49 -0700 (PDT)
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 303AD129AB7 for ; Fri, 30 Jun 2017 06:37:49 -0700 (PDT)
X-Halon-ID: 4b1615a0-5d99-11e7-8604-0050569116f7
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [77.53.36.99]) by bin-vsp-out-03.atm.binero.net (Halon) with ESMTPSA id 4b1615a0-5d99-11e7-8604-0050569116f7; Fri, 30 Jun 2017 15:37:43 +0200 (CEST)
To: Randall Gellens , slim@ietf.org
References: <149826161364.7680.4546115441019121579@ietfa.amsl.com> <8cbb2083-b02f-20eb-ab7f-a03c85cb95f8@omnitor.se>  <9c7041be-06ea-106c-90f8-14e2ae4f6abd@omnitor.se> 
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: <9f1a7c5b-09df-0584-6dc6-7be07cc8fa4f@omnitor.se>
Date: Fri, 30 Jun 2017 15:37:41 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [Slim] I-D Action: draft-ietf-slim-negotiating-human-language-11.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: Fri, 30 Jun 2017 13:37:52 -0000

Den 2017-06-30 kl. 15:15, skrev Randall Gellens:
> At 8:09 AM +0200 6/30/17, Gunnar Hellström wrote:
>
>>  Randall,
>>  All your resolutions are fine except for Issue 2. See explanation 
>> below.
>
> OK, new wording:
>
>    Note that separate work may introduce additional information
>    regarding language/modality preferences among media.
Fine.
>
> Note that there is no longer a reference to the draft.
Yes, since there are currently two drafts with competing solutions, I 
think it is better to not reference them.

The new drafts have been available for 18 days now, and I have not got 
any substantial feedback. That is not promising for the progress, and 
not what I expected when I accepted to make separate drafts for the 
functionality that will add substantial usability to 
draft-ietf-slim-negotiating-human-language.


>
>>
>>  Den 2017-06-30 kl. 05:15, skrev Randall Gellens:
>>>  At 11:30 AM +0200 6/26/17, Gunnar Hellström wrote:
>>>
>>>>   Good to see progress.
>>>>
>>>>   I checked the numbered change proposals I submitted earlier under 
>>>> subject " I-D Action: 
>>>> draft-ietf-slim-negotiating-human-language-10.txt" and found that 
>>>> most of them were solved or agreed to be ignored. Only proposal 2.2 
>>>> was not acted on, so I repeat it here together with a few new 
>>>> findings:
>>>>
>>>>   -----Issue 1, old 2.2 The attributes can appear in both offers 
>>>> and answers -----------
>>>>   -------Old text 2.2 at end of first paragraph of 5.2---------
>>>>
>>>>
>>>>   Each can appear in an offer for a media
>>>>   stream.
>>>>   --New text 2.2---
>>>>   Each can appear in an offer and answer for a media
>>>>   stream.
>>>>   ---Reasoning:----------
>>>>
>>>>   This paragraph is an introduction to the attributes. It should 
>>>> mention the full use, in both offer and answer. The following 
>>>> paragraphs tell about specifics for offer vs answer.
>>>>   --End of change 2.2---
>>>>
>>>>   ---End of Issue 1----------
>>>
>>>  Yes, I agree.
>>>
>>>>
>>>>   ------Issue 2 , reduce info on possible extensions to not be 
>>>> solution specific----------
>>>>
>>>>   In section 5.2, middle:
>>>>
>>>>   -----Old text------------
>>>>
>>>>     See Section 5.3 for more
>>>>      information and discussion.  Note that separate work
>>>>      [I-D.hellstrom-slim-modalitypref] extends the use of the 
>>>> asterisk to
>>>>      convey additional information regarding language/modality 
>>>> preferences
>>>>      among media.
>>>>
>>>>   -----New text proposal for Issue 2-----------
>>>>
>>>>       See Section 5.3 for more information and discussion.
>>>>   
>>>>      Note that separate work may introduce additional information 
>>>> regarding language/modality
>>>>      preferences among media.
>>>>
>>>>   ---Reasoning: ---------
>>>>   Two ways to convey language/modality preferences among media have 
>>>> been proposed, one based on the asterisk 
>>>> (draft-hellstrom-slim-modalitypref), and another based on the SDP 
>>>> gouping framework (draft-hellstrom-language-grouping). There are 
>>>> drafts for both. The clean one seems to be the method based on SDP 
>>>> grouping. It has no known interoperability problems.
>>>>    The proposed wording of the note (as a separate paragraph) is 
>>>> intended to cover both methods, but has less effect as a warning 
>>>> against interoperabitlity problems caused by the asterisk based 
>>>> solution.
>>>>
>>>>   A decision is needed for which alternative to continue with, I 
>>>> prefer the one based on SDP grouping.
>>>>
>>>>
>>>>
>>>>   -----End of issue 2-----------------------
>>>
>>>  I will go back to my original wording, which I think was specific 
>>> enough to give readers of this document a hint to read yours, and 
>>> general enough to not constrain your document:
>>>
>>>      "uses the asterisk (or lack thereof) to convey additional 
>>> information between endpoints."
>>  I need the whole sentence to understand the proposal. Do you mean:
>>
>>  "Note that separate work [I-D.hellstrom-slim-modalitypref] extends 
>> the use of the asterisk (or lack thereof) to
>>     convey additional information between endpoints."
>>
>>  Or did you mean:
>>
>>   "Note that separate work extends the use of the asterisk (or lack 
>> thereof) to
>>     convey additional information between endpoints."
>>
>>  Anyway, both are currently wrong. I have submitted two alternative 
>> drafts for the modality preference indication, one adding meaning to 
>> the asterisk (draft-hellstrom-slim-modalitypref) and the other using 
>> SDP grouping instead, not touching the asterisk 
>> (draft-hellstrom-language-grouping). I prefer the SDP grouping 
>> proposal, but want to hear others' views.  When we have a decision, I 
>> will let one of them expire and we can sharpen up the note if the 
>> draft is still open for modifications.
>>
>>  So, at the moment, it is only my proposed wording in a separate note 
>> as shown above in issue 2 that works.
>>
>>
>>
>>>
>>>>
>>>>   ------Issue 3 - typo in 5.5------------
>>>>
>>>>   Typo in section 5.5, at the end of page 9
>>>>
>>>>   -------old text-----
>>>>   An offer of answer
>>>>   -----new text----
>>>>
>>>>      An offer or answer
>>>>   -----end of issue 3------
>>>
>>>  Thanks.
>>>
>>>>
>>>>   ----Issue 4  allow asterisks also in answers, but do not assign a 
>>>> meaning---------
>>>>   The second example in 5.5 has asterisks last in the attributes 
>>>> and says that the example can be either an offer or an answer.
>>>
>>>  That's an error, thanks for catching it.  It should say "an offer".
>>>
>>>>
>>>>   But section 5.2, fourth paragraph currently only says that the 
>>>> asterisk can appear in an offer.
>>>
>>>  It doesn't prohibit an asterisk in an answer, but it only defines 
>>> the meaning of an asterisk in an offer.  I suggest we leave it this 
>>> way. Your draft can then define the meaning of an asterisk in an 
>>> offer.  Note that the ABNF defining the syntax does not 
>>> differentiate between an offer and an answer, hence, an asterisk is 
>>> technically permitted in an answer.  For clarity, I will add to 5.2:
>>>
>>>      An asterisk appended to any value in any media in an answer is 
>>> undefined.
>>>
>>>>
>>>>   I suggest to amend this by allowing the asterisk to appear in an 
>>>> answer, but not assign any meaning to it.
>>>>   This is more future proof and may make implementation of the 
>>>> answering part easier than keeping the currect restriction.
>>>>
>>>>   ------New paragraph after paragraph four in 5.2-------
>>>>   The asterisk token MAY also be appended last in a 'hlang' 
>>>> attribute in an answer, but this specification does not define any 
>>>> meaning to an asterisk in that position.
>>>>   ------End of proposal for Issue 4...........
>>>>   -----End of Issue 4----------------
>>>>    ----Issue 5 correct SDP syntax in answer example on page 10 
>>>> -------------------
>>>>   In the answer example in section 5.5 on page 10, the answer shows 
>>>> no video m-line. There was an m-lne for video in the offer, then 
>>>> one must be included in the aswer.
>>>>
>>>>   ---old text in 5.5----
>>>>      An answer for the above offer, indicating text in which the 
>>>> callee
>>>>      will receive written Spanish, and audio in which the callee 
>>>> will send
>>>>      spoken Spanish:
>>>>
>>>>         m=text 45020 RTP/AVP 103 104
>>>>         a=hlang-recv:sp
>>>>
>>>>         m=audio 49250 RTP/AVP 20
>>>>         a=hlang-send:sp
>>>>
>>>>   -------new text-----------
>>>>      An answer for the above offer, indicating text in which the 
>>>> callee
>>>>      will receive written Spanish, and audio in which the callee 
>>>> will send
>>>>      spoken Spanish. The answering party had no video capability:
>>>>
>>>>         m=video 0 RTP/AVP 31 32
>>>>         m=text 45020 RTP/AVP 103 104
>>>>         a=hlang-recv:sp
>>>>
>>>>         m=audio 49250 RTP/AVP 20
>>>>         a=hlang-send:sp
>>>>
>>>>
>>>>   ---------end of proposal------------
>>>>   --------end of Issue 5---------------
>>>
>>>  Thanks.
>>>
>>>>
>>>>   --------Issue 6 - most examples have asterisks on all attributes, 
>>>> reduce number of asterisks -------
>>>>   In section 5.5 Examples, nearly all examples including the use of 
>>>> the asterisk has the asterisk on all attribute lines in the whole 
>>>> SDP, even if it is sufficient to have it on one attribute. I think 
>>>> this might have confused the reviewers and caused some of the 
>>>> thoughts about assumed grouping and linking and wondering about 
>>>> semantic rules around the asterisk that was not intended by the draft.
>>>>   --------Proposed action for Issue 6------------
>>>>   Delete some of the asterisks in the examples in section 5.5, so 
>>>> that only one example has asterisks on all attributes and the 
>>>> others have just one or a varying number of asterisks.
>>>>   --------End of issue 6-----------------------------------
>>>
>>>  OK.
>>>
>>>>
>>>>   --------Issue 7 Missing link to 'hlang-value' in the syntax 
>>>> section 6.1-------------------
>>>>
>>>>   I suggest to insert a line in two places to link the attribute to 
>>>> the 'hlang-value' syntax description, matching the format used in 
>>>> rfc4566bis.
>>>>
>>>>   ------Old text in two places in section 6.1--------
>>>>    Attribute Syntax:
>>>>
>>>>   --------New text in two places in section 6.1-----
>>>>     Value: hlang-value
>>>>     Attribute Syntax:
>>>>
>>>>   ---------End of Issue 7.----------------
>>>
>>>  OK.
>>>
>>  Thanks,
>>  Gunnar
>>
>>  --
>>  -----------------------------------------
>>  Gunnar Hellström
>>  Omnitor
>>  gunnar.hellstrom@omnitor.se
>>
>
>
Gunnar

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