From nobody Sun Nov 1 14:50:54 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAF911A87E7 for ; Mon, 19 Oct 2015 02:34:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 lBXgXsGE9Gl9 for ; Mon, 19 Oct 2015 02:34:46 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0630.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::630]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E86381A87CE for ; Mon, 19 Oct 2015 02:34:44 -0700 (PDT) Received: from HE1PR04MB1033.eurprd04.prod.outlook.com (10.162.26.142) by HE1PR04MB1036.eurprd04.prod.outlook.com (10.162.26.145) with Microsoft SMTP Server (TLS) id 15.1.300.14; Mon, 19 Oct 2015 09:34:37 +0000 Received: from HE1PR04MB1033.eurprd04.prod.outlook.com ([10.162.26.142]) by HE1PR04MB1033.eurprd04.prod.outlook.com ([10.162.26.142]) with mapi id 15.01.0300.010; Mon, 19 Oct 2015 09:34:37 +0000 From: Natasha Rooney To: "slim@ietf.org" Thread-Topic: Formed Selection of Language for Internet Media (slim) Thread-Index: AQHRClFff1ZXZJUyaUawiU1iiUDYNw== Date: Mon, 19 Oct 2015 09:34:37 +0000 Message-ID: <742C57B3-32AB-4055-914B-11E6C136E568@gsma.com> References: <2C578AC9-3295-4FFA-9A06-A21B86297178@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2098) authentication-results: spf=none (sender IP is ) smtp.mailfrom=nrooney@gsma.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [118.109.86.198] x-microsoft-exchange-diagnostics: 1; HE1PR04MB1036; 5:u2yFkb5yrm0NUZHgWhAJu3UNJcll5U4b0funrOflEv26kBCBeEnYaSBPFJMhwoe+0vUSVWrilYa0UdBLsqEDjqN/15Mj5YC9AxFEkA2B+I8CxzGe99MorrnGKJinsrZPaHC3ZzQDPCrQcXOHooOfPQ==; 24:8uV+7/QAp4lS+g2gA0J7eYg0p1CM5ofTjGhuLuVg7Z81QQqvFGU0jpQMgWEj40rkCrWiqFbESEwE+GXRo0qZe+L2HQalU+y+V+tAzYuIqa8=; 20:djxyALV31IhSwqvoAIvroCH/LzhKI2owDJPy0LIhtG+LB6S9a4cNobYduF7p0CH0LWc740G8SqZwh0V8WfYEww== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR04MB1036; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(260367931017790)(194151415913766); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(520078)(3002001); SRVR:HE1PR04MB1036; BCL:0; PCL:0; RULEID:; SRVR:HE1PR04MB1036; x-forefront-prvs: 07349BFAD2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(53754006)(189002)(377454003)(199003)(45074003)(66066001)(15975445007)(57306001)(450100001)(46102003)(87936001)(86362001)(2501003)(5001960100002)(106116001)(5007970100001)(106356001)(19580395003)(2900100001)(2351001)(5004730100002)(105586002)(107886002)(19580405001)(189998001)(16236675004)(64706001)(102836002)(76176999)(11100500001)(92566002)(81156007)(36756003)(33656002)(40100003)(5008740100001)(110136002)(50986999)(77096005)(5002640100001)(82746002)(5890100001)(50226001)(19617315012)(101416001)(229853001)(10400500002)(122556002)(83716003)(97736004)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR04MB1036; H:HE1PR04MB1033.eurprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: gsma.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_742C57B332AB4055914B11E6C136E568gsmacom_" MIME-Version: 1.0 X-OriginatorOrg: gsma.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2015 09:34:37.3553 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72a4ff82-fec3-469d-aafb-ac8276216699 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR04MB1036 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: HE1PR04MB1033.eurprd04.prod.outlook.com X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-originalclientipaddress: 118.109.86.198 X-MS-Exchange-CrossPremises-avstamp-service: 1.0 X-MS-Exchange-CrossPremises-disclaimer-hash: 78ca8040c6722e32c2f5b0a45bf37e74b9409d645a53be96aa19958e0cee0f00 X-MS-Exchange-CrossPremises-antispam-scancontext: DIR:Originating; SFV:NSPM; SKIP:0; X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-OrganizationHeadersPreserved: HE1PR04MB1036.eurprd04.prod.outlook.com Archived-At: X-Mailman-Approved-At: Sun, 01 Nov 2015 14:50:52 -0800 Subject: [Slim] Formed Selection of Language for Internet Media (slim) X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2015 09:34:51 -0000 --_000_742C57B332AB4055914B11E6C136E568gsmacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsIQ0KDQpUaGFuay15b3UgZm9yIHN1YnNjcmliaW5nIHRvIHRoZSBTTElNIG1haWxpbmcg bGlzdC4gSSBoYXZlIHNvbWUgbmV3cyBmb3IgZXZlcnlvbmUgd2hpY2ggaG9wZWZ1bGx5IHdvbuKA mXQgYmUgdG9vIG11Y2ggb2YgYSBzdXJwcmlzZSENCg0KQ2hhcnRlcg0KVGhlIFNMSU0gY2hhcnRl ciBoYXMgYmVlbiBhcHByb3ZlZCwgc28gd2UgYXJlIG5vdyBvZmZpY2lhbGx5IGFuIElFVEYgV29y a2luZyBHcm91cCEgVGhhbmsteW91IHRvIGV2ZXJ5b25lIHdobyBnYXZlIGlucHV0IHRvIHRoaXMu IFlvdSBjYW4gcmVhZCB0aGUgZnVsbCBjaGFydGVyIG9uIGRhdGF0cmFja2VyIChhbGwgbGlua3Mg YXJlIGJlbG93KS4NCg0KQ2hhaXJzDQpBcyB5b3Ugc2hvdWxkIGJlIGFibGUgdG8gc2VlIGZyb20g dGhlIGFib3ZlIGxpbmsgd2UgaGF2ZSB0d28gY2hhaXJzLCBCZXJuYXJkIEFib2JhIGFuZCBteXNl bGYsIE5hdGFzaGEgUm9vbmV5LiBCZXJuYXJkIGlzIGEgZmFtb3VzIElFVEZlciBhbmQgbWFueSBv ZiB5b3Ugd2lsbCBrbm93IGhpbSBhcyBhIFByaW5jaXBsZSBBcmNoaXRlY3QgYXQgTWljcm9zb2Z0 LCBhIHByZXZpb3VzIElBQiBDaGFpciwgYSBXM0MgV2ViUlRDIGRyYWZ0IGVkaXRvciBhbmQgYSBj b250cmlidXRvciB0byBhcm91bmQgNjAgUkZDcy4gSSB3b3JrIGZvciBHU01BLCBhIGdsb2JhbCB0 ZWxlY29tbXVuaWNhdGlvbnMgYXNzb2NpYXRpb24sIGFzIGEgd2ViIGFuZCBpbnRlcm5ldCB0ZWNo bm9sb2dpc3Qgd29ya2luZyBvbiBjb25uZWN0aW5nIGludGVybmV0IHRlY2hub2xvZ2llcyB3aXRo IHRoZSBtb2JpbGUgbmV0d29yay4NCg0KQXMgY2hhaXJzIG9mIHRoZSB3b3JraW5nIGdyb3VwIEJl cm5hcmQgYW5kIEkgd2lsbCB3b3JrIHRvIHN1cHBvcnQgdGhlIGJ1aWxkaW5nIG9mIG91ciBkcmFm dHMsIG9yZ2FuaXNpbmcgb3VyIG1lZXRpbmdzLCBtYW5hZ2luZyBvdXIgbWFpbGluZyBsaXN0cyBh bmQgbWFraW5nIHN1cmUgd2Ugd29yayB3aXRoIHRoZSBJRVRGIHByb2Nlc3MgdG8gdHVybiBvdXIg ZHJhZnRzIGludG8gUkZDcyBpbiBhIHRpbWVseSBtYW5uZXIuDQoNClF1ZXN0aW9ucw0KSWYgeW91 IGhhdmUgcXVlc3Rpb25zIHBsZWFzZSBkbyBhc2sgdXMuIFBvc3RpbmcgcXVlc3Rpb25zIHRvIHRo ZSBsaXN0IGlzIHByZWZlcnJlZCwgYnV0IHlvdSBjYW4gYWxzbyBlbWFpbCB1cyBkaXJlY3RseSBp ZiB5b3UgbmVlZCB0by4NCg0KV2XigJlyZSBsb29raW5nIGZvcndhcmQgdG8gd29ya2luZyB3aXRo IHlvdSBhbGwhDQoNCk5hdGFzaGENCg0KTGlua3MNCkRhdGF0cmFja2VyIFBhZ2UNCmh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvd2cvc2xpbS9jaGFydGVyLw0KTWFpbCBBcmNoaXZlDQpodHRw czovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvYnJvd3NlL3NsaW0vDQpJRVRGOTQNCmh0dHBz Oi8vd3d3LmlldGYub3JnL21lZXRpbmcvOTQvDQpJRVRGOTQgQWdlbmRhDQpodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL21lZXRpbmcvOTQvYWdlbmRhLmh0bWwNCg0KDQoNCk5hdGFzaGEgUm9v bmV5IHwgVGVjaG5vbG9naXN0LCBXZWIgYW5kIEludGVybmV0LCBXM0MgJiBJRVRGIHwgR1NNQSB8 IG5yb29uZXlAZ3NtYS5jb208bWFpbHRvOm5yb29uZXlAZ3NtYS5jb20+IHwgKzQ0ICgwKSA3NzMw IDIxOSA3NjUgfCBAdGhpc05hdGFzaGEgfCBTa3lwZTogbnJvb25leUBnc20ub3JnPG1haWx0bzpu cm9vbmV5QGdzbS5vcmc+DQpUb2t5bywgSmFwYW4NCg0KDQpGcm9tOiBUaGUgSUVTRyA8aWVzZy1z ZWNyZXRhcnlAaWV0Zi5vcmc8bWFpbHRvOmllc2ctc2VjcmV0YXJ5QGlldGYub3JnPj4NCkRhdGU6 IE9jdG9iZXIgMTYsIDIwMTUgYXQgOTo1MzozMCBBTSBQRFQNClRvOiAiSUVURi1Bbm5vdW5jZSIg PGlldGYtYW5ub3VuY2VAaWV0Zi5vcmc8bWFpbHRvOmlldGYtYW5ub3VuY2VAaWV0Zi5vcmc+Pg0K Q2M6IHNsaW1AaWV0Zi5vcmc8bWFpbHRvOnNsaW1AaWV0Zi5vcmc+LCBUaGUgSUVTRyA8aWVzZ0Bp ZXRmLm9yZzxtYWlsdG86aWVzZ0BpZXRmLm9yZz4+LCBzbGltLWNoYWlyc0BpZXRmLm9yZzxtYWls dG86c2xpbS1jaGFpcnNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbU2xpbV0gV0cgQWN0aW9uOiBGb3Jt ZWQgU2VsZWN0aW9uIG9mIExhbmd1YWdlIGZvciBJbnRlcm5ldCBNZWRpYSAoc2xpbSkNCg0KQSBu ZXcgSUVURiB3b3JraW5nIGdyb3VwIGhhcyBiZWVuIGZvcm1lZCBpbiB0aGUgQXBwbGljYXRpb25z IGFuZA0KUmVhbC1UaW1lIEFyZWEuIEZvciBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIHBsZWFzZSBj b250YWN0IHRoZSBBcmVhDQpEaXJlY3RvcnMgb3IgdGhlIFdHIENoYWlycy4NCg0KU2VsZWN0aW9u IG9mIExhbmd1YWdlIGZvciBJbnRlcm5ldCBNZWRpYSAoc2xpbSkNCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KQ3VycmVudCBTdGF0dXM6IFByb3Bvc2Vk IFdHDQoNCkNoYWlyczoNCiBCZXJuYXJkIEFib2JhIDxCZXJuYXJkX0Fib2JhQGhvdG1haWwuY29t PG1haWx0bzpCZXJuYXJkX0Fib2JhQGhvdG1haWwuY29tPj4NCiBOIFJvb25leSA8bnJvb25leUBn c21hLmNvbTxtYWlsdG86bnJvb25leUBnc21hLmNvbT4+DQoNCkFzc2lnbmVkIEFyZWEgRGlyZWN0 b3I6DQogQmFycnkgTGVpYmEgPGJhcnJ5bGVpYmFAY29tcHV0ZXIub3JnPG1haWx0bzpiYXJyeWxl aWJhQGNvbXB1dGVyLm9yZz4+DQoNCk1haWxpbmcgbGlzdA0KIEFkZHJlc3M6IHNsaW1AaWV0Zi5v cmc8bWFpbHRvOnNsaW1AaWV0Zi5vcmc+DQogVG8gU3Vic2NyaWJlOiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NsaW0NCiBBcmNoaXZlOiBodHRwczovL21haWxhcmNoaXZl LmlldGYub3JnL2FyY2gvYnJvd3NlL3NsaW0vDQoNCkNoYXJ0ZXI6DQoNCkEgbXV0dWFsbHkgY29t cHJlaGVuc2libGUgbGFuZ3VhZ2UgaXMgaGVscGZ1bCBmb3IgaHVtYW4gY29tbXVuaWNhdGlvbi4N ClRoaXMgaXMgdHJ1ZSBhY3Jvc3MgYSByYW5nZSBvZiBjaXJjdW1zdGFuY2VzIGFuZCBlbnZpcm9u bWVudHMuICBJbg0KZ2VuZXJhbCwgdGhlIHByb2JsZW0gaXMgbW9zdCBhY3V0ZSBpbiBzaXR1YXRp b25zIHdoZXJlIHRoZXJlIGlzIG5vdCBhDQpjbGVhciBjaG9pY2UgZm9yIGEgc2luZ2xlIGxhbmd1 YWdlLCBzdWNoIGFzIGVudmlyb25tZW50cyBsYWNraW5nDQpjb250ZXh0dWFsIG9yIG91dC1vZi1i YW5kIGluZm9ybWF0aW9uIHJlZ2FyZGluZyB0aGUgaWRlbnRpdHkgb2YgdGhlDQpwYXJ0aWVzIGFu ZCB0aGUgbGFuZ3VhZ2UgdG8gYmUgdXNlZC4NCg0KVGhlIGdyb3VwIHdpbGwgYWRkcmVzcyB0d28g c3BlY2lmaWMgY2FzZXMgdGhhdCBtb3N0IHVyZ2VudGx5IG5lZWQgYQ0KdGVjaG5pY2FsIHNvbHV0 aW9uOiBPbmUgcHJvYmxlbSBzcGFjZSBpcyBub24tcmVhbC10aW1lIGNvbW11bmljYXRpb24sDQpz cGVjaWZpY2FsbHkgZW1haWwgZm9yIG9uZS10by1tYW55IG9yIHdoZXJlIHRoZSBzZXQgb2YgcmVj aXBpZW50cyBpcw0KZHluYW1pYyBvciBkaWZmZXJlbnQgcmVjaXBpZW50cyByZXF1aXJlIGRpZmZl cmVudCBsYW5ndWFnZXM7IHRoZSBvdGhlcg0KaXMgcmVhbC10aW1lIGNvbW11bmljYXRpb24sIHNw ZWNpZmljYWxseSBlbWVyZ2VuY3kgY2FsbGluZywgcHJlZmVyYWJseQ0KYWxzbyB1c2VmdWwgZm9y IG90aGVyIGNhc2VzIHdoZXJlIHRoZSBwYXJ0aWVzIG1heSBub3Qga25vdyBlYWNoIG90aGVyDQpw ZXJzb25hbGx5IG9yIHdoZXJlIG9uZSBwYXJ0eSB3aXNoZXMgdG8gYWNjb21tb2RhdGUgcGVvcGxl IHdpdGggdmFyeWluZw0KbGFuZ3VhZ2UgYW5kIG1lZGlhIG5lZWRzLg0KDQpJbiB0aGUgcmVhbC10 aW1lIGNvbW11bmljYXRpb24gY2FzZSwgbGFuZ3VhZ2UgYW5kIG1lZGlhIGFyZQ0KaW50cmluc2lj YWxseSBsaW5rZWQsIGZvciBleGFtcGxlLCBzaWduZWQgbGFuZ3VhZ2VzIHJlcXVpcmUgYSB2aWRl bw0KbWVkaWEuDQoNCldoaWxlIHRoZSB0d28gdXNlIGNhc2VzIGFyZSBpbiBkaWZmZXJlbnQgY29u dGV4dHMgKHJlYWwgdGltZSBhbmQNCm5vbi1yZWFsLXRpbWUpLCB0aGUgZnVuZGFtZW50YWwgZ29h bCBpcyB0aGUgc2FtZTogdG8gZW5hYmxlIHNlbGVjdGlvbiBvZg0KdGhlIGJlc3QtZml0IGxhbmd1 YWdlKHMpIGZvciBhIHNwZWNpZmljIHNpdHVhdGlvbi4gIFNvbWUgb2YgdGhlIGRldGFpbHMNCndp bGwgYWxzbyBiZSBpbiBjb21tb24gYWNyb3NzIHRoZSBjYXNlcywgZS5nLiwgdGhlIGxhbmd1YWdl IHRhZ3MuDQpIYXZpbmcgYSBzaW5nbGUgV0cgYWRkcmVzcyBib3RoIGNhc2VzIG1ha2VzIGl0IGNs ZWFyIHRoYXQgdGhlc2UgYXJlIHR3bw0KYXNwZWN0cyBvZiB0aGUgc2FtZSBiYXNpYyBwcm9ibGVt LiAgQSBzaW5nbGUgV0cgYWxzbyBtYWtlcyBpdCBlYXNpZXIgdG8NCm1heGltaXplIHNpbWlsYXJp dGllcyBhbmQgYXZvaWQgdW5uZWNlc3NhcnkgZnJhZ21lbnRhdGlvbiBvZiB0aGUNCnNvbHV0aW9u cyBhbmQgZmFjaWxpdGF0ZXMgYnJvYWRlciByZXZpZXcuDQoNClRoZSBncm91cCB3aWxsIHN0YXJ0 IGJ5IHByb2R1Y2luZyBzcGVjaWZpY2F0aW9ucyBmb3IgZW1haWwgYW5kIGZvcg0KcmVhbC10aW1l IGNvbW11bmljYXRpb25zLg0KDQpJbiB0aGUgZW1haWwgY2FzZSwgdGhlIGdyb3VwIHdpbGwgZGV0 ZXJtaW5lIGEgTUlNRSBiYXNlZCBzb2x1dGlvbiAoYmFzZWQNCm9uIGRyYWZ0LXRvbWtpbnNvbi1z bGltLW11bHRpbGFuZ2NvbnRlbnQpIHRoYXQgZW5hYmxlcyBhIHNpbmdsZSBlbWFpbA0KbWVzc2Fn ZSB0byBjb250YWluIG11bHRpcGxlIGxhbmd1YWdlIHZlcnNpb25zIG9mIHRoZSBjb250ZW50LCB3 aXRoDQpwcm92aXNpb25zIHRvIGhlbHAgY2xpZW50cyBzZWxlY3QgYSBiZXN0LWZpdCB2ZXJzaW9u Lg0KDQpJbiB0aGUgcmVhbC10aW1lIGNvbW11bmljYXRpb24gY2FzZSwgdGhlIGdyb3VwIHdpbGwg cHJvZHVjZSBhDQpzcGVjaWZpY2F0aW9uIChiYXNlZCBvbiBkcmFmdC1nZWxsZW5zLXNsaW0tbmVn b3RpYXRpbmctaHVtYW4tbGFuZ3VhZ2UpDQplbmFibGluZyBuZWdvdGlhdGlvbiBvZiBhIGh1bWFu IGxhbmd1YWdlIHBlciBtZWRpYSBzdHJlYW0uICBUaGUNCnNwZWNpZmljYXRpb24gbXVzdCBiZSBz dWl0YWJsZSBmb3IgdXNlIGluIGVtZXJnZW5jeSBjb21tdW5pY2F0aW9ucyBhcw0Kc3BlY2lmaWVk IGluIFJGQyA2NDQzIGFuZCBSRkMgNjg4MSAod2hpY2ggdXNlIFNJUCBhbmQgU0RQIHRvIG5lZ290 aWF0ZQ0KbWVkaWEpOyBpdCBpcyBkZXNpcmFibGUgdG8gYWxzbyBiZSBzdWl0YWJsZSBmb3IgdXNl IGluIG5vbi1lbWVyZ2VuY3kNCnJlYWwtdGltZSBjb21tdW5pY2F0aW9ucyB0aGF0IHNoYXJlIHRo ZSBzYW1lIGNhbGwgc2V0LXVwIGFuZCBtZWRpYQ0KbmVnb3RpYXRpb24gcHJvdG9jb2xzLiAgVGhl IG1lY2hhbmlzbSB3aWxsIHBlcm1pdCB0aGUgY2FsbGVyJ3MgbWVkaWEgYW5kDQpsYW5ndWFnZSBu ZWVkcyBhbmQgcHJlZmVyZW5jZXMgdG8gYmUgbWF0Y2hlZCBhZ2FpbnN0IHdoYXQgdGhlIGNhbGxl ZA0KcGFydHkgaXMgYWJsZSB0byBwcm92aWRlLiAgQWx0ZXJuYXRpdmVzIHN1Y2ggYXMgZG9pbmcg dGhlIG1lZGlhDQpuZWdvdGlhdGlvbiBpbiBTSVAgaGF2ZSBiZWVuIGV4cGxvcmVkIGluIHRoZSBw YXN0IGFuZCBhcmUgb3V0IG9mIHNjb3BlDQooYWx0aG91Z2ggU0lQLWJhc2VkIG1lY2hhbmlzbXMg bWF5IGJlIGludHJvZHVjZWQgd2hlbiByb3V0aW5nDQpjb25zaWRlcmF0aW9ucyBhcmUgYWRkcmVz c2VkKS4NCg0KVGhlIGdyb3VwJ3MgaW5pdGlhbCBmb2N1cyB3aWxsIG5vdCBiZSBvbiBzdXBwb3J0 aW5nIGxhbmd1YWdlLWJhc2VkIGNhbGwNCnJvdXRpbmcgZGVjaXNpb25zLiAgT25jZSB0aGUgaW5p dGlhbCB3b3JrIGlzIHN1ZmZpY2llbnRseSBwcm9ncmVzc2VkLCB0aGUNCmdyb3VwIG1heSAgYWRk cmVzcyBjYWxsIHJvdXRpbmcsIHdpdGggdGhlIHRpbWluZyBhdCB0aGUganVkZ21lbnQgb2YgdGhl DQpjaGFpcnMuDQoNClJlY29nbml6aW5nIHRoYXQgY29tcGxleCBzb2x1dGlvbnMgYXJlIHNpZ25p ZmljYW50bHkgbGVzcw0KbGlrZWx5IHRvIHNlZSB3aWRlc3ByZWFkIGRlcGxveW1lbnQsIHRoZSBn cm91cCB3aWxsIHNvbHZlIHRoZSBtb3N0DQpjb21tb24gdXNlIGNhc2VzIGFuZCBhdm9pZCBhZGRp bmcgY29tcGxleGl0eSB0byBzb2x2ZSBlZGdlIG9yDQpsZXNzLWNvbW1vbiBjYXNlcy4NCg0KQnkg YWRkaW5nIGxhbmd1YWdlIHRvIHRoZSBleGlzdGluZyBtZWRpYSBuZWdvdGlhdGlvbiBtZWNoYW5p c20gYXMgdXNlZA0KaW4gUkZDIDY0NDMgYW5kIFJGQyA2ODgxLCB0aGUgZ3JvdXAgY2FuIG1lZXQg dGhlIGJhc2ljIHVzZSBjYXNlcyB3aXRoDQptaW5pbWFsIGFkZGVkIGNvbXBsZXhpdHkgYW5kIGJl IGFibGUgdG8gZW5oYW5jZSBsYXRlciBmb3IgYWRkaXRpb25hbCB1c2UNCmNhc2VzIGFzIG5lZWRl ZC4NCg0KTWlsZXN0b25lczoNCiBOb3YgMjAxNSAtIFN1Ym1pdCAiTXVsdGlwbGUgTGFuZ3VhZ2Ug Q29udGVudCBUeXBlIiB0byB0aGUgSUVTRyAoYmFzZWQNCm9uIGRyYWZ0LXRvbWtpbnNvbi1zbGlt LW11bHRpbGFuZ2NvbnRlbnQpDQogTWFyIDIwMTYgLSBTdWJtaXQgIk5lZ290aWF0aW5nIEh1bWFu IExhbmd1YWdlIGluIFJlYWwtVGltZQ0KQ29tbXVuaWNhdGlvbnMiIHRvIHRoZSBJRVNHIChiYXNl ZCBvbg0KZHJhZnQtZ2VsbGVucy1zbGltLW5lZ290aWF0aW5nLWh1bWFuLWxhbmd1YWdlKQ0KDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpTTElNIG1h aWxpbmcgbGlzdA0KU0xJTUBpZXRmLm9yZzxtYWlsdG86U0xJTUBpZXRmLm9yZz4NCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2xpbQ0KDQoNClRoaXMgZW1haWwgYW5kIGl0 cyBhdHRhY2htZW50cyBhcmUgaW50ZW5kZWQgZm9yIHRoZSBhYm92ZSBuYW1lZCBvbmx5IGFuZCBt YXkgYmUgY29uZmlkZW50aWFsLiBJZiB0aGV5IGhhdmUgY29tZSB0byB5b3UgaW4gZXJyb3IgeW91 IG11c3QgdGFrZSBubyBhY3Rpb24gYmFzZWQgb24gdGhlbSwgbm9yIG11c3QgeW91IGNvcHkgb3Ig c2hvdyB0aGVtIHRvIGFueW9uZTsgcGxlYXNlIHJlcGx5IHRvIHRoaXMgZW1haWwgb3IgY2FsbCAr NDQgMjA3IDM1NiAwNjAwIGFuZCBoaWdobGlnaHQgdGhlIGVycm9yLg0K --_000_742C57B332AB4055914B11E6C136E568gsmacom_ Content-Type: text/html; charset="utf-8" Content-ID: <2CBBF76CB7FF7E4F89563BBE51D54FC4@eurprd04.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBhcHBsZS1jb250ZW50LWVk aXRlZD0idHJ1ZSIgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBs ZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsg dGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3Jt YWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Ut d2lkdGg6IDBweDsgd29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3Bh Y2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxk aXYgY2xhc3M9IiI+SGkgYWxsIQ0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+VGhhbmsteW91IGZvciBzdWJzY3JpYmluZyB0byB0aGUgU0xJTSBtYWls aW5nIGxpc3QuIEkgaGF2ZSBzb21lIG5ld3MgZm9yIGV2ZXJ5b25lIHdoaWNoIGhvcGVmdWxseSB3 b27igJl0IGJlIHRvbyBtdWNoIG9mIGEgc3VycHJpc2UhDQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj48YiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2I+PC9kaXY+DQo8ZGl2IGNsYXNz PSIiPjx1IGNsYXNzPSIiPjxiIGNsYXNzPSIiPkNoYXJ0ZXI8L2I+PC91PjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj5UaGUgU0xJTSBjaGFydGVyIGhhcyBiZWVuIGFwcHJvdmVkLCBzbyB3ZSBhcmUgbm93 IG9mZmljaWFsbHkgYW4gSUVURiBXb3JraW5nIEdyb3VwISBUaGFuay15b3UgdG8gZXZlcnlvbmUg d2hvIGdhdmUgaW5wdXQgdG8gdGhpcy4gWW91IGNhbiByZWFkIHRoZSBmdWxsIGNoYXJ0ZXIgb24g ZGF0YXRyYWNrZXIgKGFsbCBsaW5rcyBhcmUgYmVsb3cpLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PHUgY2xhc3M9IiI+PGIgY2xhc3M9 IiI+Q2hhaXJzPC9iPjwvdT48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+QXMgeW91IHNob3VsZCBiZSBh YmxlIHRvIHNlZSBmcm9tIHRoZSBhYm92ZSBsaW5rIHdlIGhhdmUgdHdvIGNoYWlycywgQmVybmFy ZCBBYm9iYSBhbmQgbXlzZWxmLCBOYXRhc2hhIFJvb25leS4gQmVybmFyZCBpcyBhIGZhbW91cyBJ RVRGZXIgYW5kIG1hbnkgb2YgeW91IHdpbGwga25vdyBoaW0gYXMgYSBQcmluY2lwbGUgQXJjaGl0 ZWN0IGF0IE1pY3Jvc29mdCwgYSBwcmV2aW91cyBJQUIgQ2hhaXIsIGEgVzNDIFdlYlJUQyBkcmFm dA0KIGVkaXRvciBhbmQgYSZuYnNwO2NvbnRyaWJ1dG9yIHRvIGFyb3VuZCA2MCBSRkNzLiBJIHdv cmsgZm9yIEdTTUEsIGEgZ2xvYmFsIHRlbGVjb21tdW5pY2F0aW9ucyBhc3NvY2lhdGlvbiwgYXMg YSB3ZWIgYW5kIGludGVybmV0IHRlY2hub2xvZ2lzdCB3b3JraW5nIG9uIGNvbm5lY3RpbmcgaW50 ZXJuZXQgdGVjaG5vbG9naWVzIHdpdGggdGhlIG1vYmlsZSBuZXR3b3JrLiZuYnNwOzwvZGl2Pg0K PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+QXMgY2hh aXJzIG9mIHRoZSB3b3JraW5nIGdyb3VwIEJlcm5hcmQgYW5kIEkgd2lsbCB3b3JrIHRvIHN1cHBv cnQgdGhlIGJ1aWxkaW5nIG9mIG91ciBkcmFmdHMsIG9yZ2FuaXNpbmcgb3VyIG1lZXRpbmdzLCBt YW5hZ2luZyBvdXIgbWFpbGluZyBsaXN0cyBhbmQgbWFraW5nIHN1cmUgd2Ugd29yayB3aXRoIHRo ZSBJRVRGIHByb2Nlc3MgdG8gdHVybiBvdXIgZHJhZnRzIGludG8gUkZDcyBpbiBhIHRpbWVseSBt YW5uZXIuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj48dSBjbGFzcz0iIj48YiBjbGFzcz0iIj5RdWVzdGlvbnM8L2I+PC91PjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj5JZiB5b3UgaGF2ZSBxdWVzdGlvbnMgcGxlYXNlIGRvIGFzayB1cy4gUG9z dGluZyBxdWVzdGlvbnMgdG8gdGhlIGxpc3QgaXMgcHJlZmVycmVkLCBidXQgeW91IGNhbiBhbHNv IGVtYWlsIHVzIGRpcmVjdGx5IGlmIHlvdSBuZWVkIHRvLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+V2XigJlyZSBsb29raW5nIGZvcndh cmQgdG8gd29ya2luZyB3aXRoIHlvdSBhbGwhPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5OYXRhc2hhPC9kaXY+DQo8ZGl2IGNsYXNzPSIi PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YiBjbGFzcz0iIj48dSBjbGFz cz0iIj5MaW5rczwvdT48L2I+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48 YiBjbGFzcz0iIj5EYXRhdHJhY2tlciBQYWdlPC9iPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YSBo cmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL3dnL3NsaW0vY2hhcnRlci8iIGNsYXNz PSIiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvd2cvc2xpbS9jaGFydGVyLzwvYT48L2Rp dj4NCjxkaXYgY2xhc3M9IiI+PGIgY2xhc3M9IiI+TWFpbCBBcmNoaXZlPC9iPjwvZGl2Pg0KPGRp diBjbGFzcz0iIj48YSBocmVmPSJodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvYnJv d3NlL3NsaW0vIiBjbGFzcz0iIj5odHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvYnJv d3NlL3NsaW0vPC9hPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YiBjbGFzcz0iIj5JRVRGOTQ8L2I+ PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21lZXRp bmcvOTQvIiBjbGFzcz0iIj5odHRwczovL3d3dy5pZXRmLm9yZy9tZWV0aW5nLzk0LzwvYT48YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGIgY2xhc3M9IiI+SUVURjk0IEFnZW5k YTwvYj48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9tZWV0aW5nLzk0L2FnZW5kYS5odG1sIiBjbGFzcz0iIj5odHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL21lZXRpbmcvOTQvYWdlbmRhLmh0bWw8L2E+PC9kaXY+DQo8ZGl2IGNsYXNz PSIiPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBsZXR0 ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4 dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7 IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lk dGg6IDBweDsgd29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7 IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgbGV0dGVy LXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQt aW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3 aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRo OiAwcHg7IHdvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAt d2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQo8YnIgY2xh c3M9IiI+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCk5hdGFzaGEgUm9vbmV5IHwgVGVjaG5vbG9n aXN0LCBXZWIgYW5kIEludGVybmV0LCBXM0MgJmFtcDsgSUVURiB8Jm5ic3A7R1NNQSB8IDxhIGhy ZWY9Im1haWx0bzpucm9vbmV5QGdzbWEuY29tIiBjbGFzcz0iIj4NCm5yb29uZXlAZ3NtYS5jb208 L2E+IHwgJiM0Mzs0NCAoMCkmbmJzcDs3NzMwIDIxOSA3NjUgfCBAdGhpc05hdGFzaGEgfCBTa3lw ZTombmJzcDs8YSBocmVmPSJtYWlsdG86bnJvb25leUBnc20ub3JnIiBjbGFzcz0iIj5ucm9vbmV5 QGdzbS5vcmc8L2E+Jm5ic3A7PGJyIGNsYXNzPSIiPg0KVG9reW8sIEphcGFuPGJyIGNsYXNzPSIi Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSB0eXBl PSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGRpcj0iYXV0byIgY2xhc3M9 IiI+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgdHlw ZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxiIGNsYXNzPSIiPkZyb206PC9iPiBU aGUgSUVTRyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmllc2ctc2VjcmV0YXJ5QGlldGYub3JnIiBjbGFz cz0iIj5pZXNnLXNlY3JldGFyeUBpZXRmLm9yZzwvYT4mZ3Q7PGJyIGNsYXNzPSIiPg0KPGIgY2xh c3M9IiI+RGF0ZTo8L2I+IE9jdG9iZXIgMTYsIDIwMTUgYXQgOTo1MzozMCBBTSBQRFQ8YnIgY2xh c3M9IiI+DQo8YiBjbGFzcz0iIj5Ubzo8L2I+ICZxdW90O0lFVEYtQW5ub3VuY2UmcXVvdDsgJmx0 OzxhIGhyZWY9Im1haWx0bzppZXRmLWFubm91bmNlQGlldGYub3JnIiBjbGFzcz0iIj5pZXRmLWFu bm91bmNlQGlldGYub3JnPC9hPiZndDs8YnIgY2xhc3M9IiI+DQo8YiBjbGFzcz0iIj5DYzo8L2I+ IDxhIGhyZWY9Im1haWx0bzpzbGltQGlldGYub3JnIiBjbGFzcz0iIj5zbGltQGlldGYub3JnPC9h PiwgVGhlIElFU0cgJmx0OzxhIGhyZWY9Im1haWx0bzppZXNnQGlldGYub3JnIiBjbGFzcz0iIj5p ZXNnQGlldGYub3JnPC9hPiZndDssDQo8YSBocmVmPSJtYWlsdG86c2xpbS1jaGFpcnNAaWV0Zi5v cmciIGNsYXNzPSIiPnNsaW0tY2hhaXJzQGlldGYub3JnPC9hPjxiciBjbGFzcz0iIj4NCjxiIGNs YXNzPSIiPlN1YmplY3Q6PC9iPiA8YiBjbGFzcz0iIj5bU2xpbV0gV0cgQWN0aW9uOiBGb3JtZWQg U2VsZWN0aW9uIG9mIExhbmd1YWdlIGZvciBJbnRlcm5ldCBNZWRpYSAoc2xpbSk8L2I+PGJyIGNs YXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90 ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PHNwYW4gY2xhc3M9IiI+QSBu ZXcgSUVURiB3b3JraW5nIGdyb3VwIGhhcyBiZWVuIGZvcm1lZCBpbiB0aGUgQXBwbGljYXRpb25z IGFuZDwvc3Bhbj48YnIgY2xhc3M9IiI+DQo8c3BhbiBjbGFzcz0iIj5SZWFsLVRpbWUgQXJlYS4g Rm9yIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gcGxlYXNlIGNvbnRhY3QgdGhlIEFyZWE8L3NwYW4+ PGJyIGNsYXNzPSIiPg0KPHNwYW4gY2xhc3M9IiI+RGlyZWN0b3JzIG9yIHRoZSBXRyBDaGFpcnMu PC9zcGFuPjxiciBjbGFzcz0iIj4NCjxzcGFuIGNsYXNzPSIiPjwvc3Bhbj48YnIgY2xhc3M9IiI+ DQo8c3BhbiBjbGFzcz0iIj5TZWxlY3Rpb24gb2YgTGFuZ3VhZ2UgZm9yIEludGVybmV0IE1lZGlh IChzbGltKTwvc3Bhbj48YnIgY2xhc3M9IiI+DQo8c3BhbiBjbGFzcz0iIj4tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08L3NwYW4+PGJyIGNsYXNzPSIiPg0K PHNwYW4gY2xhc3M9IiI+Q3VycmVudCBTdGF0dXM6IFByb3Bvc2VkIFdHPC9zcGFuPjxiciBjbGFz cz0iIj4NCjxzcGFuIGNsYXNzPSIiPjwvc3Bhbj48YnIgY2xhc3M9IiI+DQo8c3BhbiBjbGFzcz0i Ij5DaGFpcnM6PC9zcGFuPjxiciBjbGFzcz0iIj4NCjxzcGFuIGNsYXNzPSIiPiZuYnNwO0Jlcm5h cmQgQWJvYmEgJmx0OzxhIGhyZWY9Im1haWx0bzpCZXJuYXJkX0Fib2JhQGhvdG1haWwuY29tIiBj bGFzcz0iIj5CZXJuYXJkX0Fib2JhQGhvdG1haWwuY29tPC9hPiZndDs8L3NwYW4+PGJyIGNsYXNz PSIiPg0KPHNwYW4gY2xhc3M9IiI+Jm5ic3A7TiBSb29uZXkgJmx0OzxhIGhyZWY9Im1haWx0bzpu cm9vbmV5QGdzbWEuY29tIiBjbGFzcz0iIj5ucm9vbmV5QGdzbWEuY29tPC9hPiZndDs8L3NwYW4+ PGJyIGNsYXNzPSIiPg0KPHNwYW4gY2xhc3M9IiI+PC9zcGFuPjxiciBjbGFzcz0iIj4NCjxzcGFu IGNsYXNzPSIiPkFzc2lnbmVkIEFyZWEgRGlyZWN0b3I6PC9zcGFuPjxiciBjbGFzcz0iIj4NCjxz cGFuIGNsYXNzPSIiPiZuYnNwO0JhcnJ5IExlaWJhICZsdDs8YSBocmVmPSJtYWlsdG86YmFycnls ZWliYUBjb21wdXRlci5vcmciIGNsYXNzPSIiPmJhcnJ5bGVpYmFAY29tcHV0ZXIub3JnPC9hPiZn dDs8L3NwYW4+PGJyIGNsYXNzPSIiPg0KPHNwYW4gY2xhc3M9IiI+PC9zcGFuPjxiciBjbGFzcz0i Ij4NCjxzcGFuIGNsYXNzPSIiPk1haWxpbmcgbGlzdDwvc3Bhbj48YnIgY2xhc3M9IiI+DQo8c3Bh biBjbGFzcz0iIj4mbmJzcDtBZGRyZXNzOiA8YSBocmVmPSJtYWlsdG86c2xpbUBpZXRmLm9yZyIg Y2xhc3M9IiI+c2xpbUBpZXRmLm9yZzwvYT48L3NwYW4+PGJyIGNsYXNzPSIiPg0KPHNwYW4gY2xh c3M9IiI+Jm5ic3A7VG8gU3Vic2NyaWJlOiA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3NsaW0iIGNsYXNzPSIiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zbGltPC9hPjwvc3Bhbj48YnIgY2xhc3M9IiI+DQo8c3BhbiBjbGFzcz0i Ij4mbmJzcDtBcmNoaXZlOiA8YSBocmVmPSJodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2Fy Y2gvYnJvd3NlL3NsaW0vIiBjbGFzcz0iIj4NCmh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcv YXJjaC9icm93c2Uvc2xpbS88L2E+PC9zcGFuPjxiciBjbGFzcz0iIj4NCjxzcGFuIGNsYXNzPSIi Pjwvc3Bhbj48YnIgY2xhc3M9IiI+DQo8c3BhbiBjbGFzcz0iIj5DaGFydGVyOjwvc3Bhbj48YnIg Y2xhc3M9IiI+DQo8c3BhbiBjbGFzcz0iIj48L3NwYW4+PGJyIGNsYXNzPSIiPg0KPHNwYW4gY2xh c3M9IiI+QSBtdXR1YWxseSBjb21wcmVoZW5zaWJsZSBsYW5ndWFnZSBpcyBoZWxwZnVsIGZvciBo dW1hbiBjb21tdW5pY2F0aW9uLg0KPC9zcGFuPjxiciBjbGFzcz0iIj4NCjxzcGFuIGNsYXNzPSIi PlRoaXMgaXMgdHJ1ZSBhY3Jvc3MgYSByYW5nZSBvZiBjaXJjdW1zdGFuY2VzIGFuZCBlbnZpcm9u bWVudHMuICZuYnNwO0luPC9zcGFuPjxiciBjbGFzcz0iIj4NCjxzcGFuIGNsYXNzPSIiPmdlbmVy YWwsIHRoZSBwcm9ibGVtIGlzIG1vc3QgYWN1dGUgaW4gc2l0dWF0aW9ucyB3aGVyZSB0aGVyZSBp cyBub3QgYTwvc3Bhbj48YnIgY2xhc3M9IiI+DQo8c3BhbiBjbGFzcz0iIj5jbGVhciBjaG9pY2Ug Zm9yIGEgc2luZ2xlIGxhbmd1YWdlLCBzdWNoIGFzIGVudmlyb25tZW50cyBsYWNraW5nPC9zcGFu PjxiciBjbGFzcz0iIj4NCjxzcGFuIGNsYXNzPSIiPmNvbnRleHR1YWwgb3Igb3V0LW9mLWJhbmQg aW5mb3JtYXRpb24gcmVnYXJkaW5nIHRoZSBpZGVudGl0eSBvZiB0aGU8L3NwYW4+PGJyIGNsYXNz PSIiPg0KPHNwYW4gY2xhc3M9IiI+cGFydGllcyBhbmQgdGhlIGxhbmd1YWdlIHRvIGJlIHVzZWQu PC9zcGFuPjxiciBjbGFzcz0iIj4NCjxzcGFuIGNsYXNzPSIiPjwvc3Bhbj48YnIgY2xhc3M9IiI+ DQo8c3BhbiBjbGFzcz0iIj5UaGUgZ3JvdXAgd2lsbCBhZGRyZXNzIHR3byBzcGVjaWZpYyBjYXNl cyB0aGF0IG1vc3QgdXJnZW50bHkgbmVlZCBhPC9zcGFuPjxiciBjbGFzcz0iIj4NCjxzcGFuIGNs YXNzPSIiPnRlY2huaWNhbCBzb2x1dGlvbjogT25lIHByb2JsZW0gc3BhY2UgaXMgbm9uLXJlYWwt dGltZSBjb21tdW5pY2F0aW9uLDwvc3Bhbj48YnIgY2xhc3M9IiI+DQo8c3BhbiBjbGFzcz0iIj5z cGVjaWZpY2FsbHkgZW1haWwgZm9yIG9uZS10by1tYW55IG9yIHdoZXJlIHRoZSBzZXQgb2YgcmVj aXBpZW50cyBpczwvc3Bhbj48YnIgY2xhc3M9IiI+DQo8c3BhbiBjbGFzcz0iIj5keW5hbWljIG9y IGRpZmZlcmVudCByZWNpcGllbnRzIHJlcXVpcmUgZGlmZmVyZW50IGxhbmd1YWdlczsgdGhlIG90 aGVyPC9zcGFuPjxiciBjbGFzcz0iIj4NCjxzcGFuIGNsYXNzPSIiPmlzIHJlYWwtdGltZSBjb21t dW5pY2F0aW9uLCBzcGVjaWZpY2FsbHkgZW1lcmdlbmN5IGNhbGxpbmcsIHByZWZlcmFibHk8L3Nw YW4+PGJyIGNsYXNzPSIiPg0KPHNwYW4gY2xhc3M9IiI+YWxzbyB1c2VmdWwgZm9yIG90aGVyIGNh c2VzIHdoZXJlIHRoZSBwYXJ0aWVzIG1heSBub3Qga25vdyBlYWNoIG90aGVyPC9zcGFuPjxiciBj bGFzcz0iIj4NCjxzcGFuIGNsYXNzPSIiPnBlcnNvbmFsbHkgb3Igd2hlcmUgb25lIHBhcnR5IHdp c2hlcyB0byBhY2NvbW1vZGF0ZSBwZW9wbGUgd2l0aCB2YXJ5aW5nPC9zcGFuPjxiciBjbGFzcz0i Ij4NCjxzcGFuIGNsYXNzPSIiPmxhbmd1YWdlIGFuZCBtZWRpYSBuZWVkcy48L3NwYW4+PGJyIGNs YXNzPSIiPg0KPHNwYW4gY2xhc3M9IiI+PC9zcGFuPjxiciBjbGFzcz0iIj4NCjxzcGFuIGNsYXNz PSIiPkluIHRoZSByZWFsLXRpbWUgY29tbXVuaWNhdGlvbiBjYXNlLCBsYW5ndWFnZSBhbmQgbWVk aWEgYXJlPC9zcGFuPjxiciBjbGFzcz0iIj4NCjxzcGFuIGNsYXNzPSIiPmludHJpbnNpY2FsbHkg bGlua2VkLCBmb3IgZXhhbXBsZSwgc2lnbmVkIGxhbmd1YWdlcyByZXF1aXJlIGEgdmlkZW88L3Nw YW4+PGJyIGNsYXNzPSIiPg0KPHNwYW4gY2xhc3M9IiI+bWVkaWEuPC9zcGFuPjxiciBjbGFzcz0i Ij4NCjxzcGFuIGNsYXNzPSIiPjwvc3Bhbj48YnIgY2xhc3M9IiI+DQo8c3BhbiBjbGFzcz0iIj5X aGlsZSB0aGUgdHdvIHVzZSBjYXNlcyBhcmUgaW4gZGlmZmVyZW50IGNvbnRleHRzIChyZWFsIHRp bWUgYW5kPC9zcGFuPjxiciBjbGFzcz0iIj4NCjxzcGFuIGNsYXNzPSIiPm5vbi1yZWFsLXRpbWUp LCB0aGUgZnVuZGFtZW50YWwgZ29hbCBpcyB0aGUgc2FtZTogdG8gZW5hYmxlIHNlbGVjdGlvbiBv Zjwvc3Bhbj48YnIgY2xhc3M9IiI+DQo8c3BhbiBjbGFzcz0iIj50aGUgYmVzdC1maXQgbGFuZ3Vh Z2UocykgZm9yIGEgc3BlY2lmaWMgc2l0dWF0aW9uLiAmbmJzcDtTb21lIG9mIHRoZSBkZXRhaWxz PC9zcGFuPjxiciBjbGFzcz0iIj4NCjxzcGFuIGNsYXNzPSIiPndpbGwgYWxzbyBiZSBpbiBjb21t b24gYWNyb3NzIHRoZSBjYXNlcywgZS5nLiwgdGhlIGxhbmd1YWdlIHRhZ3MuIDwvc3Bhbj4NCjxi ciBjbGFzcz0iIj4NCjxzcGFuIGNsYXNzPSIiPkhhdmluZyBhIHNpbmdsZSBXRyBhZGRyZXNzIGJv dGggY2FzZXMgbWFrZXMgaXQgY2xlYXIgdGhhdCB0aGVzZSBhcmUgdHdvPC9zcGFuPjxiciBjbGFz cz0iIj4NCjxzcGFuIGNsYXNzPSIiPmFzcGVjdHMgb2YgdGhlIHNhbWUgYmFzaWMgcHJvYmxlbS4g Jm5ic3A7QSBzaW5nbGUgV0cgYWxzbyBtYWtlcyBpdCBlYXNpZXIgdG88L3NwYW4+PGJyIGNsYXNz PSIiPg0KPHNwYW4gY2xhc3M9IiI+bWF4aW1pemUgc2ltaWxhcml0aWVzIGFuZCBhdm9pZCB1bm5l Y2Vzc2FyeSBmcmFnbWVudGF0aW9uIG9mIHRoZTwvc3Bhbj48YnIgY2xhc3M9IiI+DQo8c3BhbiBj bGFzcz0iIj5zb2x1dGlvbnMgYW5kIGZhY2lsaXRhdGVzIGJyb2FkZXIgcmV2aWV3Ljwvc3Bhbj48 YnIgY2xhc3M9IiI+DQo8c3BhbiBjbGFzcz0iIj48L3NwYW4+PGJyIGNsYXNzPSIiPg0KPHNwYW4g Y2xhc3M9IiI+VGhlIGdyb3VwIHdpbGwgc3RhcnQgYnkgcHJvZHVjaW5nIHNwZWNpZmljYXRpb25z IGZvciBlbWFpbCBhbmQgZm9yPC9zcGFuPjxiciBjbGFzcz0iIj4NCjxzcGFuIGNsYXNzPSIiPnJl YWwtdGltZSBjb21tdW5pY2F0aW9ucy48L3NwYW4+PGJyIGNsYXNzPSIiPg0KPHNwYW4gY2xhc3M9 IiI+PC9zcGFuPjxiciBjbGFzcz0iIj4NCjxzcGFuIGNsYXNzPSIiPkluIHRoZSBlbWFpbCBjYXNl LCB0aGUgZ3JvdXAgd2lsbCBkZXRlcm1pbmUgYSBNSU1FIGJhc2VkIHNvbHV0aW9uIChiYXNlZDwv c3Bhbj48YnIgY2xhc3M9IiI+DQo8c3BhbiBjbGFzcz0iIj5vbiBkcmFmdC10b21raW5zb24tc2xp bS1tdWx0aWxhbmdjb250ZW50KSB0aGF0IGVuYWJsZXMgYSBzaW5nbGUgZW1haWw8L3NwYW4+PGJy IGNsYXNzPSIiPg0KPHNwYW4gY2xhc3M9IiI+bWVzc2FnZSB0byBjb250YWluIG11bHRpcGxlIGxh bmd1YWdlIHZlcnNpb25zIG9mIHRoZSBjb250ZW50LCB3aXRoPC9zcGFuPjxiciBjbGFzcz0iIj4N CjxzcGFuIGNsYXNzPSIiPnByb3Zpc2lvbnMgdG8gaGVscCBjbGllbnRzIHNlbGVjdCBhIGJlc3Qt Zml0IHZlcnNpb24uPC9zcGFuPjxiciBjbGFzcz0iIj4NCjxzcGFuIGNsYXNzPSIiPjwvc3Bhbj48 YnIgY2xhc3M9IiI+DQo8c3BhbiBjbGFzcz0iIj5JbiB0aGUgcmVhbC10aW1lIGNvbW11bmljYXRp b24gY2FzZSwgdGhlIGdyb3VwIHdpbGwgcHJvZHVjZSBhPC9zcGFuPjxiciBjbGFzcz0iIj4NCjxz cGFuIGNsYXNzPSIiPnNwZWNpZmljYXRpb24gKGJhc2VkIG9uIGRyYWZ0LWdlbGxlbnMtc2xpbS1u ZWdvdGlhdGluZy1odW1hbi1sYW5ndWFnZSk8L3NwYW4+PGJyIGNsYXNzPSIiPg0KPHNwYW4gY2xh c3M9IiI+ZW5hYmxpbmcgbmVnb3RpYXRpb24gb2YgYSBodW1hbiBsYW5ndWFnZSBwZXIgbWVkaWEg c3RyZWFtLiAmbmJzcDtUaGU8L3NwYW4+PGJyIGNsYXNzPSIiPg0KPHNwYW4gY2xhc3M9IiI+c3Bl Y2lmaWNhdGlvbiBtdXN0IGJlIHN1aXRhYmxlIGZvciB1c2UgaW4gZW1lcmdlbmN5IGNvbW11bmlj YXRpb25zIGFzPC9zcGFuPjxiciBjbGFzcz0iIj4NCjxzcGFuIGNsYXNzPSIiPnNwZWNpZmllZCBp biBSRkMgNjQ0MyBhbmQgUkZDIDY4ODEgKHdoaWNoIHVzZSBTSVAgYW5kIFNEUCB0byBuZWdvdGlh dGU8L3NwYW4+PGJyIGNsYXNzPSIiPg0KPHNwYW4gY2xhc3M9IiI+bWVkaWEpOyBpdCBpcyBkZXNp cmFibGUgdG8gYWxzbyBiZSBzdWl0YWJsZSBmb3IgdXNlIGluIG5vbi1lbWVyZ2VuY3k8L3NwYW4+ PGJyIGNsYXNzPSIiPg0KPHNwYW4gY2xhc3M9IiI+cmVhbC10aW1lIGNvbW11bmljYXRpb25zIHRo YXQgc2hhcmUgdGhlIHNhbWUgY2FsbCBzZXQtdXAgYW5kIG1lZGlhPC9zcGFuPjxiciBjbGFzcz0i Ij4NCjxzcGFuIGNsYXNzPSIiPm5lZ290aWF0aW9uIHByb3RvY29scy4gJm5ic3A7VGhlIG1lY2hh bmlzbSB3aWxsIHBlcm1pdCB0aGUgY2FsbGVyJ3MgbWVkaWEgYW5kPC9zcGFuPjxiciBjbGFzcz0i Ij4NCjxzcGFuIGNsYXNzPSIiPmxhbmd1YWdlIG5lZWRzIGFuZCBwcmVmZXJlbmNlcyB0byBiZSBt YXRjaGVkIGFnYWluc3Qgd2hhdCB0aGUgY2FsbGVkPC9zcGFuPjxiciBjbGFzcz0iIj4NCjxzcGFu IGNsYXNzPSIiPnBhcnR5IGlzIGFibGUgdG8gcHJvdmlkZS4gJm5ic3A7QWx0ZXJuYXRpdmVzIHN1 Y2ggYXMgZG9pbmcgdGhlIG1lZGlhPC9zcGFuPjxiciBjbGFzcz0iIj4NCjxzcGFuIGNsYXNzPSIi Pm5lZ290aWF0aW9uIGluIFNJUCBoYXZlIGJlZW4gZXhwbG9yZWQgaW4gdGhlIHBhc3QgYW5kIGFy ZSBvdXQgb2Ygc2NvcGU8L3NwYW4+PGJyIGNsYXNzPSIiPg0KPHNwYW4gY2xhc3M9IiI+KGFsdGhv dWdoIFNJUC1iYXNlZCBtZWNoYW5pc21zIG1heSBiZSBpbnRyb2R1Y2VkIHdoZW4gcm91dGluZzwv c3Bhbj48YnIgY2xhc3M9IiI+DQo8c3BhbiBjbGFzcz0iIj5jb25zaWRlcmF0aW9ucyBhcmUgYWRk cmVzc2VkKS48L3NwYW4+PGJyIGNsYXNzPSIiPg0KPHNwYW4gY2xhc3M9IiI+PC9zcGFuPjxiciBj bGFzcz0iIj4NCjxzcGFuIGNsYXNzPSIiPlRoZSBncm91cCdzIGluaXRpYWwgZm9jdXMgd2lsbCBu b3QgYmUgb24gc3VwcG9ydGluZyBsYW5ndWFnZS1iYXNlZCBjYWxsPC9zcGFuPjxiciBjbGFzcz0i Ij4NCjxzcGFuIGNsYXNzPSIiPnJvdXRpbmcgZGVjaXNpb25zLiAmbmJzcDtPbmNlIHRoZSBpbml0 aWFsIHdvcmsgaXMgc3VmZmljaWVudGx5IHByb2dyZXNzZWQsIHRoZTwvc3Bhbj48YnIgY2xhc3M9 IiI+DQo8c3BhbiBjbGFzcz0iIj5ncm91cCBtYXkgJm5ic3A7YWRkcmVzcyBjYWxsIHJvdXRpbmcs IHdpdGggdGhlIHRpbWluZyBhdCB0aGUganVkZ21lbnQgb2YgdGhlPC9zcGFuPjxiciBjbGFzcz0i Ij4NCjxzcGFuIGNsYXNzPSIiPmNoYWlycy48L3NwYW4+PGJyIGNsYXNzPSIiPg0KPHNwYW4gY2xh c3M9IiI+PC9zcGFuPjxiciBjbGFzcz0iIj4NCjxzcGFuIGNsYXNzPSIiPlJlY29nbml6aW5nIHRo YXQgY29tcGxleCBzb2x1dGlvbnMgYXJlIHNpZ25pZmljYW50bHkgbGVzczwvc3Bhbj48YnIgY2xh c3M9IiI+DQo8c3BhbiBjbGFzcz0iIj5saWtlbHkgdG8gc2VlIHdpZGVzcHJlYWQgZGVwbG95bWVu dCwgdGhlIGdyb3VwIHdpbGwgc29sdmUgdGhlIG1vc3Q8L3NwYW4+PGJyIGNsYXNzPSIiPg0KPHNw YW4gY2xhc3M9IiI+Y29tbW9uIHVzZSBjYXNlcyBhbmQgYXZvaWQgYWRkaW5nIGNvbXBsZXhpdHkg dG8gc29sdmUgZWRnZSBvcjwvc3Bhbj48YnIgY2xhc3M9IiI+DQo8c3BhbiBjbGFzcz0iIj5sZXNz LWNvbW1vbiBjYXNlcy48L3NwYW4+PGJyIGNsYXNzPSIiPg0KPHNwYW4gY2xhc3M9IiI+PC9zcGFu PjxiciBjbGFzcz0iIj4NCjxzcGFuIGNsYXNzPSIiPkJ5IGFkZGluZyBsYW5ndWFnZSB0byB0aGUg ZXhpc3RpbmcgbWVkaWEgbmVnb3RpYXRpb24gbWVjaGFuaXNtIGFzIHVzZWQ8L3NwYW4+PGJyIGNs YXNzPSIiPg0KPHNwYW4gY2xhc3M9IiI+aW4gUkZDIDY0NDMgYW5kIFJGQyA2ODgxLCB0aGUgZ3Jv dXAgY2FuIG1lZXQgdGhlIGJhc2ljIHVzZSBjYXNlcyB3aXRoPC9zcGFuPjxiciBjbGFzcz0iIj4N CjxzcGFuIGNsYXNzPSIiPm1pbmltYWwgYWRkZWQgY29tcGxleGl0eSBhbmQgYmUgYWJsZSB0byBl bmhhbmNlIGxhdGVyIGZvciBhZGRpdGlvbmFsIHVzZTwvc3Bhbj48YnIgY2xhc3M9IiI+DQo8c3Bh biBjbGFzcz0iIj5jYXNlcyBhcyBuZWVkZWQuPC9zcGFuPjxiciBjbGFzcz0iIj4NCjxzcGFuIGNs YXNzPSIiPjwvc3Bhbj48YnIgY2xhc3M9IiI+DQo8c3BhbiBjbGFzcz0iIj5NaWxlc3RvbmVzOjwv c3Bhbj48YnIgY2xhc3M9IiI+DQo8c3BhbiBjbGFzcz0iIj4mbmJzcDtOb3YgMjAxNSAtIFN1Ym1p dCAmcXVvdDtNdWx0aXBsZSBMYW5ndWFnZSBDb250ZW50IFR5cGUmcXVvdDsgdG8gdGhlIElFU0cg KGJhc2VkPC9zcGFuPjxiciBjbGFzcz0iIj4NCjxzcGFuIGNsYXNzPSIiPm9uIGRyYWZ0LXRvbWtp bnNvbi1zbGltLW11bHRpbGFuZ2NvbnRlbnQpPC9zcGFuPjxiciBjbGFzcz0iIj4NCjxzcGFuIGNs YXNzPSIiPiZuYnNwO01hciAyMDE2IC0gU3VibWl0ICZxdW90O05lZ290aWF0aW5nIEh1bWFuIExh bmd1YWdlIGluIFJlYWwtVGltZTwvc3Bhbj48YnIgY2xhc3M9IiI+DQo8c3BhbiBjbGFzcz0iIj5D b21tdW5pY2F0aW9ucyZxdW90OyB0byB0aGUgSUVTRyAoYmFzZWQgb248L3NwYW4+PGJyIGNsYXNz PSIiPg0KPHNwYW4gY2xhc3M9IiI+ZHJhZnQtZ2VsbGVucy1zbGltLW5lZ290aWF0aW5nLWh1bWFu LWxhbmd1YWdlKTwvc3Bhbj48YnIgY2xhc3M9IiI+DQo8c3BhbiBjbGFzcz0iIj48L3NwYW4+PGJy IGNsYXNzPSIiPg0KPHNwYW4gY2xhc3M9IiI+PC9zcGFuPjxiciBjbGFzcz0iIj4NCjxzcGFuIGNs YXNzPSIiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC9z cGFuPjxiciBjbGFzcz0iIj4NCjxzcGFuIGNsYXNzPSIiPlNMSU0gbWFpbGluZyBsaXN0PC9zcGFu PjxiciBjbGFzcz0iIj4NCjxzcGFuIGNsYXNzPSIiPjxhIGhyZWY9Im1haWx0bzpTTElNQGlldGYu b3JnIiBjbGFzcz0iIj5TTElNQGlldGYub3JnPC9hPjwvc3Bhbj48YnIgY2xhc3M9IiI+DQo8c3Bh biBjbGFzcz0iIj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NsaW0iIGNsYXNzPSIiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2xp bTwvYT48L3NwYW4+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8cCBzdHlsZT0i Zm9udC1mYW1pbHk6IEFyaWFsLHNhbnMtc2VyaWY7Zm9udC1zaXplOjExcHg7Y29sb3I6Izk5OTk5 OTsiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLHNhbnMtc2Vy aWY7Y29sb3I6Izk5OTk5OTsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IEFyaWFsOyBtc28tZmFy ZWFzdC10aGVtZS1mb250OiBtaW5vci1sYXRpbjsgbXNvLWJpZGktZm9udC1mYW1pbHk6ICZxdW90 O0FyaWFsJnF1b3Q7OyBtc28tYW5zaS1sYW5ndWFnZTogRU4tVVM7IG1zby1mYXJlYXN0LWxhbmd1 YWdlOiBFTi1HQjsgbXNvLWJpZGktbGFuZ3VhZ2U6IEFSLVNBIj5UaGlzDQogZW1haWwgYW5kIGl0 cyBhdHRhY2htZW50cyBhcmUgaW50ZW5kZWQgZm9yIHRoZSBhYm92ZSBuYW1lZCBvbmx5IGFuZCBt YXkgYmUgY29uZmlkZW50aWFsLiBJZiB0aGV5IGhhdmUgY29tZSB0byB5b3UgaW4gZXJyb3IgeW91 IG11c3QgdGFrZSBubyBhY3Rpb24gYmFzZWQgb24gdGhlbSwgbm9yIG11c3QgeW91IGNvcHkgb3Ig c2hvdyB0aGVtIHRvIGFueW9uZTsgcGxlYXNlIHJlcGx5IHRvIHRoaXMgZW1haWwgb3IgY2FsbCAm IzQzOzQ0IDIwNyAzNTYgMDYwMA0KIGFuZCBoaWdobGlnaHQgdGhlIGVycm9yLiA8L3NwYW4+PC9w Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_742C57B332AB4055914B11E6C136E568gsmacom_-- From nobody Sun Nov 1 14:50:55 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A6AF1A87D9 for ; Mon, 19 Oct 2015 02:35:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 bTM1njhPjUTU for ; Mon, 19 Oct 2015 02:35:30 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0623.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::623]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 290C31A87CE for ; Mon, 19 Oct 2015 02:35:28 -0700 (PDT) Received: from HE1PR04MB1033.eurprd04.prod.outlook.com (10.162.26.142) by HE1PR04MB1036.eurprd04.prod.outlook.com (10.162.26.145) with Microsoft SMTP Server (TLS) id 15.1.300.14; Mon, 19 Oct 2015 09:35:21 +0000 Received: from HE1PR04MB1033.eurprd04.prod.outlook.com ([10.162.26.142]) by HE1PR04MB1033.eurprd04.prod.outlook.com ([10.162.26.142]) with mapi id 15.01.0300.010; Mon, 19 Oct 2015 09:35:21 +0000 From: Natasha Rooney To: "slim@ietf.org" Thread-Topic: Request for agenda items of IETF94 Thread-Index: AQHRClF5KkJZL40XckW8jLnnxV5njA== Date: Mon, 19 Oct 2015 09:35:21 +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.2098) authentication-results: spf=none (sender IP is ) smtp.mailfrom=nrooney@gsma.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [118.109.86.198] x-microsoft-exchange-diagnostics: 1; HE1PR04MB1036; 5:sCMKAlGgjlp8eKORJZCw95rtFqPhnqT34+tXZ0oHscE7929OlRMQtvvceVKbL51xaHTAGHDFmRU+hUcMcs8wM6ir498wuzJSy8RHXsIxcv2yIrOIEEEGs6byujyauJXxHhQCte6j5JuvMMi3U0dRtg==; 24:gYM5D9sgEFNA2m/VqLtZ5GMi6GNKLjiPrlpZB/bLfgCDnoxIGjkd67oirGG/Io5V8+WR09IR73P4K7pPX6LsBWwHw7nDFNfq0va9FLsainQ=; 20:wrooGllevfaqgGTrfz9+7jlFg8aNXd5nVmX4A/LIaI0/VQpuWgZ7/hYT6aXPj5KgWpBSw0M5plXKlHxLf+OPnA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR04MB1036; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(260367931017790); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(520078)(3002001); SRVR:HE1PR04MB1036; BCL:0; PCL:0; RULEID:; SRVR:HE1PR04MB1036; x-forefront-prvs: 07349BFAD2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(53754006)(189002)(199003)(66066001)(15975445007)(57306001)(450100001)(46102003)(87936001)(86362001)(2501003)(5001960100002)(106116001)(5007970100001)(106356001)(19580395003)(2900100001)(2351001)(5004730100002)(105586002)(107886002)(19580405001)(189998001)(16236675004)(64706001)(102836002)(11100500001)(92566002)(81156007)(36756003)(33656002)(40100003)(5008740100001)(110136002)(50986999)(77096005)(5002640100001)(82746002)(5890100001)(50226001)(19617315012)(101416001)(229853001)(10400500002)(122556002)(83716003)(97736004)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR04MB1036; H:HE1PR04MB1033.eurprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: gsma.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_E1C03D34DC834F1181A6F7B807E8C905gsmacom_" MIME-Version: 1.0 X-OriginatorOrg: gsma.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2015 09:35:21.0587 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72a4ff82-fec3-469d-aafb-ac8276216699 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR04MB1036 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: HE1PR04MB1033.eurprd04.prod.outlook.com X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-originalclientipaddress: 118.109.86.198 X-MS-Exchange-CrossPremises-avstamp-service: 1.0 X-MS-Exchange-CrossPremises-disclaimer-hash: 78ca8040c6722e32c2f5b0a45bf37e74b9409d645a53be96aa19958e0cee0f00 X-MS-Exchange-CrossPremises-antispam-scancontext: DIR:Originating; SFV:NSPM; SKIP:0; X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-OrganizationHeadersPreserved: HE1PR04MB1036.eurprd04.prod.outlook.com Archived-At: X-Mailman-Approved-At: Sun, 01 Nov 2015 14:50:52 -0800 Subject: [Slim] Request for agenda items of IETF94 X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2015 09:35:31 -0000 --_000_E1C03D34DC834F1181A6F7B807E8C905gsmacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsIQ0KDQpBcyB5b3UgY2FuIHNlZSBmcm9tIHRoZSBJRVRGOTQgYWdlbmRhIHdlIGhhdmUg YSBtZWV0aW5nIGJvb2tlZCBmb3IgMTc6MTAtMTk6MTAgb24gTW9uZGF5IEFmdGVybm9vbiBTZXNz aW9uIElJSSAod2hlcmUgSeKAmW0gZnJvbSB3ZSBjYWxsIHRoaXMgImV2ZW5pbmciIGJ1dCBvayEp Lg0KDQpCZXJuYXJkIGFuZCBJIGFyZSBub3cgcmVxdWVzdGluZyBhZ2VuZGEgaXRlbXMgZm9yIHRo aXMgbWVldGluZy4gUGxlYXNlIHNlbmQgYSBtYWlsIHRvIHRoaXMgbGlzdCB3aXRoIHN1Z2dlc3Rp b25zIGZvciB0aGUgbWVldGluZy4NCg0KQmVybmFyZCBhbHNvIHNlbnQgYSBtYWlsIHJlY2VudGx5 IGFza2luZyBpZiBhbnlvbmUgaGFzIGFueSByZXF1aXJlbWVudHMgZm9yIHRoZSBtZWV0aW5nLiBX ZSB3aWxsIG9mIGNvdXJzZSBoYXZlIHJlbW90ZSBjb25mZXJlbmNpbmcgYXZhaWxhYmxlLCBidXQg aWYgeW91IHJlcXVpcmUgYW55IG90aGVyIHN1cHBvcnQgZm9yIHRoZSBtZWV0aW5nIHBsZWFzZSBk byBsZXQgdXMga25vdy4NCg0KVGhhbmtzIGV2ZXJ5b25lIQ0KDQpOYXRhc2hhDQoNCkxpbmtzDQpE YXRhdHJhY2tlciBQYWdlDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL3dnL3NsaW0vY2hh cnRlci8NCk1haWwgQXJjaGl2ZQ0KaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL2Jy b3dzZS9zbGltLw0KSUVURjk0DQpodHRwczovL3d3dy5pZXRmLm9yZy9tZWV0aW5nLzk0Lw0KSUVU Rjk0IEFnZW5kYQ0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nLzk0L2FnZW5k YS5odG1sDQoNCg0KDQpOYXRhc2hhIFJvb25leSB8IFRlY2hub2xvZ2lzdCwgV2ViIGFuZCBJbnRl cm5ldCwgVzNDICYgSUVURiB8IEdTTUEgfCBucm9vbmV5QGdzbWEuY29tPG1haWx0bzpucm9vbmV5 QGdzbWEuY29tPiB8ICs0NCAoMCkgNzczMCAyMTkgNzY1IHwgQHRoaXNOYXRhc2hhIHwgU2t5cGU6 IG5yb29uZXlAZ3NtLm9yZzxtYWlsdG86bnJvb25leUBnc20ub3JnPg0KVG9reW8sIEphcGFuDQoN Cg0KDQpUaGlzIGVtYWlsIGFuZCBpdHMgYXR0YWNobWVudHMgYXJlIGludGVuZGVkIGZvciB0aGUg YWJvdmUgbmFtZWQgb25seSBhbmQgbWF5IGJlIGNvbmZpZGVudGlhbC4gSWYgdGhleSBoYXZlIGNv bWUgdG8geW91IGluIGVycm9yIHlvdSBtdXN0IHRha2Ugbm8gYWN0aW9uIGJhc2VkIG9uIHRoZW0s IG5vciBtdXN0IHlvdSBjb3B5IG9yIHNob3cgdGhlbSB0byBhbnlvbmU7IHBsZWFzZSByZXBseSB0 byB0aGlzIGVtYWlsIG9yIGNhbGwgKzQ0IDIwNyAzNTYgMDYwMCBhbmQgaGlnaGxpZ2h0IHRoZSBl cnJvci4NCg== --_000_E1C03D34DC834F1181A6F7B807E8C905gsmacom_ Content-Type: text/html; charset="utf-8" Content-ID: <2FFD6E9A2FD7BC4B888E3DB99A483F8E@eurprd04.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYg Y2xhc3M9IiI+SGkgYWxsITwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+QXMgeW91IGNhbiBzZWUgZnJvbSB0aGUgSUVURjk0IGFnZW5kYSB3 ZSBoYXZlIGEgbWVldGluZyBib29rZWQgZm9yJm5ic3A7MTc6MTAtMTk6MTAgb24gTW9uZGF5IEFm dGVybm9vbiBTZXNzaW9uIElJSSAod2hlcmUgSeKAmW0gZnJvbSB3ZSBjYWxsIHRoaXMgJnF1b3Q7 ZXZlbmluZyZxdW90OyBidXQgb2shKS4mbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkJlcm5hcmQgYW5kIEkgYXJlIG5vdyByZXF1 ZXN0aW5nIGFnZW5kYSBpdGVtcyBmb3IgdGhpcyBtZWV0aW5nLiBQbGVhc2UmbmJzcDtzZW5kIGEg bWFpbCB0byB0aGlzIGxpc3Qgd2l0aCBzdWdnZXN0aW9ucyBmb3IgdGhlIG1lZXRpbmcuJm5ic3A7 PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij5CZXJuYXJkIGFsc28gc2VudCBhIG1haWwgcmVjZW50bHkgYXNraW5nIGlmIGFueW9uZSBoYXMg YW55IHJlcXVpcmVtZW50cyBmb3IgdGhlIG1lZXRpbmcuIFdlIHdpbGwgb2YgY291cnNlIGhhdmUg cmVtb3RlIGNvbmZlcmVuY2luZyBhdmFpbGFibGUsIGJ1dCBpZiB5b3UgcmVxdWlyZSBhbnkgb3Ro ZXIgc3VwcG9ydCBmb3IgdGhlIG1lZXRpbmcgcGxlYXNlIGRvIGxldCB1cyBrbm93LiZuYnNwOzwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ VGhhbmtzIGV2ZXJ5b25lITwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+TmF0YXNoYTwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+ DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGIgY2xhc3M9IiI+PHUgY2xhc3M9IiI+TGlua3M8L3U+ PC9iPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGIgY2xhc3M9IiI+RGF0 YXRyYWNrZXIgUGFnZTwvYj48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGEgaHJlZj0iaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy93Zy9zbGltL2NoYXJ0ZXIvIiBjbGFzcz0iIj5odHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL3dnL3NsaW0vY2hhcnRlci88L2E+PC9kaXY+DQo8ZGl2IGNsYXNz PSIiPjxiIGNsYXNzPSIiPk1haWwgQXJjaGl2ZTwvYj48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGEg aHJlZj0iaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL2Jyb3dzZS9zbGltLyIgY2xh c3M9IiI+aHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL2Jyb3dzZS9zbGltLzwvYT48 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGIgY2xhc3M9IiI+SUVURjk0PC9iPjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tZWV0aW5nLzk0LyIgY2xhc3M9 IiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWVldGluZy85NC88L2E+PGJyIGNsYXNzPSIiPg0KPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPjxiIGNsYXNzPSIiPklFVEY5NCBBZ2VuZGE8L2I+PC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGlu Zy85NC9hZ2VuZGEuaHRtbCIgY2xhc3M9IiI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9t ZWV0aW5nLzk0L2FnZW5kYS5odG1sPC9hPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48L2Rpdj4NCjwv ZGl2Pg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9k ZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0i Ij4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBhcHBsZS1jb250ZW50LWVkaXRlZD0idHJ1 ZSIgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBsZXR0ZXItc3Bh Y2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRl bnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93 czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBw eDsgd29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJr aXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxiciBjbGFzcz0i Ij4NCjxiciBjbGFzcz0iIj4NCk5hdGFzaGEgUm9vbmV5IHwgVGVjaG5vbG9naXN0LCBXZWIgYW5k IEludGVybmV0LCBXM0MgJmFtcDsgSUVURiB8Jm5ic3A7R1NNQSB8IDxhIGhyZWY9Im1haWx0bzpu cm9vbmV5QGdzbWEuY29tIiBjbGFzcz0iIj4NCm5yb29uZXlAZ3NtYS5jb208L2E+IHwgJiM0Mzs0 NCAoMCkmbmJzcDs3NzMwIDIxOSA3NjUgfCBAdGhpc05hdGFzaGEgfCBTa3lwZTombmJzcDs8YSBo cmVmPSJtYWlsdG86bnJvb25leUBnc20ub3JnIiBjbGFzcz0iIj5ucm9vbmV5QGdzbS5vcmc8L2E+ Jm5ic3A7PGJyIGNsYXNzPSIiPg0KVG9reW8sIEphcGFuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNz PSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxwIHN0eWxlPSJmb250LWZhbWls eTogQXJpYWwsc2Fucy1zZXJpZjtmb250LXNpemU6MTFweDtjb2xvcjojOTk5OTk5OyI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsc2Fucy1zZXJpZjtjb2xvcjoj OTk5OTk5OyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogQXJpYWw7IG1zby1mYXJlYXN0LXRoZW1l LWZvbnQ6IG1pbm9yLWxhdGluOyBtc28tYmlkaS1mb250LWZhbWlseTogJnF1b3Q7QXJpYWwmcXVv dDs7IG1zby1hbnNpLWxhbmd1YWdlOiBFTi1VUzsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEVOLUdC OyBtc28tYmlkaS1sYW5ndWFnZTogQVItU0EiPlRoaXMNCiBlbWFpbCBhbmQgaXRzIGF0dGFjaG1l bnRzIGFyZSBpbnRlbmRlZCBmb3IgdGhlIGFib3ZlIG5hbWVkIG9ubHkgYW5kIG1heSBiZSBjb25m aWRlbnRpYWwuIElmIHRoZXkgaGF2ZSBjb21lIHRvIHlvdSBpbiBlcnJvciB5b3UgbXVzdCB0YWtl IG5vIGFjdGlvbiBiYXNlZCBvbiB0aGVtLCBub3IgbXVzdCB5b3UgY29weSBvciBzaG93IHRoZW0g dG8gYW55b25lOyBwbGVhc2UgcmVwbHkgdG8gdGhpcyBlbWFpbCBvciBjYWxsICYjNDM7NDQgMjA3 IDM1NiAwNjAwDQogYW5kIGhpZ2hsaWdodCB0aGUgZXJyb3IuIDwvc3Bhbj48L3A+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_E1C03D34DC834F1181A6F7B807E8C905gsmacom_-- From nobody Sun Nov 1 14:50:57 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BA6E1B29AD for ; Sat, 31 Oct 2015 21:20:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 NE2DHtktC78n for ; Sat, 31 Oct 2015 21:20:10 -0700 (PDT) Received: from mail.amsl.com (mail.amsl.com [4.31.198.40]) by ietfa.amsl.com (Postfix) with ESMTP id 525431B29B6 for ; Sat, 31 Oct 2015 21:20:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 2CA321E59F1 for ; Sat, 31 Oct 2015 21:19:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H_ju6G6LwoIM for ; Sat, 31 Oct 2015 21:19:44 -0700 (PDT) Received: from dhcp-33-28.meeting.ietf94.jp (unknown [133.93.28.33]) by c8a.amsl.com (Postfix) with ESMTPA id D08671E59E4 for ; Sat, 31 Oct 2015 21:19:43 -0700 (PDT) From: Alexa Morris Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Sat, 31 Oct 2015 21:20:19 -0700 Message-Id: To: slim@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Sendlaterdate: Sat, 31 Oct 2015 21:20:19 -0700 X-Mailer: Apple Mail (2.1878.6) Archived-At: X-Mailman-Approved-At: Sun, 01 Nov 2015 14:50:52 -0800 Subject: [Slim] Virtual Queue for SLIM Remote Attendees X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 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, 01 Nov 2015 04:20:11 -0000 If you are planning to participate in the SLIM session here at IETF 94 = on Monday =97 either locally in Prague or as a remote participant =97 we = want to make sure that you are aware that the IETF is providing a remote = participants with a fairly new way to ask questions or make comments. In = addition to using the Jabber room, for the SLIM session there is also = the opportunity for remote participants to enter a virtual queue and ask = questions directly into the meeting room.=20 This experimental queue was used in several sessions at IETF 92 and IETF = 93, so you may have already seen it in action. There will be two queues = for the SLIM session =97 a virtual queue and an actual (in-room) queue. = Remote attendees will log into the Meetecho platform and will have a = virtual mic line that they can enter if they have a question or comment. = In-room participants will continue to use normal mic lines.=20 Instructions for remote participants are at = http://ietf94.conf.meetecho.com/index.php/Remote_Participation.=20 Information on how to join the Meetecho session is at = http://ietf94.conf.meetecho.com/. Verify that you are WebRTC compliant (required to use the virtual queue) = by performing a self-test here: = http://ietf94.conf.meetecho.com/index.php/Self_Test.=20 Regards, Alexa ---------- Alexa Morris / Executive Director / IETF 48377 Fremont Blvd., Suite 117, Fremont, CA 94538 Phone: +1.510.492.4089 / Fax: +1.510.492.4001 Email: amorris@amsl.com Managed by Association Management Solutions (AMS) Forum Management, Meeting and Event Planning www.amsl.com From nobody Sun Nov 1 22:07:58 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DABC1B4812 for ; Sun, 1 Nov 2015 22:07:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.987 X-Spam-Level: X-Spam-Status: No, score=-5.987 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, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 S6jFov4PaS57 for ; Sun, 1 Nov 2015 22:07:53 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D94871B481D for ; Sun, 1 Nov 2015 22:07:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1446444473; x=1477980473; h=message-id:in-reply-to:references:date:to:from:subject: mime-version:content-transfer-encoding; bh=+iMidSnQmCQ5ANGOMBD55XFDh/vWSLo4LsFwfz3L45Q=; b=gnKwDdC7+D1s4W5Dxit+MEGqF5CX/pfpk8aeOsXYefDLfXnqwLowwhs8 EmyHKWEvlqgvDUZktIfxUNwb1tfcrvfcrwbJQUIw8dapE1posuZg4FcVq w4MpQPfJORNWpoy7P6kfT08ItSiYqL/f2Z4yBt4uybMN6TG3XPM0+50Ip I=; X-IronPort-AV: E=McAfee;i="5700,7163,7972"; a="147256278" Received: from ironmsg02-r-new.qualcomm.com (HELO ironmsg02-R.qualcomm.com) ([10.53.140.106]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Nov 2015 22:07:53 -0800 X-IronPort-AV: E=Sophos;i="5.20,233,1444719600"; d="scan'208,217";a="609297499" Received: from nasanexm02f.na.qualcomm.com ([10.85.0.87]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 01 Nov 2015 22:07:53 -0800 Received: from dhcp-96-48.meeting.ietf94.jp (10.80.80.8) by nasanexm02f.na.qualcomm.com (10.85.0.87) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Sun, 1 Nov 2015 22:07:38 -0800 Message-ID: In-Reply-To: <5610DC61.5020005@omnitor.se> References: <5610DC61.5020005@omnitor.se> X-Mailer: Eudora for Mac OS X Date: Sun, 1 Nov 2015 22:01:35 -0800 To: Gunnar =?iso-8859-1?Q?Hellstr=F6m?= , "slim@ietf.org" From: Randall Gellens MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01E.na.qualcomm.com (10.85.0.31) To nasanexm02f.na.qualcomm.com (10.85.0.87) Archived-At: Subject: Re: [Slim] The use of multiple lang attributes in SDP X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 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, 02 Nov 2015 06:07:56 -0000 Re: [Slim] The use of multiple lang attributes in SDP
At 9:59 AM +0200 10/4/15, Gunnar Hellstr=F6m wrote:

I have looked a bit further into the vague specification of use of multiple a=3D lang attributes in SDP, as discussed in section 6 of
https://tools.ietf.org/html/draft-gellens-slim-negotiating-human-language-02

My conclusion is that we can safely assume that for real-time sessions, the meaning of multiple lang specifications is a range of capabilities, and not a requirement to use all languages as the current interpretation in the draft leans towards.

This was not my interpretation from the wording, and also from an example (it's been years so I am no longer sure of the source of the example) which was a clip of a TV interview where the person being interviewed spoke another language from that of the interviewer.

By that interpretation, we can also assume that an offer/answer exchange can negotiate the language(s) to use in a session to be a subset of what the offer contained.

If this wording is correct, then we don't need anything new, we can use the existing lang attribute for negotiation, and the real-time milestone of the group can be declared moot and we can move on.  That would be great, but doesn't match my understanding.


The wording from RFC 4566, repeated in the draft, section 6 is:

"
Multiple lang attributes can be
      provided either at session or media level if the session
      description or media use multiple languages, in which case the
      order of the attributes indicates the order of importance of the
      various languages in the session or media from most important to
      least important."

I traced the introduction of the wording from an announcement in mmusic on 1997-11-23, and then the wording appeared in draft-ietf-mmusic-sdp-05 on 1997-12-23. There was no further discussion and the wording has stayed like that since then.

In the mail announcing the introduction it was said that the intention was to fulfill requirements from a draft by Harald Alvestrand that then became RFC 2277.

A relevant section in RFC 2277 is:
"
4.4.  Considerations for language negotiation

   Protocols where users have text presented to them in response to user
   actions MUST provide for support of multiple languages.

   How this is done will vary between protocols; for instance, in some
   cases, a negotiation where the client proposes a set of languages and
   the server replies with one is appropriate; in other cases, a server
   may choose to send multiple variants of a text and let the client
   pick which one to display.

   Negotiation is useful in the case where one side of the protocol
   exchange is able to present text in multiple languages to the other
   side, and the other side has a preference for one of these; the most
   common example is the text part of error responses, or Web pages that
   are available in multiple languages.

   Negotiating a language should be regarded as a permanent requirement
   of the protocol that will not go away at any time in the future.

   In many cases, it should be possible to include it as part of the
   connection establishment, together with authentication and other
   preferences negotiation. "

So it is apparent that the intention for real-time conversational cases is a negotiation with
 an offer and a selection, either in an answer or by human agreement in the session.

The central word creating the current interpretation in our draft that all languages must be used is "use" in this phrase:
"if the session description or media use multiple languages".

It is hard to believe that that was the intention. A very simple change makes it more realistic:
"if the session or media can use multiple languages".

There are multiple reasons for that interpretation:

1. It aligns with the requirement for language negotiation in RFC 2277 that was said to be
   the requirement behind the wording.
2. It is usually unrealistic to use multiple languages at the same time in a medium.
   It is more in line with real-time conversation that events during the conversation causes decision to use
   just one language.

3. The following discussion of importance of languages lose its meaning if all must be used. "the
order of the attributes indicates the order of importance of the various languages in the session or media".
There is no use of knowing how important a language is if they all must be presented. It is more likely that
this relates to a possibility to select and the importance is a grading of preference.

This would mean that we can safely assume that the use of multiple lang attributes in SDP are intended as
a selection and negotiation through offer/answer.

To put this assumption in words, we could either just insert the word "can" in the sentence from RFC 4566,
or make a more elaborated rewording, e.g. into:

" Multiple lang attributes can be provided either at session or media level if the session or media has
capability to use multiple languages, in which case the order of the attributes indicates the order of
preference of the various possible languages in the session or media from most preferred to least preferred.
Events during the session may influence which language(s) are used, and for real-time sessions, the
participants are not strictly bound to only use the declared languages."

( the last sentence was inspired from a similar specification, I do not remember from where. It may have been from CLUE or XCON )

Which wording do you prefer?

Is it realistic to propose an errata to rfc 4566 for this kind of diffuse interpretation issue, or is it sufficient to declare the interpretation in our draft?

If the reasoning above is accepted in slim, it would require changes in section 6 of the draft and open for some
use of the current lang attributes for simple cases. But since we do not get directionality from the current attributes,
there is still a need to add the humintlang attributes.

/Gunnar

_______________________________________________
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: ---------------
He knows nothing, and he thinks he knows everything. That points
clearly to a political career.
    -- George Bernard Shaw
From nobody Sun Nov 1 22:16:37 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 911F71B481A for ; Sun, 1 Nov 2015 22:16:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 kF0p3ekM3fXB for ; Sun, 1 Nov 2015 22:16:33 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A10371B4819 for ; Sun, 1 Nov 2015 22:16:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1446444993; x=1477980993; h=message-id:in-reply-to:references:date:to:from:subject: mime-version; bh=H9sm5WSifU/2bQyU5BiMxLGuZZamq7OPAPZmEDzGI9M=; b=vzZW7OmaczOxi9U6brnerCqO57ulpPKLRgpd/iknn6UDi6Xq2pQrQIFZ kFxJocYfrF9j3/9m8DlBuyshiBsA/otHwcheRUkBfZOZsXKozdMfW7Gwc ilXd2uEiw5x/8b2VzQLvSQi+7ZbndKLRKClaPzQ578dMXVGDdbxmTE83e 4=; X-IronPort-AV: E=McAfee;i="5700,7163,7972"; a="147257928" Received: from ironmsg04-r-new.qualcomm.com (HELO Ironmsg04-R.qualcomm.com) ([10.53.140.108]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Nov 2015 22:16:26 -0800 X-IronPort-AV: E=Sophos;i="5.20,233,1444719600"; d="scan'208";a="1078084245" Received: from nasanexm02f.na.qualcomm.com ([10.85.0.87]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 01 Nov 2015 22:16:27 -0800 Received: from dhcp-96-48.meeting.ietf94.jp (10.80.80.8) by nasanexm02f.na.qualcomm.com (10.85.0.87) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Sun, 1 Nov 2015 22:16:11 -0800 Message-ID: In-Reply-To: <9d9f51af87d94c8caf26b1f3801c69d4@EX13D08UWC002.ant.amazon.com> References: <9d9f51af87d94c8caf26b1f3801c69d4@EX13D08UWC002.ant.amazon.com> X-Mailer: Eudora for Mac OS X Date: Sun, 1 Nov 2015 22:16:21 -0800 To: "Phillips, Addison" , "slim@ietf.org" From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01F.na.qualcomm.com (10.85.0.32) To nasanexm02f.na.qualcomm.com (10.85.0.87) Archived-At: Subject: [Slim] Primary language tags (was "Re: draft-tomkinson comments") X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 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, 02 Nov 2015 06:16:35 -0000 Extracting this one comment: At 2:10 AM +0000 10/21/15, Addison Phillips wrote: > 5. There is this recommendation: > > -- > While RFC 5646 provides a mechanism accommodating > increasingly fine-grained distinctions, in the interest of maximum > interoperability, each Content-Language value SHOULD be restricted to > the largest granularity of language tags; in other words, it is > RECOMMENDED to specify only a Primary-subtag and NOT to include > subtags (e.g., for region or dialect) unless the languages might be > mutually incomprehensible without them. > -- > > I think this text is potentially harmful, as it might interfere > with the needs of senders and clients to distinguish text based on > a variety of factors and ignores the fact that some language > variation is not mutually comprehensible at the primary language > level. I am very confused. The text explicitly says "unless the languages might be mutually incomprehensible without them" so how can you say that the text ignores cases where subtags are needed for mutual comprehensibility? > > An implementation restriction to the primary language subtag would > be a disadvantage to languages that have important script, region, > or other variations such as extlang or variant. BCP 47 has a whole > section (http://tools.ietf.org/html/bcp47#section-4.1) about the > choice of language tag that basically recommends similar things and > I understand why it's important for senders not to add unnecessary > subtags. But I think you'd be better off not having quite so much > normative language in this specification and a more focused > recommendation that does not impinge on the needs of senders and > clients to provide adequate language information. Please keep in mind that the text in question uses SHOULD and RECOMMENDED, not MUST. That means that when there is a good reason to deviate, and the implications of deviating are well understood, it is acceptable and does not violate conformance. I believe that the text in question does a good job of guiding implementations to maximally-interoperable behavior without forcing problematic behavior in those cases where subtags are needed. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- I'm not proud.... Our products just aren't engineered for security. --Brian Valentine, Senior Vice President, Microsoft Windows Development Team at the Microsoft 2002 .Net developer conference. From nobody Sun Nov 1 23:12:52 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 751E11B3337 for ; Sun, 1 Nov 2015 23:12:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 zwqT6vmCvhbv for ; Sun, 1 Nov 2015 23:12:44 -0800 (PST) Received: from bin-vsp-out-05.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 13A8D1B3201 for ; Sun, 1 Nov 2015 23:12:43 -0800 (PST) X-Halon-ID: 19ba3a81-8131-11e5-8d6a-005056916f53 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.48] (unknown [77.53.228.139]) by bin-vsp-out-05.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Mon, 2 Nov 2015 08:12:38 +0100 (CET) To: slim@ietf.org References: <9d9f51af87d94c8caf26b1f3801c69d4@EX13D08UWC002.ant.amazon.com> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <56370CE6.1000307@omnitor.se> Date: Mon, 2 Nov 2015 08:12:38 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Slim] Primary language tags (was "Re: draft-tomkinson comments") X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 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, 02 Nov 2015 07:12:48 -0000 Good reasoning, I agree with Randall that subtags should be included to the extent that it is important for distinguishing that the contents is suitable and understandable. The same reasoning enable us to distinguish written from spoken language by using the Script subtag to indicate written, even if Suppress-Script is registered for the language tag. RFC 5646 says about Script and Suppress-Script "the script subtag SHOULD be omitted when it adds no distinguishing value to the tag or when the primary or extended language subtag's record in the subtag registry includes a 'Suppress-Script' field listing the applicable script subtag." So, when it is clear from the context if the language tag represents written vs spoken language, then no Script subtag is needed, but if the tag is used in a place where it can be ambigous, then a tag without Script means spoken and a tag with Script means written. Also where written is used in an unusual context, the Script subtag would be used to indicate that it is written. E.g. If captions are overlaid in video, a language tag for the video stream including the Script subtag would make the fact clear that that language is there in text form. ( as distinguished from seeing a person talking that language. ) /Gunnar Den 2015-11-02 kl. 07:16, skrev Randall Gellens: > Extracting this one comment: > > At 2:10 AM +0000 10/21/15, Addison Phillips wrote: > >> 5. There is this recommendation: >> >> -- >> While RFC 5646 provides a mechanism accommodating >> increasingly fine-grained distinctions, in the interest of maximum >> interoperability, each Content-Language value SHOULD be >> restricted to >> the largest granularity of language tags; in other words, it is >> RECOMMENDED to specify only a Primary-subtag and NOT to include >> subtags (e.g., for region or dialect) unless the languages might be >> mutually incomprehensible without them. >> -- >> >> I think this text is potentially harmful, as it might interfere with >> the needs of senders and clients to distinguish text based on a >> variety of factors and ignores the fact that some language variation >> is not mutually comprehensible at the primary language level. > > I am very confused. The text explicitly says "unless the languages > might be mutually incomprehensible without them" so how can you say > that the text ignores cases where subtags are needed for mutual > comprehensibility? > >> >> An implementation restriction to the primary language subtag would >> be a disadvantage to languages that have important script, region, or >> other variations such as extlang or variant. BCP 47 has a whole >> section (http://tools.ietf.org/html/bcp47#section-4.1) about the >> choice of language tag that basically recommends similar things and I >> understand why it's important for senders not to add unnecessary >> subtags. But I think you'd be better off not having quite so much >> normative language in this specification and a more focused >> recommendation that does not impinge on the needs of senders and >> clients to provide adequate language information. > > Please keep in mind that the text in question uses SHOULD and > RECOMMENDED, not MUST. That means that when there is a good reason to > deviate, and the implications of deviating are well understood, it is > acceptable and does not violate conformance. > > I believe that the text in question does a good job of guiding > implementations to maximally-interoperable behavior without forcing > problematic behavior in those cases where subtags are needed. > From nobody Sun Nov 1 23:32:52 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 230071B340F for ; Sun, 1 Nov 2015 23:32:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 Y9KFVYvcbEij for ; Sun, 1 Nov 2015 23:32:46 -0800 (PST) Received: from bin-vsp-out-05.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 3E0741B33F9 for ; Sun, 1 Nov 2015 23:32:46 -0800 (PST) X-Halon-ID: e6a3a08a-8133-11e5-8d6a-005056916f53 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.48] (unknown [77.53.228.139]) by bin-vsp-out-05.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Mon, 2 Nov 2015 08:32:41 +0100 (CET) To: Randall Gellens , "slim@ietf.org" References: <5610DC61.5020005@omnitor.se> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <56371199.4010500@omnitor.se> Date: Mon, 2 Nov 2015 08:32:41 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------050008060905030109050502" Archived-At: Subject: Re: [Slim] The use of multiple lang attributes in SDP X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 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, 02 Nov 2015 07:32:50 -0000 This is a multi-part message in MIME format. --------------050008060905030109050502 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Den 2015-11-02 kl. 07:01, skrev Randall Gellens: > Re: [Slim] The use of multiple lang attributes in SDP > At 9:59 AM +0200 10/4/15, Gunnar Hellström wrote: > >> I have looked a bit further into the vague specification of use of >> multiple a= lang attributes in SDP, as discussed in section 6 of >> https://tools.ietf.org/html/draft-gellens-slim-negotiating-human-language-02 >> >> >> My conclusion is that we can safely assume that for real-time >> sessions, the meaning of multiple lang specifications is a range of >> capabilities, and not a requirement to use all languages as the >> current interpretation in the draft leans towards. > > This was not my interpretation from the wording, and also from an > example (it's been years so I am no longer sure of the source of the > example) which was a clip of a TV interview where the person being > interviewed spoke another language from that of the interviewer. > >> By that interpretation, we can also assume that an offer/answer >> exchange can negotiate the language(s) to use in a session to be a >> subset of what the offer contained. > > If this wording is correct, then we don't need anything new, we can > use the existing lang attribute for negotiation, and the real-time > milestone of the group can be declared moot and we can move on. That > would be great, but doesn't match my understanding. There was a brief mail exchange on this topic in mmusic - RFC4566bis under the subject: [MMUSIC] Clarification for multiple lang attributes in rfc4566bis and the current conclusion is that the interpretation I suggest is acceptable and that a wording change is on its way into RFC 4566 bis. We could work for an errata to RFC 4566 also, but I think that that is overkill for this kind of subtile wording interpretation. But we should change the humintlang draft accordingly. The humintlang added value over the lang attribute is still needed for the cases of 1. different preferences for different directions, ( e.g. speak and read ) 2. linked requirements between media (e.g. must speak and must read ) 3. (absolute) preference relation between language in different media ( e.g. prefer sign language in video but can accept to use written text ) And we need to describe how lang and humintlang attributes interact. /Gunnar > >> >> The wording from RFC 4566, repeated in the draft, section 6 is: >> >> " >> Multiple lang attributes can be >> provided either at session or media level if the session >> description or media use multiple languages, in which case the >> order of the attributes indicates the order of importance of the >> various languages in the session or media from most important to >> least important." >> >> I traced the introduction of the wording from an announcement in >> mmusic on 1997-11-23, and then the wording appeared in >> draft-ietf-mmusic-sdp-05 on 1997-12-23. There was no further >> discussion and the wording has stayed like that since then. >> >> In the mail announcing the introduction it was said that the >> intention was to fulfill requirements from a draft by Harald >> Alvestrand that then became RFC 2277. >> >> A relevant section in RFC 2277 is: >> " >> 4.4. Considerations for language negotiation >> >> Protocols where users have text presented to them in response to user >> actions MUST provide for support of multiple languages. >> >> How this is done will vary between protocols; for instance, in some >> cases, a negotiation where the client proposes a set of languages and >> the server replies with one is appropriate; in other cases, a server >> may choose to send multiple variants of a text and let the client >> pick which one to display. >> >> Negotiation is useful in the case where one side of the protocol >> exchange is able to present text in multiple languages to the other >> side, and the other side has a preference for one of these; the most >> common example is the text part of error responses, or Web pages that >> are available in multiple languages. >> >> Negotiating a language should be regarded as a permanent requirement >> of the protocol that will not go away at any time in the future. >> >> In many cases, it should be possible to include it as part of the >> connection establishment, together with authentication and other >> preferences negotiation. " >> >> So it is apparent that the intention for real-time conversational >> cases is a negotiation with >> an offer and a selection, either in an answer or by human agreement >> in the session. >> >> The central word creating the current interpretation in our draft >> that all languages must be used is "use" in this phrase: >> "if the session description or media*use* multiple languages". >> >> It is hard to believe that that was the intention. A very simple >> change makes it more realistic: >> "if the session or media*can use* multiple languages". >> >> There are multiple reasons for that interpretation: >> >> 1. It aligns with the requirement for language negotiation in RFC >> 2277 that was said to be >> the requirement behind the wording. >> 2. It is usually unrealistic to use multiple languages at the same >> time in a medium. >> It is more in line with real-time conversation that events during >> the conversation causes decision to use >> just one language. >> >> 3. The following discussion of importance of languages lose its >> meaning if all must be used. "the >> order of the attributes indicates the order of importance of the >> various languages in the session or media". >> There is no use of knowing how important a language is if they all >> must be presented. It is more likely that >> this relates to a possibility to select and the importance is a >> grading of preference. >> >> This would mean that we can safely assume that the use of multiple >> lang attributes in SDP are intended as >> a selection and negotiation through offer/answer. >> >> To put this assumption in words, we could either just insert the word >> "can" in the sentence from RFC 4566, >> or make a more elaborated rewording, e.g. into: >> >> " Multiple lang attributes can be provided either at session or media >> level if the session or media has >> capability to use multiple languages, in which case the order of the >> attributes indicates the order of >> preference of the various possible languages in the session or media >> from most preferred to least preferred. >> Events during the session may influence which language(s) are used, >> and for real-time sessions, the >> participants are not strictly bound to only use the declared languages." >> >> ( the last sentence was inspired from a similar specification, I do >> not remember from where. It may have been from CLUE or XCON ) >> >> Which wording do you prefer? >> >> Is it realistic to propose an errata to rfc 4566 for this kind of >> diffuse interpretation issue, or is it sufficient to declare the >> interpretation in our draft? >> >> If the reasoning above is accepted in slim, it would require changes >> in section 6 of the draft and open for some >> use of the current lang attributes for simple cases. But since we do >> not get directionality from the current attributes, >> there is still a need to add the humintlang attributes. >> >> /Gunnar >> >> _______________________________________________ >> 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: --------------- > He knows nothing, and he thinks he knows everything. That points > clearly to a political career. > -- George Bernard Shaw --------------050008060905030109050502 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Den 2015-11-02 kl. 07:01, skrev Randall Gellens:
Re: [Slim] The use of multiple lang attributes in SDP
At 9:59 AM +0200 10/4/15, Gunnar Hellström wrote:

I have looked a bit further into the vague specification of use of multiple a= lang attributes in SDP, as discussed in section 6 of
https://tools.ietf.org/html/draft-gellens-slim-negotiating-human-language-02

My conclusion is that we can safely assume that for real-time sessions, the meaning of multiple lang specifications is a range of capabilities, and not a requirement to use all languages as the current interpretation in the draft leans towards.

This was not my interpretation from the wording, and also from an example (it's been years so I am no longer sure of the source of the example) which was a clip of a TV interview where the person being interviewed spoke another language from that of the interviewer.

By that interpretation, we can also assume that an offer/answer exchange can negotiate the language(s) to use in a session to be a subset of what the offer contained.

If this wording is correct, then we don't need anything new, we can use the existing lang attribute for negotiation, and the real-time milestone of the group can be declared moot and we can move on.  That would be great, but doesn't match my understanding.
There was a brief mail exchange on this topic in mmusic - RFC4566bis under the subject:
[MMUSIC] Clarification for multiple lang attributes in rfc4566bis
and the current conclusion is that the interpretation I suggest is acceptable and that a wording change is on its way into RFC 4566 bis.
We could work for an errata to RFC 4566 also, but I think that that is overkill for this kind of subtile wording interpretation.
But we should change the humintlang draft accordingly.

The humintlang added value over the lang attribute is still needed for the cases of
1. different preferences for different directions, ( e.g. speak and read )
2. linked requirements between media (e.g. must speak and must read )
3. (absolute) preference relation between language in different media ( e.g. prefer sign language in video  but can accept to use written text )

And we need to describe how lang and humintlang attributes interact.

/Gunnar



The wording from RFC 4566, repeated in the draft, section 6 is:

"
Multiple lang attributes can be
      provided either at session or media level if the session
      description or media use multiple languages, in which case the
      order of the attributes indicates the order of importance of the
      various languages in the session or media from most important to
      least important."

I traced the introduction of the wording from an announcement in mmusic on 1997-11-23, and then the wording appeared in draft-ietf-mmusic-sdp-05 on 1997-12-23. There was no further discussion and the wording has stayed like that since then.

In the mail announcing the introduction it was said that the intention was to fulfill requirements from a draft by Harald Alvestrand that then became RFC 2277.

A relevant section in RFC 2277 is:
"
4.4.  Considerations for language negotiation

   Protocols where users have text presented to them in response to user
   actions MUST provide for support of multiple languages.

   How this is done will vary between protocols; for instance, in some
   cases, a negotiation where the client proposes a set of languages and
   the server replies with one is appropriate; in other cases, a server
   may choose to send multiple variants of a text and let the client
   pick which one to display.

   Negotiation is useful in the case where one side of the protocol
   exchange is able to present text in multiple languages to the other
   side, and the other side has a preference for one of these; the most
   common example is the text part of error responses, or Web pages that
   are available in multiple languages.

   Negotiating a language should be regarded as a permanent requirement
   of the protocol that will not go away at any time in the future.

   In many cases, it should be possible to include it as part of the
   connection establishment, together with authentication and other
   preferences negotiation. "

So it is apparent that the intention for real-time conversational cases is a negotiation with
 an offer and a selection, either in an answer or by human agreement in the session.

The central word creating the current interpretation in our draft that all languages must be used is "use" in this phrase:
"if the session description or media use multiple languages".

It is hard to believe that that was the intention. A very simple change makes it more realistic:
"if the session or media can use multiple languages".

There are multiple reasons for that interpretation:

1. It aligns with the requirement for language negotiation in RFC 2277 that was said to be
   the requirement behind the wording.
2. It is usually unrealistic to use multiple languages at the same time in a medium.
   It is more in line with real-time conversation that events during the conversation causes decision to use
   just one language.

3. The following discussion of importance of languages lose its meaning if all must be used. "the
order of the attributes indicates the order of importance of the various languages in the session or media".
There is no use of knowing how important a language is if they all must be presented. It is more likely that
this relates to a possibility to select and the importance is a grading of preference.

This would mean that we can safely assume that the use of multiple lang attributes in SDP are intended as
a selection and negotiation through offer/answer.

To put this assumption in words, we could either just insert the word "can" in the sentence from RFC 4566,
or make a more elaborated rewording, e.g. into:

" Multiple lang attributes can be provided either at session or media level if the session or media has
capability to use multiple languages, in which case the order of the attributes indicates the order of
preference of the various possible languages in the session or media from most preferred to least preferred.
Events during the session may influence which language(s) are used, and for real-time sessions, the
participants are not strictly bound to only use the declared languages."

( the last sentence was inspired from a similar specification, I do not remember from where. It may have been from CLUE or XCON )

Which wording do you prefer?

Is it realistic to propose an errata to rfc 4566 for this kind of diffuse interpretation issue, or is it sufficient to declare the interpretation in our draft?

If the reasoning above is accepted in slim, it would require changes in section 6 of the draft and open for some
use of the current lang attributes for simple cases. But since we do not get directionality from the current attributes,
there is still a need to add the humintlang attributes.

/Gunnar

_______________________________________________
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: ---------------
He knows nothing, and he thinks he knows everything. That points
clearly to a political career.
    -- George Bernard Shaw

--------------050008060905030109050502-- From nobody Sun Nov 1 23:57:30 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC77F1B346B for ; Sun, 1 Nov 2015 23:57:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 tiG7GkzPd9BA for ; Sun, 1 Nov 2015 23:57:27 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0682.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::682]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 051E31B3464 for ; Sun, 1 Nov 2015 23:57:26 -0800 (PST) Received: from HE1PR04MB1033.eurprd04.prod.outlook.com (10.162.26.142) by HE1PR04MB1035.eurprd04.prod.outlook.com (10.162.26.144) with Microsoft SMTP Server (TLS) id 15.1.312.18; Mon, 2 Nov 2015 07:57:19 +0000 Received: from HE1PR04MB1033.eurprd04.prod.outlook.com ([10.162.26.142]) by HE1PR04MB1033.eurprd04.prod.outlook.com ([10.162.26.142]) with mapi id 15.01.0312.014; Mon, 2 Nov 2015 07:57:19 +0000 From: Natasha Rooney To: "slim@ietf.org" Thread-Topic: Meeting begins in 10 mins: Room 301 Thread-Index: AQHRFUQZwwEdcfBQB0GTE6SjhgDJkA== Date: Mon, 2 Nov 2015 07:57:19 +0000 Message-ID: <121FC619-8505-439B-BA0C-7CEA51311BC5@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.2098) authentication-results: spf=none (sender IP is ) smtp.mailfrom=nrooney@gsma.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [133.93.38.240] x-microsoft-exchange-diagnostics: 1; HE1PR04MB1035; 5:6O33C20KfOU6YX819jeH9xtA27F0IDQasRoik9KdM9LXXT8DSLCetcLqcshhIFQJT+qal22eDpd1mvXf8kbK49B8R2qyk6x5fxtB/BNFBDLyEZwYk7uuX0/GScQA0YGJeMSFH1jMwCHeCFk8Hbu1VQ==; 24:r/Z7V96k2tbX8OZqqKbMVbabKChz2gMm9GSsr3iPtZHSAFuQVg9Q8qXspgOn46iSS84H+CNPjPnCQVULobel6cxl/7wDHT1f6zZL95UeWqM=; 20:PLF/1U0IgsUfDXGStmbKTG311a3FROUmLYWzts24S6JMT/15NfphHNJQmKoeZqbFHr4zjVah/tcokXFJeHiBMw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR04MB1035; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(260367931017790)(161861816099999); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(10201501046)(3002001); SRVR:HE1PR04MB1035; BCL:0; PCL:0; RULEID:; SRVR:HE1PR04MB1035; x-forefront-prvs: 0748FF9A04 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(189002)(199003)(33656002)(50226001)(5004730100002)(77096005)(5007970100001)(5002640100001)(106356001)(106116001)(36756003)(105586002)(82746002)(83716003)(189998001)(16236675004)(2900100001)(19580405001)(50986999)(57306001)(5001960100002)(19580395003)(40100003)(110136002)(102836002)(107886002)(5890100001)(92566002)(87936001)(229853001)(86362001)(450100001)(66066001)(2501003)(10400500002)(5008740100001)(101416001)(81156007)(97736004)(11100500001)(2351001)(122556002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR04MB1035; H:HE1PR04MB1033.eurprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: gsma.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_121FC6198505439BBA0C7CEA51311BC5gsmacom_" MIME-Version: 1.0 X-OriginatorOrg: gsma.com X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Nov 2015 07:57:19.4507 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72a4ff82-fec3-469d-aafb-ac8276216699 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR04MB1035 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: HE1PR04MB1033.eurprd04.prod.outlook.com X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-originalclientipaddress: 133.93.38.240 X-MS-Exchange-CrossPremises-avstamp-service: 1.0 X-MS-Exchange-CrossPremises-disclaimer-hash: 78ca8040c6722e32c2f5b0a45bf37e74b9409d645a53be96aa19958e0cee0f00 X-MS-Exchange-CrossPremises-antispam-scancontext: DIR:Originating; SFV:NSPM; SKIP:0; X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-OrganizationHeadersPreserved: HE1PR04MB1035.eurprd04.prod.outlook.com Archived-At: Subject: [Slim] Meeting begins in 10 mins: Room 301 X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 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, 02 Nov 2015 07:57:29 -0000 --_000_121FC6198505439BBA0C7CEA51311BC5gsmacom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Natasha Natasha Rooney | Technologist, Web and Internet, W3C & IETF | GSMA | nroone= y@gsma.com | +44 (0) 7730 219 765 | @thisNatasha |= Skype: nrooney@gsm.org Tokyo, Japan 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_121FC6198505439BBA0C7CEA51311BC5gsmacom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable

Natasha


Natasha Rooney | Technologist, Web and Internet, W3C & IETF | GSMA= | nrooney@gsma.com | +44 (0) 7730 219 765 | @thisNatasha | Skype= : nrooney@gsm.org&nb= sp;
Tokyo, Japan


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_121FC6198505439BBA0C7CEA51311BC5gsmacom_-- From nobody Mon Nov 2 00:10:33 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CEAA1A1B29 for ; Mon, 2 Nov 2015 00:10:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 KOh8BbJh6_TE for ; Mon, 2 Nov 2015 00:10:27 -0800 (PST) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0640.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::640]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 391571A1A91 for ; Mon, 2 Nov 2015 00:10:27 -0800 (PST) Received: from HE1PR04MB1033.eurprd04.prod.outlook.com (10.162.26.142) by HE1PR04MB1036.eurprd04.prod.outlook.com (10.162.26.145) with Microsoft SMTP Server (TLS) id 15.1.312.18; Mon, 2 Nov 2015 08:10:06 +0000 Received: from HE1PR04MB1033.eurprd04.prod.outlook.com ([10.162.26.142]) by HE1PR04MB1033.eurprd04.prod.outlook.com ([10.162.26.142]) with mapi id 15.01.0312.014; Mon, 2 Nov 2015 08:10:06 +0000 From: Natasha Rooney To: "slim@ietf.org" Thread-Topic: [Slim] Meeting begins in 10 mins: Room 301 Thread-Index: AQHRFUQahOlAmjvS1kKmzvSRXDcHy56IYTqA Date: Mon, 2 Nov 2015 08:10:06 +0000 Message-ID: <9D846096-BEA8-4676-AF20-17FEE94DE1B3@gsma.com> References: <121FC619-8505-439B-BA0C-7CEA51311BC5@gsma.com> In-Reply-To: <121FC619-8505-439B-BA0C-7CEA51311BC5@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.2098) authentication-results: spf=none (sender IP is ) smtp.mailfrom=nrooney@gsma.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2001:c40:0:3032:68a5:adeb:a948:ab28] x-microsoft-exchange-diagnostics: 1; HE1PR04MB1036; 5:IhORlgql+D9fzaxJbhX0c/3NXUwl65gx+CJVmWeANi/XUp+LQIIBz3zxVbimSDUbIj5xbbDzYdYGOzzACh9gKUda9UNJdsoJmQZvQs6p7XIJZpgKlnnwcv5lXP1Kfrttk9tNA24dVq4hdRyga+4GRQ==; 24:16B1mqfVQXA9lvxT0NCQSVo21bJ6s2sh862Oyur+Q0fiRABIHJjRzmtwD5ZpGQpqZbhTRiO6PxL+YzrQYnDFbzp6C0MBOjtUPU/Veo0FJs8=; 20:X0zy6a5E5bUpPXPmTrRV5yiyab0rzOFjhzpDJfoSwChgGdnZ9RbNqPDQvx1IJDMQ5ymeBs+ZATwJWEodDsVm6A== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR04MB1036; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(260367931017790)(161861816099999); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(10201501046)(3002001); SRVR:HE1PR04MB1036; BCL:0; PCL:0; RULEID:; SRVR:HE1PR04MB1036; x-forefront-prvs: 0748FF9A04 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(189002)(199003)(377454003)(24454002)(2351001)(105586002)(106116001)(107886002)(189998001)(15975445007)(110136002)(106356001)(50226001)(2950100001)(5002640100001)(10400500002)(86362001)(2900100001)(81156007)(87936001)(83716003)(5008740100001)(102836002)(2501003)(92566002)(5001960100002)(5890100001)(36756003)(77096005)(82746002)(5007970100001)(40100003)(450100001)(11100500001)(122556002)(57306001)(97736004)(5004730100002)(16236675004)(101416001)(19580405001)(19580395003)(33656002)(76176999)(50986999)(3826002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR04MB1036; H:HE1PR04MB1033.eurprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: gsma.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_9D846096BEA84676AF2017FEE94DE1B3gsmacom_" MIME-Version: 1.0 X-OriginatorOrg: gsma.com X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Nov 2015 08:10:06.0444 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72a4ff82-fec3-469d-aafb-ac8276216699 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR04MB1036 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: HE1PR04MB1033.eurprd04.prod.outlook.com X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-originalclientipaddress: 2001:c40:0:3032:68a5:adeb:a948:ab28 X-MS-Exchange-CrossPremises-avstamp-service: 1.0 X-MS-Exchange-CrossPremises-disclaimer-hash: 78ca8040c6722e32c2f5b0a45bf37e74b9409d645a53be96aa19958e0cee0f00 X-MS-Exchange-CrossPremises-antispam-scancontext: DIR:Originating; SFV:NSPM; SKIP:0; X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-OrganizationHeadersPreserved: HE1PR04MB1036.eurprd04.prod.outlook.com Archived-At: Subject: Re: [Slim] Meeting begins in 10 mins: Room 301 X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 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, 02 Nov 2015 08:10:32 -0000 --_000_9D846096BEA84676AF2017FEE94DE1B3gsmacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SWYgeW914oCZcmUgcmVtb3RlIGFuZCB5b3UgaGF2ZSBzb21lIHByb2JsZW1zIGRpYWxpbmcgaW4g cGxlYXNlIGVtYWlsIG1lIGFuZCBtdGRAaWV0Zi5vcmc8bWFpbHRvOm10ZEBpZXRmLm9yZz4uDQoN Cg0KTmF0YXNoYQ0KDQoNCk5hdGFzaGEgUm9vbmV5IHwgVGVjaG5vbG9naXN0LCBXZWIgYW5kIElu dGVybmV0LCBXM0MgJiBJRVRGIHwgR1NNQSB8IG5yb29uZXlAZ3NtYS5jb208bWFpbHRvOm5yb29u ZXlAZ3NtYS5jb20+IHwgKzQ0ICgwKSA3NzMwIDIxOSA3NjUgfCBAdGhpc05hdGFzaGEgfCBTa3lw ZTogbnJvb25leUBnc20ub3JnPG1haWx0bzpucm9vbmV5QGdzbS5vcmc+DQpUb2t5bywgSmFwYW4N Cg0KDQpPbiBOb3YgMiwgMjAxNSwgYXQgNDo1NyBQTSwgTmF0YXNoYSBSb29uZXkgPG5yb29uZXlA Z3NtYS5jb208bWFpbHRvOm5yb29uZXlAZ3NtYS5jb20+PiB3cm90ZToNCg0KDQoNCk5hdGFzaGEN Cg0KDQpOYXRhc2hhIFJvb25leSB8IFRlY2hub2xvZ2lzdCwgV2ViIGFuZCBJbnRlcm5ldCwgVzND ICYgSUVURiB8IEdTTUEgfCBucm9vbmV5QGdzbWEuY29tPG1haWx0bzpucm9vbmV5QGdzbWEuY29t PiB8ICs0NCAoMCkgNzczMCAyMTkgNzY1IHwgQHRoaXNOYXRhc2hhIHwgU2t5cGU6IG5yb29uZXlA Z3NtLm9yZzxtYWlsdG86bnJvb25leUBnc20ub3JnPg0KVG9reW8sIEphcGFuDQoNCg0KDQpUaGlz IGVtYWlsIGFuZCBpdHMgYXR0YWNobWVudHMgYXJlIGludGVuZGVkIGZvciB0aGUgYWJvdmUgbmFt ZWQgb25seSBhbmQgbWF5IGJlIGNvbmZpZGVudGlhbC4gSWYgdGhleSBoYXZlIGNvbWUgdG8geW91 IGluIGVycm9yIHlvdSBtdXN0IHRha2Ugbm8gYWN0aW9uIGJhc2VkIG9uIHRoZW0sIG5vciBtdXN0 IHlvdSBjb3B5IG9yIHNob3cgdGhlbSB0byBhbnlvbmU7IHBsZWFzZSByZXBseSB0byB0aGlzIGVt YWlsIG9yIGNhbGwgKzQ0IDIwNyAzNTYgMDYwMCBhbmQgaGlnaGxpZ2h0IHRoZSBlcnJvci4NCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClNMSU0gbWFp bGluZyBsaXN0DQpTTElNQGlldGYub3JnPG1haWx0bzpTTElNQGlldGYub3JnPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zbGltDQoNCg0KVGhpcyBlbWFpbCBhbmQgaXRz IGF0dGFjaG1lbnRzIGFyZSBpbnRlbmRlZCBmb3IgdGhlIGFib3ZlIG5hbWVkIG9ubHkgYW5kIG1h eSBiZSBjb25maWRlbnRpYWwuIElmIHRoZXkgaGF2ZSBjb21lIHRvIHlvdSBpbiBlcnJvciB5b3Ug bXVzdCB0YWtlIG5vIGFjdGlvbiBiYXNlZCBvbiB0aGVtLCBub3IgbXVzdCB5b3UgY29weSBvciBz aG93IHRoZW0gdG8gYW55b25lOyBwbGVhc2UgcmVwbHkgdG8gdGhpcyBlbWFpbCBvciBjYWxsICs0 NCAyMDcgMzU2IDA2MDAgYW5kIGhpZ2hsaWdodCB0aGUgZXJyb3IuDQo= --_000_9D846096BEA84676AF2017FEE94DE1B3gsmacom_ Content-Type: text/html; charset="utf-8" Content-ID: <518338B1AAC5924C9E7793CD76C4F4DE@eurprd04.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSWYgeW914oCZcmUgcmVtb3RlIGFu ZCB5b3UgaGF2ZSBzb21lIHByb2JsZW1zIGRpYWxpbmcgaW4gcGxlYXNlIGVtYWlsIG1lIGFuZCZu YnNwOzxhIGhyZWY9Im1haWx0bzptdGRAaWV0Zi5vcmciIGNsYXNzPSIiPm10ZEBpZXRmLm9yZzwv YT4uPGJyIGNsYXNzPSIiPg0KPGRpdiBhcHBsZS1jb250ZW50LWVkaXRlZD0idHJ1ZSIgY2xhc3M9 IiI+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBsZXR0ZXItc3BhY2luZzogbm9y bWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsg dGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsg d29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgd29yZC13 cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1i cmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBj bGFzcz0iIj4NCk5hdGFzaGE8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9 IiI+DQpOYXRhc2hhIFJvb25leSB8IFRlY2hub2xvZ2lzdCwgV2ViIGFuZCBJbnRlcm5ldCwgVzND ICZhbXA7IElFVEYgfCZuYnNwO0dTTUEgfCA8YSBocmVmPSJtYWlsdG86bnJvb25leUBnc21hLmNv bSIgY2xhc3M9IiI+DQpucm9vbmV5QGdzbWEuY29tPC9hPiB8ICYjNDM7NDQgKDApJm5ic3A7Nzcz MCAyMTkgNzY1IHwgQHRoaXNOYXRhc2hhIHwgU2t5cGU6Jm5ic3A7PGEgaHJlZj0ibWFpbHRvOm5y b29uZXlAZ3NtLm9yZyIgY2xhc3M9IiI+bnJvb25leUBnc20ub3JnPC9hPiZuYnNwOzxiciBjbGFz cz0iIj4NClRva3lvLCBKYXBhbjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0K PC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIE5vdiAyLCAyMDE1LCBhdCA0OjU3IFBN LCBOYXRhc2hhIFJvb25leSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5yb29uZXlAZ3NtYS5jb20iIGNs YXNzPSIiPm5yb29uZXlAZ3NtYS5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0i QXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0i d29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQt bGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4N CjxkaXYgYXBwbGUtY29udGVudC1lZGl0ZWQ9InRydWUiIGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0i bGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7 IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9y bWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tl LXdpZHRoOiAwcHg7IHdvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNw YWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQo8 YnIgY2xhc3M9IiI+DQpOYXRhc2hhPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNs YXNzPSIiPg0KTmF0YXNoYSBSb29uZXkgfCBUZWNobm9sb2dpc3QsIFdlYiBhbmQgSW50ZXJuZXQs IFczQyAmYW1wOyBJRVRGIHwmbmJzcDtHU01BIHwgPGEgaHJlZj0ibWFpbHRvOm5yb29uZXlAZ3Nt YS5jb20iIGNsYXNzPSIiPg0KbnJvb25leUBnc21hLmNvbTwvYT4gfCAmIzQzOzQ0ICgwKSZuYnNw Ozc3MzAgMjE5IDc2NSB8IEB0aGlzTmF0YXNoYSB8IFNreXBlOiZuYnNwOzxhIGhyZWY9Im1haWx0 bzpucm9vbmV5QGdzbS5vcmciIGNsYXNzPSIiPm5yb29uZXlAZ3NtLm9yZzwvYT4mbmJzcDs8YnIg Y2xhc3M9IiI+DQpUb2t5bywgSmFwYW48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8L2Rp dj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPHAgc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCxz YW5zLXNlcmlmO2ZvbnQtc2l6ZToxMXB4O2NvbG9yOiM5OTk5OTk7IiBjbGFzcz0iIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCxzYW5zLXNlcmlmO2NvbG9yOiM5 OTk5OTk7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiBBcmlhbDsgbXNvLWZhcmVhc3QtdGhlbWUt Zm9udDogbWlub3ItbGF0aW47IG1zby1iaWRpLWZvbnQtZmFtaWx5OiAmcXVvdDtBcmlhbCZxdW90 OzsgbXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogRU4tR0I7 IG1zby1iaWRpLWxhbmd1YWdlOiBBUi1TQSIgY2xhc3M9IiI+VGhpcw0KIGVtYWlsIGFuZCBpdHMg YXR0YWNobWVudHMgYXJlIGludGVuZGVkIGZvciB0aGUgYWJvdmUgbmFtZWQgb25seSBhbmQgbWF5 IGJlIGNvbmZpZGVudGlhbC4gSWYgdGhleSBoYXZlIGNvbWUgdG8geW91IGluIGVycm9yIHlvdSBt dXN0IHRha2Ugbm8gYWN0aW9uIGJhc2VkIG9uIHRoZW0sIG5vciBtdXN0IHlvdSBjb3B5IG9yIHNo b3cgdGhlbSB0byBhbnlvbmU7IHBsZWFzZSByZXBseSB0byB0aGlzIGVtYWlsIG9yIGNhbGwgJiM0 Mzs0NCAyMDcgMzU2IDA2MDANCiBhbmQgaGlnaGxpZ2h0IHRoZSBlcnJvci4gPC9zcGFuPjwvcD4N CjwvZGl2Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnIgY2xhc3M9IiI+DQpTTElNIG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Im1h aWx0bzpTTElNQGlldGYub3JnIiBjbGFzcz0iIj5TTElNQGlldGYub3JnPC9hPjxiciBjbGFzcz0i Ij4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2xpbTxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8cCBzdHls ZT0iZm9udC1mYW1pbHk6IEFyaWFsLHNhbnMtc2VyaWY7Zm9udC1zaXplOjExcHg7Y29sb3I6Izk5 OTk5OTsiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLHNhbnMt c2VyaWY7Y29sb3I6Izk5OTk5OTsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IEFyaWFsOyBtc28t ZmFyZWFzdC10aGVtZS1mb250OiBtaW5vci1sYXRpbjsgbXNvLWJpZGktZm9udC1mYW1pbHk6ICZx dW90O0FyaWFsJnF1b3Q7OyBtc28tYW5zaS1sYW5ndWFnZTogRU4tVVM7IG1zby1mYXJlYXN0LWxh bmd1YWdlOiBFTi1HQjsgbXNvLWJpZGktbGFuZ3VhZ2U6IEFSLVNBIj5UaGlzDQogZW1haWwgYW5k IGl0cyBhdHRhY2htZW50cyBhcmUgaW50ZW5kZWQgZm9yIHRoZSBhYm92ZSBuYW1lZCBvbmx5IGFu ZCBtYXkgYmUgY29uZmlkZW50aWFsLiBJZiB0aGV5IGhhdmUgY29tZSB0byB5b3UgaW4gZXJyb3Ig eW91IG11c3QgdGFrZSBubyBhY3Rpb24gYmFzZWQgb24gdGhlbSwgbm9yIG11c3QgeW91IGNvcHkg b3Igc2hvdyB0aGVtIHRvIGFueW9uZTsgcGxlYXNlIHJlcGx5IHRvIHRoaXMgZW1haWwgb3IgY2Fs bCAmIzQzOzQ0IDIwNyAzNTYgMDYwMA0KIGFuZCBoaWdobGlnaHQgdGhlIGVycm9yLiA8L3NwYW4+ PC9wPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_9D846096BEA84676AF2017FEE94DE1B3gsmacom_-- From nobody Mon Nov 2 02:19:03 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 881791A1ADD for ; Mon, 2 Nov 2015 02:19:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 2FgdObubcZF5 for ; Mon, 2 Nov 2015 02:18:58 -0800 (PST) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0644.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::644]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A9311A1AAE for ; Mon, 2 Nov 2015 02:18:57 -0800 (PST) Received: from HE1PR04MB1033.eurprd04.prod.outlook.com (10.162.26.142) by HE1PR04MB1036.eurprd04.prod.outlook.com (10.162.26.145) with Microsoft SMTP Server (TLS) id 15.1.312.18; Mon, 2 Nov 2015 10:18:51 +0000 Received: from HE1PR04MB1033.eurprd04.prod.outlook.com ([10.162.26.142]) by HE1PR04MB1033.eurprd04.prod.outlook.com ([10.162.26.142]) with mapi id 15.01.0312.014; Mon, 2 Nov 2015 10:18:51 +0000 From: Natasha Rooney To: Nik Tomkinson , Nathaniel Borenstein , "randy@qti.qualcomm.com" Thread-Topic: Drafts to accepted WG Documents Thread-Index: AQHRFVfepUS2YTh7F0+TMVuMDVIFTw== Date: Mon, 2 Nov 2015 10:18:51 +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.2098) authentication-results: spf=none (sender IP is ) smtp.mailfrom=nrooney@gsma.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [133.93.81.224] x-microsoft-exchange-diagnostics: 1; HE1PR04MB1036; 5:IO/lFvuMqwyctaFy3qFoO7XBq1QJsn3qXh5p8uYQLW6LSbnNvrbHmWRYo2d1UVdaPbFtFRZdC/qQRwqX/Hm7PTm2Fc9sxSDCCwkLZMkWHqr4yexNJSoWv45vjEtnrwCvL4AAr6iMunfwd22acoZM/Q==; 24:J6zh0gskMxIxpV9CjPmhOsdQfZ24E8YrOoTEURptqdCN1JsH450if27gpwnccYFhJ8ev7kbSHZobULegvnRNbCFahC8YQNSNoz0KsawYG5w=; 20:tVH8FZ6COmKjzrXPje4w6PE0jZOMHmHr4kBMD2hvC78k8aeTsHBaPld0rT5/DbNXZ4JSakzdMV8HI5KOeBTwfw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR04MB1036; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(260367931017790)(161861816099999); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(10201501046)(3002001); SRVR:HE1PR04MB1036; BCL:0; PCL:0; RULEID:; SRVR:HE1PR04MB1036; x-forefront-prvs: 0748FF9A04 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(199003)(189002)(122556002)(11100500001)(97736004)(57306001)(5004730100002)(5007970100001)(40100003)(33656002)(66066001)(50986999)(101416001)(16236675004)(19580395003)(19580405001)(50226001)(229853001)(106356001)(106116001)(10400500002)(5002640100001)(105586002)(189998001)(5890100001)(36756003)(77096005)(5001960100002)(92566002)(83716003)(82746002)(87936001)(2900100001)(5001770100001)(86362001)(81156007)(2501003)(5008740100001)(102836002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR04MB1036; H:HE1PR04MB1033.eurprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: gsma.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_E97D2299E03E4312A16275F70BFD97D5gsmacom_" MIME-Version: 1.0 X-OriginatorOrg: gsma.com X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Nov 2015 10:18:51.6227 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72a4ff82-fec3-469d-aafb-ac8276216699 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR04MB1036 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: HE1PR04MB1033.eurprd04.prod.outlook.com X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-originalclientipaddress: 133.93.81.224 X-MS-Exchange-CrossPremises-avstamp-service: 1.0 X-MS-Exchange-CrossPremises-disclaimer-hash: 78ca8040c6722e32c2f5b0a45bf37e74b9409d645a53be96aa19958e0cee0f00 X-MS-Exchange-CrossPremises-antispam-scancontext: DIR:Originating; SFV:NSPM; SKIP:0; X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-OrganizationHeadersPreserved: HE1PR04MB1036.eurprd04.prod.outlook.com Archived-At: Cc: "slim@ietf.org" Subject: [Slim] Drafts to accepted WG Documents X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 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, 02 Nov 2015 10:19:02 -0000 --_000_E97D2299E03E4312A16275F70BFD97D5gsmacom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Nik & Nathaniel, Randall, Your drafts have been accepted as work items for the group, please submit t= hese as WG Documents, Bernard and I will approve. We will take the use cases discussion to the list after I release the minut= es tomorrow. Thanks all! Natasha Natasha Rooney | Technologist, Web and Internet, W3C & IETF | GSMA | nroone= y@gsma.com | +44 (0) 7730 219 765 | @thisNatasha |= Skype: nrooney@gsm.org Tokyo, Japan 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_E97D2299E03E4312A16275F70BFD97D5gsmacom_ Content-Type: text/html; charset="us-ascii" Content-ID: <065E0D7F6EED7F4C8913870FCB1763F1@eurprd04.prod.outlook.com> Content-Transfer-Encoding: quoted-printable Nik & Nathaniel, Randall,

Your drafts have been accepted as work items for the group, please submit t= hese as WG Documents, Bernard and I will approve.

We will take the use cases discussion to the list after I release the minut= es tomorrow.

Thanks all!

Natasha


Natasha Rooney | Technologist, Web and Internet, W3C & IETF | GSMA= | nrooney@gsma.com | +44 (0) 7730 219 765 | @thisNatasha | Skype= : nrooney@gsm.org&nb= sp;
Tokyo, Japan


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_E97D2299E03E4312A16275F70BFD97D5gsmacom_-- From nobody Mon Nov 2 03:47:49 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B435E1B3308 for ; Mon, 2 Nov 2015 03:47:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.711 X-Spam-Level: X-Spam-Status: No, score=-6.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 B_6cST0PSs2Y for ; Mon, 2 Nov 2015 03:47:47 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 093161B32E8 for ; Mon, 2 Nov 2015 03:47:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1446464867; x=1478000867; h=message-id:in-reply-to:references:date:to:from:subject: mime-version:content-transfer-encoding; bh=xMSyLXS8IhWSJ7Ll3urHWZJ7Oj9tIGgOFeVDMTf+CWA=; b=GRjg3nTD7krJmvaLgD4MKALUFXlxYwCAYWyQpZ9bIZVdyvt6uJAeh2XC UCxHpeSNL5rWEvfSUGyjeQ5tk18PQnDA/E1EX6SMZP4QE20VgW//5hUhY HRHi0rc5/3SAZK8vTYpXAhItzC3T2cWsjjnCrglVI/vtPonxGgE2M0e2E k=; X-IronPort-AV: E=McAfee;i="5700,7163,7972"; a="147316729" Received: from ironmsg02-r-new.qualcomm.com (HELO ironmsg02-R.qualcomm.com) ([10.53.140.106]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Nov 2015 03:47:46 -0800 X-IronPort-AV: E=Sophos;i="5.20,234,1444719600"; d="scan'208";a="609440374" Received: from nasanexm02f.na.qualcomm.com ([10.85.0.87]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 02 Nov 2015 03:47:46 -0800 Received: from dhcp-96-48.meeting.ietf94.jp (10.80.80.8) by nasanexm02f.na.qualcomm.com (10.85.0.87) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Mon, 2 Nov 2015 03:47:30 -0800 Message-ID: In-Reply-To: <56370CE6.1000307@omnitor.se> References: <9d9f51af87d94c8caf26b1f3801c69d4@EX13D08UWC002.ant.amazon.com> <56370CE6.1000307@omnitor.se> X-Mailer: Eudora for Mac OS X Date: Mon, 2 Nov 2015 03:44:50 -0800 To: Gunnar =?iso-8859-1?Q?Hellstr=F6m?= , From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01C.na.qualcomm.com (10.85.0.83) To nasanexm02f.na.qualcomm.com (10.85.0.87) Archived-At: Subject: Re: [Slim] Primary language tags (was "Re: draft-tomkinson comments") X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 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, 02 Nov 2015 11:47:48 -0000 At 8:12 AM +0100 11/2/15, Gunnar Hellstr=F6m wrote: > Good reasoning, I agree with Randall that=20 > subtags should be included to the extent that=20 > it is important for distinguishing that the=20 > contents is suitable and understandable. > > The same reasoning enable us to distinguish=20 > written from spoken language by using the=20 > Script subtag to indicate written, even if=20 > Suppress-Script is registered for the language=20 > tag. > > RFC 5646 says about Script and Suppress-Script > "the script subtag SHOULD be omitted when it=20 > adds no distinguishing value to the tag or when=20 > the primary or extended language subtag's=20 > record in the subtag registry includes a=20 > 'Suppress-Script' field listing the applicable=20 > script subtag." I am concerned that overloading the use of=20 'script' in this way is dangerous, and further, I=20 am not convinced that we need to differentiate=20 written from spoken language. If it turns out=20 that we do, we should choose a different=20 mechanism where that is the only meaning. > > So, when it is clear from the context if the=20 > language tag represents written vs spoken=20 > language, then no Script subtag is needed, but=20 > if the tag is used in a place where it can be=20 > ambigous, then a tag without Script means=20 > spoken and a tag with Script means written. > > Also where written is used in an unusual=20 > context, the Script subtag would be used to=20 > indicate that it is written. E.g. If captions=20 > are overlaid in video, a language tag for the=20 > video stream including the Script subtag would=20 > make the fact clear that that language is there=20 > in text form. ( as distinguished from seeing a=20 > person talking that language. ) > > /Gunnar > > > Den 2015-11-02 kl. 07:16, skrev Randall Gellens: >> Extracting this one comment: >> >> At 2:10 AM +0000 10/21/15, Addison Phillips wrote: >> >>> 5. There is this recommendation: >>> >>> -- >>> While RFC 5646 provides a mechanism accommodating >>> increasingly fine-grained distinctions, in the interest of maximum >>> interoperability, each Content-Language value SHOULD be restricted = to >>> the largest granularity of language tags; in other words, it is >>> RECOMMENDED to specify only a Primary-subtag and NOT to include >>> subtags (e.g., for region or dialect) unless the languages might be >>> mutually incomprehensible without them. >>> -- >>> >>> I think this text is potentially harmful, as=20 >>> it might interfere with the needs of senders=20 >>> and clients to distinguish text based on a=20 >>> variety of factors and ignores the fact that=20 >>> some language variation is not mutually=20 >>> comprehensible at the primary language level. >> >> I am very confused. The text explicitly says=20 >> "unless the languages might be mutually=20 >> incomprehensible without them" so how can you=20 >> say that the text ignores cases where subtags=20 >> are needed for mutual comprehensibility? >> >>> >>> An implementation restriction to the primary=20 >>> language subtag would be a disadvantage to=20 >>> languages that have important script, region,=20 >>> or other variations such as extlang or=20 >>> variant. BCP 47 has a whole section=20 >>> (http://tools.ietf.org/html/bcp47#section-4.1)=20 >>> about the choice of language tag that=20 >>> basically recommends similar things and I=20 >>> understand why it's important for senders not=20 >>> to add unnecessary subtags. But I think you'd=20 >>> be better off not having quite so much=20 >>> normative language in this specification and=20 >>> a more focused recommendation that does not=20 >>> impinge on the needs of senders and clients=20 >>> to provide adequate language information. >> >> Please keep in mind that the text in question=20 >> uses SHOULD and RECOMMENDED, not MUST. That=20 >> means that when there is a good reason to=20 >> deviate, and the implications of deviating are=20 >> well understood, it is acceptable and does not=20 >> violate conformance. >> >> I believe that the text in question does a=20 >> good job of guiding implementations to=20 >> maximally-interoperable behavior without=20 >> forcing problematic behavior in those cases=20 >> where subtags are needed. >> > > _______________________________________________ > 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: --------------- Cabbage: A familiar kitchen-garden vegetable about as large and wise as a man's head. From nobody Mon Nov 2 03:50:30 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 020951B2D2C for ; Mon, 2 Nov 2015 03:41:33 -0800 (PST) X-Quarantine-ID: <4N1ZkV6VqUIY> 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.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 4N1ZkV6VqUIY for ; Mon, 2 Nov 2015 03:41:31 -0800 (PST) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id D7A3C1B2D2A for ; Mon, 2 Nov 2015 03:41:31 -0800 (PST) Received: from dhcp-96-48.meeting.ietf94.jp (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Mon, 2 Nov 2015 03:41:31 -0800 Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Mailer: Eudora for Mac OS X Date: Mon, 2 Nov 2015 03:41:24 -0800 To: Natasha Rooney , Nik Tomkinson , Nathaniel Borenstein , "randy@qti.qualcomm.com" From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 Archived-At: X-Mailman-Approved-At: Mon, 02 Nov 2015 03:50:27 -0800 Cc: "slim@ietf.org" Subject: Re: [Slim] Drafts to accepted WG Documents X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 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, 02 Nov 2015 11:41:33 -0000 Done, thank you. At 10:18 AM +0000 11/2/15, Natasha Rooney wrote: > Nik & Nathaniel, Randall, > > Your drafts have been accepted as work items for the group, please > submit these as WG Documents, Bernard and I will approve. > > We will take the use cases discussion to the list after I release > the minutes tomorrow. > > Thanks all! > > Natasha > > > Natasha Rooney | Technologist, Web and Internet, W3C & IETF | GSMA > | nrooney@gsma.com | +44 (0) 7730 219 765 > | @thisNatasha | Skype: nrooney@gsm.org > Tokyo, Japan > > > 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. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Police Begin Campaign to Run Down Jaywalkers --Newspaper headline From nobody Mon Nov 2 06:52:09 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 508801B379B for ; Mon, 2 Nov 2015 06:52:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 rw5pS4JaKAVR for ; Mon, 2 Nov 2015 06:52:04 -0800 (PST) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::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 3A74C1B3799 for ; Mon, 2 Nov 2015 06:52:04 -0800 (PST) Received: by qgem9 with SMTP id m9so117448952qge.1 for ; Mon, 02 Nov 2015 06:52:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yKqQfcgU5QRgRrgPR8DzoSfClYzVy88n/JmSbOqEhzY=; b=UPz078WYiJd8j2Kyx1owP6B9E7RVuY3A11fvD65G9jBf2MZSsl1AkSkGBkbQBfaNMM rJbqeJMbIaFqq+A2DaytxF8NJy7SijfKB+m3bXfc5l1qS9yoAuZdHdGck9CUxcC62Ag7 CG85x3Tm363x3fUWB0raLcqEriHuiIiedKO+vF4aqXbJQDfE5iGxGSVvxc5Yc7MlhMOR RtgoF4Y7hsI3nbzwaf9iu1mJpIbsI4TBmAqzpDNyPirc9IJFjvHBTvRAPB3jEEAZAnUI y6JFSsblQeaXc7oX2oljhJXR0IF3yvOPN/qIL2YhnkF/6PmPeweydN0BN9U2/3RMD/IL Zr5Q== MIME-Version: 1.0 X-Received: by 10.140.96.53 with SMTP id j50mr29370584qge.100.1446475923434; Mon, 02 Nov 2015 06:52:03 -0800 (PST) Received: by 10.55.76.78 with HTTP; Mon, 2 Nov 2015 06:52:03 -0800 (PST) In-Reply-To: References: Date: Mon, 2 Nov 2015 14:52:03 +0000 Message-ID: From: Nik Tomkinson To: Randall Gellens Content-Type: multipart/alternative; boundary=001a113b30d697b40e05238feb64 Archived-At: Cc: "slim@ietf.org" , Nathaniel Borenstein , "randy@qti.qualcomm.com" , Natasha Rooney Subject: Re: [Slim] Drafts to accepted WG Documents X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 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, 02 Nov 2015 14:52:06 -0000 --001a113b30d697b40e05238feb64 Content-Type: text/plain; charset=UTF-8 I have just submitted draft-ietf-slim-multilangcontent-00 (and I think the rename makes it a working group document). It is pending approval. This version takes into account all the agreed comments from Addison but nothing that is still under discussion or anything from today's (Monday's) session questions as some of this needs some thought and/or testing. Nik. On 2 November 2015 at 11:41, Randall Gellens wrote: > Done, thank you. > > At 10:18 AM +0000 11/2/15, Natasha Rooney wrote: > > Nik & Nathaniel, Randall, >> >> Your drafts have been accepted as work items for the group, please >> submit these as WG Documents, Bernard and I will approve. >> >> We will take the use cases discussion to the list after I release the >> minutes tomorrow. >> >> Thanks all! >> >> Natasha >> >> >> Natasha Rooney | Technologist, Web and Internet, W3C & IETF | GSMA | >> nrooney@gsma.com | +44 (0) 7730 219 765 | >> @thisNatasha | Skype: nrooney@gsm.org Tokyo, >> Japan >> >> >> 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. >> > > > > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- > Police Begin Campaign to Run Down Jaywalkers > --Newspaper headline > -- ----------------------------------------------------------------- Multiple Language Content Type Internet Draft: http://datatracker.ietf.org/doc/draft-tomkinson-slim-multilangcontent/ ----------------------------------------------------------------- --001a113b30d697b40e05238feb64 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have just submitted=C2=A0draft-ietf-slim-multilangconten= t-00 (and I think the rename makes it a working group document).

It is pending approval.

This version take= s into account all the agreed comments from Addison but nothing that is sti= ll under discussion or anything from today's (Monday's) session que= stions as some of this needs some thought and/or testing.

Nik.

On 2 November 2015 at 11:41, Randall Gellens <<= a href=3D"mailto:rg+ietf@randy.pensive.org" target=3D"_blank">rg+ietf@randy= .pensive.org> wrote:
Done, = thank you.

At 10:18 AM +0000 11/2/15, Natasha Rooney wrote:

=C2=A0Nik & Nathaniel, Randall,

=C2=A0Your drafts have been accepted as work items for the group, please su= bmit these as WG Documents, Bernard and I will approve.

=C2=A0We will take the use cases discussion to the list after I release the= minutes tomorrow.

=C2=A0Thanks all!

=C2=A0Natasha


 =C2=A0Natasha Rooney | Technologist, Web and Internet, W3C & IETF | GSM= A | <mailto:nroone= y@gsma.com> nr= ooney@gsma.com | +44 (0) 7730 219 765 | @thisNata= sha | Skype: <mailto:nrooney@gsm.org>nrooney@gsm.org=C2=A0 Tokyo, Japan


=C2=A0This 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 rep= ly to this email or call +44 207 356 0600 and highlight the err= or.



--
Randall Gellens
Opinions are personal;=C2=A0 =C2=A0 facts are suspect;=C2=A0 =C2=A0 I speak= for myself only
-------------- Randomly selected tag: ---------------
Police Begin Campaign to Run Down Jaywalkers
--Newspaper headline



-- 
-=
----------------------------------------------------------------
Multipl=
e Language Content Type Internet Draft:
http://datatracker.ietf.org/doc/draft-tomkinson-slim-multilangc= ontent/
-----=
------------------------------------------------------------
--001a113b30d697b40e05238feb64-- From nobody Mon Nov 2 09:26:50 2015 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 6BAD01B4930; Mon, 2 Nov 2015 08:09:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.7.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151102160934.3160.2433.idtracker@ietfa.amsl.com> Date: Mon, 02 Nov 2015 08:09:34 -0800 Archived-At: X-Mailman-Approved-At: Mon, 02 Nov 2015 09:26:49 -0800 Cc: slim@ietf.org Subject: [Slim] I-D Action: draft-ietf-slim-negotiating-human-language-00.txt X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 16:09:34 -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 Working Group of the IETF. Title : Negotiating Human Language in Real-Time Communications Author : Randall Gellens Filename : draft-ietf-slim-negotiating-human-language-00.txt Pages : 18 Date : 2015-11-02 Abstract: Users have various human (natural) language needs, abilities, and preferences regarding spoken, written, and signed languages. When establishing interactive communication ("calls") there needs to be a way 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 stream attributes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-slim-negotiating-human-language/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-slim-negotiating-human-language-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/ From nobody Mon Nov 2 15:12:21 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 852951A9026 for ; Mon, 2 Nov 2015 15:12:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.9 X-Spam-Level: X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_I_LETTER=-2, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham 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 WHDSkSdLV9Xh for ; Mon, 2 Nov 2015 15:12:19 -0800 (PST) Received: from p3plwbeout03-05.prod.phx3.secureserver.net (p3plsmtp03-05-2.prod.phx3.secureserver.net [72.167.218.217]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14AFF1A9027 for ; Mon, 2 Nov 2015 15:12:18 -0800 (PST) Received: from localhost ([72.167.218.245]) by p3plwbeout03-05.prod.phx3.secureserver.net with bizsmtp id cnCJ1r0015JG3DC01nCJ5w; Mon, 02 Nov 2015 16:12:18 -0700 X-SID: cnCJ1r0015JG3DC01 Received: (qmail 32561 invoked by uid 99); 2 Nov 2015 23:12:18 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 208.51.143.189 User-Agent: Workspace Webmail 5.15.9 Message-Id: <20151102161215.665a7a7059d7ee80bb4d670165c8327d.643b000064.wbe@email03.secureserver.net> From: "Doug Ewell" To: "Randall Gellens" , "Gunnar =?UTF-8?Q?Hellstr=C3=B6m?=" , slim@ietf.org Date: Mon, 02 Nov 2015 16:12:15 -0700 Mime-Version: 1.0 Archived-At: Subject: Re: [Slim] Primary language tags (was "Re: draft-tomkinson comments") X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 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, 02 Nov 2015 23:12:20 -0000 Randall Gellens wrote:=0A=0A>> The same reasoning enable us to distinguish= =0A>> written from spoken language by using the=0A>> Script subtag to indic= ate written, even if=0A>> Suppress-Script is registered for the language=0A= >> tag.=0A>=0A> [...]=0A>=0A> I am concerned that overloading the use of=0A= > 'script' in this way is dangerous, and further, I=0A> am not convinced th= at we need to differentiate=0A> written from spoken language. If it turns o= ut=0A> that we do, we should choose a different=0A> mechanism where that is= the only meaning.=0A=0AI agree. Although a script subtag does identify the= script in which the=0Atagged content is written -- implying that the conte= nt is indeed written=0A-- BCP 47 does not state anywhere that a script subt= ag should be used to=0Adistinguish written content from content in other mo= dalities, and for=0Agood reason. Identification of modality, like many othe= r attributes of=0Alinguistic content, is out of scope for BCP 47. The draft= should define=0Aa protocol that uses BCP 47, not seek to extend it.=0A=0AF= urthermore, encouraging the use of script subtags even in the presence=0Aof= Suppress-Script, without good reason to override (such as when=0Aidentifyi= ng French written in Cyrillic letters), runs counter to the=0Ageneral princ= iple of avoiding unnecessary subtags -- although I agree=0Awith Addison tha= t the draft may go too far beyond BCP 47 in discouraging=0Apotentially nece= ssary subtags.=0A=0A--=0ADoug Ewell | http://ewellic.org | Thornton, CO =F0= =9F=87=BA=F0=9F=87=B8=0A From nobody Mon Nov 2 18:02:02 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB4671A1A73 for ; Mon, 2 Nov 2015 18:02:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 5zcqBUIVFLpg for ; Mon, 2 Nov 2015 18:02:00 -0800 (PST) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::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 4F0B31A1A58 for ; Mon, 2 Nov 2015 18:02:00 -0800 (PST) Received: by lfgh9 with SMTP id h9so2378588lfg.1 for ; Mon, 02 Nov 2015 18:01:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen_net.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to:content-type; bh=WwIgLX9gzuZCUnda4LONPeydgYdfz4RgihbbCfvCjQg=; b=KRuqoLTglTPPWP4qbPok2de45C8TNuTdJl3V1/IIRudfhsWePvAAp2yYKAAYIve7zd yK7F7W24R+AgNUrpLFSeJcWKj+nOHxuQHAhrERoIYv8juO4/hIwVPpd01uDEmQV2KZ2f 04AwrjJ7nd1kyytlfkR2eEdr+IKpVXh2yBXvxoJT2sOA3qLfLZ+tvcr4J8eo/d9+OZ/w 8Dt0ZjSdskqDt+CVZTPptm9yBPquY4OPsM3txX9xkq7Pnrnd0fihNFV++nqHrdqCjOo/ OPNA/YiFVfnoZCleEdjM3TyWIQbrwSv7VgAr9R46KPnu1hKzhVPTXX2CpWMa/mtHcnor ph1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=WwIgLX9gzuZCUnda4LONPeydgYdfz4RgihbbCfvCjQg=; b=BtVGdbmlQ9aVhRNERgc6qWJj8QlF/+j1UYVOOTR+Rw2mY0w3I5wpLBolI6G0YxUheH ci5xjbH7vpbAti+l9wN0Y546JmwuYQYI8nB3ORLaOh6c9aVowkaraR7K54NkAVXoEKY/ /YauHuEe/F+KsF9Qyj3LdoeqYCmnmqyFhtIjHwSkPY8qxuRV0zq16rVsOPpSg+N7HGgk hl/S0avVji4psXVW+DU6pDkX6jGwdCEEK3FP8IUXi5rBjr/NwcIN+YE1e5jr1ONbLI3G 1rmqESHdhJ9LnGfLhlm53mjZMaAYQauR4yjKum/y5HnczVyaKBYTXJ/ZtSKI4KQkzA7T cR7g== X-Gm-Message-State: ALoCoQlPhBHg6swr0/UZk8BugNt2Kee1ouZw65gkqQIiDLuoWDfgVGkLKL4F0Sc0B3d9f0o/ibou MIME-Version: 1.0 X-Received: by 10.112.157.166 with SMTP id wn6mr9421311lbb.30.1446516118548; Mon, 02 Nov 2015 18:01:58 -0800 (PST) Received: by 10.25.163.6 with HTTP; Mon, 2 Nov 2015 18:01:58 -0800 (PST) X-Originating-IP: [209.173.57.233] Date: Tue, 3 Nov 2015 11:01:58 +0900 Message-ID: From: Brian Rosen To: "slim@ietf.org" Content-Type: multipart/alternative; boundary=001a11c2641668955505239947ae Archived-At: Subject: [Slim] Handling the complex multi-media cases X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 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, 03 Nov 2015 02:02:02 -0000 --001a11c2641668955505239947ae Content-Type: text/plain; charset=UTF-8 Gunnar has described situations where it is desirable to have relatively complex decisions on the right set of media streams, translators, relays, etc to achieve the user's goals. I have been consistently trying to solve the 95% cases with simple mechanisms, and trying not to make our solutions so complex that they don't get implemented. However, these cases DO occur, and we need to figure out, at some point, how we deal with them. One suggestion (thanks Stephen) is to use clue in those cases. It has the kind of flexibility that Gunnar is looking for. There is a complexity cost (clue isn't simple), but that's the right tradeoff - simple things are simple, complex things are harder. I'm fairly sure clue would work unmodified, but maybe we can ask Gunnar to take a look (not easy, sorry) at the clue document set and see if it works for all the cases he is aware of. Brian --001a11c2641668955505239947ae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Gunnar has described situations where it is desirable to h= ave relatively complex decisions on the right set of media streams, transla= tors, relays, etc to achieve the user's goals.=C2=A0 I have been consis= tently trying to solve the 95% cases with simple mechanisms, and trying not= to make our solutions so complex that they don't get implemented.
=
However, these cases DO occur, and we need to figure out, at= some point, how we deal with them.

One suggestion= (thanks Stephen) is to use clue in those cases.=C2=A0 It has the kind of f= lexibility that Gunnar is looking for.=C2=A0 There is a complexity cost (cl= ue isn't simple), but that's the right tradeoff - simple things are= simple, complex things are harder.

I'm fairly= sure clue would work unmodified, but maybe we can ask Gunnar to take a loo= k (not easy, sorry) at the clue document set and see if it works for all th= e cases he is aware of.

Brian
--001a11c2641668955505239947ae-- From nobody Mon Nov 2 18:14:52 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 143771ACD68 for ; Mon, 2 Nov 2015 18:14:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 g260PNte6ezd for ; Mon, 2 Nov 2015 18:14:48 -0800 (PST) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (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 0F57B1ACCE5 for ; Mon, 2 Nov 2015 18:14:48 -0800 (PST) Received: by wmff134 with SMTP id f134so73362132wmf.1 for ; Mon, 02 Nov 2015 18:14:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=kc/JPYUNdZFvMiR0kkBxMjdrm9KkxclAomLnkME4Xvs=; b=f17TIKtXLdJKluNtfwSlVhD/FqXa3l4Wy8p6PSyPzT7/bDWdvCdPklgxcJLjxZfDfu CpJiQuree9BxA7oG8/FNoQ+H7Y3dFR5BVtiEp878ElSZfw4dy7xpr9QNjpvoC629utrk NvpB57YFRQ+6REqWTQEIUthuza+OQb5u5RMNYcQCztkZ9Vt55kwbnVWFkVgvGTsiQXST tEgKGTobItUCkrCgBysu5oBknz7c/W6kXzN3NAaru/m6Vx9RaYC6g4ZwLbwK55fPN8wz XfU//pjjzf9lKgG7vUniVcd+opwQsJ9SefFYHASNOHMRdUWyMVWmyMAEtPuCcM8fRGYm N3Cw== X-Received: by 10.28.10.142 with SMTP id 136mr17614334wmk.84.1446516886600; Mon, 02 Nov 2015 18:14:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.0.81 with HTTP; Mon, 2 Nov 2015 18:14:27 -0800 (PST) In-Reply-To: References: From: Bernard Aboba Date: Mon, 2 Nov 2015 21:14:27 -0500 Message-ID: To: Brian Rosen Content-Type: multipart/alternative; boundary=001a11444d4030004405239975d2 Archived-At: Cc: "slim@ietf.org" Subject: Re: [Slim] Handling the complex multi-media cases X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 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, 03 Nov 2015 02:14:50 -0000 --001a11444d4030004405239975d2 Content-Type: text/plain; charset=UTF-8 Brian said: "One suggestion (thanks Stephen) is to use clue in those cases." [BA] Before getting into solutions, can we first understand what use cases are not handled by the current draft and SDP O/A functionality? The recently adopted draft can handle asymmetric use cases, which expands the potential list of supported disability modes considerably. As you described, O/A cannot express preferences between combinations of media and languages, but it is possible to negotiate multiple media/language pairs and deal with the "preference" aspect out of band. So it would be helpful to understand which of the complex use cases cannot be accommodated in any shape or form. On Mon, Nov 2, 2015 at 9:01 PM, Brian Rosen wrote: > Gunnar has described situations where it is desirable to have relatively > complex decisions on the right set of media streams, translators, relays, > etc to achieve the user's goals. I have been consistently trying to solve > the 95% cases with simple mechanisms, and trying not to make our solutions > so complex that they don't get implemented. > > However, these cases DO occur, and we need to figure out, at some point, > how we deal with them. > > One suggestion (thanks Stephen) is to use clue in those cases. It has the > kind of flexibility that Gunnar is looking for. There is a complexity cost > (clue isn't simple), but that's the right tradeoff - simple things are > simple, complex things are harder. > > I'm fairly sure clue would work unmodified, but maybe we can ask Gunnar to > take a look (not easy, sorry) at the clue document set and see if it works > for all the cases he is aware of. > > Brian > > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim > > --001a11444d4030004405239975d2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Brian said:=C2=A0

"One suggestion (thanks Stephen) is to use clue in those c= ases."

[BA] Before getting into solution= s, can we first understand what use cases are not handled by the current dr= aft and SDP O/A functionality?=C2=A0

The rece= ntly adopted draft can=C2=A0handle = asymmetric use cases, which expands the potential list of supported disabil= ity modes considerably. =C2=A0

As you describ= ed, O/A cannot express preferences between combinations of media and langua= ges, but it is possible to negotiate multiple media/language pairs and deal= with the "preference" aspect out of band.=C2=A0

So it would be help= ful to understand which of the complex use cases cannot be accommodated in = any shape or form.=C2=A0





=

On Mon, Nov= 2, 2015 at 9:01 PM, Brian Rosen <br@brianrosen.net> wrote:<= br>
Gunnar has described sit= uations where it is desirable to have relatively complex decisions on the r= ight set of media streams, translators, relays, etc to achieve the user'= ;s goals.=C2=A0 I have been consistently trying to solve the 95% cases with= simple mechanisms, and trying not to make our solutions so complex that th= ey don't get implemented.

However, these cases DO oc= cur, and we need to figure out, at some point, how we deal with them.
=

One suggestion (thanks Stephen) is to use clue in those= cases.=C2=A0 It has the kind of flexibility that Gunnar is looking for.=C2= =A0 There is a complexity cost (clue isn't simple), but that's the = right tradeoff - simple things are simple, complex things are harder.
=

I'm fairly sure clue would work unmodified, but may= be we can ask Gunnar to take a look (not easy, sorry) at the clue document = set and see if it works for all the cases he is aware of.

Brian
<= /span>

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


--001a11444d4030004405239975d2-- From nobody Mon Nov 2 18:19:56 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37B3E1ACDAE for ; Mon, 2 Nov 2015 18:19:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 oTaQwQehn_L9 for ; Mon, 2 Nov 2015 18:19:47 -0800 (PST) Received: from resqmta-po-05v.sys.comcast.net (resqmta-po-05v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:164]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99F551ACDE9 for ; Mon, 2 Nov 2015 18:18:49 -0800 (PST) Received: from resomta-po-11v.sys.comcast.net ([96.114.154.235]) by resqmta-po-05v.sys.comcast.net with comcast id cqJK1r00154zqzk01qJpZy; Tue, 03 Nov 2015 02:18:49 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([216.239.175.66]) by resomta-po-11v.sys.comcast.net with comcast id cqGS1r00D1SKl7c01qGZ3E; Tue, 03 Nov 2015 02:16:44 +0000 To: slim@ietf.org References: From: Paul Kyzivat Message-ID: <563818F9.2060709@alum.mit.edu> Date: Mon, 2 Nov 2015 21:16:25 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1446517129; bh=8Lw8E5kDQ+KUHKZTZSw8RuCCipOLEWyASS7alleOR9c=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=RWnbfarEPnUgfsA3SZzl1qwg8jtbnuGxFmnEvjkv1JfKTTYTqHBb1wAfuGmP5hbu0 ld7x9XT6AVxZoQVA9w9A7BEGkDXnb/5kPCAZwR/26/trmHTTj/dgKLgE9gubqA5ZKl Klc4QbzxvYsmQSrosmjg+u8eT1EUmFeNOggW1E4Jx2qHklBtUhGYixBUpzTuYwRIoi fR8AogaZ85KrFXoa11+to33ULU9NJa17rAlC6XQhNJfalYNDsgUqcBwpyufloZRnSF ScPeMibMN9n9unmJ7nH2MCg5Zes42nooPdmruVayr1PLdubRi1dmRmUcGXex/Ndshk ovVW3bGcfkHaQ== Archived-At: Subject: Re: [Slim] Handling the complex multi-media cases X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 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, 03 Nov 2015 02:19:49 -0000 I have proposed in the past that most of CLUE could be used complex multi-stream calls that are *not* telepresence. At the moment, CLUE advertisements are biased toward the kinds of attributes that are meaningful for telepresence. It would be trivial to extend that to carry other sorts of attributes. And it is true that what it has now might be sufficient to describe all of Gunnar's complex cases. (But I haven't analyzed that in detail.) It could work out in a fairly smooth way. The recommended way to initial a clue call is by first offering non-clue media (in case the callee doesn't do clue), plus the clue data channel. The non-clue part of the offer could include all the slim stuff. If the callee doesn't support clue, then it will work just like we have been discussing here, and the clue channel will be rejected. If the callee supports clue, then it would also accept the clue channel. Then the complex negotiation could happen, and other media set up. So I concur that this is one possible way forward. But it would only handle the complex cases if both ends do. I don't know whether there could be enough uptake of clue for that to be useful for these cases. Thanks, Paul On 11/2/15 9:01 PM, Brian Rosen wrote: > Gunnar has described situations where it is desirable to have relatively > complex decisions on the right set of media streams, translators, > relays, etc to achieve the user's goals. I have been consistently > trying to solve the 95% cases with simple mechanisms, and trying not to > make our solutions so complex that they don't get implemented. > > However, these cases DO occur, and we need to figure out, at some point, > how we deal with them. > > One suggestion (thanks Stephen) is to use clue in those cases. It has > the kind of flexibility that Gunnar is looking for. There is a > complexity cost (clue isn't simple), but that's the right tradeoff - > simple things are simple, complex things are harder. > > I'm fairly sure clue would work unmodified, but maybe we can ask Gunnar > to take a look (not easy, sorry) at the clue document set and see if it > works for all the cases he is aware of. > > Brian > > > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim > From nobody Mon Nov 2 23:07:26 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 110631B2EE3 for ; Mon, 2 Nov 2015 23:07:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.001 X-Spam-Level: X-Spam-Status: No, score=-3.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, J_CHICKENPOX_17=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 aNcZ_KbMyI23 for ; Mon, 2 Nov 2015 23:07:22 -0800 (PST) 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 0088E1B2C90 for ; Mon, 2 Nov 2015 23:07:21 -0800 (PST) X-Halon-ID: 87d83368-81f9-11e5-9922-005056917a89 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.43.70] (unknown [2.65.111.8]) by bin-vsp-out-01.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Tue, 3 Nov 2015 08:07:22 +0100 (CET) To: Doug Ewell , Randall Gellens , slim@ietf.org References: <20151102161215.665a7a7059d7ee80bb4d670165c8327d.643b000064.wbe@email03.secureserver.net> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <56385D24.9060608@omnitor.se> Date: Tue, 3 Nov 2015 08:07:16 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151102161215.665a7a7059d7ee80bb4d670165c8327d.643b000064.wbe@email03.secureserver.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Slim] Primary language tags (was "Re: draft-tomkinson comments") X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 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, 03 Nov 2015 07:07:25 -0000 Den 2015-11-03 kl. 00:12, skrev Doug Ewell: > Randall Gellens wrote: > >>> The same reasoning enable us to distinguish >>> written from spoken language by using the >>> Script subtag to indicate written, even if >>> Suppress-Script is registered for the language >>> tag. >> [...] >> >> I am concerned that overloading the use of >> 'script' in this way is dangerous, and further, I >> am not convinced that we need to differentiate >> written from spoken language. If it turns out >> that we do, we should choose a different >> mechanism where that is the only meaning. > I agree. Although a script subtag does identify the script in which the > tagged content is written -- implying that the content is indeed written > -- BCP 47 does not state anywhere that a script subtag should be used to > distinguish written content from content in other modalities, and for > good reason. Identification of modality, like many other attributes of > linguistic content, is out of scope for BCP 47. The draft should define > a protocol that uses BCP 47, not seek to extend it. > > Furthermore, encouraging the use of script subtags even in the presence > of Suppress-Script, without good reason to override (such as when > identifying French written in Cyrillic letters), runs counter to the > general principle of avoiding unnecessary subtags -- although I agree > with Addison that the draft may go too far beyond BCP 47 in discouraging > potentially necessary subtags. OK, let us add the distinguishing of modalities to BCP 47 in an acceptable way then. This seems to be needed for both slim drafts. Neither m= media types in SDP nor Content-Types in e-mail are consistent enough to tell if the content will be spoken, written or signed. Sign languages are well identified in BCP 47, but not written versus spoken. Examples of when the sdp types or Content-Types are not specific: Text overlay on video versus the image of a speaking person. The m=message media type for MSRP can contain text or audio or video messages A number of application types can have combined media, e.g. mp4 The draft-sdpneg data channel for WebRTC can contain a number of subchannels, one of them being text, but identified by a subprotocol name. WebRTC can be controlled by SIP, so it would be in scope to negotiate language and modality also for this form of WebRTC with slim. How would the difference between spoken and written best be expressed in an extended BCP47? /Gunnar > > -- > Doug Ewell | http://ewellic.org | Thornton, CO 🇺🇸 > From nobody Tue Nov 3 02:28:42 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 411461B319D for ; Tue, 3 Nov 2015 02:28:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 FJLNXiayYDOu for ; Tue, 3 Nov 2015 02:28:37 -0800 (PST) Received: from bin-vsp-out-05.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 9AC121B319C for ; Tue, 3 Nov 2015 02:28:36 -0800 (PST) X-Halon-ID: a1189385-8215-11e5-8d6b-005056916f53 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.43.70] (unknown [2.65.89.221]) by bin-vsp-out-05.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Tue, 3 Nov 2015 11:28:31 +0100 (CET) To: slim@ietf.org References: <563818F9.2060709@alum.mit.edu> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <56388C4D.4090808@omnitor.se> Date: Tue, 3 Nov 2015 11:28:29 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <563818F9.2060709@alum.mit.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Slim] Handling the complex multi-media cases X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 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, 03 Nov 2015 10:28:40 -0000 Yes, it is a good approach to explain the complex cases and agree on how important they are and check how they are met or can be met by real-time slim. First, a comment on Clue. Yes, it seems to have audio, video and text. It is a bit vague about test, but I think it is there. It is possible to set a parameter for relates-to, and that is what we may be missing in sdp and slim so far. So, not attractive, but could be looked at again. I agree with Paul that the likelihood of implementation would be low if we point to Clue for solving the complex slim cases. I would rather think that we need a supplement in form of an assisting service parameter meaning, "if our languages and modalities are not compatible, here is a service that can help with translation between my preferences and spoken language (yes, all current relay services go between spoken and other modalities ). But let us look at the use cases: First an assumption: The user sets the settings in its terminal or application provider supplied user profile in a way that it is included in sdp of the call setup. The vision is that this setting is not or only occasionally modified by the user when making a call or receiving a call. 1. Single two-way language ( the simple one) One language and modality both ways in media described in sdp as audio or video or text. Straightforward. Works for spoken, written and signed languages. Result: Possible 2. Alternatives in the same modality (also simple ) Two or more language alternatives in the same modality. Two or more languages both ways in media described in sdp as audio or video or text, but only in one modality. Straightforward. Works for spoken, written and signed languages. The answering part selects. There is a relative preference expressed by the order, and the answering part can try to fulfill that in the best way. Result: Possible 3. Fairly equal alternatives in different modalities. Two or more modality alternatives. Two or more languages in different modalities both ways in media described in sdp as audio or video or text Example a hearing person also competent in sign language declares both spoken and sign language competence in audio and video. This is fairly straightforward, as long as there is no strong difference in preference for these alternatives. The indication of sign language competence is needed to avoid invoking relay services in calls with deaf sign language users only indicating sign language. Result: Possible 4. Last resort indication. A hearing user has text capability but want to use that as last resort. With current hunintlang specification, there is no way to describe preference level between modalities and no way to describe absolute preference. Result: An answering service will have no guidance to which is the preferred modality and may select to use the modality that is the callers last resort even if the preferred alternative is available. A practical case can be a sign language user with a small mobile terminal that has some inconvenient means for texting, but sign language will be strongly preferred. In order to not miss any calls, the indication of text as last resort would be desirable. Possible solution: coding of an absolute preference: hi, med, lo together with the tag. Result: Need for absolute preference indication. 5. Directional capabilities in different modalities A hard-of-hearing user strongly prefers to talk and get text back. Getting spoken language input is appreciated. This can be indicated by spoken language two-ways in audio, and reception of language in text. But there is nothing in current coding that says that the text path is important. The answering part may see it as an alternative, just as case 3. There is a way to indicate that the call shall fail if a language is not met, but that may be too drastic for this user. It may be important to be able to connect and just say something, or use residual hearing to get something back when the voice is familiar. Possible solution: coding of an absolute preference: hi, med, lo together with the tag could solve this case if used together with the directional indications. Another solution would be to indicate required grouping of media. But that seems more complex. Result: Need for absolute preference indication. 6. Combination of modalities Quite similar to case 5. A deaf-blind person may have highest preference for signing out and getting text back. Indication of sign language output in video and text reception in text, using the current directional attributes. An answering part may seek suitable modalities for each direction and find the only possible combination. Result: Possible 7. Person with speech disabilities who prefer speech-to-speech service. A person who speaks in a way that is hard to understand, may be used to have support of a speech-to-speech relay service that adds clear speech when needed for the understanding. Calls with close friends and family might be possible without the relay service. Text can be used as a fall-back. This user would indicate preference for receiving spoken language in audio. Text output can be indicated but this user might want to use that as last resort. But there is no current coding for vague or unarticulated speech or other needs for a speech-to-speech service. A possibility could be to indicate no preference for spoken language out, a coding of proposed assisting service and an indication of text output on a low absolute level. Result: Need of service indication, and absolute level of preference indication 8. Person with speech disabilities who prefer to type and hear. A person who speaks in a way that is hard to understand, may be used to use text for output and listen to spoken language for input. This user would indicate preference for receiving spoken language in audio. Text output modality can be indicated. If the answering part has text and audio capabilities, there is a match. If only voice, there is a need to invoke a text relay service. Result: Possible. 9. A tele-sales center calls out and want to offer all kinds of possibilities so that the answering part can select. (Hated example, but I take it anyway) A tele-sales center has competence in multiple spoken languages and can invoke relay services rapidly if needed. So, it indicates in the call setup competence in a number of spoken languages in audio, a number of sign languages in video and a number of written languages in text. A deaf-blind person who prefers to sign out and get text back answers with only these capabilities. The center can detect that and act accordingly. Alternative1: The center calls without sdp. The deafblind user includes its sdp offer and the center sees what is needed to fulfill the call. Alternative 2: The center calls out with only the spoken language capabilities indicated that the caller can handle. The deaf-blind answering person, or terminal or service provider detects the difference compared to the capabilities of the answering party, and adds a suitable relay service. ( this does not use all the offerings of the callers competence to pull in extra services, but is maybe a more realistic case for what usually happens. ) Result: doable in the same way as cases 1-8. Total result: The currently specified directionality is needed. An indication of absolute preference is needed. ( maybe instead of the current switch between complete vs fail the call that seems too drastic for most cases. ) An indication of suitable service and its spoken language is needed for the speech-to-speech case, but can be useful for other cases as well. No clear need for explicit grouping of modalities seem to be needed. ( and that was what clue could contribute, so the clue idea can probably be dropped) More thoughts are needed on who really evaluates the indications and invokes a needed service, but the above likely covers the needs for language/modality indications. Gunnar Den 2015-11-03 kl. 03:16, skrev Paul Kyzivat: > I have proposed in the past that most of CLUE could be used complex > multi-stream calls that are *not* telepresence. At the moment, CLUE > advertisements are biased toward the kinds of attributes that are > meaningful for telepresence. It would be trivial to extend that to > carry other sorts of attributes. And it is true that what it has now > might be sufficient to describe all of Gunnar's complex cases. (But I > haven't analyzed that in detail.) > > It could work out in a fairly smooth way. The recommended way to > initial a clue call is by first offering non-clue media (in case the > callee doesn't do clue), plus the clue data channel. The non-clue part > of the offer could include all the slim stuff. If the callee doesn't > support clue, then it will work just like we have been discussing > here, and the clue channel will be rejected. > > If the callee supports clue, then it would also accept the clue > channel. Then the complex negotiation could happen, and other media > set up. > > So I concur that this is one possible way forward. > > But it would only handle the complex cases if both ends do. I don't > know whether there could be enough uptake of clue for that to be > useful for these cases. > > Thanks, > Paul > > On 11/2/15 9:01 PM, Brian Rosen wrote: >> Gunnar has described situations where it is desirable to have relatively >> complex decisions on the right set of media streams, translators, >> relays, etc to achieve the user's goals. I have been consistently >> trying to solve the 95% cases with simple mechanisms, and trying not to >> make our solutions so complex that they don't get implemented. >> >> However, these cases DO occur, and we need to figure out, at some point, >> how we deal with them. >> >> One suggestion (thanks Stephen) is to use clue in those cases. It has >> the kind of flexibility that Gunnar is looking for. There is a >> complexity cost (clue isn't simple), but that's the right tradeoff - >> simple things are simple, complex things are harder. >> >> I'm fairly sure clue would work unmodified, but maybe we can ask Gunnar >> to take a look (not easy, sorry) at the clue document set and see if it >> works for all the cases he is aware of. >> >> Brian >> >> >> _______________________________________________ >> 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 Tue Nov 3 05:24:03 2015 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 C0D621B2E24; Mon, 2 Nov 2015 20:59:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.8.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151103045949.27011.8599.idtracker@ietfa.amsl.com> Date: Mon, 02 Nov 2015 20:59:49 -0800 Archived-At: X-Mailman-Approved-At: Tue, 03 Nov 2015 05:24:01 -0800 Cc: slim@ietf.org Subject: [Slim] I-D Action: draft-ietf-slim-multilangcontent-00.txt X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 04:59:49 -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 Working Group of the IETF. Title : Multiple Language Content Type Authors : Nik Tomkinson Nathaniel Borenstein Filename : draft-ietf-slim-multilangcontent-00.txt Pages : 13 Date : 2015-11-02 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's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-slim-multilangcontent-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/ From nobody Tue Nov 3 05:27:52 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E64261B337B for ; Tue, 3 Nov 2015 05:27:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 bh9x8F91HQS2 for ; Tue, 3 Nov 2015 05:27:48 -0800 (PST) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2CE01B3377 for ; Tue, 3 Nov 2015 05:27:47 -0800 (PST) Received: by qkcl124 with SMTP id l124so6063211qkc.3 for ; Tue, 03 Nov 2015 05:27:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=sqtPBxnjuJUuCW7GUsvWUOMaCWIr0OjlI9oYL3br1lg=; b=URcjGaFx2BCUumbA4VNZqwOnc2hLU9lw/CmoXyPcoxulcxNHS9ogyqql7XlNeZIUy8 I8iHBZBQujd3UemEUhsKcrOV4AW/7DReFWpVnyjqnFgK5wA9YdHe6Y5gXQWSDIhRTuwA qkFaa66tSQVKY4PABnZ2IP/50iF4d37aWPDBlY0JaGFr7kkDxVZ/0IESiXj4hW0NQ9Vy u5Dod+Ltpm9rTfJPUGq+XgHyjeMj5SS4O1qxB3o6SMCl0g4KlTKBucWgUeVjRIakQFL6 vzgy7QhkmbInP/dkcw4LKMeQOhdVITZagKODTWl4hkDJubWpJJsqr2h+6fuNc+vMzHDZ 2KbQ== MIME-Version: 1.0 X-Received: by 10.55.71.19 with SMTP id u19mr36512905qka.82.1446557266918; Tue, 03 Nov 2015 05:27:46 -0800 (PST) Received: by 10.55.76.78 with HTTP; Tue, 3 Nov 2015 05:27:46 -0800 (PST) In-Reply-To: <20151103045949.27011.8599.idtracker@ietfa.amsl.com> References: <20151103045949.27011.8599.idtracker@ietfa.amsl.com> Date: Tue, 3 Nov 2015 13:27:46 +0000 Message-ID: From: Nik Tomkinson To: slim@ietf.org Content-Type: multipart/alternative; boundary=001a114a85420ac5000523a2dc50 Archived-At: Subject: Re: [Slim] I-D Action: draft-ietf-slim-multilangcontent-00.txt X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 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, 03 Nov 2015 13:27:50 -0000 --001a114a85420ac5000523a2dc50 Content-Type: text/plain; charset=UTF-8 Just to reiterate, this new version takes into account all the agreed comments from Addison but nothing that is still under discussion or anything from Monday's session questions as some of this needs some thought and/or testing. Nik. On 3 November 2015 at 04:59, wrote: > > 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 > Working Group of the IETF. > > Title : Multiple Language Content Type > Authors : Nik Tomkinson > Nathaniel Borenstein > Filename : draft-ietf-slim-multilangcontent-00.txt > Pages : 13 > Date : 2015-11-02 > > 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's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-slim-multilangcontent-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/ > > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim > -- ----------------------------------------------------------------- Multiple Language Content Type Internet Draft: http://datatracker.ietf.org/doc/draft-tomkinson-slim-multilangcontent/ ----------------------------------------------------------------- --001a114a85420ac5000523a2dc50 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Just to reiterate, this new version takes into account all= the agreed comments from Addison but nothing that is still under discussio= n or anything from Monday's session questions as some of this needs som= e thought and/or testing.

Nik.

On 3 November 2015 at 04:59, <= span dir=3D"ltr"><internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the Selection of Language for Internet M= edia Working Group of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Multiple Language Content Type
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Nik = Tomkinson
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Nathaniel Borenstein
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-slim-multilangcontent-00.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 13
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2015-11-02

Abstract:
=C2=A0 =C2=A0This document defines an addition to the Multipurpose Internet= Mail
=C2=A0 =C2=A0Extensions (MIME) standard to make it possible to send one mes= sage
=C2=A0 =C2=A0that contains multiple language versions of the same informati= on.
=C2=A0 =C2=A0The translations would be identified by a language tag and sel= ected
=C2=A0 =C2=A0by the email client based on a user's language settings.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/d= raft-ietf-slim-multilangcontent/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-iet= f-slim-multilangcontent-00


Please note that it may take a couple of minutes from the time of submissio= n
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



-- 
-----------=
------------------------------------------------------
Multiple Language=
 Content Type Internet Draft:
http://datatracker.ietf.org/doc/draft-tomkinson-slim-multilangcontent/= 
----------------=
-------------------------------------------------
--001a114a85420ac5000523a2dc50-- From nobody Tue Nov 3 11:55:54 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE9331A88C4 for ; Tue, 3 Nov 2015 11:55:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.299 X-Spam-Level: X-Spam-Status: No, score=0.299 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 aWzlXYSQwgI5 for ; Tue, 3 Nov 2015 11:55:51 -0800 (PST) Received: from p3plwbeout03-06.prod.phx3.secureserver.net (p3plsmtp03-06-2.prod.phx3.secureserver.net [72.167.218.218]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D65CB1A88AF for ; Tue, 3 Nov 2015 11:55:51 -0800 (PST) Received: from localhost ([72.167.218.244]) by p3plwbeout03-06.prod.phx3.secureserver.net with bizsmtp id d7vr1r0015GyNsw017vrao; Tue, 03 Nov 2015 12:55:51 -0700 X-SID: d7vr1r0015GyNsw01 Received: (qmail 1552 invoked by uid 99); 3 Nov 2015 19:55:51 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 208.51.143.189 User-Agent: Workspace Webmail 5.15.9 Message-Id: <20151103125549.665a7a7059d7ee80bb4d670165c8327d.d41148fb15.wbe@email03.secureserver.net> From: "Doug Ewell" To: "=?UTF-8?Q?Gunnar=5FHellstr=C3=B6m?=" , "Randall Gellens" , slim@ietf.org Date: Tue, 03 Nov 2015 12:55:49 -0700 Mime-Version: 1.0 Archived-At: Subject: Re: [Slim] Primary language tags (was "Re: draft-tomkinson comments") X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 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, 03 Nov 2015 19:55:53 -0000 Gunnar Hellstr=C3=B6m wrote:=0A=0A> How would the difference between spoken= and written best be expressed=0A> in an extended BCP47?=0A=0AWithout expre= ssing any opinion about the use case itself with regard to=0ASLIM, I'll poi= nt out that there are basically three possible ways to do=0Athis conformant= ly:=0A=0A1. Private-use subtags (e.g. en-x-spoken, en-x-written)=0A=0AWhile= this solution would work immediately, out of the box, with no need=0Ato re= gister or publish anything, I realize that just about nobody wants=0Athis s= olution, and to some extent why.=0A=0A2. Variant subtags (e.g. en-spoken, e= n-written)=0A=0AThese would need to be individually registered as per RFC 5= 646, Section=0A3.5, via the ietf-languages list. I can say with reasonable = certainty=0Athat there would be fairly strong opposition to this approach, = as=0Amodality is not generally considered to "define a language or its=0Adi= alects" (Section 2.2.5) except in special cases like sign languages.=0AOne = might reasonably ask if whispered, shouted, muttered, sung,=0Adisplayed on = a billboard, skywritten, etc. would also qualify.=0A=0A3. Registered extens= ion (e.g. en-m-spoken, en-m-written)=0A=0AThis would involve writing and pu= blishing an RFC to define an extension=0Afor "modality" together with an in= itial list of values, as per Section=0A3.7. Extensions have been created so= far to denote attributes that are=0Amore closely associated with locales t= han with languages per se, so=0Athere might be some support for this approa= ch. It would, however,=0Ainvolve the usual lengthy RFC gestation period.=0A= =0AAn alternative approach, which I believe has been discussed here before,= =0Awould be to encode modality in its own separate attribute, rather than= =0Atrying to fit language identification and modality into the same tag.=0A= =0AHope this helps,=0A=0A--=0ADoug Ewell | http://ewellic.org | Thornton, C= O =F0=9F=87=BA=F0=9F=87=B8=0A From nobody Tue Nov 3 12:31:25 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C55351B34D7 for ; Tue, 3 Nov 2015 12:31:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 I0KbpHjc6oav for ; Tue, 3 Nov 2015 12:31:22 -0800 (PST) Received: from bin-vsp-out-04.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 6E5261B34CE for ; Tue, 3 Nov 2015 12:31:21 -0800 (PST) X-Halon-ID: d25308e9-8269-11e5-83b0-005056917c0c Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.48] (unknown [83.209.226.9]) by bin-vsp-out-04.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Tue, 3 Nov 2015 21:31:11 +0100 (CET) To: slim@ietf.org References: <20151103125549.665a7a7059d7ee80bb4d670165c8327d.d41148fb15.wbe@email03.secureserver.net> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <56391992.9030000@omnitor.se> Date: Tue, 3 Nov 2015 21:31:14 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151103125549.665a7a7059d7ee80bb4d670165c8327d.d41148fb15.wbe@email03.secureserver.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Slim] Primary language tags (was "Re: draft-tomkinson comments") X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 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, 03 Nov 2015 20:31:23 -0000 Den 2015-11-03 kl. 20:55, skrev Doug Ewell: > An alternative approach, which I believe has been discussed here before, > would be to encode modality in its own separate attribute, rather than > trying to fit language identification and modality into the same tag. That is close to what we have now in the real-time spec, by tacking on the language tag to the media specification in SDP. But it has some drawbacks, in that media types are not strict on what modalities they carry, with all these application and message etc media types not revealing clearly what they contain. And I think, the same with Content-Type on the mail side. So, for the humintlang attribute one solution would be to have a parameter for modality. But it is a general problem that should best be solved at its source - in BCP-47. Spoken and written languages are not identical, we just believe so at first thought. This problem makes language tags ambigous in many applications. Users usually want to know if they are supposed to read or listen. Gunnar From nobody Tue Nov 3 12:43:06 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88F4D1B352F for ; Tue, 3 Nov 2015 12:43:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.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, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 oUZw_7Cpxsb5 for ; Tue, 3 Nov 2015 12:43:04 -0800 (PST) Received: from mail-yk0-x22a.google.com (mail-yk0-x22a.google.com [IPv6:2607:f8b0:4002:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF5FC1B352D for ; Tue, 3 Nov 2015 12:43:03 -0800 (PST) Received: by ykft191 with SMTP id t191so37197674ykf.0 for ; Tue, 03 Nov 2015 12:43:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=0mdGJ/5CwXaOZe20c4LoFP9WtVmdbNNkzoF2eYrTGlI=; b=PGu4m+XNhVJuFy8P9xJHB9FgUqhvYT5r43s+RcI79uZMyaqO8QTkG4mDgBw9/Fze4I 6rko5jgaQ3/FMxgJICg9hN755G3hDj6OG0O7/PK44qGLHGoGvPd+nFl9ZAVstJAZpFt4 bWm+lwALMIYWhWrVkOkMuemFyDFUEmhAMPl7Qv3kSSZOIZTbvv0VYPotp0jfl9nOoubJ aYBknki+bf2ZjSkoOBSHN5/t0OLOEavObZEbuSTY5Q4KCinmKc+UGHDQ0bolqdQA7nWM 5oTVdnKXHMBE3HJliG438iNuvjxl8YrCiMiFHMY1eQmeeZMUKcJ8J9lmW29z0ze5C7oH 0KWA== X-Received: by 10.129.97.9 with SMTP id v9mr24286955ywb.262.1446583383293; Tue, 03 Nov 2015 12:43:03 -0800 (PST) Received: from ?IPv6:2601:580:4001:290f:9c60:521d:9bcb:d9d0? ([2601:580:4001:290f:9c60:521d:9bcb:d9d0]) by smtp.gmail.com with ESMTPSA id w184sm17665427ywe.50.2015.11.03.12.43.01 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Nov 2015 12:43:01 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPad Mail (13B143) In-Reply-To: <56388C4D.4090808@omnitor.se> Date: Tue, 3 Nov 2015 15:43:00 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <563818F9.2060709@alum.mit.edu> <56388C4D.4090808@omnitor.se> To: =?utf-8?Q?Gunnar_Hellstr=C3=B6m?= Archived-At: Cc: slim@ietf.org Subject: Re: [Slim] Handling the complex multi-media cases X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 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, 03 Nov 2015 20:43:05 -0000 On Nov 3, 2015, at 05:28, Gunnar Hellstr=C3=B6m wrote: >=20 > 4. Last resort indication. > A hearing user has text capability but want to use that as last resort. > With current hunintlang specification, there is no way to describe prefere= nce level between modalities and no way to describe absolute preference. > Result: An answering service will have no guidance to which is the preferr= ed modality and may select to use the modality that is the callers last reso= rt even if the preferred alternative is available. > A practical case can be a sign language user with a small mobile terminal t= hat has some inconvenient means for texting, but sign language will be stron= gly preferred. In order to not miss any calls, the indication of text as las= t resort would be desirable. > Possible solution: coding of an absolute preference: hi, med, lo together w= ith the tag. > Result: Need for absolute preference indication. [BA] The user offers to send and receive ASL in the video m-line, as well as= to receive (and send?) RTT on the text m-line. Is the concern that the Answ= erer will accept both due to lack of preference when ASL is enough? Since vi= deo can be congested, having RTT as a backup doesn't seem so bad, even if it= is not used by agreement between the parties. Or is the concern that the An= swerer could do video/ASL but will reject that while accepting RTT, for some= reason? > 5. Directional capabilities in different modalities > A hard-of-hearing user strongly prefers to talk and get text back. Getting= spoken language input is appreciated. > This can be indicated by spoken language two-ways in audio, and reception o= f language in text. > But there is nothing in current coding that says that the text path is imp= ortant. The answering part may see it as an alternative, just as case 3. > There is a way to indicate that the call shall fail if a language is not m= et, but that may be too drastic for this user. It may be important to be abl= e to connect and just say something, or use residual hearing to get somethin= g back when the voice is familiar. > Possible solution: coding of an absolute preference: hi, med, lo together w= ith the tag could solve this case if used together with the directional indi= cations. > Another solution would be to indicate required grouping of media. But that= seems more complex. > Result: Need for absolute preference indication. [BA] Is the concern that an Answerer capable of sending RTT will decline to d= o so, since a bi-directional audio m-line has been successfully negotiated? I= f the Answerer accepts bi-directional audio and RTT is that an issue? It see= ms that after the call is set up the Offerer could indicate the preference f= or receiving both audio and RTT out of band. 7. Person with speech disabilities who prefer speech-to-speech service. > A person who speaks in a way that is hard to understand, may be used to ha= ve support of a speech-to-speech relay service that adds clear speech when n= eeded for the understanding. > Calls with close friends and family might be possible without the relay se= rvice. > Text can be used as a fall-back. > This user would indicate preference for receiving spoken language in audio= . > Text output can be indicated but this user might want to use that as last r= esort. > But there is no current coding for vague or unarticulated speech or other n= eeds for a speech-to-speech service. > A possibility could be to indicate no preference for spoken language out, a= coding of proposed assisting service and an indication of text output on a l= ow absolute level. > Result: Need of service indication, and absolute level of preference indic= ation [BA] How is the decision to invoke a speech-speech relay made? If the Offerer offers to receive audio and but send (and receive?) RTT, and t= he Answerer accepts both m-lines, would this avoid invoking a speech-speech r= elay? Bi-directional audio could be offered along with sending (and receiving?) RT= T. If the Answerer accepts both, the offerer could request out of band that t= he Answerer use RTT if audio cannot be understood (would speech-speech relay= be invoked at that point?)= From nobody Tue Nov 3 13:05:11 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 731AD1A8711 for ; Tue, 3 Nov 2015 13:05:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.601 X-Spam-Level: X-Spam-Status: No, score=-5.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, TVD_FROM_1=0.999] autolearn=ham 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 U4pNXQIAPHFn for ; Tue, 3 Nov 2015 13:05:08 -0800 (PST) Received: from smtp-fw-4101.amazon.com (smtp-fw-4101.amazon.com [72.21.198.25]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 031A61A86F7 for ; Tue, 3 Nov 2015 13:05:07 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.20,239,1444694400"; d="scan'208";a="378839540" Received: from iad12-co-svc-p1-lb1-vlan2.amazon.com (HELO email-inbound-relay-71008.iad55.amazon.com) ([10.43.8.2]) by smtp-border-fw-out-4101.iad4.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Nov 2015 21:05:06 +0000 Received: from ex10-hub-7001.ant.amazon.com (iad1-ws-svc-lb91-vlan2.amazon.com [10.0.103.146]) by email-inbound-relay-71008.iad55.amazon.com (8.14.7/8.14.7) with ESMTP id tA3L4o23005920 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 3 Nov 2015 21:05:05 GMT Received: from EX13D08UWB002.ant.amazon.com (10.43.161.168) by ex10-hub-7001.ant.amazon.com (10.43.103.49) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 3 Nov 2015 13:04:49 -0800 Received: from EX13D08UWB003.ant.amazon.com (10.43.161.186) by EX13D08UWB002.ant.amazon.com (10.43.161.168) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Tue, 3 Nov 2015 21:04:48 +0000 Received: from EX13D08UWB003.ant.amazon.com ([10.43.161.186]) by EX13D08UWB003.ant.amazon.com ([10.43.161.186]) with mapi id 15.00.1076.000; Tue, 3 Nov 2015 21:04:48 +0000 From: "Phillips, Addison" To: =?utf-8?B?R3VubmFyIEhlbGxzdHLDtm0=?= , "slim@ietf.org" Thread-Topic: [Slim] Primary language tags (was "Re: draft-tomkinson comments") Thread-Index: AQHRFnGibXVuRCaHCk6rEFnbtQoU/Z6KwEcAgAAAxRA= Date: Tue, 3 Nov 2015 21:04:48 +0000 Message-ID: <212ff0f6c22048e883b9eeb3c0e74672@EX13D08UWB003.ant.amazon.com> References: <20151103125549.665a7a7059d7ee80bb4d670165c8327d.d41148fb15.wbe@email03.secureserver.net> <56391992.9030000@omnitor.se> In-Reply-To: <56391992.9030000@omnitor.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.162.250] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Precedence: Bulk Archived-At: Subject: Re: [Slim] Primary language tags (was "Re: draft-tomkinson comments") X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 21:05:10 -0000 VGhhdCdzIHRydWU6IHNwb2tlbiBhbmQgd3JpdHRlbiBsYW5ndWFnZSBhcmUgZGlmZmVyZW50LiBB cyBhIHJlc3VsdCwgb2NjYXNpb25hbGx5IHNvbWUgc3Bva2VuIG9yIHdyaXR0ZW4gY29udGVudCBu ZWVkcyB0byB1c2UgYSBkaWZmZXJlbnQgbGFuZ3VhZ2UgdGFnIGZyb20gdGhlIG90aGVyIG1vZGFs aXR5ICpiZWNhdXNlKiB0aGUgdmFsdWUgYmVpbmcgaWRlbnRpZmllZCBpcyBpdHNlbGYgZGlmZmVy ZW50LiBUaGlzIGlzIGNvbW1vbiwgZm9yIGV4YW1wbGUsIGZvciB0aGUgQ2hpbmVzZSBtYWNyb2xh bmd1YWdlLCB3aGVyZSB0aGUgd3JpdHRlbiBmb3JtIGdlbmVyYWxseSBidXQgbm90IGFsd2F5cyBp cyBzb21lIGZvcm0gb2YgTWFuZGFyaW4gQ2hpbmVzZSBpbiBlaXRoZXIgdGhlIFNpbXBsaWZpZWQg b3IgVHJhZGl0aW9uYWwgc2NyaXB0IGJ1dCB3aGVyZSB0aGUgc3Bva2VuIGZvcm0gZG9lcyBub3Qg d2FudCBhIHNjcmlwdCBzdWJ0YWcgYW5kIG1heSBuZWVkIHRvIHVzZSB0aGUgc3BlY2lmaWMgc3Vi dGFnIGZvciB0aGUgc3Bva2VuIHZhcmlldHktLS1zdWNoIGFzICd5dWUnLg0KDQpIb3dldmVyLCB0 aGVyZSBhcmVuJ3QgbWFueSBjYXNlcyB3aGVyZSB0aGUgc3Bva2VuIHZhcmlhbnQgYW5kIHRoZSB3 cml0dGVuIHZhcmlhbnQgb2YgYSBsYW5ndWFnZSBzaGFyZSBhIHNpbmdsZSByZXNvdXJjZS4gVGhh dCBpcywgeW91IGRvbid0IGhhdmUgYW55IGF1ZGlvIHJlY29yZGluZ3MgY29udGFpbmluZyB0aGUg d3JpdHRlbiB2YXJpYXRpb24gb2YgR2VybWFuLiBUaGUgc3VidGl0bGVzIGluIGEgbW92aWUgYXJl IHdyaXR0ZW4sIGJ1dCB0aGUgYXVkaW8gdHJhY2tzIGFyZSBhdWRpbyByZWNvcmRpbmdzOiB0aGVz ZSBtYXkgYmUgaWRlbnRpZmllZCBzZXBhcmF0ZWx5LiBTaWduIGxhbmd1YWdlIGludGVycHJldGF0 aW9uIG9mIGEgc3BlZWNoIGlzIGFjdHVhbGx5ICppbiogYW5vdGhlciBsYW5ndWFnZSBpbiBtb3N0 IGNhc2VzLiBBbmQgc28gb24uDQoNCkFzIHN1Y2gsIEkgZ3Vlc3MgSSBkb24ndCBiZWxpZXZlIHRo YXQgdGhlcmUgaXMgbXVjaCBuZWVkIHRvIGludHJvZHVjZSBhIHNjcmlwdCBzdWJ0YWcgbWVyZWx5 IHRvIHNheSB0aGF0IHNvbWUgc2V0IG9mIHN0cmluZ3MgKG9yIGNvbGxlY3Rpb24gb2YgcGl4ZWxz KSBpcyB3cml0dGVuLiBUaGF0IG11Y2ggaXMgdXN1YWxseSBvYnZpb3VzIGZyb20gdGhlIHJlc291 cmNlIGl0c2VsZi4gSW50cm9kdWNpbmcgYSBzdWJ0YWcgYXJ0aWZpY2lhbGx5IHRvIGNvbnZleSB0 aGlzIGluZm9ybWF0aW9uIGludGVyZmVyZXMgd2l0aCB0YWcgbWF0Y2hpbmcgYW5kIHNlbGVjdGlv biAocGFydGljdWxhcmx5IHdoZW4gdGhlIHNlbGVjdGlvbiBpcyBhdXRvbWF0ZWQgZnJvbSBleGlz dGluZyBjb250ZW50KS4gQW5kIHdoZW4gdGhlICJkaWZmZXJlbmNlIiBiZWluZyBpZGVudGlmaWVk IGlzIGFscmVhZHkgIm9idmlvdXMiIHRvIHByb2Nlc3NpbmcsIGl0J3Mgbm90IHdvcnRoIHRoZSBw cm9ibGVtcyBpdCBjYXVzZXMuIFVzZSBsYW5ndWFnZSB0YWdzIHRvIGlkZW50aWZ5IGxhbmd1YWdl IHZhcmlhdGlvbiBhbmQgbm90IGFzIGEgcHJveHkgZm9yIENvbnRlbnQtVHlwZSA7LSkuDQoNCj4g VGhpcyBwcm9ibGVtIG1ha2VzIGxhbmd1YWdlIHRhZ3MgYW1iaWdvdXMgaW4gbWFueSBhcHBsaWNh dGlvbnMuIFVzZXJzDQo+IHVzdWFsbHkgd2FudCB0byBrbm93IGlmIHRoZXkgYXJlIHN1cHBvc2Vk IHRvIHJlYWQgb3IgbGlzdGVuLg0KDQpXaGVuIGNvbnRlbnQgaXMgaW50ZXJjaGFuZ2VkLCB1c2Vy cyBhbHJlYWR5IGtub3cgd2hldGhlciB0aGUgZXhjaGFuZ2VkIGNvbnRlbnQgY2FuIGJlIHJlYWQg b3IgY2FuIGJlIGxpc3RlbmVkIHRvLiBJdCdzIGEgcHJvcGVydHkgb2YgdGhlIGRhdGEgZm9ybWF0 LiBJZiBhIGRhdGEgZm9ybWF0IGlzIGNvbXBsZXRlbHkgYW1iaWd1b3VzLCB0aGVuIHRoZSByZWNl aXZlciB3b24ndCBiZSBhYmxlIHRvICJwbGF5IiBpdD8NCg0KQWRkaXNvbg0KDQo+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFNMSU0gW21haWx0bzpzbGltLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBHdW5uYXIgSGVsbHN0csO2bQ0KPiBTZW50OiBUdWVzZGF5LCBO b3ZlbWJlciAwMywgMjAxNSAxMjozMSBQTQ0KPiBUbzogc2xpbUBpZXRmLm9yZw0KPiBTdWJqZWN0 OiBSZTogW1NsaW1dIFByaW1hcnkgbGFuZ3VhZ2UgdGFncyAod2FzICJSZTogZHJhZnQtdG9ta2lu c29uDQo+IGNvbW1lbnRzIikNCj4gDQo+IERlbiAyMDE1LTExLTAzIGtsLiAyMDo1NSwgc2tyZXYg RG91ZyBFd2VsbDoNCj4gPiBBbiBhbHRlcm5hdGl2ZSBhcHByb2FjaCwgd2hpY2ggSSBiZWxpZXZl IGhhcyBiZWVuIGRpc2N1c3NlZCBoZXJlDQo+ID4gYmVmb3JlLCB3b3VsZCBiZSB0byBlbmNvZGUg bW9kYWxpdHkgaW4gaXRzIG93biBzZXBhcmF0ZSBhdHRyaWJ1dGUsDQo+ID4gcmF0aGVyIHRoYW4g dHJ5aW5nIHRvIGZpdCBsYW5ndWFnZSBpZGVudGlmaWNhdGlvbiBhbmQgbW9kYWxpdHkgaW50byB0 aGUgc2FtZQ0KPiB0YWcuDQo+IFRoYXQgaXMgY2xvc2UgdG8gd2hhdCB3ZSBoYXZlIG5vdyBpbiB0 aGUgcmVhbC10aW1lIHNwZWMsIGJ5IHRhY2tpbmcgb24gdGhlDQo+IGxhbmd1YWdlIHRhZyB0byB0 aGUgbWVkaWEgc3BlY2lmaWNhdGlvbiBpbiBTRFAuDQo+IEJ1dCBpdCBoYXMgc29tZSBkcmF3YmFj a3MsIGluIHRoYXQgbWVkaWEgdHlwZXMgYXJlIG5vdCBzdHJpY3Qgb24gd2hhdA0KPiBtb2RhbGl0 aWVzIHRoZXkgY2FycnksIHdpdGggYWxsIHRoZXNlIGFwcGxpY2F0aW9uIGFuZCBtZXNzYWdlIGV0 YyBtZWRpYSB0eXBlcw0KPiBub3QgcmV2ZWFsaW5nIGNsZWFybHkgd2hhdCB0aGV5IGNvbnRhaW4u DQo+IEFuZCBJIHRoaW5rLCB0aGUgc2FtZSB3aXRoIENvbnRlbnQtVHlwZSBvbiB0aGUgbWFpbCBz aWRlLg0KPiANCj4gU28sIGZvciB0aGUgaHVtaW50bGFuZyBhdHRyaWJ1dGUgb25lIHNvbHV0aW9u IHdvdWxkIGJlIHRvIGhhdmUgYSBwYXJhbWV0ZXINCj4gZm9yIG1vZGFsaXR5Lg0KPiANCj4gQnV0 IGl0IGlzIGEgZ2VuZXJhbCBwcm9ibGVtIHRoYXQgc2hvdWxkIGJlc3QgYmUgc29sdmVkIGF0IGl0 cyBzb3VyY2UgLSBpbiBCQ1AtNDcuDQo+IFNwb2tlbiBhbmQgd3JpdHRlbiBsYW5ndWFnZXMgYXJl IG5vdCBpZGVudGljYWwsIHdlIGp1c3QgYmVsaWV2ZSBzbyBhdCBmaXJzdA0KPiB0aG91Z2h0Lg0K PiBUaGlzIHByb2JsZW0gbWFrZXMgbGFuZ3VhZ2UgdGFncyBhbWJpZ291cyBpbiBtYW55IGFwcGxp Y2F0aW9ucy4gVXNlcnMNCj4gdXN1YWxseSB3YW50IHRvIGtub3cgaWYgdGhleSBhcmUgc3VwcG9z ZWQgdG8gcmVhZCBvciBsaXN0ZW4uDQo+IA0KPiBHdW5uYXINCj4gDQo+IA0KPiANCj4gDQo+IA0K PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBTTElN IG1haWxpbmcgbGlzdA0KPiBTTElNQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc2xpbQ0K From nobody Tue Nov 3 13:11:54 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 107551A89FA for ; Tue, 3 Nov 2015 13:11:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 3-1Y168BPAr2 for ; Tue, 3 Nov 2015 13:11:51 -0800 (PST) Received: from p3plwbeout03-01.prod.phx3.secureserver.net (p3plsmtp03-01-2.prod.phx3.secureserver.net [72.167.218.213]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C72F91A89F9 for ; Tue, 3 Nov 2015 13:11:51 -0800 (PST) Received: from localhost ([72.167.218.245]) by p3plwbeout03-01.prod.phx3.secureserver.net with bizsmtp id d9Br1r0015JG3DC019BrVa; Tue, 03 Nov 2015 14:11:51 -0700 X-SID: d9Br1r0015JG3DC01 Received: (qmail 23531 invoked by uid 99); 3 Nov 2015 21:11:51 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 208.51.143.189 User-Agent: Workspace Webmail 5.15.9 Message-Id: <20151103141150.665a7a7059d7ee80bb4d670165c8327d.d744f8874b.wbe@email03.secureserver.net> From: "Doug Ewell" To: "=?UTF-8?Q?Gunnar=5FHellstr=C3=B6m?=" , slim@ietf.org Date: Tue, 03 Nov 2015 14:11:50 -0700 Mime-Version: 1.0 Archived-At: Subject: Re: [Slim] Primary language tags (was "Re: draft-tomkinson comments") X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 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, 03 Nov 2015 21:11:53 -0000 Gunnar Hellstr=C3=B6m wrote:=0A=0A> But it is a general problem that should= best be solved at its source -=0A> in BCP-47. Spoken and written languages= are not identical, we just=0A> believe so at first thought.=0A=0ALanguage = tags aren't generally meant to show what is or is not=0Aidentical. They're = meant to assist searching, filtering, and selection=0Aof tools like spell-c= heckers and translation engines. Those aren't=0Ausually sensitive to distin= ctions between spoken and written forms.=0A=0A> This problem makes language= tags ambigous in many applications. Users=0A> usually want to know if they= are supposed to read or listen.=0A=0AMost language-tagged content is self-= evident as to its modality. An=0Aaudio recording, for example, is obviously= meant to be listened to. A=0Atext file is meant to be read, or otherwise p= rocessed as text. Language=0Atags don't try to state the obvious here.=0A= =0AI suggest joining the ietf-languages list if you feel there are=0Ashortc= omings in BCP 47 that need to be addressed, either by registering=0Anew var= iants or by revising the specification.=0A=0A--=0ADoug Ewell | http://ewell= ic.org | Thornton, CO =F0=9F=87=BA=F0=9F=87=B8=0A From nobody Tue Nov 3 20:19:12 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AF8F1A913D for ; Tue, 3 Nov 2015 20:19:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 S1TDBivZEPnH for ; Tue, 3 Nov 2015 20:19:07 -0800 (PST) Received: from bin-vsp-out-02.atm.binero.net (vsp-unauthed02.binero.net [195.74.38.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A5FB1A9131 for ; Tue, 3 Nov 2015 20:19:05 -0800 (PST) X-Halon-ID: 2831f886-82ab-11e5-bda9-005056917f90 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [10.101.1.132] (unknown [88.131.62.38]) by bin-vsp-out-02.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Wed, 4 Nov 2015 05:18:52 +0100 (CET) To: slim@ietf.org References: <563818F9.2060709@alum.mit.edu> <56388C4D.4090808@omnitor.se> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <56398719.7030205@omnitor.se> Date: Wed, 4 Nov 2015 05:18:33 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Slim] Handling the complex multi-media cases X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 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, 04 Nov 2015 04:19:10 -0000 Den 2015-11-03 kl. 21:43, skrev Bernard Aboba: > On Nov 3, 2015, at 05:28, Gunnar Hellström wrote: >> 4. Last resort indication. >> A hearing user has text capability but want to use that as last resort. >> With current hunintlang specification, there is no way to describe preference level between modalities and no way to describe absolute preference. >> Result: An answering service will have no guidance to which is the preferred modality and may select to use the modality that is the callers last resort even if the preferred alternative is available. >> A practical case can be a sign language user with a small mobile terminal that has some inconvenient means for texting, but sign language will be strongly preferred. In order to not miss any calls, the indication of text as last resort would be desirable. >> Possible solution: coding of an absolute preference: hi, med, lo together with the tag. >> Result: Need for absolute preference indication. > [BA] The user offers to send and receive ASL in the video m-line, as well as to receive (and send?) RTT on the text m-line. Is the concern that the Answerer will accept both due to lack of preference when ASL is enough? Since video can be congested, having RTT as a backup doesn't seem so bad, even if it is not used by agreement between the parties. Or is the concern that the Answerer could do video/ASL but will reject that while accepting RTT, for some reason? Yes, the last explanation. Both modaities are not needed ( even if good to have). So if an answerer scans the indications and find ASL and RTT there and has the capability to select between ASL only and RTT only then the preference indication should guide to answer with ASL. > >> 5. Directional capabilities in different modalities >> A hard-of-hearing user strongly prefers to talk and get text back. Getting spoken language input is appreciated. >> This can be indicated by spoken language two-ways in audio, and reception of language in text. >> But there is nothing in current coding that says that the text path is important. The answering part may see it as an alternative, just as case 3. >> There is a way to indicate that the call shall fail if a language is not met, but that may be too drastic for this user. It may be important to be able to connect and just say something, or use residual hearing to get something back when the voice is familiar. >> Possible solution: coding of an absolute preference: hi, med, lo together with the tag could solve this case if used together with the directional indications. >> Another solution would be to indicate required grouping of media. But that seems more complex. >> Result: Need for absolute preference indication. > [BA] Is the concern that an Answerer capable of sending RTT will decline to do so, since a bi-directional audio m-line has been successfully negotiated? If the Answerer accepts bi-directional audio and RTT is that an issue? It seems that after the call is set up the Offerer could indicate the preference for receiving both audio and RTT out of band. Yes, the user in the example will not be well served with a plain audio call. Receiving RTT is essential. Receiving speech is not equally important, but good. So some indication of the minimum reqiured combination of modalities and directions seems to be needed. The preference for reception of text should be sufficient. It is likely best for this case that the indication for spoken modality is divided in one high priority for spoken output, but a medium preference for spoken reception. By that, the answering part can scan the indications and find the minimum set, and also answer in the best modality. In earlier discussions, I have leaned towards a need for a specific service preference indication for captioned telephony for this case. But I think this indication would be sufficient, and enable a direct connection with a person who is willing to type and listen. That should be checked. > > 7. Person with speech disabilities who prefer speech-to-speech service. >> A person who speaks in a way that is hard to understand, may be used to have support of a speech-to-speech relay service that adds clear speech when needed for the understanding. >> Calls with close friends and family might be possible without the relay service. >> Text can be used as a fall-back. >> This user would indicate preference for receiving spoken language in audio. >> Text output can be indicated but this user might want to use that as last resort. >> But there is no current coding for vague or unarticulated speech or other needs for a speech-to-speech service. >> A possibility could be to indicate no preference for spoken language out, a coding of proposed assisting service and an indication of text output on a low absolute level. >> Result: Need of service indication, and absolute level of preference indication > [BA] How is the decision to invoke a speech-speech relay made? > > If the Offerer offers to receive audio and but send (and receive?) RTT, and the Answerer accepts both m-lines, would this avoid invoking a speech-speech relay? > > Bi-directional audio could be offered along with sending (and receiving?) RTT. If the Answerer accepts both, the offerer could request out of band that the Answerer use RTT if audio cannot be understood (would speech-speech relay be invoked at that point?) If this is a good choice that works for the user, yes. For some it would work, for others not. So we need to specify indications suitable for both requiring a speech-to-speech service in that case and for accepting the spoken + RTT combination. > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim From nobody Tue Nov 3 21:27:00 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05BDB1ACD33 for ; Tue, 3 Nov 2015 21:26:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.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, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 emwVu6L0HLwf for ; Tue, 3 Nov 2015 21:26:58 -0800 (PST) Received: from mail-yk0-x22f.google.com (mail-yk0-x22f.google.com [IPv6:2607:f8b0:4002:c07::22f]) (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 C6E8B1ACD32 for ; Tue, 3 Nov 2015 21:26:57 -0800 (PST) Received: by ykek133 with SMTP id k133so54946452yke.2 for ; Tue, 03 Nov 2015 21:26:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ePTRzvP8T5G2DKqK91TyGfo/a5E/+6f+vgywVTGAv28=; b=S1o6ihwrSyWw1lb25Q7TU3w5FuhARi/uNf2JP2EYsMs0h+qOoprORYSuHk4t3e7PI5 QPUw7Jk6Iv+1Fa0yiec+zZoTv7p65cByalGluCeGPQD67Tt7qTu5ixPB8mbpVy8m19KD 3OC0tohwl6JeqcLUkuF92k7mdE8eXQfNKFfV85GELNKgyQMrBrrhFRczaKH527nJy5CH 6jfxMzulCeowURt84XVN/+IBuIa3aDh6c0Bt2HS0ie0Yk5T2AfH0LzfhO9B0oZ7W4e3A N/aGdfWTIkcGptXCC9tStAmIeD7RNLwQzFyL/iRpt1JB8TubuZgLEUaFwz+c7XNE73Mp pKNw== X-Received: by 10.13.250.69 with SMTP id k66mr23362450ywf.107.1446614817107; Tue, 03 Nov 2015 21:26:57 -0800 (PST) Received: from [10.0.1.2] (c-73-49-202-70.hsd1.fl.comcast.net. [73.49.202.70]) by smtp.gmail.com with ESMTPSA id j187sm18981507ywd.20.2015.11.03.21.26.55 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Nov 2015 21:26:55 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPad Mail (13B143) In-Reply-To: <56398719.7030205@omnitor.se> Date: Wed, 4 Nov 2015 00:26:55 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <21767FCE-C1BD-4C42-A07E-16BC81586073@gmail.com> References: <563818F9.2060709@alum.mit.edu> <56388C4D.4090808@omnitor.se> <56398719.7030205@omnitor.se> To: =?utf-8?Q?Gunnar_Hellstr=C3=B6m?= Archived-At: Cc: slim@ietf.org Subject: Re: [Slim] Handling the complex multi-media cases X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 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, 04 Nov 2015 05:26:59 -0000 On Nov 3, 2015, at 23:18, Gunnar Hellstr=C3=B6m wrote: >>>=20 >> [BA] The user offers to send and receive ASL in the video m-line, as well= as to receive (and send?) RTT on the text m-line. Is the concern that the A= nswerer will accept both due to lack of preference when ASL is enough? Since= video can be congested, having RTT as a backup doesn't seem so bad, even if= it is not used by agreement between the parties. Or is the concern that the= Answerer could do video/ASL but will reject that while accepting RTT, for s= ome reason? > Yes, the last explanation. Both modaities are not needed ( even if goo= d to have). So if an answerer scans the indications and find ASL and RTT the= re and has the capability to select between ASL only and RTT only then the p= reference indication should guide to answer with ASL. [BA] RFC 3264 Section 5.1 says: "If multiple media streams of different types are present, it means that the= offerer wishes to use those streams at the same time. A typical case is an a= udio and a video stream as part of a videoconference." Based on the above, an Offer including both video/ASL and text/English means= that the Offerer wants to use both. The Answerer may not be video or RTT ca= pable or may decline one or both m-lines even if it is capable, but it canno= t conclude that the Offerer considers one of the streams "enough" based on t= he media type or order of the m-lines. >> [BA] Is the concern that an Answerer capable of sending RTT will decline t= o do so, since a bi-directional audio m-line has been successfully negotiate= d? If the Answerer accepts bi-directional audio and RTT is that an issue? It= seems that after the call is set up the Offerer could indicate the preferen= ce for receiving both audio and RTT out of band. > Yes, the user in the example will not be well served with a plain audi= o call. Receiving RTT is essential. Receiving speech is not equally importan= t, but good. [BA] Since Offering both is an indication that both audio and RTT are desire= d, based on RFC 3264, the Answerer cannot conclude that the Offerer consider= ed audio alone sufficient.= From nobody Tue Nov 3 21:30:02 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F081B1ACD44 for ; Tue, 3 Nov 2015 21:30:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 lcIb-PQDFGVF for ; Tue, 3 Nov 2015 21:29:59 -0800 (PST) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0677.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::677]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF9281ACD4D for ; Tue, 3 Nov 2015 21:29:55 -0800 (PST) Received: from HE1PR04MB1033.eurprd04.prod.outlook.com (10.162.26.142) by HE1PR04MB1034.eurprd04.prod.outlook.com (10.162.26.143) with Microsoft SMTP Server (TLS) id 15.1.312.18; Wed, 4 Nov 2015 05:29:33 +0000 Received: from HE1PR04MB1033.eurprd04.prod.outlook.com ([10.162.26.142]) by HE1PR04MB1033.eurprd04.prod.outlook.com ([10.162.26.142]) with mapi id 15.01.0312.014; Wed, 4 Nov 2015 05:29:33 +0000 From: Natasha Rooney To: "slim@ietf.org" Thread-Topic: IETF94 Minutes Thread-Index: AQHRFsHJc3X18uISkkm0TG8AbhRL4g== Date: Wed, 4 Nov 2015 05:29:33 +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.2098) authentication-results: spf=none (sender IP is ) smtp.mailfrom=nrooney@gsma.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [133.93.38.240] x-microsoft-exchange-diagnostics: 1; HE1PR04MB1034; 5:KhGmvnbOv4UZh1vt9NMdfdBh2DRhNjUdDeY3wa/Z6o3ut4tE21LeIbt4m1VYAKhL0saEo2m1EbmUSG1g9qFeSbNE6fSSkAV4q8bwv5AUcK2mTMjOOqD4ut+sNcXkmL7Oq7i5Euimsw8Pt0LXShg6+w==; 24:Yd/gi2KQompFmF4OEj5aXP6Wm1tBzqdq+QIqYJaMCRXlBLYvAHFVMdt1YPjhWvGbTRe6vcL692W55yXg7AW2z7v7bN7QfofFfoJ5go2USaU=; 20:kzSLSY0rZmOnj2QyTp3K5X/h+e4jJZdBroJwju2YxaWRAPbVE5kOKoLQzKgslgWS0I25ZzU/34t+dhioZemWSQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR04MB1034; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(260367931017790)(161861816099999); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(8121501046)(5005006)(10201501046)(3002001); SRVR:HE1PR04MB1034; BCL:0; PCL:0; RULEID:; SRVR:HE1PR04MB1034; x-forefront-prvs: 0750463DC9 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(189002)(66654002)(199003)(77096005)(5007970100001)(5002640100001)(11100500001)(101416001)(106116001)(16236675004)(86362001)(50226001)(105586002)(2501003)(2351001)(5890100001)(33656002)(106356001)(5008740100001)(36756003)(5004730100002)(82746002)(66066001)(102836002)(10400500002)(189998001)(19580395003)(81156007)(110136002)(19580405001)(19617315012)(15975445007)(107886002)(5001960100002)(83716003)(40100003)(92566002)(87936001)(97736004)(2900100001)(229853001)(450100001)(57306001)(50986999)(122556002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR04MB1034; H:HE1PR04MB1033.eurprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: gsma.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_E717067138434A24A586CAB88DD9CFA9gsmacom_" MIME-Version: 1.0 X-OriginatorOrg: gsma.com X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Nov 2015 05:29:33.1633 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72a4ff82-fec3-469d-aafb-ac8276216699 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR04MB1034 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: HE1PR04MB1033.eurprd04.prod.outlook.com X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-originalclientipaddress: 133.93.38.240 X-MS-Exchange-CrossPremises-avstamp-service: 1.0 X-MS-Exchange-CrossPremises-disclaimer-hash: 78ca8040c6722e32c2f5b0a45bf37e74b9409d645a53be96aa19958e0cee0f00 X-MS-Exchange-CrossPremises-antispam-scancontext: DIR:Originating; SFV:NSPM; SKIP:0; X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-OrganizationHeadersPreserved: HE1PR04MB1034.eurprd04.prod.outlook.com Archived-At: Subject: [Slim] IETF94 Minutes X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 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, 04 Nov 2015 05:30:01 -0000 --_000_E717067138434A24A586CAB88DD9CFA9gsmacom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Minutes from our IETF94 meeting are up: https://tools.ietf.org/wg/slim/minutes Thank-you to our presenters: Gunnar, Nik and Randall, and a special thanks = to Brian Rosen for being our scribe! If you have issues with the minutes please let us know. Many thanks! Natasha Natasha Rooney | Technologist, Web and Internet, W3C & IETF | GSMA | nroone= y@gsma.com | +44 (0) 7730 219 765 | @thisNatasha |= Skype: nrooney@gsm.org Tokyo, Japan 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_E717067138434A24A586CAB88DD9CFA9gsmacom_ Content-Type: text/html; charset="us-ascii" Content-ID: <537686A4EB85DF409B759E31BA6B3A68@eurprd04.prod.outlook.com> Content-Transfer-Encoding: quoted-printable Minutes from our IETF94 meeting are up:
https://tools= .ietf.org/wg/slim/minutes

Thank-you to our presenters: Gunnar, Nik and Randall, and a special thanks = to Brian Rosen for being our scribe!

If you have issues with the minutes please let us know.

Many thanks!

Natasha


Natasha Rooney | Technologist, Web and Internet, W3C & IETF | GSMA= | nrooney@gsma.com | +44 (0) 7730 219 765 | @thisNatasha | Skype= : nrooney@gsm.org&nb= sp;
Tokyo, Japan


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_E717067138434A24A586CAB88DD9CFA9gsmacom_-- From nobody Tue Nov 3 21:32:33 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDA641ACD69 for ; Tue, 3 Nov 2015 21:32:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 uF0vQ-y2l8fi for ; Tue, 3 Nov 2015 21:32:28 -0800 (PST) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0639.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::639]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E84F31ACD60 for ; Tue, 3 Nov 2015 21:32:27 -0800 (PST) Received: from HE1PR04MB1033.eurprd04.prod.outlook.com (10.162.26.142) by HE1PR04MB1034.eurprd04.prod.outlook.com (10.162.26.143) with Microsoft SMTP Server (TLS) id 15.1.312.18; Wed, 4 Nov 2015 05:32:08 +0000 Received: from HE1PR04MB1033.eurprd04.prod.outlook.com ([10.162.26.142]) by HE1PR04MB1033.eurprd04.prod.outlook.com ([10.162.26.142]) with mapi id 15.01.0312.014; Wed, 4 Nov 2015 05:32:08 +0000 From: Natasha Rooney To: Nik Tomkinson Thread-Topic: Drafts to accepted WG Documents Thread-Index: AQHRFVfg3jFj8C/XNUKy9lG1JPCJ256InB0AgAA1RYCAAog2AA== Date: Wed, 4 Nov 2015 05:32:08 +0000 Message-ID: <9BB0C3E2-F511-44C8-A398-F86B698636FE@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.2098) authentication-results: spf=none (sender IP is ) smtp.mailfrom=nrooney@gsma.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [133.93.38.240] x-microsoft-exchange-diagnostics: 1; HE1PR04MB1034; 5:vZmNfiuQ30EYnBFC0uSKiZIVHZzqcXxxK9Vz7feH+WECEi1Fa9VwZ2fMVeMS5ZRszv0Ybi8kHgiloyiuD97rA0y/nHXHANuRnl2Ch5aTr1zKTkWlpivgn7ndXl+v2lpDeDYLs1bQaYP4jH/H+553pQ==; 24:V+RqKnt0CJV0akdAKoU67nVeHtnfdWQPGKanOzEuDWJtM9a2YJjJoHEdyGIm2G1XSnoY+5g1+2hSlQVo9dtC3kV+pLNBR4CQkuTaPCpFDvE=; 20:8VcuN+FS4jZ2Fy36WCQwTj3Qt3svoauzxtLEdtGK7K7QOWwXsCgPhSiEF5RgXKIAUxmsKPYlLAiE8kwMsW2gbg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR04MB1034; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(260367931017790)(161861816099999); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(8121501046)(5005006)(10201501046)(3002001); SRVR:HE1PR04MB1034; BCL:0; PCL:0; RULEID:; SRVR:HE1PR04MB1034; x-forefront-prvs: 0750463DC9 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(189002)(479174004)(24454002)(377454003)(199003)(76176999)(77096005)(5007970100001)(5002640100001)(11100500001)(101416001)(106116001)(16236675004)(86362001)(50226001)(105586002)(5890100001)(33656002)(106356001)(5008740100001)(36756003)(5004730100002)(82746002)(66066001)(102836002)(10400500002)(189998001)(19580395003)(81156007)(110136002)(19580405001)(19617315012)(15975445007)(5001960100002)(83716003)(40100003)(92566002)(2950100001)(87936001)(97736004)(2900100001)(57306001)(50986999)(122556002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR04MB1034; H:HE1PR04MB1033.eurprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: gsma.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_9BB0C3E2F51144C8A398F86B698636FEgsmacom_" MIME-Version: 1.0 X-OriginatorOrg: gsma.com X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Nov 2015 05:32:08.8039 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72a4ff82-fec3-469d-aafb-ac8276216699 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR04MB1034 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: HE1PR04MB1033.eurprd04.prod.outlook.com X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-originalclientipaddress: 133.93.38.240 X-MS-Exchange-CrossPremises-avstamp-service: 1.0 X-MS-Exchange-CrossPremises-disclaimer-hash: 78ca8040c6722e32c2f5b0a45bf37e74b9409d645a53be96aa19958e0cee0f00 X-MS-Exchange-CrossPremises-antispam-scancontext: DIR:Originating; SFV:NSPM; SKIP:0; X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-OrganizationHeadersPreserved: HE1PR04MB1034.eurprd04.prod.outlook.com Archived-At: Cc: "slim@ietf.org" , Nathaniel Borenstein , "randy@qti.qualcomm.com" , Randall Gellens Subject: Re: [Slim] Drafts to accepted WG Documents X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 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, 04 Nov 2015 05:32:31 -0000 --_000_9BB0C3E2F51144C8A398F86B698636FEgsmacom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All docs are now WG Documents: https://datatracker.ietf.org/wg/slim/documents/ Thanks guys for submitting quickly! Natasha Natasha Rooney | Technologist, Web and Internet, W3C & IETF | GSMA | nroone= y@gsma.com | +44 (0) 7730 219 765 | @thisNatasha |= Skype: nrooney@gsm.org Tokyo, Japan On Nov 2, 2015, at 11:52 PM, Nik Tomkinson > wrote: I have just submitted draft-ietf-slim-multilangcontent-00 (and I think the = rename makes it a working group document). It is pending approval. This version takes into account all the agreed comments from Addison but no= thing that is still under discussion or anything from today's (Monday's) se= ssion questions as some of this needs some thought and/or testing. Nik. On 2 November 2015 at 11:41, Randall Gellens > wrote: Done, thank you. At 10:18 AM +0000 11/2/15, Natasha Rooney wrote: Nik & Nathaniel, Randall, Your drafts have been accepted as work items for the group, please submit = these as WG Documents, Bernard and I will approve. We will take the use cases discussion to the list after I release the minu= tes tomorrow. Thanks all! Natasha Natasha Rooney | Technologist, Web and Internet, W3C & IETF | GSMA | > nrooney@gsma.com | +44 (0) 7730 219 765= | @thisNatasha | Skype: >nr= ooney@gsm.org Tokyo, Japan This email and its attachments are intended for the above named only and m= ay be confidential. If they have come to you in error you must take no acti= on based on them, nor must you copy or show them to anyone; please reply to= this email or call +44 207 356 0600 and high= light the error. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Police Begin Campaign to Run Down Jaywalkers --Newspaper headline -- ----------------------------------------------------------------- Multiple Language Content Type Internet Draft: http://d= atatracker.ietf.org/doc/draft-tomkinson-slim-multilangcontent/ ----------------------------------------------------------------- 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_9BB0C3E2F51144C8A398F86B698636FEgsmacom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable All docs are now WG Documents:
https://datatracker.ietf.org/wg/slim/documents/

Thanks guys for submitting quickly!

Natasha


Natasha Rooney | Technologist, Web and Internet, W3C & IETF | GSMA= | nrooney@gsma.com | +44 (0) 7730 219 765 | @thisNatasha | Skype= : nrooney@gsm.org&nb= sp;
Tokyo, Japan


On Nov 2, 2015, at 11:52 PM, Nik Tomkinson <rfc.nik.tomkinson@gmail.com> wrote:

I have just submitted draft-ietf-slim-mult= ilangcontent-00 (and I think the rename makes it a working group document).

It is pending approval.

This version takes into account all the agreed comments fro= m Addison but nothing that is still under discussion or anything from today= 's (Monday's) session questions as some of this needs some thought and/or t= esting.

Nik.

On 2 November 2015 at 11:41, Randall Gellens <rg+ietf@randy.pensive.org> wrote:
Done, thank you.

At 10:18 AM +0000 11/2/15, Natasha Rooney wrote:
 Nik & Nathaniel, Randall,

 Your drafts have been accepted as work items for the group, please su= bmit these as WG Documents, Bernard and I will approve.

 We will take the use cases discussion to the list after I release the= minutes tomorrow.

 Thanks all!

 Natasha


 Natasha Rooney | Technologist, Web and Internet, W3C & IET= F | GSMA | <mailto:nrooney@gsma.com> nrooney@gs= ma.com | +44 (0) 7730 219 765 | @thisNatasha | Skype: <mailto:nrooney@gsm.org>= ;nrooney@gs= m.org  Tokyo, Japan


 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 rep= ly to this email or call +44 207 356 0600 and highlight the error.



--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak= for myself only
-------------- Randomly selected tag: ---------------
Police Begin Campaign to Run Down Jaywalkers
--Newspaper headline



-- 
-----------------------------------------------------------------
Multiple Language Content Type Internet Draft:
http://da= tatracker.ietf.org/doc/draft-tomkinson-slim-multilangcontent/
-----------------------------------------------------------------<=
br class=3D"">

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_9BB0C3E2F51144C8A398F86B698636FEgsmacom_-- From nobody Wed Nov 4 07:54:16 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A654D1B3220 for ; Wed, 4 Nov 2015 07:54:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 gtuSD6J3romT for ; Wed, 4 Nov 2015 07:54:14 -0800 (PST) Received: from resqmta-po-01v.sys.comcast.net (resqmta-po-01v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:160]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1E2A1B321F for ; Wed, 4 Nov 2015 07:54:14 -0800 (PST) Received: from resomta-po-12v.sys.comcast.net ([96.114.154.236]) by resqmta-po-01v.sys.comcast.net with comcast id dTu11r00456HXL001TuEuN; Wed, 04 Nov 2015 15:54:14 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-po-12v.sys.comcast.net with comcast id dTuD1r00L3KdFy101TuDp3; Wed, 04 Nov 2015 15:54:14 +0000 To: slim@ietf.org References: <563818F9.2060709@alum.mit.edu> <56388C4D.4090808@omnitor.se> <56398719.7030205@omnitor.se> <21767FCE-C1BD-4C42-A07E-16BC81586073@gmail.com> From: Paul Kyzivat Message-ID: <563A2A24.2020102@alum.mit.edu> Date: Wed, 4 Nov 2015 10:54:12 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <21767FCE-C1BD-4C42-A07E-16BC81586073@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1446652454; bh=PwLICxrEtnphV7AgFMOFI9KBjWTtFW7ZeF2W5zRAzW4=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=VN7opxZ2eshK9sZqTSJWo354vuIpeF4gnmM+oEA8xx8Ig5sd11WmUZv1wBRcAcP21 DY0jPf+mpscIPb3vrJyG/3cfRDZEaAXZ7h7OLDHlBrNRFhX88mKkQmgd2KeyIx6eim qRm/XghlSWHkml/rJnUi/ZW+r+IHpxBEqgL6/eEkYQF01ap+JpvptZIVUUyUNbztw3 XCTmeAc7dycdfKlL9IXXWahuosBH0YvFjObjpVFiCblXPVq2hoUlNlBxE18LZAoh07 ifqWsW1W0LAG4pfwPNmU7B6BvSG1c4JHG8eXWGeMLVJAgKqp9cJcOMRofbV4XSz4Hc sfgiqpUjQWV0g== Archived-At: Subject: Re: [Slim] Handling the complex multi-media cases X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 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, 04 Nov 2015 15:54:15 -0000 On 11/4/15 12:26 AM, Bernard Aboba wrote: >>> [BA] Is the concern that an Answerer capable of sending RTT will decline to do so, since a bi-directional audio m-line has been successfully negotiated? If the Answerer accepts bi-directional audio and RTT is that an issue? It seems that after the call is set up the Offerer could indicate the preference for receiving both audio and RTT out of band. >> Yes, the user in the example will not be well served with a plain audio call. Receiving RTT is essential. Receiving speech is not equally important, but good. > > [BA] Since Offering both is an indication that both audio and RTT are desired, based on RFC 3264, the Answerer cannot conclude that the Offerer considered audio alone sufficient. Well... Consider the analogy to an offer of audio and video. Typically there will be a reasonable expectation that you might get only audio. That will be true if the called device only supports audio, but it will also occur if the called user chooses not to use video. It is likely to be different for audio + RTT? Of course, it may be contextual. People who anticipate receiving calls from deaf people may behave differently from those who don't. Also, if the initial call doesn't yield the media I want, I can always retry with a reinvite. Then the two ends will have had a chance to assess the situation, and may offer/accept modalities that didn't get negotiated the first time. Thanks, Paul From nobody Wed Nov 4 09:15:36 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70C481B3724 for ; Wed, 4 Nov 2015 09:15:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 GUQKOzbeY6OF for ; Wed, 4 Nov 2015 09:15:34 -0800 (PST) Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002: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 A6D721B36F5 for ; Wed, 4 Nov 2015 09:15:33 -0800 (PST) Received: by ykek133 with SMTP id k133so83878818yke.2 for ; Wed, 04 Nov 2015 09:15:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Mf3mV3YoOMYyATrRkxhetVtHzodBP4i52QDcJ7zo9q8=; b=ChkHtEGZjhL25AiMaq6/K4uLGOWExUciJeetjFQI7gzeCgsjxUVT0jOYUIgfuuvPxQ orByYdonLF0gExY7lVWXEIuJcGQvqutRIIrKdVilPdbY2FTXcI3cg+KbMLB5rCgKLE9o pobge84C+25ilTxODAqAm4W5rSvbyAmwEu2tDW1DjO0nN0aZqh74jdWl8zSSi7+maAaS IUDYC1Z5VIiT0uqssdPH00J1V7zCtbj1GxHG7U4xBGjC1ctN/W4Rhws5PHEeWUb33Qzw eQFbXFg9soUvW03hvSb9rulAwNEObi7rzBoQB6QhkOYcrSIwyKj29zSdKLGApdjaZrU6 A0Rw== X-Received: by 10.13.222.131 with SMTP id h125mr2423583ywe.185.1446657332770; Wed, 04 Nov 2015 09:15:32 -0800 (PST) Received: from [10.0.1.10] (c-73-49-202-70.hsd1.fl.comcast.net. [73.49.202.70]) by smtp.gmail.com with ESMTPSA id l68sm1360544ywd.3.2015.11.04.09.15.31 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Nov 2015 09:15:31 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPhone Mail (13B143) In-Reply-To: <563A2A24.2020102@alum.mit.edu> Date: Wed, 4 Nov 2015 12:15:30 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <44BE7894-2944-42FE-A136-ADB629D49143@gmail.com> References: <563818F9.2060709@alum.mit.edu> <56388C4D.4090808@omnitor.se> <56398719.7030205@omnitor.se> <21767FCE-C1BD-4C42-A07E-16BC81586073@gmail.com> <563A2A24.2020102@alum.mit.edu> To: Paul Kyzivat Archived-At: Cc: slim@ietf.org Subject: Re: [Slim] Handling the complex multi-media cases X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 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, 04 Nov 2015 17:15:35 -0000 On Nov 4, 2015, at 10:54 AM, Paul Kyzivat wrote: >=20 > On 11/4/15 12:26 AM, Bernard Aboba wrote: >>=20 >> [BA] Since Offering both is an indication that both audio and RTT are des= ired, based on RFC 3264, the Answerer cannot conclude that the Offerer consi= dered audio alone sufficient. >=20 > Well... >=20 > Consider the analogy to an offer of audio and video. Typically there will b= e a reasonable expectation that you might get only audio. That will be true i= f the called device only supports audio, but it will also occur if the calle= d user chooses not to use video. >=20 > It is likely to be different for audio + RTT? [BA] It seems very analogous to me - an m-line of video/ASL might be decline= d by an Answerer supporting ASL who chooses not to use video - even though t= hey can support it. In such a situation though, would "priority" make a difference? > Of course, it may be contextual. People who anticipate receiving calls fro= m deaf people may behave differently from those who don't. [BA] Yes - and for such a person, a question is whether accepting all m-line= s that can be supported could actually cause a problem. > Also, if the initial call doesn't yield the media I want, I can always ret= ry with a reinvite. Then the two ends will have had a chance to assess the s= ituation, and may offer/accept modalities that didn't get negotiated the fir= st time. [BA] Right. This may be particularly relevant when a non-disabled person cal= ls someone who is disabled. We probably should look at those use cases as we= ll.= From nobody Wed Nov 4 20:09:38 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A8DF1A9112 for ; Wed, 4 Nov 2015 20:09:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 z3qCAPbEY_PF for ; Wed, 4 Nov 2015 20:09:36 -0800 (PST) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (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 D9B191A90B1 for ; Wed, 4 Nov 2015 20:09:35 -0800 (PST) Received: by igvi2 with SMTP id i2so3422748igv.0 for ; Wed, 04 Nov 2015 20:09:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=vKCHVT+EHVqtws1HbhVL/qIo0b6eOKZjMVtL78oWeqs=; b=eMDhOCpxPVgBTfkP95FUIjCzPbECxHho8i/4RECvGl7dnW5rGc8TYGsM/LjT2niZBo uA4Zae+wXCUbvetin4oeuUpNmHTbalkz/FiuvQwXYCWPGuly0Es5tvXcvfjUPHMiVjGl k3Xbd0EddzZxDdopigO7oJQHMbphUHu4ti8hwg1Q97VJtMM9cfi6zG6zYu9xztztxI8L YCBMtxXToeszMQyMGdDI9cnf+PZS+4z0FJPG5hHG2QBojCh0/9PJLWvawUf/syTEFKMd EGRZ9HXRekYgijLB1a2eXOWMpGxBQClJ6lasS0GIdlb89IL2IXKNVKXAiaQNLi57IzSr Ef0g== MIME-Version: 1.0 X-Received: by 10.50.43.131 with SMTP id w3mr703828igl.33.1446696575204; Wed, 04 Nov 2015 20:09:35 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.107.181.202 with HTTP; Wed, 4 Nov 2015 20:09:35 -0800 (PST) In-Reply-To: References: Date: Thu, 5 Nov 2015 05:09:35 +0100 X-Google-Sender-Auth: jMDGd9Xh7STo8XM2sOPQ-IjY6OE Message-ID: From: Barry Leiba To: Natasha Rooney Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "slim@ietf.org" Subject: Re: [Slim] IETF94 Minutes X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 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, 05 Nov 2015 04:09:37 -0000 Thank you for getting the minutes posted quickly! Barry On Wed, Nov 4, 2015 at 6:29 AM, Natasha Rooney wrote: > Minutes from our IETF94 meeting are up: > https://tools.ietf.org/wg/slim/minutes > > Thank-you to our presenters: Gunnar, Nik and Randall, and a special thanks > to Brian Rosen for being our scribe! > > If you have issues with the minutes please let us know. > > Many thanks! > > Natasha > > > Natasha Rooney | Technologist, Web and Internet, W3C & IETF | GSMA | > nrooney@gsma.com | +44 (0) 7730 219 765 | @thisNatasha | Skype: > nrooney@gsm.org > Tokyo, Japan > > > 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 > From nobody Wed Nov 4 23:26:41 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C7FF1B309B for ; Wed, 4 Nov 2015 23:26:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 TdttrOk53Zif for ; Wed, 4 Nov 2015 23:26:37 -0800 (PST) Received: from bin-vsp-out-03.atm.binero.net (vsp-unauthed02.binero.net [195.74.38.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64E2D1B3B58 for ; Wed, 4 Nov 2015 23:26:37 -0800 (PST) X-Halon-ID: 878b75a7-838e-11e5-8d2f-0050569116f7 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [10.128.53.190] (unknown [194.70.169.190]) by bin-vsp-out-03.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Thu, 5 Nov 2015 08:26:28 +0100 (CET) To: slim@ietf.org References: <563818F9.2060709@alum.mit.edu> <56388C4D.4090808@omnitor.se> <56398719.7030205@omnitor.se> <21767FCE-C1BD-4C42-A07E-16BC81586073@gmail.com> <563A2A24.2020102@alum.mit.edu> <44BE7894-2944-42FE-A136-ADB629D49143@gmail.com> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <563B04A5.4040407@omnitor.se> Date: Thu, 5 Nov 2015 08:26:29 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <44BE7894-2944-42FE-A136-ADB629D49143@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Slim] Handling the complex multi-media cases X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 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, 05 Nov 2015 07:26:40 -0000 Den 2015-11-04 kl. 18:15, skrev Bernard Aboba: > On Nov 4, 2015, at 10:54 AM, Paul Kyzivat wrote: >> On 11/4/15 12:26 AM, Bernard Aboba wrote: >>> [BA] Since Offering both is an indication that both audio and RTT are desired, based on RFC 3264, the Answerer cannot conclude that the Offerer considered audio alone sufficient. >> Well... >> >> Consider the analogy to an offer of audio and video. Typically there will be a reasonable expectation that you might get only audio. That will be true if the called device only supports audio, but it will also occur if the called user chooses not to use video. >> >> It is likely to be different for audio + RTT? > [BA] It seems very analogous to me - an m-line of video/ASL might be declined by an Answerer supporting ASL who chooses not to use video - even though they can support it. > > In such a situation though, would "priority" make a difference? > >> Of course, it may be contextual. People who anticipate receiving calls from deaf people may behave differently from those who don't. > [BA] Yes - and for such a person, a question is whether accepting all m-lines that can be supported could actually cause a problem. [GH]Accepting m-lines is another thing than accepting languages. We want to express alternatives, across media. E.g. I prefer sign language but can accept to use text. Then it must be acceptable that the answerer only accepts one of them. It is acceptable then to deny the medium that will not be used for language, but that is not at all required. You can very well still connect and have good use of media even if it is not intended for language communication. []But we also need to be able to express required pairs or groups: E.g. I prefer talking and reading. A question is if we can define an implied rule for how such grouping is done. Is it sufficient to say that such groupings shall be expressed with directional humintlang attributes, and that the answerer is supposed to include at least one language in each direction with the highest priority possible? Or do we need to explicitly point out required pairs or groups? My numbered cases did not reveal any real need to use any coding for explicit pairing of language indications, but we might need to take more examples and test. > >> Also, if the initial call doesn't yield the media I want, I can always retry with a reinvite. Then the two ends will have had a chance to assess the situation, and may offer/accept modalities that didn't get negotiated the first time. > [BA] Right. This may be particularly relevant when a non-disabled person calls someone who is disabled. We probably should look at those use cases as well. > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim From nobody Thu Nov 5 07:47:03 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C544C1B2F39 for ; Thu, 5 Nov 2015 07:47:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 SV2_dU_esj5K for ; Thu, 5 Nov 2015 07:47:00 -0800 (PST) Received: from resqmta-ch2-03v.sys.comcast.net (resqmta-ch2-03v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:35]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D09B31B2AEC for ; Thu, 5 Nov 2015 07:47:00 -0800 (PST) Received: from resomta-ch2-01v.sys.comcast.net ([69.252.207.97]) by resqmta-ch2-03v.sys.comcast.net with comcast id drmu1r00226dK1R01rn0V1; Thu, 05 Nov 2015 15:47:00 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-01v.sys.comcast.net with comcast id drmz1r00Q3KdFy101rmz6X; Thu, 05 Nov 2015 15:47:00 +0000 To: slim@ietf.org References: <563818F9.2060709@alum.mit.edu> <56388C4D.4090808@omnitor.se> <56398719.7030205@omnitor.se> <21767FCE-C1BD-4C42-A07E-16BC81586073@gmail.com> <563A2A24.2020102@alum.mit.edu> <44BE7894-2944-42FE-A136-ADB629D49143@gmail.com> <563B04A5.4040407@omnitor.se> From: Paul Kyzivat Message-ID: <563B79F2.1010608@alum.mit.edu> Date: Thu, 5 Nov 2015 10:46:58 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <563B04A5.4040407@omnitor.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1446738420; bh=cI8Pk/tBNkOAVqrynFetZ+E5XE9J2BOzNI1Ba+ttHWg=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=XrWQH6vkYhuExWaw1gKOHB7IolYnAqoRKCnxCdKFhlGq2iyiFbflDAbiHfouk4RKD eohbA+3glzZD0XTu0O7nKYw6Ol74puK510wSamnStCSxJRpPmNFm6w568bs1mgkxEs 8qciyOz4M1NSGTiMZMRfiUF8LD/n8xA6uluyJdXZOfrOo/tFKY5Ciy+Uhoxlpdreca ty+Eyme/D3MmRDF7Zzhug+ORjGO4tLATXFAWtKlN5FRXJAAt35F7ewRXeIrWss9rEi g4XNB5MfbnNTkF/kRgHvHqJyWnBT+iXEjRGFF8b01t3auZZNj4mMis/WT3m8DCkGNO XUlxRs2FSQVpA== Archived-At: Subject: Re: [Slim] Handling the complex multi-media cases X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 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, 05 Nov 2015 15:47:01 -0000 On 11/5/15 2:26 AM, Gunnar Hellström wrote: > []But we also need to be able to express required pairs or groups: E.g. > I prefer talking and reading. > A question is if we can define an implied rule for how such grouping is > done. Is it sufficient to say that such groupings shall be expressed > with directional humintlang attributes, and that the answerer is > supposed to include at least one language in each direction with the > highest priority possible? Or do we need to explicitly point out > required pairs or groups? My numbered cases did not reveal any real > need to use any coding for explicit pairing of language indications, but > we might need to take more examples and test. There are two distinct but related issues here: - ensuring that the necessary media are established for the desired modalities - communicating to the other party what modality is desired. For instance, if you wish to talk and read, then the other person needs to listen and type. Establishing the media is only half the battle. He still needs to use them as intended. Putting the info in the SDP doesn't ensure that it will be rendered to the user in the device UI. Is this important? Or, once the necessary media have been established, can we count on the two ends to figure out how to behave with each other. (This does get more complex if the intent is use this information to decide whether to optionally introduce a relay to convert modalities.) Thanks, Paul From nobody Thu Nov 5 08:13:53 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 854611B2ECB for ; Thu, 5 Nov 2015 08:13:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 3fdpX-hJYp5o for ; Thu, 5 Nov 2015 08:13:49 -0800 (PST) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) (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 830351B2EC5 for ; Thu, 5 Nov 2015 08:13:49 -0800 (PST) Received: by ykdr3 with SMTP id r3so138952793ykd.1 for ; Thu, 05 Nov 2015 08:13:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Tdd2f09tc4zOCd0HzWQbtIgAWj4LRxnpNfjLjR3aluc=; b=EjV68890YuAW8VQZKv3vsX6RVn+yMLV4sSjCBkixhWTwkX6Ani+rpk3pdlpO2X3e6b 8jN0S9rtiDZfCM/D4QDPurIudj8/4XSlA5BViD7LAx8k7DxHin5+XSDQj3S9B8sDPmHR QBTS97vCQlJIrCHLcp9xHFp93eElVtnmGiCGUFhJZEDJOYT79Irpli3asOReJNpNb5Fl hclQBInbcVS97JzRNAE7Gs5zBjVIb1qwktTAKSrR6dSb8DFvoJc5nk6grvPN9gmesFVe dpyztCo4Hc0qcc13iuekwRQqvFj3FUzkhUGkKu/17aZfY4vnz+Yew4PL++Kf4tEAx3y0 OHpg== X-Received: by 10.129.124.139 with SMTP id x133mr3184836ywc.300.1446740028595; Thu, 05 Nov 2015 08:13:48 -0800 (PST) Received: from [10.0.1.2] (c-73-49-202-70.hsd1.fl.comcast.net. [73.49.202.70]) by smtp.gmail.com with ESMTPSA id x65sm4849155ywb.36.2015.11.05.08.13.46 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Nov 2015 08:13:46 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPad Mail (13B143) In-Reply-To: <563B79F2.1010608@alum.mit.edu> Date: Thu, 5 Nov 2015 11:13:47 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <69185871-5446-4027-8725-A2C2F187144F@gmail.com> References: <563818F9.2060709@alum.mit.edu> <56388C4D.4090808@omnitor.se> <56398719.7030205@omnitor.se> <21767FCE-C1BD-4C42-A07E-16BC81586073@gmail.com> <563A2A24.2020102@alum.mit.edu> <44BE7894-2944-42FE-A136-ADB629D49143@gmail.com> <563B04A5.4040407@omnitor.se> <563B79F2.1010608@alum.mit.edu> To: Paul Kyzivat Archived-At: Cc: slim@ietf.org Subject: Re: [Slim] Handling the complex multi-media cases X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 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, 05 Nov 2015 16:13:51 -0000 On Nov 5, 2015, at 10:46, Paul Kyzivat wrote: >=20 >> On 11/5/15 2:26 AM, Gunnar Hellstr=C3=B6m wrote: >>=20 >> []But we also need to be able to express required pairs or groups: E.g. >> I prefer talking and reading. >> A question is if we can define an implied rule for how such grouping is >> done. Is it sufficient to say that such groupings shall be expressed >> with directional humintlang attributes, and that the answerer is >> supposed to include at least one language in each direction with the >> highest priority possible? Or do we need to explicitly point out >> required pairs or groups? My numbered cases did not reveal any real >> need to use any coding for explicit pairing of language indications, but >> we might need to take more examples and test. >=20 > There are two distinct but related issues here: >=20 > - ensuring that the necessary media are established for the desired modali= ties >=20 > - communicating to the other party what modality is desired. >=20 > For instance, if you wish to talk and read, then the other person needs to= listen and type. Establishing the media is only half the battle. He still n= eeds to use them as intended. > Putting the info in the SDP doesn't ensure that it will be rendered to the= user in the device UI. >=20 > Is this important? Or, once the necessary media have been established, can= we count on the two ends to figure out how to behave with each other. [BA] The SDP Offers and answers may need to be formulated with the need to c= ommunicate desired behavior considered. Consider the scenario where the Off= erer can speak, but is hearing impaired, and therefore prefers to send audio= /English (but cannot receive it) and therefore needs to receive RTT/English.= Even if the Answerer accepts both audio and text m-lines there could be so= me confusion about the intended communication mode. For example, if the Answ= erer did not understand the new language attributes and the audio m-line was= send/recv he/she could start out speaking to the Offerer who cannot hear hi= m/her. The situation might be made more clear if the audio m-line in the Off= er was send-only. However a send/recv text m-line may be desirable even if t= he language attribute indicates only the desire to receive English, not send= it. If the text m-line was recv-only instead of send/recv then the Offerer m= ight not have a channel to communicate their need to receive RTT, not audio.= >=20 > (This does get more complex if the intent is use this information to decid= e whether to optionally introduce a relay to convert modalities.) >=20 > Thanks, > Paul >=20 > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim From nobody Thu Nov 5 14:01:35 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B14441A88D2 for ; Thu, 5 Nov 2015 14:01:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 s-FvgE-8e15k for ; Thu, 5 Nov 2015 14:01:33 -0800 (PST) Received: from resqmta-ch2-03v.sys.comcast.net (resqmta-ch2-03v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:35]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6824B1A88CA for ; Thu, 5 Nov 2015 14:01:33 -0800 (PST) Received: from resomta-ch2-12v.sys.comcast.net ([69.252.207.108]) by resqmta-ch2-03v.sys.comcast.net with comcast id dy0v1r00A2LrikM01y1YlK; Thu, 05 Nov 2015 22:01:32 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-12v.sys.comcast.net with comcast id dy1Y1r0043KdFy101y1YuG; Thu, 05 Nov 2015 22:01:32 +0000 To: Bernard Aboba References: <563818F9.2060709@alum.mit.edu> <56388C4D.4090808@omnitor.se> <56398719.7030205@omnitor.se> <21767FCE-C1BD-4C42-A07E-16BC81586073@gmail.com> <563A2A24.2020102@alum.mit.edu> <44BE7894-2944-42FE-A136-ADB629D49143@gmail.com> <563B04A5.4040407@omnitor.se> <563B79F2.1010608@alum.mit.edu> <69185871-5446-4027-8725-A2C2F187144F@gmail.com> From: Paul Kyzivat Message-ID: <563BD1BB.2040006@alum.mit.edu> Date: Thu, 5 Nov 2015 17:01:31 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <69185871-5446-4027-8725-A2C2F187144F@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1446760892; bh=qR6HMLYC3Tci+vI23Ljvh0UUNCMdMaO4+7/KSxk7Tjg=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=JEL58XODoztoSRNAcdJzTsvjTQhas746SYcvuv622tCav8dcNyzDs15Y2+YX/wJ6z Bq+2NVopUAfP8WC7NWcyQxbR1fVXPBv/DA3CKEunpZY0IPPnZ0dAONjCZrNaGUi6Uh +Su0r1kyvt3tEXLOcHrdPZg0N1P/SEieeK+FtDD8rMHr7hvMmwBgK67n6X1t7SnWAS YQ+yhsLI3bRaJqFUhuiy5X+YvUP6woEIS8fA6VMlalPnB9r+yh0eFP5tXDHpDh/lI9 e+kp1e4ecIDmWnf/8f3uYquuF63wl3+uWoFyp0qvN/y/XE2n+6Ay1AJbgi3q0u0int L13zxEJfgZCVA== Archived-At: Cc: slim@ietf.org Subject: Re: [Slim] Handling the complex multi-media cases X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 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, 05 Nov 2015 22:01:34 -0000 On 11/5/15 11:13 AM, Bernard Aboba wrote: >> There are two distinct but related issues here: >> >> - ensuring that the necessary media are established for the desired modalities >> >> - communicating to the other party what modality is desired. >> >> For instance, if you wish to talk and read, then the other person needs to listen and type. Establishing the media is only half the battle. He still needs to use them as intended. >> Putting the info in the SDP doesn't ensure that it will be rendered to the user in the device UI. >> >> Is this important? Or, once the necessary media have been established, can we count on the two ends to figure out how to behave with each other. > > [BA] The SDP Offers and answers may need to be formulated with the need to communicate desired behavior considered. Consider the scenario where the Offerer can speak, but is hearing impaired, and therefore prefers to send audio/English (but cannot receive it) and therefore needs to receive RTT/English. Even if the Answerer accepts both audio and text m-lines there could be some confusion about the intended communication mode. For example, if the Answerer did not understand the new language attributes and the audio m-line was send/recv he/she could start out speaking to the Offerer who cannot hear him/her. The situation might be made more clear if the audio m-line in the Offer was send-only. However a send/recv text m-line may be desirable even if the language attribute indicates only the desire to receive English, not send it. If the text m-line was recv-only instead of send/recv then the Offerer might not have a channel to communicate their need to receive RTT, not audio. Your response elaborates what I was talking about. Even if that information is in the SDP, we have no guarantee that it will be communicated to the user so that he can alter his behavior. Even if it does communicate it to the user, he may not understand it. (Maybe this is the first time he has ever received a call from a deaf person.) Still, I hopefully after a brief time of poor communication he will figure out what he needs to do to communicate successfully. My question is whether we expect that the UI of the called device will actually be built to communicate this sort of information? I think we can minimally assume that devices that support audio and video will see to it that the user knows whether audio and video are present in the call. And those that support RTT will make sure that the user knows when it is in the call, and provide a way to enter and display text. Beyond that, we can probably assume that devices explicitly built for the deaf market will go further, to communicate modality preferences. Whether others will is hard to say. I'm not aware of any UAs that have support for RTT for reasons *other* that supporting the deaf community. It may be that any device supporting RTT may be assumed to cater to the deaf community. But that may not be true. It is certainly conceivable that it would be used for other purposes. IMO it would be good if all devices that support chat also supported RTT. They could then negotiate on a call by call basis which protocol to use for text exchange. (RTT, MSRP, XMPP, etc.) That would maximize the possibility of meeting each user's needs while establishing the session whenever possible. But I don't see how this is going to happen. Thanks, Paul From nobody Thu Nov 5 14:28:37 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C71A1B3C80 for ; Thu, 5 Nov 2015 14:28:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 te24NI62BnR4 for ; Thu, 5 Nov 2015 14:28:33 -0800 (PST) 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 5DE911B3C78 for ; Thu, 5 Nov 2015 14:28:33 -0800 (PST) X-Halon-ID: 8a965943-840c-11e5-aee3-005056917a89 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.43.70] (unknown [2.65.139.22]) by bin-vsp-out-01.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Thu, 5 Nov 2015 23:28:30 +0100 (CET) To: slim@ietf.org References: <563818F9.2060709@alum.mit.edu> <56388C4D.4090808@omnitor.se> <56398719.7030205@omnitor.se> <21767FCE-C1BD-4C42-A07E-16BC81586073@gmail.com> <563A2A24.2020102@alum.mit.edu> <44BE7894-2944-42FE-A136-ADB629D49143@gmail.com> <563B04A5.4040407@omnitor.se> <563B79F2.1010608@alum.mit.edu> <69185871-5446-4027-8725-A2C2F187144F@gmail.com> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <563BBAA7.7000400@omnitor.se> Date: Thu, 5 Nov 2015 21:23:03 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <69185871-5446-4027-8725-A2C2F187144F@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Slim] Handling the complex multi-media cases X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 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, 05 Nov 2015 22:28:36 -0000 Den 2015-11-05 kl. 17:13, skrev Bernard Aboba: > On Nov 5, 2015, at 10:46, Paul Kyzivat wrote: >>> On 11/5/15 2:26 AM, Gunnar Hellstr=C3=B6m wrote: >>> >>> []But we also need to be able to express required pairs or groups: E.= g. >>> I prefer talking and reading. >>> A question is if we can define an implied rule for how such grouping = is >>> done. Is it sufficient to say that such groupings shall be expressed >>> with directional humintlang attributes, and that the answerer is >>> supposed to include at least one language in each direction with the >>> highest priority possible? Or do we need to explicitly point out >>> required pairs or groups? My numbered cases did not reveal any real >>> need to use any coding for explicit pairing of language indications, = but >>> we might need to take more examples and test. >> There are two distinct but related issues here: >> >> - ensuring that the necessary media are established for the desired mo= dalities >> >> - communicating to the other party what modality is desired. >> >> For instance, if you wish to talk and read, then the other person need= s to listen and type. Establishing the media is only half the battle. He = still needs to use them as intended. >> Putting the info in the SDP doesn't ensure that it will be rendered to= the user in the device UI. >> >> Is this important? Or, once the necessary media have been established,= can we count on the two ends to figure out how to behave with each other= =2E > [BA] The SDP Offers and answers may need to be formulated with the need= to communicate desired behavior considered. Consider the scenario where= the Offerer can speak, but is hearing impaired, and therefore prefers to= send audio/English (but cannot receive it) and therefore needs to receiv= e RTT/English. Even if the Answerer accepts both audio and text m-lines = there could be some confusion about the intended communication mode. For = example, if the Answerer did not understand the new language attributes a= nd the audio m-line was send/recv he/she could start out speaking to the = Offerer who cannot hear him/her. The situation might be made more clear i= f the audio m-line in the Offer was send-only. However a send/recv text = m-line may be desirable even if the language attribute indicates only the= desire to receive English, not send it. If the text m-line was recv-only= instead of send/recv then the Offerer might not have a channel to commun= icate their need to receive RTT, not audio. [GH] We should not use sendonly and recvonly as means to indicate=20 modality preferences. Media flow in the other direction may be very=20 desirable for other purposes, or for very occasional language transfer,=20 not worth complicating the language/modality indications. So, yes, your=20 main reasoning is good, we simply should not complicate our task by=20 discussing sendonly and recvonly. /Gunnar >> (This does get more complex if the intent is use this information to d= ecide whether to optionally introduce a relay to convert modalities.) >> >> Thanks, >> Paul >> >> _______________________________________________ >> 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 Nov 5 14:50:47 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F8A41B3CE3 for ; Thu, 5 Nov 2015 14:50:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 8vyejKCVVuun for ; Thu, 5 Nov 2015 14:50:44 -0800 (PST) Received: from bin-vsp-out-04.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 DC2AA1B3459 for ; Thu, 5 Nov 2015 14:50:43 -0800 (PST) X-Halon-ID: 9eb2a718-840f-11e5-83b0-005056917c0c Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.43.70] (unknown [2.65.139.22]) by bin-vsp-out-04.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Thu, 5 Nov 2015 23:50:32 +0100 (CET) To: slim@ietf.org References: <563818F9.2060709@alum.mit.edu> <56388C4D.4090808@omnitor.se> <56398719.7030205@omnitor.se> <21767FCE-C1BD-4C42-A07E-16BC81586073@gmail.com> <563A2A24.2020102@alum.mit.edu> <44BE7894-2944-42FE-A136-ADB629D49143@gmail.com> <563B04A5.4040407@omnitor.se> <563B79F2.1010608@alum.mit.edu> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <563BDD3B.9030107@omnitor.se> Date: Thu, 5 Nov 2015 23:50:35 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <563B79F2.1010608@alum.mit.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Slim] Handling the complex multi-media cases X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 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, 05 Nov 2015 22:50:46 -0000 Den 2015-11-05 kl. 16:46, skrev Paul Kyzivat: > On 11/5/15 2:26 AM, Gunnar Hellström wrote: > >> []But we also need to be able to express required pairs or groups: E.g. >> I prefer talking and reading. >> A question is if we can define an implied rule for how such grouping is >> done. Is it sufficient to say that such groupings shall be expressed >> with directional humintlang attributes, and that the answerer is >> supposed to include at least one language in each direction with the >> highest priority possible? Or do we need to explicitly point out >> required pairs or groups? My numbered cases did not reveal any real >> need to use any coding for explicit pairing of language indications, but >> we might need to take more examples and test. > > There are two distinct but related issues here: > > - ensuring that the necessary media are established for the desired > modalities > > - communicating to the other party what modality is desired. > > For instance, if you wish to talk and read, then the other person > needs to listen and type. Establishing the media is only half the > battle. He still needs to use them as intended. > > Putting the info in the SDP doesn't ensure that it will be rendered to > the user in the device UI. > > Is this important? Or, once the necessary media have been established, > can we count on the two ends to figure out how to behave with each other. > > (This does get more complex if the intent is use this information to > decide whether to optionally introduce a relay to convert modalities.) > > Thanks, > Paul [GH] Right. We have one piece left to specify. That is how offer/answer shall be handled. Offer is well on its way. But how is the answer composed? Especially for the directional indications. Should the answer only indicate the acknowledged capabilities meeting the offeror's indications? Example: Offer: Japanese speech sending in audio Answer: Japanese speech reception in audio. ? /Gunnar > > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim From nobody Thu Nov 5 14:54:18 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 704241B3CF3 for ; Thu, 5 Nov 2015 14:54:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 oUQpi7L8TrSF for ; Thu, 5 Nov 2015 14:54:16 -0800 (PST) Received: from bin-vsp-out-05.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 8C2371B3CF2 for ; Thu, 5 Nov 2015 14:54:15 -0800 (PST) X-Halon-ID: 23448406-8410-11e5-8d6b-005056916f53 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.43.70] (unknown [2.65.139.22]) by bin-vsp-out-05.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Thu, 5 Nov 2015 23:54:14 +0100 (CET) To: slim@ietf.org References: <563818F9.2060709@alum.mit.edu> <56388C4D.4090808@omnitor.se> <56398719.7030205@omnitor.se> <21767FCE-C1BD-4C42-A07E-16BC81586073@gmail.com> <563A2A24.2020102@alum.mit.edu> <44BE7894-2944-42FE-A136-ADB629D49143@gmail.com> <563B04A5.4040407@omnitor.se> <563B79F2.1010608@alum.mit.edu> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <563BDE10.5050305@omnitor.se> Date: Thu, 5 Nov 2015 23:54:08 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <563B79F2.1010608@alum.mit.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Slim] Handling the complex multi-media cases X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 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, 05 Nov 2015 22:54:17 -0000 Den 2015-11-05 kl. 16:46, skrev Paul Kyzivat: > On 11/5/15 2:26 AM, Gunnar Hellström wrote: > >> []But we also need to be able to express required pairs or groups: E.g. >> I prefer talking and reading. >> A question is if we can define an implied rule for how such grouping is >> done. Is it sufficient to say that such groupings shall be expressed >> with directional humintlang attributes, and that the answerer is >> supposed to include at least one language in each direction with the >> highest priority possible? Or do we need to explicitly point out >> required pairs or groups? My numbered cases did not reveal any real >> need to use any coding for explicit pairing of language indications, but >> we might need to take more examples and test. > > There are two distinct but related issues here: > > - ensuring that the necessary media are established for the desired > modalities > > - communicating to the other party what modality is desired. > > For instance, if you wish to talk and read, then the other person > needs to listen and type. Establishing the media is only half the > battle. He still needs to use them as intended. > > Putting the info in the SDP doesn't ensure that it will be rendered to > the user in the device UI. > > Is this important? Or, once the necessary media have been established, > can we count on the two ends to figure out how to behave with each other. [GH] The current draft contains a brief specification that the language indications should be provided to the calling and answering users. /Gunnar > > (This does get more complex if the intent is use this information to > decide whether to optionally introduce a relay to convert modalities.) > > Thanks, > Paul > > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim From nobody Thu Nov 5 19:59:48 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B683F1A884C for ; Thu, 5 Nov 2015 19:59:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 oAnlrQkNjgKX for ; Thu, 5 Nov 2015 19:59:45 -0800 (PST) Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:37]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DC781A8890 for ; Thu, 5 Nov 2015 19:59:44 -0800 (PST) Received: from resomta-ch2-08v.sys.comcast.net ([69.252.207.104]) by resqmta-ch2-05v.sys.comcast.net with comcast id e3yX1r0042Fh1PH013zjux; Fri, 06 Nov 2015 03:59:43 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-08v.sys.comcast.net with comcast id e3zj1r00A3KdFy1013zjZn; Fri, 06 Nov 2015 03:59:43 +0000 To: slim@ietf.org References: <563818F9.2060709@alum.mit.edu> <56388C4D.4090808@omnitor.se> <56398719.7030205@omnitor.se> <21767FCE-C1BD-4C42-A07E-16BC81586073@gmail.com> <563A2A24.2020102@alum.mit.edu> <44BE7894-2944-42FE-A136-ADB629D49143@gmail.com> <563B04A5.4040407@omnitor.se> <563B79F2.1010608@alum.mit.edu> <563BDE10.5050305@omnitor.se> From: Paul Kyzivat Message-ID: <563C25AD.3050801@alum.mit.edu> Date: Thu, 5 Nov 2015 22:59:41 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <563BDE10.5050305@omnitor.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1446782383; bh=dO0ng+OSmcyi7hOnStyeV1RJBMAMYyQ2quD2OZ8pcdk=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=RdKpC+L26Z8O/VvE3/Y8xM3uO3Z67mQRBJX0/11/hD4fEUUlbCjhATPteFEkwN9Fk gr5KHPtERxTtBLlnCxcoKJ/ksc3TMOT55o/GXfq/uK/rtiFs+nA7u9fo570PHLNar+ JHLNWw3tkjLyuq1pZvMxhYYJqBS9qQzV+Kr04u3i8Jcoz+J+CGl0iE8loS51Zh+f2M Yj/bd3PotsAG55TS5nQrsBZ5p4jm8EvxZWQ3H8yhfcky35QxOsWEDb89+HCtyrRi+8 CH8OHQcBz0myhMCt7sKyt5XkxDRjliP91BIrIMgEJoMMyRE4N0CVgjyuxfxgvO/83R LLaQlx5XiXE4A== Archived-At: Subject: Re: [Slim] Handling the complex multi-media cases X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 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, 06 Nov 2015 03:59:46 -0000 On 11/5/15 5:54 PM, Gunnar Hellström wrote: >> There are two distinct but related issues here: >> >> - ensuring that the necessary media are established for the desired >> modalities >> >> - communicating to the other party what modality is desired. >> >> For instance, if you wish to talk and read, then the other person >> needs to listen and type. Establishing the media is only half the >> battle. He still needs to use them as intended. >> >> Putting the info in the SDP doesn't ensure that it will be rendered to >> the user in the device UI. >> >> Is this important? Or, once the necessary media have been established, >> can we count on the two ends to figure out how to behave with each other. > [GH] The current draft contains a brief specification that the language > indications should be provided to the calling and answering users. Sure. But that probably isn't normative (since it is about the UI, not the protocol), and in any case it would only be binding on those who support this. There is a strong possibility that this will be treated as something that is only applicable to a niche market. Is there something that we can do to encourage widespread implementation of this draft? Making it something valuable to all would be one way. (Eliminating the "press 1 for Spanish" query might provide that motivation.) Thanks, Paul From nobody Fri Nov 6 15:42:57 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AACA11B2D2B for ; Fri, 6 Nov 2015 15:42:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.201 X-Spam-Level: X-Spam-Status: No, score=-0.201 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 BhW7WGtpm4Nr for ; Fri, 6 Nov 2015 15:42:54 -0800 (PST) Received: from bin-vsp-out-03.atm.binero.net (vsp-unauthed02.binero.net [195.74.38.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6CA61B2CEC for ; Fri, 6 Nov 2015 15:42:53 -0800 (PST) X-Halon-ID: 14549955-84e0-11e5-8d2f-0050569116f7 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.48] (unknown [83.209.226.9]) by bin-vsp-out-03.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Sat, 7 Nov 2015 00:42:45 +0100 (CET) To: slim@ietf.org References: <563818F9.2060709@alum.mit.edu> <56388C4D.4090808@omnitor.se> <56398719.7030205@omnitor.se> <21767FCE-C1BD-4C42-A07E-16BC81586073@gmail.com> <563A2A24.2020102@alum.mit.edu> <44BE7894-2944-42FE-A136-ADB629D49143@gmail.com> <563B04A5.4040407@omnitor.se> <563B79F2.1010608@alum.mit.edu> <563BDE10.5050305@omnitor.se> <563C25AD.3050801@alum.mit.edu> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <563D3AF5.1020608@omnitor.se> Date: Sat, 7 Nov 2015 00:42:45 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <563C25AD.3050801@alum.mit.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Slim] Handling the complex multi-media cases X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 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, 06 Nov 2015 23:42:56 -0000 Moving on. ( I think that Paul's proposal to motivate use by that it reduces the number of times you need to listen through a voice menue is excellent. ) Another use case came to my mind. That is the hard-of-hearing or deaf person who experience that the lip-reading support achieved when you see well synced video image of the person talking is of value for understanding. That requires indicating spoken language in audio both ways, and indication of reception of spoken language in video. Indication of all three having high priority would be good to indicate that they are all needed. So, would it also here be sufficient to indicate: Spoken language reception in audio with high priority. Spoken language transmission in audio with high priority Spoken language reception in video with high priority This is for when the user really finds it important t see the person talking, and does not feel it being sufficient with only audio. Then the three media should have the same priority. There are of course variations in reality, when either of these languages can be sacrificed relatively easily, and therefore be indicated with lower priority. Can we have an application rule for composing the indications saying that If the user has different needs in different directions, it might be sufficient to declare the need in directional language tags. /Gunnar Den 2015-11-06 kl. 04:59, skrev Paul Kyzivat: > On 11/5/15 5:54 PM, Gunnar Hellström wrote: > >>> There are two distinct but related issues here: >>> >>> - ensuring that the necessary media are established for the desired >>> modalities >>> >>> - communicating to the other party what modality is desired. >>> >>> For instance, if you wish to talk and read, then the other person >>> needs to listen and type. Establishing the media is only half the >>> battle. He still needs to use them as intended. >>> >>> Putting the info in the SDP doesn't ensure that it will be rendered to >>> the user in the device UI. >>> >>> Is this important? Or, once the necessary media have been established, >>> can we count on the two ends to figure out how to behave with each >>> other. >> [GH] The current draft contains a brief specification that the language >> indications should be provided to the calling and answering users. > > Sure. But that probably isn't normative (since it is about the UI, not > the protocol), and in any case it would only be binding on those who > support this. There is a strong possibility that this will be treated > as something that is only applicable to a niche market. > > Is there something that we can do to encourage widespread > implementation of this draft? Making it something valuable to all > would be one way. (Eliminating the "press 1 for Spanish" query might > provide that motivation.) > > 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 Sat Nov 7 07:56:01 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7596B1A9005 for ; Sat, 7 Nov 2015 07:56:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.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, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 X9N0O5kw_UgX for ; Sat, 7 Nov 2015 07:55:58 -0800 (PST) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (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 DCD3A1A1A9B for ; Sat, 7 Nov 2015 07:55:57 -0800 (PST) Received: by wmdw130 with SMTP id w130so1966191wmd.0 for ; Sat, 07 Nov 2015 07:55:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=6KgRVrcE23d/9o8bqEFBjd64AVZpejM8t9N9tQmUV9w=; b=uTykYONEa4JKVea+e10ihYaglWPoDT7QmjWp2vzLjFvE5U6yWnln5Go7Lz+Pmr5xIi 9yMeBQ1ZZBhagOesJIfdPiZ8Ra/6s3y1VcPxA0ZCPLUxQRsTx0zI2a3WxcRreD3MTyhC VkH30l7JbtEg1ztCfhlgxoge1VM4tnB0HjOJwGN03Lycjugo7BxxDBq2LlsYJlWbh0OH 6cLoqKTNvIrdJ/V99Tq6oBpkQucMOG+JBO6ymOWtMLSX6oJZktOe9LK6qiVUQ9m2Q+F8 PP0uI3ktYdwSUf7J6grTMCcheCo7lfa8LJKMrAjNAUgINfbArqd6KDXN7FMubYpsAyIh QxZA== X-Received: by 10.28.23.211 with SMTP id 202mr15812734wmx.81.1446911756378; Sat, 07 Nov 2015 07:55:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.130.202 with HTTP; Sat, 7 Nov 2015 07:55:36 -0800 (PST) In-Reply-To: <563D3AF5.1020608@omnitor.se> References: <563818F9.2060709@alum.mit.edu> <56388C4D.4090808@omnitor.se> <56398719.7030205@omnitor.se> <21767FCE-C1BD-4C42-A07E-16BC81586073@gmail.com> <563A2A24.2020102@alum.mit.edu> <44BE7894-2944-42FE-A136-ADB629D49143@gmail.com> <563B04A5.4040407@omnitor.se> <563B79F2.1010608@alum.mit.edu> <563BDE10.5050305@omnitor.se> <563C25AD.3050801@alum.mit.edu> <563D3AF5.1020608@omnitor.se> From: Bernard Aboba Date: Sat, 7 Nov 2015 10:55:36 -0500 Message-ID: To: =?UTF-8?Q?Gunnar_Hellstr=C3=B6m?= Content-Type: multipart/alternative; boundary=001a1147181a42a9a80523f56513 Archived-At: Cc: slim@ietf.org Subject: Re: [Slim] Handling the complex multi-media cases X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 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, 07 Nov 2015 15:56:00 -0000 --001a1147181a42a9a80523f56513 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Gunnar said: "That is the hard-of-hearing or deaf person who experience that the lip-reading support achieved when you see well synced video image of the person talking is of value for understanding." [BA] In this case, it would probably make sense to Offer audio and video m-lines in a Lip-Sync (LS) group as defined in https://tools.ietf.org/html/rfc5888 That requires indicating spoken language in audio both ways, and indication of reception of spoken language in video. [BA] Not sure what it means to negotiate spoken language in video. For example, if the Answerer does not indicate that it can send spoken language in video, is this a problem? Or is this just a way to indicate that the video is important? The presence of a lip-sync group seems like enough of an indication that the video is intended to sync with the audio m-line. On Fri, Nov 6, 2015 at 6:42 PM, Gunnar Hellstr=C3=B6m < gunnar.hellstrom@omnitor.se> wrote: > Moving on. ( I think that Paul's proposal to motivate use by that it > reduces the number of times you need to listen through a voice menue is > excellent. ) > > Another use case came to my mind. > > That is the > hard-of-hearing or deaf person who experience that the lip-reading suppor= t > achieved when you see well synced video image of the person talking is of > value for understanding. > > That requires indicating spoken language in audio both ways, and > indication of reception of spoken language in video. > Indication of all three having high priority would be good to indicate > that they are all needed. > > So, would it also here be sufficient to indicate: > Spoken language reception in audio with high priority. > Spoken language transmission in audio with high priority > Spoken language reception in video with high priority > > This is for when the user really finds it important t see the person > talking, and does not feel it being sufficient with only audio. Then the > three media should have the same priority. > > There are of course variations in reality, when either of these languages > can be sacrificed relatively easily, and therefore be indicated with lowe= r > priority. > > Can we have an application rule for composing the indications saying that > If the user has different needs in different directions, it might be > sufficient to declare the need in directional language tags. > > /Gunnar > > > > > > > > Den 2015-11-06 kl. 04:59, skrev Paul Kyzivat: > >> On 11/5/15 5:54 PM, Gunnar Hellstr=C3=B6m wrote: >> >> There are two distinct but related issues here: >>>> >>>> - ensuring that the necessary media are established for the desired >>>> modalities >>>> >>>> - communicating to the other party what modality is desired. >>>> >>>> For instance, if you wish to talk and read, then the other person >>>> needs to listen and type. Establishing the media is only half the >>>> battle. He still needs to use them as intended. >>>> >>>> Putting the info in the SDP doesn't ensure that it will be rendered to >>>> the user in the device UI. >>>> >>>> Is this important? Or, once the necessary media have been established, >>>> can we count on the two ends to figure out how to behave with each >>>> other. >>>> >>> [GH] The current draft contains a brief specification that the language >>> indications should be provided to the calling and answering users. >>> >> >> Sure. But that probably isn't normative (since it is about the UI, not >> the protocol), and in any case it would only be binding on those who >> support this. There is a strong possibility that this will be treated as >> something that is only applicable to a niche market. >> >> Is there something that we can do to encourage widespread implementation >> of this draft? Making it something valuable to all would be one way. >> (Eliminating the "press 1 for Spanish" query might provide that motivati= on.) >> >> Thanks, >> Paul >> >> _______________________________________________ >> 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 > --001a1147181a42a9a80523f56513 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Gunnar said:=C2=A0
"That is the=C2=A0hard-of-hearin= g or deaf person who experience that the lip-reading support achieved when = you see well synced video image of the person talking is of value for under= standing."

[BA] In this case, it would p= robably make sense to Offer audio and video m-lines in a Lip-Sync (LS) grou= p as defined in=C2=A0https:= //tools.ietf.org/html/rfc5888

That requir= es indicating spoken language in audio both ways, and indication of recepti= on of spoken language in video.
=

[BA] Not sure what it means to negotiate spo= ken language in video.=C2=A0 For example, if the Answerer does not indicate= that it can send spoken language in video, is this a problem?=C2=A0 Or is = this just a way to indicate that the video is important? The presence of a = lip-sync group seems like enough of an indication that the video is intende= d to sync with the audio m-line.=C2=A0

On Fri, Nov 6, 2015 at 6:42 PM, Gun= nar Hellstr=C3=B6m <gunnar.hellstrom@omnitor.se> w= rote:
Moving on. ( I think that Paul'= s proposal to motivate use by that it reduces the number of times you need = to listen through a voice menue is excellent. )

Another use case came to my mind.

That is the
hard-of-hearing or deaf person who experience that the lip-reading support = achieved when you see well synced video image of the person talking is of v= alue for understanding.

That requires indicating spoken language in audio both ways, and indication= of reception of spoken language in video.
Indication of all three having high priority would be good to indicate that= they are all needed.

So, would it also here be sufficient to indicate:
Spoken language reception in audio with high priority.
Spoken language transmission in audio with high priority
Spoken language reception in video with high priority

This is for when the user really finds it important t see the person talkin= g, and does not feel it being sufficient with only audio. Then the three me= dia should have the same priority.

There are of course variations in reality, when either of these languages c= an be sacrificed relatively easily, and therefore be indicated with lower p= riority.

Can we have an application rule for composing the indications saying that If the user has different needs in different directions, it might be suffic= ient to declare the need in directional language tags.

/Gunnar







Den 2015-11-06 kl. 04:59, skrev Paul Kyzivat:
On 11/5/15 5:54 PM, Gunnar Hellstr=C3=B6m wrote:

There are two distinct but related issues here:

- ensuring that the necessary media are established for the desired
modalities

- communicating to the other party what modality is desired.

For instance, if you wish to talk and read, then the other person
needs to listen and type. Establishing the media is only half the
battle. He still needs to use them as intended.

Putting the info in the SDP doesn't ensure that it will be rendered to<= br> the user in the device UI.

Is this important? Or, once the necessary media have been established,
can we count on the two ends to figure out how to behave with each other.
[GH] The current draft contains a brief specification that the language
indications should be provided to the calling and answering users.

Sure. But that probably isn't normative (since it is about the UI, not = the protocol), and in any case it would only be binding on those who suppor= t this. There is a strong possibility that this will be treated as somethin= g that is only applicable to a niche market.

Is there something that we can do to encourage widespread implementation of= this draft? Making it something valuable to all would be one way. (Elimina= ting the "press 1 for Spanish" query might provide that motivatio= n.)

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

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

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


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

--001a1147181a42a9a80523f56513-- From nobody Sat Nov 7 08:42:39 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 953521A92DC for ; Sat, 7 Nov 2015 08:42:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.165 X-Spam-Level: X-Spam-Status: No, score=0.165 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 1bIv3GS67_tn for ; Sat, 7 Nov 2015 08:42:37 -0800 (PST) Received: from resqmta-po-08v.sys.comcast.net (resqmta-po-08v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:167]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02ACD1A92BC for ; Sat, 7 Nov 2015 08:42:36 -0800 (PST) Received: from resomta-po-18v.sys.comcast.net ([96.114.154.242]) by resqmta-po-08v.sys.comcast.net with comcast id egiR1r0065E3ZMc01gicqo; Sat, 07 Nov 2015 16:42:36 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-po-18v.sys.comcast.net with comcast id egiY1r00R3KdFy101giZ5X; Sat, 07 Nov 2015 16:42:36 +0000 To: slim@ietf.org References: <563818F9.2060709@alum.mit.edu> <56388C4D.4090808@omnitor.se> <56398719.7030205@omnitor.se> <21767FCE-C1BD-4C42-A07E-16BC81586073@gmail.com> <563A2A24.2020102@alum.mit.edu> <44BE7894-2944-42FE-A136-ADB629D49143@gmail.com> <563B04A5.4040407@omnitor.se> <563B79F2.1010608@alum.mit.edu> <563BDE10.5050305@omnitor.se> <563C25AD.3050801@alum.mit.edu> <563D3AF5.1020608@omnitor.se> From: Paul Kyzivat Message-ID: <563E29F6.3080906@alum.mit.edu> Date: Sat, 7 Nov 2015 11:42:30 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1446914556; bh=W4tiS4dW+OegGJ+Bb5UCCLP/PMtm5oH74baryVLTx3Q=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=PZmRWWPFqJdebdk8V4YUN17sXnV10YROB6BFa1Ky9WWwWu4uA1MHyHojOLLeMucdD Y7ySOYbFmHEcErFV53+4hpCi0g0M9lTBeCM/3TB0sBCwPBkVXSVrGiz4z+E8EsLOPi gHUOXp+aw6V/LL0eiMog8seSOwP2bULyMwDtdXikgTWPjxAaLglvoiCLPbLwuZUbVf u622deaJUaLyRTfuPqQVrsmLimm9hTLJ2xndkjS/CkVm+v3J54gDNaPDeoVcchLQyX XIF1R2GLL9GIjfxiXZ/CQE20t3V10rgIDRopERhOZEzHCYSVqMk9VbBt7zRCiYfuZH s2xKyNcNIN2/g== Archived-At: Subject: Re: [Slim] Handling the complex multi-media cases X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 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, 07 Nov 2015 16:42:38 -0000 On 11/7/15 10:55 AM, Bernard Aboba wrote: > Gunnar said: > "That is the hard-of-hearing or deaf person who experience that the > lip-reading support achieved when you see well synced video image of the > person talking is of value for understanding." > > [BA] In this case, it would probably make sense to Offer audio and video > m-lines in a Lip-Sync (LS) group as defined in > https://tools.ietf.org/html/rfc5888 > > That requires indicating spoken language in audio both ways, and > indication of reception of spoken language in video. > > [BA] Not sure what it means to negotiate spoken language in video. It makes sense to me that this would signify lip reading. > For > example, if the Answerer does not indicate that it can send spoken > language in video, is this a problem? To *send* for lip reading, you need to send video that shows the face clearly. Not indicating it for sending might mean that you aren't sending video of faces of speakers, or it could simply mean that you didn't indicate what you are doing. > Or is this just a way to indicate > that the video is important? The presence of a lip-sync group seems like > enough of an indication that the video is intended to sync with the > audio m-line. I don't know about that. In principle you don't need audio to lip read. If there was only video, then you wouldn't need lip sync. And if you are sending audio and video, lip sync is only saying that the timing is consistent between the two. It doesn't say that lips are visible. Thanks, Paul > On Fri, Nov 6, 2015 at 6:42 PM, Gunnar Hellström > > wrote: > > Moving on. ( I think that Paul's proposal to motivate use by that it > reduces the number of times you need to listen through a voice menue > is excellent. ) > > Another use case came to my mind. > > That is the > hard-of-hearing or deaf person who experience that the lip-reading > support achieved when you see well synced video image of the person > talking is of value for understanding. > > That requires indicating spoken language in audio both ways, and > indication of reception of spoken language in video. > Indication of all three having high priority would be good to > indicate that they are all needed. > > So, would it also here be sufficient to indicate: > Spoken language reception in audio with high priority. > Spoken language transmission in audio with high priority > Spoken language reception in video with high priority > > This is for when the user really finds it important t see the person > talking, and does not feel it being sufficient with only audio. Then > the three media should have the same priority. > > There are of course variations in reality, when either of these > languages can be sacrificed relatively easily, and therefore be > indicated with lower priority. > > Can we have an application rule for composing the indications saying > that > If the user has different needs in different directions, it might be > sufficient to declare the need in directional language tags. > > /Gunnar > > > > > > > > Den 2015-11-06 kl. 04:59, skrev Paul Kyzivat: > > On 11/5/15 5:54 PM, Gunnar Hellström wrote: > > There are two distinct but related issues here: > > - ensuring that the necessary media are established for > the desired > modalities > > - communicating to the other party what modality is desired. > > For instance, if you wish to talk and read, then the > other person > needs to listen and type. Establishing the media is only > half the > battle. He still needs to use them as intended. > > Putting the info in the SDP doesn't ensure that it will > be rendered to > the user in the device UI. > > Is this important? Or, once the necessary media have > been established, > can we count on the two ends to figure out how to behave > with each other. > > [GH] The current draft contains a brief specification that > the language > indications should be provided to the calling and answering > users. > > > Sure. But that probably isn't normative (since it is about the > UI, not the protocol), and in any case it would only be binding > on those who support this. There is a strong possibility that > this will be treated as something that is only applicable to a > niche market. > > Is there something that we can do to encourage widespread > implementation of this draft? Making it something valuable to > all would be one way. (Eliminating the "press 1 for Spanish" > query might provide that motivation.) > > 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 > > > _______________________________________________ > 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 Sat Nov 7 08:49:17 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE6FD1AC39A for ; Sat, 7 Nov 2015 08:49:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.165 X-Spam-Level: X-Spam-Status: No, score=0.165 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 2gtSFVGzwYbU for ; Sat, 7 Nov 2015 08:49:15 -0800 (PST) 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 DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14F071AC399 for ; Sat, 7 Nov 2015 08:49:14 -0800 (PST) Received: from resomta-ch2-03v.sys.comcast.net ([69.252.207.99]) by resqmta-ch2-06v.sys.comcast.net with comcast id egpB1r00229Cfhx01gpEAv; Sat, 07 Nov 2015 16:49:14 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-03v.sys.comcast.net with comcast id egpD1r00A3KdFy101gpDft; Sat, 07 Nov 2015 16:49:14 +0000 To: slim@ietf.org References: <563818F9.2060709@alum.mit.edu> <56388C4D.4090808@omnitor.se> <56398719.7030205@omnitor.se> <21767FCE-C1BD-4C42-A07E-16BC81586073@gmail.com> <563A2A24.2020102@alum.mit.edu> <44BE7894-2944-42FE-A136-ADB629D49143@gmail.com> <563B04A5.4040407@omnitor.se> <563B79F2.1010608@alum.mit.edu> <563BDE10.5050305@omnitor.se> <563C25AD.3050801@alum.mit.edu> <563D3AF5.1020608@omnitor.se> From: Paul Kyzivat Message-ID: <563E2B88.7040703@alum.mit.edu> Date: Sat, 7 Nov 2015 11:49:12 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <563D3AF5.1020608@omnitor.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1446914954; bh=SObRxRqL0bZmSg8aFWLrZj+uKrJ+9AH/BBQ/rg0osXw=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=KqvHXnJ+KF6xC6bdH09n27mpgdtpFELnUIbvymKitXrj15RhAsCbr2GjOlxfJPP5q Hha5IqKzZR/6s+z9gFCIMDUnBkfNt1sGeBPOVluvp0lkMw5ERZQRJCRS86RHQ8nPJv bPx8uLOc+6wgAOstPQWQH2KhZMjO4MaHWUfb/jWuRoAkR6HQPr+9Qww5NdJ7yU5/6p qy5jcH+9xXASZDqrtmWrAglvoeAfN8VnPM4dO0rwjFMihpeIfwOed6nJdBAudegIUG 6gHPE4w35qQ+et2rx5PDRvyr/J7+FU1/9tUnAvV0m6a5WSLcnGNoIpKkQ8aM5KEb2h aUUnjCWiHBV8Q== Archived-At: Subject: Re: [Slim] Handling the complex multi-media cases X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 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, 07 Nov 2015 16:49:16 -0000 On 11/6/15 6:42 PM, Gunnar Hellström wrote: > Moving on. ( I think that Paul's proposal to motivate use by that it > reduces the number of times you need to listen through a voice menue is > excellent. ) While it seems like it would be helpful, I don't know what we can do to encourage it. I expect the key would be to convince some important call centers to implement this. Or maybe there could be some support for this added to vxml, so it is easy to write a script that checks for this and bypasses the query. [snip] > Can we have an application rule for composing the indications saying that > If the user has different needs in different directions, it might be > sufficient to declare the need in directional language tags. I think this could start with a use case document, listing an assortment of differently skilled people, and the recommended indication for each, in terms of the offer they would make. That *might* eventually lead to something normative. Thanks, Paul From nobody Sat Nov 7 12:03:10 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D6731B2F0D for ; Sat, 7 Nov 2015 12:03:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 nzFQuhT8uDkM for ; Sat, 7 Nov 2015 12:03:04 -0800 (PST) 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 75EE81B2F09 for ; Sat, 7 Nov 2015 12:03:03 -0800 (PST) X-Halon-ID: 874da5ef-858a-11e5-8d2f-0050569116f7 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.48] (unknown [83.209.226.9]) by bin-vsp-out-03.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Sat, 7 Nov 2015 21:02:52 +0100 (CET) To: slim@ietf.org References: <563818F9.2060709@alum.mit.edu> <56388C4D.4090808@omnitor.se> <56398719.7030205@omnitor.se> <21767FCE-C1BD-4C42-A07E-16BC81586073@gmail.com> <563A2A24.2020102@alum.mit.edu> <44BE7894-2944-42FE-A136-ADB629D49143@gmail.com> <563B04A5.4040407@omnitor.se> <563B79F2.1010608@alum.mit.edu> <563BDE10.5050305@omnitor.se> <563C25AD.3050801@alum.mit.edu> <563D3AF5.1020608@omnitor.se> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <563E58EC.3090304@omnitor.se> Date: Sat, 7 Nov 2015 21:02:52 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------090703090308050805070904" Archived-At: Subject: Re: [Slim] Handling the complex multi-media cases X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 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, 07 Nov 2015 20:03:08 -0000 This is a multi-part message in MIME format. --------------090703090308050805070904 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Den 2015-11-07 kl. 16:55, skrev Bernard Aboba: > Gunnar said: > "That is the hard-of-hearing or deaf person who experience that the > lip-reading support achieved when you see well synced video image of > the person talking is of value for understanding." > > [BA] In this case, it would probably make sense to Offer audio and > video m-lines in a Lip-Sync (LS) group as defined in > https://tools.ietf.org/html/rfc5888 > > That requires indicating spoken language in audio both ways, and > indication of reception of spoken language in video. > > [BA] Not sure what it means to negotiate spoken language in video. > For example, if the Answerer does not indicate that it can send spoken > language in video, is this a problem? Or is this just a way to > indicate that the video is important? The presence of a lip-sync group > seems like enough of an indication that the video is intended to sync > with the audio m-line. [GH] Section 6.2 in the real-time slim draft already says: Note that while signed language tags are used with a video stream to indicate sign language, a spoken language tag for a video stream in parallel with an audio stream with the same spoken language tag indicates a request for a supplemental video stream to see the speaker. [GH] The lip-sync group is a good feature, but I think it is good that we have a way to specify the need for lip-reading possiblity from a language point of view. Bernard asks: "For example, if the Answerer does not indicate that it can send spoken language in video, is this a problem? " [GH] The other way around is reassuring. Indication of sending spoken language in video can make the lip-reading depending caller assured that the call has good opportunities to be smooth. If the indication of sending of spoken language in video is not there in the answer, it can be an alerting indication that the user or its terminal or service provider may need to make some additional measures to make the call flow well. E.g. add a relay service, start out with an explanation that text might be needed some times etc. This discussion leads to another interesting case. Assume that the person with preference for lip-reading supported spoken language want to express a clear fall-back option meaning: "If you cannot provide a view of you while talking, then I still want to talk, but I want to receive real-time text." I think that the caller would then indicate reception of written language in the text stream, but with lower absolute preference than for the spoken language in video. How can we code this absolute level of preference? The need for it has popped up as a result in many of the use cases now. A coarse coding of absolute level of preference is likely sufficient. High, medium and low or so. We are not yet quite sure that we manage without a very specific grouping specification, but for some cases it is evident that a simple absolute preference is sufficient. In the draft, section 3.2, there is a paragraph " In an offer, each language tag value MAY have an asterisk appended as the last character (after the registry value). The asterisk indicates a request by the caller to not fail the call if there is no language in common." I don't know if this syntax is really recommendable for the non-fail indication, so I think that should be discussed. Would it be better with a clearly separate parameter in the humintlang attribute, in order to not create any collision with coding of the language tag itself? The coding could be extended to indicate the absolute preference. Just to have a starting proposal, I suggest to handle it as a separate parameter in the Humintlang attribute, with possible values: Fail, Hi, Med, Lo Fail= fail the call if you cannot meet this language preference. Hi= very desirable language Med = Good alternative Lo = Wanted if you cannot meet my other higher prioritized preferences Specify just modality. I imagine that we will have cases of users who find it cumbersome to specify languages and would like to only specify modality for language use and preference. Proposal, just omit the language tag and make sure a modality parameter is there Values: text sign speech Syntax. e.g. a=humintlang-send: [] [/][/] /Gunnar > > On Fri, Nov 6, 2015 at 6:42 PM, Gunnar Hellström > > wrote: > > Moving on. ( I think that Paul's proposal to motivate use by that > it reduces the number of times you need to listen through a voice > menue is excellent. ) > > Another use case came to my mind. > > That is the > hard-of-hearing or deaf person who experience that the lip-reading > support achieved when you see well synced video image of the > person talking is of value for understanding. > > That requires indicating spoken language in audio both ways, and > indication of reception of spoken language in video. > Indication of all three having high priority would be good to > indicate that they are all needed. > > So, would it also here be sufficient to indicate: > Spoken language reception in audio with high priority. > Spoken language transmission in audio with high priority > Spoken language reception in video with high priority > > This is for when the user really finds it important t see the > person talking, and does not feel it being sufficient with only > audio. Then the three media should have the same priority. > > There are of course variations in reality, when either of these > languages can be sacrificed relatively easily, and therefore be > indicated with lower priority. > > Can we have an application rule for composing the indications > saying that > If the user has different needs in different directions, it might > be sufficient to declare the need in directional language tags. > > /Gunnar > > > > > > > > Den 2015-11-06 kl. 04:59, skrev Paul Kyzivat: > > On 11/5/15 5:54 PM, Gunnar Hellström wrote: > > There are two distinct but related issues here: > > - ensuring that the necessary media are established > for the desired > modalities > > - communicating to the other party what modality is > desired. > > For instance, if you wish to talk and read, then the > other person > needs to listen and type. Establishing the media is > only half the > battle. He still needs to use them as intended. > > Putting the info in the SDP doesn't ensure that it > will be rendered to > the user in the device UI. > > Is this important? Or, once the necessary media have > been established, > can we count on the two ends to figure out how to > behave with each other. > > [GH] The current draft contains a brief specification that > the language > indications should be provided to the calling and > answering users. > > > Sure. But that probably isn't normative (since it is about the > UI, not the protocol), and in any case it would only be > binding on those who support this. There is a strong > possibility that this will be treated as something that is > only applicable to a niche market. > > Is there something that we can do to encourage widespread > implementation of this draft? Making it something valuable to > all would be one way. (Eliminating the "press 1 for Spanish" > query might provide that motivation.) > > 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 > > > _______________________________________________ > 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 --------------090703090308050805070904 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Den 2015-11-07 kl. 16:55, skrev Bernard Aboba:
Gunnar said: 
"That is the hard-of-hearing or deaf person who experience that the lip-reading support achieved when you see well synced video image of the person talking is of value for understanding."

[BA] In this case, it would probably make sense to Offer audio and video m-lines in a Lip-Sync (LS) group as defined in https://tools.ietf.org/html/rfc5888

That requires indicating spoken language in audio both ways, and indication of reception of spoken language in video.

[BA] Not sure what it means to negotiate spoken language in video.  For example, if the Answerer does not indicate that it can send spoken language in video, is this a problem?  Or is this just a way to indicate that the video is important? The presence of a lip-sync group seems like enough of an indication that the video is intended to sync with the audio m-line.
[GH]
Section 6.2 in the real-time slim draft already says:
 Note that while signed language tags are used with a video stream to
   indicate sign language, a spoken language tag for a video stream in
   parallel with an audio stream with the same spoken language tag
   indicates a request for a supplemental video stream to see the
   speaker.

[GH] The lip-sync group is a good feature, but I think it is good that we have a way to specify the need for lip-reading possiblity from a language point of view.
Bernard asks: " For example, if the Answerer does not indicate that it can send spoken language in video, is this a problem? "
[GH] The other way around is reassuring. Indication of sending spoken language in video can make the lip-reading depending caller assured that the call has good opportunities to be smooth.

If the indication of sending of spoken language in video is not there in the answer, it can be an alerting indication that the user or its terminal or service provider may need to make some additional measures to make the call flow well. E.g. add a relay service, start out with an explanation that text might be needed some times  etc.

This discussion leads to another interesting case.

Assume that the person with preference for lip-reading supported spoken language want to express a clear fall-back option meaning:
"If you cannot provide a view of you while talking, then I still want to talk, but I want to receive real-time text."
I think that the caller would then indicate reception of written language in the text stream, but with lower absolute preference than for the spoken language in video.


How can we code this absolute level of preference? The need for it has popped up as a result in many of the use cases now. A coarse coding of absolute level of preference is likely sufficient. High, medium and low or so.  We are not yet quite sure that we manage without a very specific grouping specification, but for some cases it is evident that a simple absolute preference is sufficient.

In the draft, section 3.2, there is a paragraph
"
 
In an offer, each language tag value MAY have an asterisk appended as
   the last character (after the registry value).  The asterisk
   indicates a request by the caller to not fail the call if there is no
   language in common."

I don't know if this syntax is really recommendable for the non-fail indication, so I think that should be discussed.
Would it be better with a clearly separate parameter in the humintlang attribute, in order to not create any collision with coding of the language tag itself? 

The coding could be extended to indicate the absolute preference. Just to have a starting proposal, I suggest to handle it as a separate parameter in the Humintlang attribute, with possible values: Fail, Hi, Med, Lo   
Fail= fail the call if you cannot meet this language preference.
Hi= very desirable language
Med = Good alternative
Lo = Wanted if you cannot meet my other higher prioritized preferences
Specify just modality.

I imagine that we will have cases of users who find it cumbersome to specify languages and would like to only specify modality for language use and preference.
Proposal, just omit the language tag and make sure a modality parameter is there
Values:
text
sign
speech


Syntax. e.g.
a=humintlang-send: [<lang>] [/<modality>][/<priority>]


/Gunnar
 









On Fri, Nov 6, 2015 at 6:42 PM, Gunnar Hellström <gunnar.hellstrom@omnitor.se> wrote:
Moving on. ( I think that Paul's proposal to motivate use by that it reduces the number of times you need to listen through a voice menue is excellent. )

Another use case came to my mind.

That is the
hard-of-hearing or deaf person who experience that the lip-reading support achieved when you see well synced video image of the person talking is of value for understanding.

That requires indicating spoken language in audio both ways, and indication of reception of spoken language in video.
Indication of all three having high priority would be good to indicate that they are all needed.

So, would it also here be sufficient to indicate:
Spoken language reception in audio with high priority.
Spoken language transmission in audio with high priority
Spoken language reception in video with high priority

This is for when the user really finds it important t see the person talking, and does not feel it being sufficient with only audio. Then the three media should have the same priority.

There are of course variations in reality, when either of these languages can be sacrificed relatively easily, and therefore be indicated with lower priority.

Can we have an application rule for composing the indications saying that
If the user has different needs in different directions, it might be sufficient to declare the need in directional language tags.

/Gunnar







Den 2015-11-06 kl. 04:59, skrev Paul Kyzivat:
On 11/5/15 5:54 PM, Gunnar Hellström wrote:

There are two distinct but related issues here:

- ensuring that the necessary media are established for the desired
modalities

- communicating to the other party what modality is desired.

For instance, if you wish to talk and read, then the other person
needs to listen and type. Establishing the media is only half the
battle. He still needs to use them as intended.

Putting the info in the SDP doesn't ensure that it will be rendered to
the user in the device UI.

Is this important? Or, once the necessary media have been established,
can we count on the two ends to figure out how to behave with each other.
[GH] The current draft contains a brief specification that the language
indications should be provided to the calling and answering users.

Sure. But that probably isn't normative (since it is about the UI, not the protocol), and in any case it would only be binding on those who support this. There is a strong possibility that this will be treated as something that is only applicable to a niche market.

Is there something that we can do to encourage widespread implementation of this draft? Making it something valuable to all would be one way. (Eliminating the "press 1 for Spanish" query might provide that motivation.)

    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


_______________________________________________
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
--------------090703090308050805070904-- From nobody Sat Nov 7 13:17:56 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 743F11B3732 for ; Sat, 7 Nov 2015 13:17:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.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, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=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 y92Ug87LUTrv for ; Sat, 7 Nov 2015 13:17:54 -0800 (PST) Received: from mail-yk0-x22a.google.com (mail-yk0-x22a.google.com [IPv6:2607:f8b0:4002:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B10B1B3730 for ; Sat, 7 Nov 2015 13:17:54 -0800 (PST) Received: by ykba4 with SMTP id a4so218026501ykb.3 for ; Sat, 07 Nov 2015 13:17:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3Qxwv4Kk0I08iI1Crfv9GED/5PBuEfhLppZTqNQIPOc=; b=YJaXlPo7DEEYNIelDJj0EIEgwnSW2Vt4HBnkkyuWKFZkawtVmXUUQozLrrxWZmae+Y YWCS8if2+PK2xyeMl7lVumkf8ZcMnKIynE8zI/BwzEp+D2VxyRgNt/9bJ3aErDK17A9s +CM8410zZdwNtTVt1B6Rv34XfLXFNlfw5YmCyAPjRd0Eif3bLSqCxVi2vH3WYUfv059k WCB2B7y3CvBvgGed8d9daBCZuPvJzn6IKMJoYNz3Kf68QKzUDessanPdl9wWVvswt6Fk W8+i/ZDhkIYNDgLnkW+X2Rvthdjfp8w/Davy+FtJlWiBQQHuUTGM20LXVdILzlxsYVAV I46g== X-Received: by 10.13.239.131 with SMTP id y125mr16344229ywe.318.1446931073553; Sat, 07 Nov 2015 13:17:53 -0800 (PST) Received: from [10.1.93.63] (mobile-166-172-189-166.mycingular.net. [166.172.189.166]) by smtp.gmail.com with ESMTPSA id v4sm5056609ywf.5.2015.11.07.13.17.51 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 07 Nov 2015 13:17:52 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-9C8AEBA2-BBF3-4075-BC9B-34EF03D3C068 Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPhone Mail (13B143) In-Reply-To: <563E58EC.3090304@omnitor.se> Date: Sat, 7 Nov 2015 16:17:51 -0500 Content-Transfer-Encoding: 7bit Message-Id: References: <563818F9.2060709@alum.mit.edu> <56388C4D.4090808@omnitor.se> <56398719.7030205@omnitor.se> <21767FCE-C1BD-4C42-A07E-16BC81586073@gmail.com> <563A2A24.2020102@alum.mit.edu> <44BE7894-2944-42FE-A136-ADB629D49143@gmail.com> <563B04A5.4040407@omnitor.se> <563B79F2.1010608@alum.mit.edu> <563BDE10.5050305@omnitor.se> <563C25AD.3050801@alum.mit.edu> <563D3AF5.1020608@omnitor.se> <563E58EC.3090304@omnitor.se> To: =?utf-8?Q?Gunnar_Hellstr=C3=B6m?= Archived-At: Cc: slim@ietf.org Subject: Re: [Slim] Handling the complex multi-media cases X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 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, 07 Nov 2015 21:17:55 -0000 --Apple-Mail-9C8AEBA2-BBF3-4075-BC9B-34EF03D3C068 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Nov 7, 2015, at 3:02 PM, Gunnar Hellstr=C3=B6m wrote: > If the indication of sending of spoken language in video is not there in t= he answer, it can be an alerting indication that the user or its terminal or= service provider may need to make some additional measures to make the call= flow well. E.g. add a relay service, start out with an explanation that tex= t might be needed some times etc.=20 [BA] yes, the Offerer might need to communicate needs out-of-band, since the= Answerer probably lacks the ability. > This discussion leads to another interesting case.=20 >=20 > Assume that the person with preference for lip-reading supported spoken la= nguage want to express a clear fall-back option meaning: > "If you cannot provide a view of you while talking, then I still want to t= alk, but I want to receive real-time text." > I think that the caller would then indicate reception of written language i= n the text stream, but with lower absolute preference than for the spoken la= nguage in video. [BA] Given potential issues that could arise with video in event of loss or b= ad lighting, might it make sense to have RTT just in case? Systems are incre= asingly supporting text by default (realtime or not) for this debugging/fall= back reason. > We are not yet quite sure that we manage without a very specific grouping s= pecification, but for some cases it is evident that a simple absolute prefer= ence is sufficient.=20 [BA] So far, existing grouping types (e.g. LS) seem adequate - or is there a= use case that suggests the need for another grouping?= --Apple-Mail-9C8AEBA2-BBF3-4075-BC9B-34EF03D3C068 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Nov 7, 2015, at 3:02 PM,= Gunnar Hellstr=C3=B6m <gu= nnar.hellstrom@omnitor.se> wrote:

=
If the indication of sending= of spoken language in video is not there in the answer, it can be an alerting indication that the user or its terminal or service provider may need to make some additional measures to make the call flow well. E.g. add a relay service, start out with an explanation that text might be needed some times  etc.

[BA] yes, the Offerer might need to communicate n= eeds out-of-band, since the Answerer probably lacks the ability.

This= discussion leads to another interesting case.

Assume that the person with preference for lip-reading supported spoken language want to express a clear fall-back option meaning:
"If you cannot provide a view of you while talking, then I still want to talk, but I want to receive real-time text."
I think that the caller would then indicate reception of written language in the text stream, but with lower absolute preference than for the spoken language in video.
<= /span>

[BA] Given potential issues that cou= ld arise with video in event of loss or bad lighting, might it make sense to= have RTT just in case? Systems are increasingly supporting text by default (= realtime or not) for this debugging/fallback reason.

We are not yet qui= te sure that we manage without a very specific grouping specification, but for some cases it is evident that a simple absolute preference is sufficient.

[BA] So far, existing grouping types (e.g. LS= ) seem adequate - or is there a use case that suggests the need for another g= rouping?
= --Apple-Mail-9C8AEBA2-BBF3-4075-BC9B-34EF03D3C068-- From nobody Sat Nov 7 15:13:27 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1263C1B2D2C for ; Sat, 7 Nov 2015 15:13:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 PrKIhKkOLqus for ; Sat, 7 Nov 2015 15:13:23 -0800 (PST) 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 2AC0A1B2C64 for ; Sat, 7 Nov 2015 15:13:22 -0800 (PST) X-Halon-ID: 1ed811ab-85a5-11e5-8d2f-0050569116f7 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.48] (unknown [83.209.226.9]) by bin-vsp-out-03.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Sun, 8 Nov 2015 00:13:13 +0100 (CET) To: slim@ietf.org References: <563818F9.2060709@alum.mit.edu> <56388C4D.4090808@omnitor.se> <56398719.7030205@omnitor.se> <21767FCE-C1BD-4C42-A07E-16BC81586073@gmail.com> <563A2A24.2020102@alum.mit.edu> <44BE7894-2944-42FE-A136-ADB629D49143@gmail.com> <563B04A5.4040407@omnitor.se> <563B79F2.1010608@alum.mit.edu> <563BDE10.5050305@omnitor.se> <563C25AD.3050801@alum.mit.edu> <563D3AF5.1020608@omnitor.se> <563E58EC.3090304@omnitor.se> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <563E8589.9030600@omnitor.se> Date: Sun, 8 Nov 2015 00:13:13 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------070708000504060508070804" Archived-At: Subject: Re: [Slim] Handling the complex multi-media cases X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 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, 07 Nov 2015 23:13:27 -0000 This is a multi-part message in MIME format. --------------070708000504060508070804 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Den 2015-11-07 kl. 22:17, skrev Bernard Aboba: > On Nov 7, 2015, at 3:02 PM, Gunnar Hellström > > wrote: > >> If the indication of sending of spoken language in video is not there >> in the answer, it can be an alerting indication that the user or its >> terminal or service provider may need to make some additional >> measures to make the call flow well. E.g. add a relay service, start >> out with an explanation that text might be needed some times etc. > > [BA] yes, the Offerer might need to communicate needs out-of-band, > since the Answerer probably lacks the ability. > >> This discussion leads to another interesting case. >> >> Assume that the person with preference for lip-reading supported >> spoken language want to express a clear fall-back option meaning: >> "If you cannot provide a view of you while talking, then I still want >> to talk, but I want to receive real-time text." >> I think that the caller would then indicate reception of written >> language in the text stream, but with lower absolute preference than >> for the spoken language in video. > > [BA] Given potential issues that could arise with video in event of > loss or bad lighting, might it make sense to have RTT just in case? > Systems are increasingly supporting text by default (realtime or not) > for this debugging/fallback reason. [GH]Yes, connecting all three media is always good, and we do not want to encourage any weakening of that ambition. We just want to indicate what the media are intended for, and how important it is to support them and the intended use of them for language communication. Other use of the media is always welcome, as well as variations in use for language during the call by mutual agreements between the call participants even if it was not indicated from the beginning. > >> We are not yet quite sure that we manage without a very specific >> grouping specification, but for some cases it is evident that a >> simple absolute preference is sufficient. > > [BA] So far, existing grouping types (e.g. LS) seem adequate - or is > there a use case that suggests the need for another grouping? [GH] Yeah, possibly. I would hope that we did not need that level of complexity. The LS grouping type for lip-reading seems to be a possible solution for indication of same level of priority for including audio and video, and also arranging sync on them. Streching the logic severely, we can also apply LS grouping for indication of a preference for captioned telephony support. The normal action of that service is to add real-time text as soon as possible as a written form of the spoken language in the audio stream. The latency is probably most often between 4 and 8 seconds. So, it does not hold exactly as "synchronized", but at least has the ambition to be rapid. Some other use cases only need to indicate grouping of language and modality in a group where the value lies in using all media in the group, but not requiring any sychronization. That is the case with the deafblind user wanting to use sign language in video out and text back. I imagined that we could say that implementations should scan sdp for a humintlang-send and a humintlang-recv with same priority and view them as a group that should be supported together. But a new kind of RFC 5888 grouping might do the same job. Also the hard-of-hearing user who want to use spoken out and text back can be seen as that kind of grouping just for the sake of being needed both. And that is different from the hearing person who want to express preference for using spoken language both ways, but an acceptance on lower priority level to use text both ways. That is no grouping, just prioritizing. I have not grasped yet if there will be any complication if we want to have two or more language usages of different priority on the same medium, and they need to be grouped with different media. ....... How about this example ( maybe we are stepping over the borderline for what is feasible to expect that users want to express here,.... A hard-of-hearing person in USA manages well with spoken Spanish in audio with a video view of the other party for complementing hearing with some lip-reading. But it is harder for this person with lip-reading in English. So he wants to offer also spoken English out and reception of written English in the text stream. That is two alternative groupings. Not totally unrealistic. There is not much use in setting very different absolute priorities on them. Instead it is the capabilities of the other party that will cause a selection. Can this grouping be expressed in any realistic way without conflicts? /Gunnar > > > _______________________________________________ > 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 --------------070708000504060508070804 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Den 2015-11-07 kl. 22:17, skrev Bernard Aboba:
On Nov 7, 2015, at 3:02 PM, Gunnar Hellström <gunnar.hellstrom@omnitor.se> wrote:

If the indication of sending of spoken language in video is not there in the answer, it can be an alerting indication that the user or its terminal or service provider may need to make some additional measures to make the call flow well. E.g. add a relay service, start out with an explanation that text might be needed some times  etc.

[BA] yes, the Offerer might need to communicate needs out-of-band, since the Answerer probably lacks the ability.

This discussion leads to another interesting case.

Assume that the person with preference for lip-reading supported spoken language want to express a clear fall-back option meaning:
"If you cannot provide a view of you while talking, then I still want to talk, but I want to receive real-time text."
I think that the caller would then indicate reception of written language in the text stream, but with lower absolute preference than for the spoken language in video.

[BA] Given potential issues that could arise with video in event of loss or bad lighting, might it make sense to have RTT just in case? Systems are increasingly supporting text by default (realtime or not) for this debugging/fallback reason.
[GH]Yes, connecting all three media is always good, and we do not want to encourage any weakening of that ambition. We just want to indicate what the media are intended for, and how important it is to support them and  the intended use of them for language communication.  Other use of the media is always welcome, as well as variations in use for language during the call by mutual agreements between the call participants even if it was not indicated from the beginning.  

We are not yet quite sure that we manage without a very specific grouping specification, but for some cases it is evident that a simple absolute preference is sufficient.

[BA] So far, existing grouping types (e.g. LS) seem adequate - or is there a use case that suggests the need for another grouping?
[GH] Yeah, possibly. I would hope that we did not need that level of complexity.
The LS grouping type for lip-reading seems to be a possible solution for indication of same level of priority for including audio and video, and also arranging sync on them.

Streching the logic severely, we can also apply LS grouping for indication of a preference for captioned telephony support. The normal action of that service is to add real-time text as soon as possible as a written form of the spoken language in the audio stream. The latency is probably most often between 4 and 8 seconds. So, it does not hold exactly as "synchronized", but at least has the ambition to be rapid.

Some other use cases only need to indicate grouping of language and modality in a group where the value lies in using all media in the group, but not requiring any sychronization.
That is the case with the deafblind user wanting to use sign language in video out and text back.  I imagined that we could say that implementations should scan sdp for a humintlang-send and a humintlang-recv with same priority and view them as a group that should be supported together.  But a new kind of RFC 5888 grouping might do the same job.

Also the hard-of-hearing user who want to use spoken out and text back  can be seen as that kind of grouping just for the sake of being needed both.

And that is different from the hearing person who want to express preference for using spoken language both ways, but an acceptance on lower priority level to use text both ways. That is no grouping, just prioritizing.

I have not grasped yet if there will be any complication if we want to have two or more language usages of different priority on the same medium, and they need to be grouped with different media. .......  How about this example ( maybe we are stepping over the borderline for what is feasible to expect that users want to express here,....
A hard-of-hearing person in USA manages well with spoken Spanish in audio with a video view of the other party for complementing hearing with some lip-reading.
But it is harder for this person with lip-reading in English. So he wants to offer also spoken English out and reception of written English in the text stream.
That is two alternative groupings. Not totally unrealistic. There is not much use in setting very different absolute priorities on them. Instead it is the capabilities of the other party that will cause a selection.   Can this grouping be expressed in any realistic way without conflicts?

/Gunnar







_______________________________________________
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
--------------070708000504060508070804-- From nobody Sat Nov 7 18:24:30 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 284521A8AB5 for ; Sat, 7 Nov 2015 18:24:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.201 X-Spam-Level: X-Spam-Status: No, score=-0.201 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 8AgR-JFxqPTk for ; Sat, 7 Nov 2015 18:24:25 -0800 (PST) Received: from APC01-SG2-obe.outbound.protection.outlook.com (mail-sg2apc01on0122.outbound.protection.outlook.com [104.47.125.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD71D1A8AA0 for ; Sat, 7 Nov 2015 18:24:24 -0800 (PST) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=duerst@it.aoyama.ac.jp; Received: from [192.168.1.3] (60.42.129.117) by OS2PR01MB0137.jpnprd01.prod.outlook.com (10.161.77.145) with Microsoft SMTP Server (TLS) id 15.1.312.18; Sun, 8 Nov 2015 02:24:17 +0000 To: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= , References: <563818F9.2060709@alum.mit.edu> <56388C4D.4090808@omnitor.se> <56398719.7030205@omnitor.se> <21767FCE-C1BD-4C42-A07E-16BC81586073@gmail.com> <563A2A24.2020102@alum.mit.edu> <44BE7894-2944-42FE-A136-ADB629D49143@gmail.com> <563B04A5.4040407@omnitor.se> <563B79F2.1010608@alum.mit.edu> <563BDE10.5050305@omnitor.se> <563C25AD.3050801@alum.mit.edu> <563D3AF5.1020608@omnitor.se> <563E58EC.3090304@omnitor.se> From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <563EB249.7020909@it.aoyama.ac.jp> Date: Sun, 8 Nov 2015 11:24:09 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <563E58EC.3090304@omnitor.se> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [60.42.129.117] X-ClientProxiedBy: OS1PR01CA0008.jpnprd01.prod.outlook.com (25.161.225.146) To OS2PR01MB0137.jpnprd01.prod.outlook.com (25.161.77.145) X-Microsoft-Exchange-Diagnostics: 1; OS2PR01MB0137; 2:UWESpPnJCZt9LIgQ2UqIaGmdEjQIG0i0UYnIGdFqHhxwkV8ppZEktmKcQJL4Y7UzwRGFdr0hWr60DSqf7XQD5Bf+8T6Pt5JgC07ec7vlmXzIyO2ahL0I26hq8OGj0qmQnMRzf5WRx1CyT2Ynz9KaJXbImugHytyOtQSEoz8cVYI=; 3:j+0fubj7x7tMTtEBKLBeVuGdPqpOqqpRIE43D8OeSC2tWS1RoDIBN7RAi05Tl8IGNzwPvdRuMxh8pal8z6H4ZISECPqvkvl8Wae0DuU920duJBpfJtCx+JMU+JXXfs1/Dy7ZcjXhR5eMUPE7H+ItjQ==; 25:HB/VNrxn0qRPfjDWKzOhMXfD8qcDWsLBbLXFjySa5AeLMobz175scuoHGZ98i/HS88dfVmoG6cNmVt+4DZPXX1Tk57lWqd1roKDwJX3Rwy3HDReN2OlBBtZ1J4FZ31fBUO477lUQuHQeV72b490Rv0EXKxanIzlFoRBPfWEPjyL4mV2p1CxXaO/tFt58xIV2THXcoCDi7QHsIUqBo3Um88vVgXqqyn9cfQxWpSlVPnyikfYTvhc3Plf/Nxbf6LkXn5bZpsTqVfu5YgJEYZL+ig== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:OS2PR01MB0137; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(2401047)(5005006)(520078)(8121501046)(10201501046)(3002001); SRVR:OS2PR01MB0137; BCL:0; PCL:0; RULEID:; SRVR:OS2PR01MB0137; X-Microsoft-Exchange-Diagnostics: 1; OS2PR01MB0137; 4:iV49WJNspLDqub2pB0oLeiEjUrd0rAKfSij6h3s56Hif4PYwKra5huaqHYAyx+4q+C2uB5EfabMSK/J5OATjeNCnyvOEBsPDEDHVhdEzcyGQmBn1D7gUUky4Hxc+8jW0Tw9leobO1Odp1YsF1HfE0AoT/gk2z/nVwlxM9J4UTItOamxVcGuuAnJZBfJANmWahRkRIEUfYXTFo7C5B1zYXbxWWlkWlAsS68XIoHRaXs9M7DdeUT7gqgWPqF79BmajiI+8RmfaUbZJzEd84R0ijlBjRzKyjRHLpo62MzYAJwI4UQ+lZjWiZq78gnqdXfe0XZktH3BqMOR/shsB5/27UFh7OAAg0EvoWy9s6htniiPRDGkYsudq8Pg2fo9THAGi X-Forefront-PRVS: 0754F7E325 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(6009001)(24454002)(189002)(199003)(479174004)(42186005)(122386002)(40100003)(117156001)(80316001)(19580395003)(59896002)(93886004)(83506001)(23676002)(50466002)(87976001)(64126003)(106356001)(105586002)(86362001)(74482002)(65816999)(5001960100002)(107886002)(101416001)(33656002)(189998001)(54356999)(50986999)(87266999)(2950100001)(5004730100002)(5007970100001)(5001770100001)(81156007)(4001350100001)(97736004)(5001920100001)(47776003)(92566002)(5008740100001)(65956001)(15975445007)(76176999)(77096005)(65806001)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:OS2PR01MB0137; H:[192.168.1.3]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: it.aoyama.ac.jp does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtPUzJQUjAxTUIwMTM3OzIzOnB1dU5mbVdMOERqVFc5QUdqUXVCd2tqU01z?= =?utf-8?B?UkdpRVFFM1U5Ukx3MGdOdEp6TU55LzkyUU9Xa05HY01yLzBaaWFCN2lOWXJv?= =?utf-8?B?blR0cm1FUHBsbCtwYm4wVXE4bG9Ma2t6NnI1bG5xMXJQWE9KODI5QVdTWThS?= =?utf-8?B?ZUhvMWFtVEhnMm04M1NtdlJkNzFxRkhUZnVMMmhIWWFKL0tiV3Vqbnd6amJm?= =?utf-8?B?bVlSSEx3am12ZjNMUmE0eFhnZG5NMnFOS280VkxtTDRyT25zeHM2eWIvOXhM?= =?utf-8?B?UUgvWldnaVZlSFlwQ1RlN2hDVmxYVjF2QVZ5RXNMY0EwajduQmFRQ3VEQUZW?= =?utf-8?B?a0Z0dDNUNkkxdGZabDgvSU9hWVVQNTZoZjFScS9ZTWVrYjljWDZLM3ROcUFU?= =?utf-8?B?MGVFMk54VzBDcmw1UmlpK0hlaTY0MkNpTDJ6WmZrSjhraG1xOTJ2Q1kxZFFn?= =?utf-8?B?QXdSZDVKUGlXanFzam1iQkd3azVRVm16V2ZwVFJVblA1ZEltdnRxaXRjQ3Qv?= =?utf-8?B?YmwvR1Jpejl4L3NUZUNOc1F5TElyaG4vN2gzeVVFaHU2K2syRE9YYUM5TFdX?= =?utf-8?B?dm1BQiswdTdqLzV6cnlGalJMeGRSd1lISi9XWTJVbW01QVA4czh2WWt0M1Za?= =?utf-8?B?c21vRTM5TlJ6YmVYUVNqYkcwdVdRSyt5djVXV1MrZCtKOXQxc2dUdm5Ib3l2?= =?utf-8?B?ajA0MHZqWENPZ2xyQ1JkbDV0Mms1ZWZXVUFEaUt3R3ZoZlVwQnBGNEVObUpj?= =?utf-8?B?QmtaMmJzSUJFTDUzY04zRVRkNFBhREJBQmsyYnF5MjZpK2lGVEdhejM1TEU4?= =?utf-8?B?M1RuSERoOVVVdkYvakYrZkhXa21SRE0zek45ZUJuL3U3eDFJM3ZORXR6YVA0?= =?utf-8?B?Z0VFeFRzM3NYSGtVR3FFelRHaDhnVWxUalJLbWsyek5IZThyODZnRzR4UVZq?= =?utf-8?B?VDltTHdGSzkycGZOTW5QUjkyZkY2L0xmaTA2dGZuemh4Z0F0bWFEUEpZcWVU?= =?utf-8?B?T2tWYVAxMUpSb0lFOGFjVDhiNnRWY2pua1BkM1FxbGhvVXE4OVF3cUJrWElx?= =?utf-8?B?RDh3NWRlL1dxZW1jNWhoaEErTEgyRjhPVkplOHU5UmFxaSt6L1BqSjR0UFlQ?= =?utf-8?B?M05PTERHdUs4TWZSQjRZcVhEVzBTNm9uOERRdlQvaEM5N0wwNHVWSitpMWFF?= =?utf-8?B?R1pQVVhZZDExMENhOTZnYU1GNW9mU2crQ2JzdzVwNThwMklRdHJxbW1MNEtS?= =?utf-8?B?UjcrUTJEUjFtY3diQi9yaTluRmhaWEpSRE1VUGs3Yk04M2VEUlZMYlF6UWVy?= =?utf-8?B?Zk1hMHR6NDltTUJmRW9qaFVkVm16SmhuZXZkWlNxU1g5MlpYV0Nnb0VFWEtr?= =?utf-8?B?MmxnZzlsZWZGa0s2YTJNS0h5QzZQS0J3Vm93NDlzd1FPczlzUHhIdXRRSnJY?= =?utf-8?B?N1lSSDA3ZHZSdGZIMzVRMStyWXg1enQxL1B2V25JQisxT3lKZWxkSW9iY1I1?= =?utf-8?B?SmVoYlVPV1FwNGRJSkJQNW5HdmdKdG5FRVdMQy9UUVBVNGkrWTlzY3U4TEJM?= =?utf-8?B?M2hPOUh6YytEYlpXd2NnQUtrMkR4aXEyMnRySGVIQTZYb3AxWGpiMmpJSWRY?= =?utf-8?B?NXp6TkVCSFVWTmh3Nk1wbFdzZFpYaWprcTQySE56bUo0T0NZZlp1WmRpNHRl?= =?utf-8?B?YXJXVFZ1cklpM25aMmdHMzRlcnJiOGkvUWF1aVMydSs2bjFKTnFsU3VObzdv?= =?utf-8?Q?6/KVtS+rat85+WI1iCI8gKM4qmBdkwUG6SdA8=3D?= X-Microsoft-Exchange-Diagnostics: 1; OS2PR01MB0137; 5:FWH60asSGtAl6bWGOC7pxIWLkPTFTzzmENvHTke78ptxerKxxCcMClxqLvLtG/2RAOE5j3mYi3Fd0V9B2krx1dMQ793QFPceMtJtjljf5jQGEjMvN5xFmUVzLpcqbThrz11b43DCYnyycFG/zwDkkQ==; 24:rzBk48QLYbE94C/GgXsHFjlbhZLObYf3yi053mv0F1d3wyckR0lMgSz9dSJUIuuTYVB4zm4fXwxCxdtHfTXIb6gehT0NwgUIR6dNE/McmIs=; 20:GS991UZMC7vbztV0RV/pNVQgWX7OywFICqktB0SJ5HVCgvjqEd5LdyeiGBb5yyFmoM6fvgITK5yJQ8R3QHwxFw== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Nov 2015 02:24:17.9494 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: OS2PR01MB0137 Archived-At: Subject: Re: [Slim] Handling the complex multi-media cases X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 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, 08 Nov 2015 02:24:28 -0000 On 2015/11/08 05:02, Gunnar Hellström wrote: > In the draft, section 3.2, there is a paragraph Which draft? I thought we are speaking about https://tools.ietf.org/html/draft-ietf-slim-negotiating-human-language-00 but there's no section 3.2 (Section 3 is extremely short). > " > > In an offer, each language tag value MAY have an asterisk appended as > the last character (after the registry value). The asterisk > indicates a request by the caller to not fail the call if there is no > language in common." What exactly is meant with this? Is it something like: en-US, en-AU, fr-CA, * (i.e. essentially the same as the HTTP Accept-Language header)? Or is it something like en-US*, en-AU*, fr-CA* The later would be totally out of line with previous use of language tags and subtags, but it's what I'd guess from a direct reading of the text. Regards, Martin. From nobody Sat Nov 7 21:15:03 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56DFB1B393D for ; Sat, 7 Nov 2015 21:15:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 gqLHCJOgcRKR for ; Sat, 7 Nov 2015 21:15:00 -0800 (PST) Received: from bin-vsp-out-04.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 95CC91B393E for ; Sat, 7 Nov 2015 21:14:59 -0800 (PST) X-Halon-ID: a170d7b0-85d7-11e5-83b0-005056917c0c Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.48] (unknown [83.209.226.9]) by bin-vsp-out-04.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Sun, 8 Nov 2015 06:14:47 +0100 (CET) To: slim@ietf.org References: <563818F9.2060709@alum.mit.edu> <56388C4D.4090808@omnitor.se> <56398719.7030205@omnitor.se> <21767FCE-C1BD-4C42-A07E-16BC81586073@gmail.com> <563A2A24.2020102@alum.mit.edu> <44BE7894-2944-42FE-A136-ADB629D49143@gmail.com> <563B04A5.4040407@omnitor.se> <563B79F2.1010608@alum.mit.edu> <563BDE10.5050305@omnitor.se> <563C25AD.3050801@alum.mit.edu> <563D3AF5.1020608@omnitor.se> <563E58EC.3090304@omnitor.se> <563EB249.7020909@it.aoyama.ac.jp> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <563EDA4A.6050206@omnitor.se> Date: Sun, 8 Nov 2015 06:14:50 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <563EB249.7020909@it.aoyama.ac.jp> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Slim] Handling the complex multi-media cases X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 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, 08 Nov 2015 05:15:02 -0000 Den 2015-11-08 kl. 03:24, skrev Martin J. Dürst: > On 2015/11/08 05:02, Gunnar Hellström wrote: > >> In the draft, section 3.2, there is a paragraph > > Which draft? I thought we are speaking about > https://tools.ietf.org/html/draft-ietf-slim-negotiating-human-language-00 [GH]Yes, sorry, I meant 6.2. There is also an expansion of the topic in 6.3. > > but there's no section 3.2 (Section 3 is extremely short). > >> " >> >> In an offer, each language tag value MAY have an asterisk appended as >> the last character (after the registry value). The asterisk >> indicates a request by the caller to not fail the call if there >> is no >> language in common." > > What exactly is meant with this? > > Is it something like: > > en-US, en-AU, fr-CA, * > > (i.e. essentially the same as the HTTP Accept-Language header)? > > Or is it something like > > en-US*, en-AU*, fr-CA* > > The later would be totally out of line with previous use of language > tags and subtags, but it's what I'd guess from a direct reading of the > text. [GH] Yes, that was also my interpretation. And wondering what was meant. A complete syntax description and example is needed. But also a discussion if this non-fail parameter should be merged with the other priority values that I propose. /Gunnar > > Regards, Martin. > > _______________________________________________ > 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 Sun Nov 8 16:24:37 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F3491B5374 for ; Sun, 8 Nov 2015 16:24:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.099 X-Spam-Level: * X-Spam-Status: No, score=1.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 NKsixWEs--bb for ; Sun, 8 Nov 2015 16:24:34 -0800 (PST) Received: from APC01-SG2-obe.outbound.protection.outlook.com (mail-sg2apc01on0111.outbound.protection.outlook.com [104.47.125.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2BDA1B5370 for ; Sun, 8 Nov 2015 16:24:32 -0800 (PST) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=duerst@it.aoyama.ac.jp; Received: from [133.2.210.64] (133.2.210.64) by OS1PR01MB0134.jpnprd01.prod.outlook.com (10.161.228.15) with Microsoft SMTP Server (TLS) id 15.1.318.15; Mon, 9 Nov 2015 00:24:27 +0000 To: "Phillips, Addison" , =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= , "slim@ietf.org" References: <20151103125549.665a7a7059d7ee80bb4d670165c8327d.d41148fb15.wbe@email03.secureserver.net> <56391992.9030000@omnitor.se> <212ff0f6c22048e883b9eeb3c0e74672@EX13D08UWB003.ant.amazon.com> From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <563FE7B6.5020800@it.aoyama.ac.jp> Date: Mon, 9 Nov 2015 09:24:22 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <212ff0f6c22048e883b9eeb3c0e74672@EX13D08UWB003.ant.amazon.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [133.2.210.64] X-ClientProxiedBy: OS2PR01CA0022.jpnprd01.prod.outlook.com (25.161.74.160) To OS1PR01MB0134.jpnprd01.prod.outlook.com (25.161.228.15) X-Microsoft-Exchange-Diagnostics: 1; OS1PR01MB0134; 2:w1MJd2GNY8XU/l2G+QBuVF/AoJTJUdhC4nOrUzjxjM9l1tO3fMmG3whllzekc5pKBRV6PywLuxUoyYGX9UHEQGyW6+mdli/QzVEkTk15479k1WTQX+bEcrnSkurEddeSy03ifoogrsaLePbovd8gn56FoXtuDZ0lJy1qz32XtcA=; 3:Glcuf/84l+7qunmQJINuiEmuVU+seXA8m8M86x+AYy/kF0+ixvWbQ+LTAeK9U6Xru9IdJsrQFTV+pZLLv17OLUFqjz/e1WSLzlhLaR0nI/IGvG42crMLfBzP9d1OeJo9tndWcp6MRCQ1o/iff5jw5A==; 25:bTTxXlCXy+6ByfvXo7TLEx5NkyToj9dzqN2yrfCKGqbJH8pWlgJ5wBEOExeDQZRrzDXs6SYA5+vKpK7hd7HxocX8evrEjxKvP8G6mGuSqc0s9gw+CAw8uwTLriMhCAbza/F+14XTwNxMPUmL+jlz5Xu+xPiHTyVneWDtZCIV1g1MGpzW4ag6RwjzNThHGM69ELRMj9oCt5gZgLn603Ic8mSpcm4JE5D4x+QVoD4tEBTMarYfLJwA150IhdivRE4sFcHtnTLiSHeAdhcxR9iBxg== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:OS1PR01MB0134; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(2401047)(520078)(5005006)(8121501046)(10201501046)(3002001); SRVR:OS1PR01MB0134; BCL:0; PCL:0; RULEID:; SRVR:OS1PR01MB0134; X-Microsoft-Exchange-Diagnostics: 1; OS1PR01MB0134; 4:b0tF6Gde4du5XKRaHTkAzZqZrOkXAyeCeC8/1XmQNHwwLbrI1+WJlVlgdrwmsxGcXuBrXu2H5tk7bZUa/8MjsbHo6Zx0UAMN9hXmbVa+gp4Qg/LK1gxX6NSkkHglA63ZFzzQEdkuxjaxclamyp7P8C1P4OoiK5vm+KbxpWor+7aoftzqYQWIoSx09atJD2Xno7YX5+nhLnhLikQHsonNnEO2N0QX1PBwyCqVmnkbZxvnjQFlYW1YhdsParLBgrRdkE/lxfk0AnThhfIauAc+nA8p9IHO7SHTqrrJIi65QcGyQBjS8EN9dXvl28FwqdtYonzUkb2I8h2chXzi8MOUnGir4RGRTgSxb9hzWIvXRpH9ROwDpXRIPcS64eL7Wajp X-Forefront-PRVS: 0755F54DD9 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(6049001)(24454002)(189002)(479174004)(199003)(5008740100001)(66066001)(65956001)(40100003)(83506001)(4001350100001)(97736004)(65816999)(65806001)(122386002)(64126003)(54356999)(5004730100002)(87266999)(23676002)(50466002)(2501003)(5007970100001)(5001770100001)(189998001)(81156007)(47776003)(77096005)(2950100001)(87976001)(50986999)(42186005)(59896002)(76176999)(230700001)(33656002)(5001960100002)(92566002)(74482002)(107886002)(101416001)(106356001)(105586002)(80316001)(86362001)(3940600001); DIR:OUT; SFP:1102; SCL:1; SRVR:OS1PR01MB0134; H:[133.2.210.64]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: it.aoyama.ac.jp does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtPUzFQUjAxTUIwMTM0OzIzOmxneXpObndSSXI2WnRPYXdpVjlrUWhrMzNm?= =?utf-8?B?VDlZNS9BM3dEWEpBa2p4N2JlaGdQT0thQzdybUw5TjVybDhkbU54dDNXS2d6?= =?utf-8?B?dytOK20xbjFiWDgzaEs5cGdMcVgzLzJWTEFhVm1tcTJPYUxISld2bXF1RzZU?= =?utf-8?B?OUt3TXJJMXBUUm9qSktUWGdpYytteGV6ZVpUWUdyU0VsMGUxUFFFbE5jVzhZ?= =?utf-8?B?QU1vTWZaNWVmZmlLWXl1NXByZnlhSXRHMVc0aGp3UzMyejVuWlFDRUtMbFlL?= =?utf-8?B?MTc5QU1EbnZ5ZFFWajNvdmZaSnVDWnFtbExCZHpNeVRaM3lFSi92QjFXN0Rm?= =?utf-8?B?MDNDQVRGc29ZTDlka1FldmxVQ2RLRTdyWmpxQWIrUk1ZaWF3am9sS2lmRENy?= =?utf-8?B?bmY3T3dYUGd1TldTdmtoQlAxOHRGM1JNemtsb1VtTVJSSTZiUllCcDBTRHZP?= =?utf-8?B?M1ZWbHRRNERPM1pCTnA2dHNuZW9scUo1SCs4djNOS2xuU0F2V1VmdFFZanpC?= =?utf-8?B?Mk9aeVQyUTh6NU5FZm5ybTJ1bmE3S1BmUWprZ2lRQU9zTGlKMm9OMTFVK2dK?= =?utf-8?B?MS9JM0xMUVlwUGhkMVpTM0ZGUWwwVHE0MDlMWWFpdDduQ0R1emdRcDdDRUsw?= =?utf-8?B?YVRabktsclNPLzVJVFZwOWFlUUovT0lpRS9zeEJ5clFvOE4zRVZhU3UwY2xU?= =?utf-8?B?RVRBQVNWV2tRdk0rL0pkRWR5dWM3dEQ1ZzJzbXpRK2hpczFNbXhGYU5NTVdM?= =?utf-8?B?MG43eFcycy9ib0hlY3loL01uL0NocENTdUJnTndrTCtSeWJUVGxIWG5FMHBR?= =?utf-8?B?eFR1ZnpST3ZOem9wbnZJMjNNQm5FQkQwdGFTbFFkWGlMcVhDNmNRaEZaOEJD?= =?utf-8?B?SFB1TkplWkNvd3JER0V0YnVrclJiOE5tVFgwNnNVUERaTDh1WFBZdG1qR3pl?= =?utf-8?B?bmFTZTA2YWxpZEFCZTBYb01CQ2dCN0VHZUhOT2JDVURpRFYzcmVSVVdLeXg3?= =?utf-8?B?N2FsN0xmMEdxRzB1aXVnT1F4bHI2OW5mbTRJekZVWnRWNWxyS2VWVGpYeHR3?= =?utf-8?B?QUZxK3dsd2FuVjI5OHc3R0tGSU5tRXJUK1lMYVhsZlR6RHNwWmo4RTE5RTBV?= =?utf-8?B?M2I2bEJla2UyUU04QUJlMVFMUWVhWExLMndXN3NWTFBqUk1Uckl0Um5Zbmsx?= =?utf-8?B?TEdGVENNenMwbWh3eWw2WDgzUm5ZYnZVVXVkVlljVVdIWlEyMnBkWmkrajRp?= =?utf-8?B?OG1NV1pNY2VEaUg2U0tZVmJrOFZpcytiaW1EQ0RpTk9hdmtRQkdjQkQwRHdr?= =?utf-8?B?TWxTczNTNVVEWjlicUl0Qi9icDhsSEJoaFE5dkI0eUExZk5xQTJ6c2VxK1BR?= =?utf-8?B?UFd4MkRXNTl3YWU4RXNXTGZScTE5a3dIalJjMGd5a0tFdlhzaks2Vk5sbDBk?= =?utf-8?B?OEhjaHdOWlBiUURLRStvMHlJWGNjdUpLY25FMzdiNHRsdDQ0c2ZiTGcwNDZN?= =?utf-8?B?bG9QYWJtajRITEZoNTdlUUpSZTAwMithOW51SUpHeHE0a3ZoZWRPek1pRTRi?= =?utf-8?B?MVYrNjBKQStacWxmRTB6cDBRYm4rclByWUNybzFPMWNzYkxRR09XZnFzRlNt?= =?utf-8?B?YnhhUloyZXNIc011MmZZemtDQVZYcUc2OVdPeU9BMkY2dGo2b09vVmRnMnZF?= =?utf-8?Q?4k5ld9MQVjl6YTnzLU=3D?= X-Microsoft-Exchange-Diagnostics: 1; OS1PR01MB0134; 5:Pw28iHDEPrXSLFTQiGIFFZtewvBZu5wMWjbmhw4F6FBfGro66AJjZTc7OY8NZlP/JOA/Hm7WmppAMJS8Yiq79B9XbT+rscOI+l5TTUTKqjoQMa/xY3IL5Tus8mszmcEHWwezD0iGKXyRFIcj8QSKUA==; 24:OQFSQHAY9T9sgSiS25CDWyceFYuxRxEAokEkLSM6YK5zBcw7qmj/FCYZEDGWPwAC3y7qVnELPGMW+PjaA6wzcNDQDH4cul2JMAc53YH/LEM=; 20:pkW/e5pot1DpU+tJdwkLba1AJmkZ5RASSsIYr8P4/CjgSeHDu9H7AieJ4MCx5DP7XiZ7IAl4TW1B7u8JZx5gqw== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Nov 2015 00:24:27.4374 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: OS1PR01MB0134 Archived-At: Subject: Re: [Slim] Primary language tags (was "Re: draft-tomkinson comments") X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 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, 09 Nov 2015 00:24:36 -0000 Hello Addison, On 2015/11/04 06:04, Phillips, Addison wrote: > As such, I guess I don't believe that there is much need to introduce a script subtag merely to say that some set of strings (or collection of pixels) is written. That much is usually obvious from the resource itself. Introducing a subtag artificially to convey this information interferes with tag matching and selection (particularly when the selection is automated from existing content). And when the "difference" being identified is already "obvious" to processing, it's not worth the problems it causes. Use language tags to identify language variation and not as a proxy for Content-Type ;-). I agree with you with respect to tagging content. But language tags are also about requesting content, and there it can make a huge difference whether something is spoken or written. Regards, Martin. From nobody Sun Nov 8 16:29:39 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9C881B3C46 for ; Sun, 8 Nov 2015 16:29:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.099 X-Spam-Level: * X-Spam-Status: No, score=1.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 2gRDQ7lqK8Fx for ; Sun, 8 Nov 2015 16:29:31 -0800 (PST) Received: from APC01-HK2-obe.outbound.protection.outlook.com (mail-hk2apc01on0133.outbound.protection.outlook.com [104.47.124.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A94B1B541E for ; Sun, 8 Nov 2015 16:29:30 -0800 (PST) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=duerst@it.aoyama.ac.jp; Received: from [133.2.210.64] (133.2.210.64) by OS1PR01MB0134.jpnprd01.prod.outlook.com (10.161.228.15) with Microsoft SMTP Server (TLS) id 15.1.318.15; Mon, 9 Nov 2015 00:29:26 +0000 To: Doug Ewell , =?UTF-8?Q?Gunnar=5fHellstr=c3=b6m?= , Randall Gellens , References: <20151103125549.665a7a7059d7ee80bb4d670165c8327d.d41148fb15.wbe@email03.secureserver.net> From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <563FE8DD.9040608@it.aoyama.ac.jp> Date: Mon, 9 Nov 2015 09:29:17 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151103125549.665a7a7059d7ee80bb4d670165c8327d.d41148fb15.wbe@email03.secureserver.net> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [133.2.210.64] X-ClientProxiedBy: HKXPR03CA0053.apcprd03.prod.outlook.com (10.141.129.43) To OS1PR01MB0134.jpnprd01.prod.outlook.com (25.161.228.15) X-Microsoft-Exchange-Diagnostics: 1; OS1PR01MB0134; 2:xWk/NBR1xxafJ0dbCD66vkcOxKF5SeQFed3tFTQaZZZmcfdbp5rcJ2VytmXbOIECDwdbp6nkSWGIYwO3e4fXFqBxR7xWYem3CmzrTRhWlBX/aWkAgIixmc+C3ue1u6QlMv0Pq4pQdDKcbOYHwCJi7oF+6A5d2p3GzI1b3unRMMw=; 3:T7EdZUadF7jgRytf6k11cMZLdEqYDg8Qwow64P4iZdlrOPInKi70lXHUlxoL+oNMYIyhWvhI7FQ/sLtCtNQmkSAt2rswdy3zFGSsKlrp7/MI0torj3VramUqIdZcCY5uUrMfg+/g+Gzbma8qVh1ERQ==; 25:KyEwk+3lFkUb+DBO6duZIV2qFVuKtRDijcSm3x109oKpenLBD28w7dKnG/nOGvkCzfehgq5yfZw5Y65rHz84/KCD4JbHZ3zm5BZpdBtCmUcaKYUc3uCvOYEaSqpOrw53fYkfnC+K/6//rUqMn4Bq9xAfKu2vbsJpAVgS3nTAoE8rB1pBga3b7oonKW6/E1o65YXWqow/N56QKV3PN91vPdEe/Zr6ZEzrdemGuDyEuTsvMX8SBRkVNj3gL1JsLOh/; 4:xqFGrqiGO8g7Sv2BQKLsG+jqkq3/3Tdjqp1JWEut/Ud96vIyybNkH5G1LeJ2oXcwjjj8ixubjCwN6o+NFNrDKB8SYHek5GdMcd9amtp6+S8jgouoHUc9HNKtbGmdG971d76HbgwHv9dQh3HeC22raXg3WAg8/t8KjUJ56aURUK9a+/hpUbKJdNK/AKN98xRlNOCIBh3a7VJCoo7qgllnmrz995/40E8/7+9lMxaM1owAw+3Ek9gwJpyZfI6XqTvJgeELGxfuY3qpSfu7ZWp3OZGRZxxIJUCRU4AcNx+5uJSSI1+DJuVyN+697fDvOAS3uhQOvX4bcD8Iq6mLl1RzP7IevrrgfRwIBI4GtlrJyxfJdj/ef/sNlWmqdW5LXQ4j X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:OS1PR01MB0134; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(2401047)(520078)(5005006)(8121501046)(10201501046)(3002001); SRVR:OS1PR01MB0134; BCL:0; PCL:0; RULEID:; SRVR:OS1PR01MB0134; X-Forefront-PRVS: 0755F54DD9 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(6009001)(479174004)(189002)(199003)(24454002)(33656002)(76176999)(5001960100002)(92566002)(42186005)(59896002)(101416001)(86362001)(106356001)(105586002)(80316001)(107886002)(74482002)(65816999)(65806001)(122386002)(64126003)(23676002)(50466002)(54356999)(5004730100002)(87266999)(65956001)(66066001)(5008740100001)(4001350100001)(97736004)(83506001)(40100003)(47776003)(77096005)(189998001)(81156007)(50986999)(87976001)(2950100001)(5001770100001)(5007970100001)(3940600001); DIR:OUT; SFP:1102; SCL:1; SRVR:OS1PR01MB0134; H:[133.2.210.64]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: it.aoyama.ac.jp does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtPUzFQUjAxTUIwMTM0OzIzOlY1a3dyVFhVRkFpVTdGN3lvRFI2SFZpaFIz?= =?utf-8?B?OU1MSjYxaFFKbXFUMXR0bmwxaEkxTXl2UUVGc1lzQ1gvUnhLbkd1RnFRcEhv?= =?utf-8?B?RVZEMTdtU0hTbC81YkRwY2IyV01XWWJWanJNVGQwRlBsWE5EdXM5ZmdBaWdI?= =?utf-8?B?NVBBcEdqRWZ2YXhvNHkvOHVNNGRKek1LSkprSGIyTG55V2oxK1cwcGp3MWNx?= =?utf-8?B?UnRrNm1RUkZnQ2ZuK250clZyTENTYzNXeGpDaUhJeUNHY1BIOHNHMzBoa3cy?= =?utf-8?B?L1gwUEEzSXVOaTEybDViYUQrdUpWMTU4dm9GMURUMGp5SkZYM1NmNko2UkJ5?= =?utf-8?B?UUoxcHdKTUFCSmJPVWxKVDF5SlMrQzRJR3NnWHZwS1BIMlRjZWxjcGdhdEpN?= =?utf-8?B?eS9iZ2ZtWnFvanU2YWRWYVFYdEdReTZsNGlqcHNXZjBYOERDL0V1ZngrNWIx?= =?utf-8?B?dXhpL1RxM3F2bS9ONVFFTk0rb3pQQ1I2dUFPVjhGMm9QY2E5YUl0aU15RG5L?= =?utf-8?B?Ly84NllyUTkzQjB5cFhTSjRGbmVtUENVdEg2OUE3QVdKQWJyY2xkV1RnTjZZ?= =?utf-8?B?dnFwVW5VNG5jZVBXL2FQR3ZabTdESWZjKzA5aXRadUNFb3B6MVdRQ25EbHpQ?= =?utf-8?B?c1UyamNvKzBPNXo1bDZVeVZESnpLQk9ERHRSYXY0N1NqTkdrTG8vV1RqdEVo?= =?utf-8?B?Q3dNMjJjWStvUG1uVFR2QWg1anUzOFBBM0ZrSlR2Wko0eWtDMEJLZ2RJS1JR?= =?utf-8?B?L0NoL0o3bVNtUHpwemV4QU1nTEJnTktuZkJDSFo5bDVFTWoyU25RM0ZsWEJS?= =?utf-8?B?cURXTWdRQkJNU1c0cE5MRzRrSjBqbUNiTGZLOG81WlJGSU9mOXpnVDdCKzBX?= =?utf-8?B?WWh2NGl6L0M4WStnSUx5WGN0SyszTWhHUUFtWllCcnY4cllaT2Nra3h0bG9p?= =?utf-8?B?eWJFa3Q2bUdoaGhva3l3bDhReHVjVkNJUWs1T095R2tLWEdVc0JiZExiUEFq?= =?utf-8?B?Yk15N1lHWXJHMS9LeklkN25hVWRWMDlVT2JPOEpLbXIzRUovNHFVa2QxaDdG?= =?utf-8?B?RUFmMFVxcXRPV083KzBFWFZlRUd1OXlhVHZGYWwrUmQzSWNaSXdXNW9EWUI3?= =?utf-8?B?YTBvTDQ1c0tZS00xb3c5NFBXdWhTVXlXa0Q3cU04RnllVWJpM0lTeXZpNmlt?= =?utf-8?B?MkkxTXcvTnFabFZUOFV1YlA0TndxaG1NOEVjNTlJdXhTQ2Q1b3dtQnRoeFVw?= =?utf-8?B?K21JVDdJOEwralZET2pqQjJIOXhzWndScGdnKzJHYTRtcVkvV3p6V0RIdmE2?= =?utf-8?B?VExYUEJGaldqV3paczN1Q21udnFnL05YbEtueEY0dnRFbUVWZnhaT29OYzB0?= =?utf-8?B?TFYvd3N0aEo3QUViNWowVHNqOHpVSWVBQmZURHorM1hJOXgwOHM2ZnF4cVht?= =?utf-8?B?U1FtU0d0UFZVZnRlQ2I2am93eHJMamZDUWNKdlNJZ2R2blA5M0p0WEtuQURs?= =?utf-8?B?WlhLMU9HWW9MT2d6MklNU1hWUmM4b21wWU5mZktCQUY5VkVrUHVwanM5STEz?= =?utf-8?B?MzBjdDZDRU1SOUFKQ3lrYnRrTExkakY3dkQ1WVoxRjRXMlBHSDF1R1VrN0Fo?= =?utf-8?Q?DaEWjgehlKBYqjbkCwjH?= X-Microsoft-Exchange-Diagnostics: 1; OS1PR01MB0134; 5:BvGLBaJjosxzMhksJh4X50vHFIAApERGcApFPvy3C6daGPjICuoHwqUm76TnilTfnPAkxyO6GitLjf9OtX0coHTuTXkZ2bMcbxhy2psuaTCDHpscMvYyOY2usjgynTQcxlgCnMYurBwGVoI0+mii/w==; 24:qCh3tTpyNDBVMrmyMeVE7cYMW1pUKXJA3CvICkHwUnUqHafFn8x0jrxEN+i+HB8Akdo0CfaEVarkrnobv1WdWonWCLcl75El3JhGiFMQJF0=; 20:3cossDklEF3pppR48fui8RQNU5LIQufLUIhvHec8RtiSPRfIZttOAfZe7kw0J/CXOnziyNxrtQmOOJeIZd6SVw== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Nov 2015 00:29:26.5661 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: OS1PR01MB0134 Archived-At: Subject: Re: [Slim] Primary language tags (was "Re: draft-tomkinson comments") X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 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, 09 Nov 2015 00:29:37 -0000 On 2015/11/04 04:55, Doug Ewell wrote: > Gunnar Hellström wrote: > >> How would the difference between spoken and written best be expressed >> in an extended BCP47? > > Without expressing any opinion about the use case itself with regard to > SLIM, I'll point out that there are basically three possible ways to do > this conformantly: > > 1. Private-use subtags (e.g. en-x-spoken, en-x-written) > 2. Variant subtags (e.g. en-spoken, en-written) > 3. Registered extension (e.g. en-m-spoken, en-m-written) > > This would involve writing and publishing an RFC to define an extension > for "modality" together with an initial list of values, as per Section > 3.7. Extensions have been created so far to denote attributes that are > more closely associated with locales than with languages per se, so > there might be some support for this approach. It would, however, > involve the usual lengthy RFC gestation period. Please note that the SLIM WG is already working on one or more RFCs, and that such an extension could be added as part of an RFC, there would not be a need to have it as a separate RFC. Also please note that while the gestation periods for the RFCs in the LTRU WG have been quite lengthy (several years), that's not necessarily the case in every WG. So I personally could very well see a registered extension for this use case. Regards, Martin. From nobody Sun Nov 8 16:32:57 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01C6E1B5496 for ; Sun, 8 Nov 2015 16:32:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.099 X-Spam-Level: * X-Spam-Status: No, score=1.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 2QFXUBFvUQkJ for ; Sun, 8 Nov 2015 16:32:53 -0800 (PST) Received: from APC01-PU1-obe.outbound.protection.outlook.com (mail-pu1apc01on0116.outbound.protection.outlook.com [104.47.126.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32F2C1B5494 for ; Sun, 8 Nov 2015 16:32:52 -0800 (PST) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=duerst@it.aoyama.ac.jp; Received: from [133.2.210.64] (133.2.210.64) by TY1PR01MB0144.jpnprd01.prod.outlook.com (10.161.134.148) with Microsoft SMTP Server (TLS) id 15.1.318.15; Mon, 9 Nov 2015 00:32:48 +0000 To: "Phillips, Addison" , =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= , "slim@ietf.org" References: <20151103125549.665a7a7059d7ee80bb4d670165c8327d.d41148fb15.wbe@email03.secureserver.net> <56391992.9030000@omnitor.se> <212ff0f6c22048e883b9eeb3c0e74672@EX13D08UWB003.ant.amazon.com> <563FE7B6.5020800@it.aoyama.ac.jp> From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <563FE9AA.4090108@it.aoyama.ac.jp> Date: Mon, 9 Nov 2015 09:32:42 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <563FE7B6.5020800@it.aoyama.ac.jp> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [133.2.210.64] X-ClientProxiedBy: OS1PR01CA0022.jpnprd01.prod.outlook.com (25.161.225.160) To TY1PR01MB0144.jpnprd01.prod.outlook.com (25.161.134.148) X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB0144; 2:Um3F4niSHdIQ81TDWRztVnITFA6POSorfX2VdYKSxJBftq1GoHqh9TUGphvheP3KCIrfhlyYltmn5UofMRx2/6DZbBsanCfqTOz4WAb70gVB1aivD9hSgg9kQ9G9J5LdiH02Lppt8XA7mBlsDOMHfJrkt4UxTCvOpcuDP3+zncc=; 3:GdGD1roPgtrmynqIcSmcsz4vJ1smFHzNrK+QRTNvcIjkK+yemLOtLOlrBGaLF51jL+6g67QnYmH7WFV/XyrtEHxSOCZTX+hMKA3ERxETgc85Ccjf+Q3XVhKkSsSHDbtzwNyEaCtCVUkMJxzS78NDjw==; 25:SUIkE8kDRokWKvTSndb17lYM4fCkmOA9eGMW+fCK1pP2PWPX9+nrMxHlKZBkBMl3piCqeQirshi3xgHMCphs/by6v9YG0ZetMitwp5/Xi5q35kNnlPVp7LvkiSsMkRWEl5WUglhWNXWNKWzaY5OS6EKPWRNT1MG68RyWc+XmZMfQRriEI5biPtKj7Z0grmCRuz+p7PnN27DO74E808F6sl289wPmnYX73fElm+L8awFfgKltJi/bD3XpKHh6ZBfxMuGpUJk9/lf0rLoQ2Zukvg== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:TY1PR01MB0144; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(2401047)(5005006)(520078)(8121501046)(10201501046)(3002001); SRVR:TY1PR01MB0144; BCL:0; PCL:0; RULEID:; SRVR:TY1PR01MB0144; X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB0144; 4:+Lv2F/fYkdqzq2TOxlcFdmq79yyRNVkpCMUpEzjCys01I1PMR9nnukjzS/eZyZmd7WvZpRnGzJYbeH/Ezdp9I4YTTYtprxQtKe7e3aV1YFenHNszfS60YGQWAKTg6AXoHWuGniOHlmCHUNU2RU7fzlMmBTQCL6hZcKWMUCY56OcYQ7XMLP+8MbGBVctYX4FK8bvbQHXO5hkisKIooS4jvzmNOF8MwYgWVdepZ08rvbXUb0d4UMqMnVXsHeMQuhGSqBBhHLzpjt/MVHGyhOE5lTxyU56yjjoilPFqaGxREf1bdT5tK/FxTk0b/cVsCq2cy5FVNarxWXrVSDhgqFkNiN7Htf7wiklxYt2uUc/8EGAeOXUG5tyb+3sdzXIlbHkr X-Forefront-PRVS: 0755F54DD9 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(6009001)(199003)(479174004)(189002)(24454002)(106356001)(80316001)(77096005)(83506001)(65956001)(66066001)(59896002)(65806001)(23676002)(5001960100002)(122386002)(92566002)(105586002)(107886002)(2950100001)(47776003)(5007970100001)(86362001)(5001770100001)(2501003)(54356999)(87266999)(93886004)(5008740100001)(50986999)(101416001)(65816999)(76176999)(189998001)(4001350100001)(5004730100002)(33656002)(64126003)(40100003)(87976001)(42186005)(50466002)(81156007)(74482002)(97736004)(3940600001); DIR:OUT; SFP:1102; SCL:1; SRVR:TY1PR01MB0144; H:[133.2.210.64]; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: it.aoyama.ac.jp does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtUWTFQUjAxTUIwMTQ0OzIzOnZGclBKWTV0V09WbGVLcDVyWXRDT2ZIRmxR?= =?utf-8?B?T3MwU3Jadnk3U21wa0lqZXE0aW9VK3QyUVJkcCtYOExwaE9DUmorekl6QlZF?= =?utf-8?B?SGwrcFBoRDZGOWs2TnRHMzREVmNCZnBWTzZ4MlhxYXlIci9sSHB2MitqZmx4?= =?utf-8?B?Y05rc0E4ekpqVVV4Ly8yOVJiOG5RZlR2Sk5pMFRyQmo3bGVRb1E0NVRQbDVn?= =?utf-8?B?Nm9Ka1VkSDg4Vml2KzI0eWYzVWcwODZ5Tlk4UGR6THpDTlloaHFSKzBiUmtZ?= =?utf-8?B?Qk9NbHFtMStrdEJHak1TemZKc29hYlJ2TXdvT0pDZTI0ODJvMkcyY1lJbXpw?= =?utf-8?B?QUN1QURXa2dDam1NekJuNlZoS2w2UXN2T2VFQ0JZUmtHUi9HYmVINThzaGh3?= =?utf-8?B?KzloaVRNY0xPSkl2Z1lPU0lUMUdkWGxHSmQxcEFiYzFlbEkyT3F1ZS9EMVF1?= =?utf-8?B?ZnltazgvTFA0U2V3alFlQjBJbHdFSTRIclNtQnBZZjI5SExRZHdQV1RzYTNi?= =?utf-8?B?ZyswbitQaU11NHFnaUp6UUNOdmpkUklxN3FJVVZRV0duNzVGaDNONVFRakwz?= =?utf-8?B?cCtPRFpZVHl5TEJQekJaTnhpTHJSYmQ0N08wUnZSL2p3MFEvazEvNEdjWldq?= =?utf-8?B?VU03bXJ6ZFQxZHVNZzEwRFJ6d0pJejFFd1duMXdLTENHQStqaVB6ekJOUGhL?= =?utf-8?B?dmN5cjVrVlFBV0laTForTXFSRHUzOTJWZWl5OFY3eUR4NytXZEJPOVJWelAw?= =?utf-8?B?N0ZGRDk1WXFQMXBJYnNWMVk0Wk1rcnI3cCtza2h0WTZQZS8vVVpPWjh2bGxB?= =?utf-8?B?VTdPN1NDY2t4KzJ1K1N4OUp3Y01FZjBic0N1bm5Weld1OHBTOU9lVGZodGlT?= =?utf-8?B?QkU0c3c1T2Z4bks0S3NXa2JLWjVodmZnTlRKTkJFQlVLcnVURHJ5R0xPQ2lK?= =?utf-8?B?d0VDcVJQUnluZUI3bUxMOXBYYTlsYkpyeDl4WVo1WEVrVUNnWHZqL0dQa3Np?= =?utf-8?B?NmlIZlRNYU12M0hHeG9xTGptQzBXS3dnTkI2c2lOeDJadFFCdlpyQWlkQWx0?= =?utf-8?B?dTdDLzIwR3c5Tkc0VHIzV0ZscG1XRytqWWtkbDlNY2ppam1lMTFZTDA5SmVm?= =?utf-8?B?bXY0ZHNuQkF0QlA0ZXYzS1RqNnFlaXhoSDFaYjY2dGQ4RGhhbTVoWExTRjI0?= =?utf-8?B?SmlQcUZKc3JJc3AzT3VXbXEyNk5SZ2xNNC9uUkUvQjBZcEZKV2EzTE5Yek9q?= =?utf-8?B?VnV0d2VpR0M5dGtmaUF6d3A0dTNrT3pRQzA4TUh4dy91TkZUM3ppS3BjQ3BB?= =?utf-8?B?N1c3cDRKV0VKc2I1T3NCazZsdUpNdklDbVZPS0pwME9jR1JHRmQ0azhnNjVG?= =?utf-8?B?K1E1Y0Jka2tMNE9ReHM4UFRkdkIxQ2ZGLzM2eXRRb2ZxaytKa1ZsTlh3NzRY?= =?utf-8?B?bXhndWt4WlpFMWNCamdnMTl2dm5DdTI1UFIxMFM4WWdyVXhjSkRXa2dlK09L?= =?utf-8?B?UndvM1BZZlVZbmtCUjc4ekRpWVpnREZKS3RCM3RpbEdvM0k2ZS9MOXM4UTAw?= =?utf-8?B?K1NJK0N1QUNiWjc0bkJpdTNOWVRIbTN6QVVpNUY5Vlp0L3hRdStVSkwzVHNk?= =?utf-8?B?VUFSbmFQYStpV1RHOUN6Z3pCbGgvTm9QYUtySDJyTVZmVndUSTJOWHQ5a0t5?= =?utf-8?Q?ylTwjJDxkjf1B9CBjo=3D?= X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB0144; 5:XDpOzHPEVI0QrT6F0Y7EyGkE12tHLu5zfukzon5CpJrc0kpznD2iK/0UvmpShah8pFJAJA+s6FwToRbfXPV2oMtnc9JnOQxB50tFePD6lK2ez57eBUGNdWCrocBSGqVlxU0cYYQS8VhiynHYfcUtQA==; 24:oGBTRBtHb+NuA3xzgun7xmMaaJejyR6lpa5pJH0aRyWlEFIBTE2BoClzH8PPZQO0NGEiUK+ADeX5VP4+l+2KthUiPyUxp6VWArR3Z1FRDM8=; 20:MtPLy3SCxoFp++DVBvVPby1HgAiC7Bkn+uuEzPJ06Qe++6jaJciIadK6po7GnHx/ZQmppmlNvPEeT7DaZyb+Ew== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Nov 2015 00:32:48.0908 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY1PR01MB0144 Archived-At: Subject: Re: [Slim] Primary language tags (was "Re: draft-tomkinson comments") X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 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, 09 Nov 2015 00:32:56 -0000 Sorry forgot one important additional thing: On 2015/11/09 09:24, Martin J. Dürst wrote: > Hello Addison, > > On 2015/11/04 06:04, Phillips, Addison wrote: > >> As such, I guess I don't believe that there is much need to introduce >> a script subtag merely to say that some set of strings (or collection >> of pixels) is written. That much is usually obvious from the resource >> itself. Introducing a subtag artificially to convey this information >> interferes with tag matching and selection (particularly when the >> selection is automated from existing content). And when the >> "difference" being identified is already "obvious" to processing, it's >> not worth the problems it causes. Use language tags to identify >> language variation and not as a proxy for Content-Type ;-). > > I agree with you with respect to tagging content. But language tags are > also about requesting content, and there it can make a huge difference > whether something is spoken or written. There's also the case of subtitled video. It's spoken in one language, and written in another. There are hacks to indicate this with the language tags that we have now (using a script subtag on the written one, and no script tag on the spoken one), but it's quite a stretch. Regards, Martin. From nobody Sun Nov 8 16:51:10 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9D9A1B55A6 for ; Sun, 8 Nov 2015 16:51:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.099 X-Spam-Level: * X-Spam-Status: No, score=1.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 f-hEvJhlxXeN for ; Sun, 8 Nov 2015 16:51:05 -0800 (PST) Received: from APC01-SG2-obe.outbound.protection.outlook.com (mail-sg2apc01on0109.outbound.protection.outlook.com [104.47.125.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B4091B4ECD for ; Sun, 8 Nov 2015 16:51:04 -0800 (PST) Received: from TY1PR01MB0143.jpnprd01.prod.outlook.com (10.161.134.147) by TY1PR01MB0096.jpnprd01.prod.outlook.com (10.161.133.15) with Microsoft SMTP Server (TLS) id 15.1.318.15; Mon, 9 Nov 2015 00:50:59 +0000 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=duerst@it.aoyama.ac.jp; Received: from [133.2.210.64] (133.2.210.64) by TY1PR01MB0143.jpnprd01.prod.outlook.com (10.161.134.147) with Microsoft SMTP Server (TLS) id 15.1.318.15; Mon, 9 Nov 2015 00:50:57 +0000 To: Doug Ewell , =?UTF-8?Q?Gunnar=5fHellstr=c3=b6m?= , References: <20151103141150.665a7a7059d7ee80bb4d670165c8327d.d744f8874b.wbe@email03.secureserver.net> From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <563FEDEC.8040302@it.aoyama.ac.jp> Date: Mon, 9 Nov 2015 09:50:52 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151103141150.665a7a7059d7ee80bb4d670165c8327d.d744f8874b.wbe@email03.secureserver.net> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [133.2.210.64] X-ClientProxiedBy: OS2PR01CA0004.jpnprd01.prod.outlook.com (25.161.74.142) To TY1PR01MB0143.jpnprd01.prod.outlook.com (25.161.134.147) X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB0143; 2:YGwxIES1AHbKbQei/Fy6CKo0byoiYth67T3xlhEjVnqtFH77j+E2nJK/ETWKOmwl9+n5yA0dOrZBOMi+g0u5gVF/tdZVNTzNULatsSozwsREjm+09GIP++0JiRHsCS2iWpIb/8JpJGnhqyaYp9jUmhUjQZCk9hQlSzGijLXTBaU=; 3:JZz1xiIXA1Y4mjI1zgVv8uMnAWUCo4hHLocbbyryC0+FUk0lR7uZOHvfK/7fv6cwGyDnjpwO84uZDSoMfQnWyEuAL/jLgKgd5tlHNhQKbK4s3UsfWOcT9DW6TwvlxoyL5IkGIxTbtt73qzRDvm8Ubw==; 25:gtx40CMXnyQdKQ2pZR7n77fgXFCjGTRgVztztUK0fVQPTKUYAJ5NPQhYY72+htoqdYqh0+fArSz2fYLzLJZLga99u1stfyx5+tYzeo7htvHsn8PuJw+3WKrSYHC0cJnd8Y0tK53GHZ4rQi0y/C05MexxHphHBJGYSu03uX834swb1S8piIKHeeEypMVvXn2qskOZvTzd6AEwRfWQV/tNil7kZMOOqrUHRRRX/aAtcqcQcV9rZJ1w8ZYLmXyfYNqDtFyxzUv5FKOdJw/RkambGQ== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:TY1PR01MB0143; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(2401047)(5005006)(520078)(8121501046)(10201501046)(3002001); SRVR:TY1PR01MB0143; BCL:0; PCL:0; RULEID:; SRVR:TY1PR01MB0143; X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB0143; 4:HV5iuEFO+oGkNs1BQ38z9VejuVmLYKeCuXFFj/SVPZCjVI5mFL2Y8cvyusulY7VXuHcu0Is3Eq6V64GY36C6oeCCuxh51HAHGkCso4HoypOZ9OGol9i3wQ/YH1OQIyf7RKwPcupVCfl1qQNQ7usnL+RGbXqSvH0wYRqcbUHwgYqhX+FBG9l16v9SQbIWjZfWDGsuBet82jQkgvSqzGVqR6aMIOaIvMtCjdEeLyoV2t5m+LHTXmsA5gFIIHXqDpbdQrxl7OphKWo04Yemr6ayDM12fJkoDDYbvTe7Mp8FgTDBkNX+CqIaeKP5c1c9OsouRTgoVvqWH19QSVFdpMU1isW9PmXITGdm2gNL4XDhFYrDM4ccATrTDMlnFSDEpz+R X-Forefront-PRVS: 0755F54DD9 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(6009001)(24454002)(479174004)(199003)(189002)(87976001)(64126003)(33656002)(189998001)(74482002)(101416001)(83506001)(59896002)(86362001)(230700001)(92566002)(15975445007)(77096005)(5007970100001)(4001350100001)(23676002)(5001770100001)(81156007)(97736004)(19580405001)(2950100001)(19580395003)(76176999)(5004730100002)(47776003)(66066001)(106356001)(65956001)(42186005)(65806001)(5001960100002)(105586002)(50986999)(107886002)(5008740100001)(65816999)(80316001)(87266999)(54356999)(122386002)(40100003)(50466002)(3940600001); DIR:OUT; SFP:1102; SCL:1; SRVR:TY1PR01MB0143; H:[133.2.210.64]; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: it.aoyama.ac.jp does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtUWTFQUjAxTUIwMTQzOzIzOktuOGFWcWlqbXNVcHlrcURQdFhlSVJOZ1p2?= =?utf-8?B?SVo5SjdUcys4YmlUR1pIVHdEb29VQk9hQm5OUlJkRWlqbVozUldtcTNhR1Vx?= =?utf-8?B?Sk13VHZEekNiQm9YKzVKVEsrN2FyYmNLWlpBNmtBcDB6NDcwWHNrZXNLU0VG?= =?utf-8?B?L0FrM1ZPL2xuWlo1ZUNMZkliTDJEYlNoa2pMeG04VEZvQ2JrNE81L0dIaDJS?= =?utf-8?B?L090bStRbFpVcUxXMFBKSUVXaTY0L0srQURNYUhQaEd1dU1KTXZ4K1dpUW1W?= =?utf-8?B?b240MHBseUtFQzN0WkNzUEtNRGRsNDZTbHFDOHNSL3NQR0tpVnRaVmxES1Vz?= =?utf-8?B?UC95WXNOSklVdWEyWHoxUU5WU0IveVJPWW1oakllRDRleDY0TUdoUmxVQ2Uy?= =?utf-8?B?bE9sUWw2d3dNVEVqeFNhRG5GK0dBUnQxMS9zUVZXeExraTNWd1llS1ZGS01h?= =?utf-8?B?dXFqNmRwdmRkeXlCMVRIdlFSbVVsbjZoR2FkQTRRbHdnQlZuVkRxWlgvOEkx?= =?utf-8?B?MEZMUUZCVkxXMmg2ZDB3bFRVZWpnc3RwSCt4QUpTRWFlWnRvVUFZMXhkK2pP?= =?utf-8?B?K0c4SmJMa1dIOTJaYmNIaWhCZzFGQWRlWkdVN2xkaCt3MHRUaGlrRnJBVmhU?= =?utf-8?B?d2pJTDg2QWRRZURwbk9oaWpjTHpVTWNGZHlGejFCMklOWXpJR3RPV1BNRERz?= =?utf-8?B?Mlk0VlU2QytIaFVUMjAwaWhNdkhrUnlEZ2JoS3A4Q3FEOU9XR0hrUXdjV1l3?= =?utf-8?B?b3FyaVIwcElzN0s1bTh1a3hYMmlmMm9DRzF6NEVIS0hlalBlYmkzaFVkQ0M3?= =?utf-8?B?Y1N6UUtPOVViQ0JYdUpuaVVHWHZCalVYak1wVklNT1BDaVVrVnhFQmhQTzdB?= =?utf-8?B?bnluNE1IZkdPc1hTNTcwa0d4NmUvazd0dm9nUGdaUzYvU1BnbFhNUGQ3bU1m?= =?utf-8?B?UktwTExxUnQybUxGMW03QjlSalhFQU9xTUV6RzFHSllPcXdscEwwbWthMjF2?= =?utf-8?B?V3N0ak9pTFdMNjhCWm5hN1QzNmhHazhhNjNhK0JnaVhHTmd0Ri9ab284L1Yw?= =?utf-8?B?dkswTm92TGVHSEtZL0tHRnUxOXlmZUl3cnY0MFVMRm5mbmVFS0lvRUs2Z2M5?= =?utf-8?B?eVRoSExMb1BENkVCUTNjcWxteENIeU1keWZPUGczN09MbHJvNkVNdzJHc0pY?= =?utf-8?B?VWV5bmR1WkRxV1pqbHU4TWdCVnRmT3pFbXJUZWZZY2daRVY3QzZXeGUvSjZy?= =?utf-8?B?akJWVy9zWnMyQmp5UVdYVlA2cTlIOWtjY0Z2UGJta1lZSEduY3ZneldmZTRB?= =?utf-8?B?SWRraGRub0RZZ2IyUjFaV0RLM09RNzlMbVpSUU55OWY4eFVPZXl6VmV1TjUw?= =?utf-8?B?ckU5MnlwVy85Q3d4Yk8zenBwVTBaYzZyMWVMT01XNjZKUmkrb0FyYnQ1Mno3?= =?utf-8?B?ME1lWHFxT1pqK1JuZnpPUEtHc2VWNDcxUzBiQ3h5blQ4bWRlV1l4KytCZG9o?= =?utf-8?B?NEp6M0FuOVV2eXRuRlROOU5nQ1NNcDMxYzhMdEk0VDI2bGplRzhsandJTGd2?= =?utf-8?B?WWorMG1EcmFwRXdaR0JTVWZuS3NqRWhGbFhoYzlJZTFRTUNNR1RQeVpCd1VF?= =?utf-8?B?SXlTL2xPUUt3am1xN01rRzlXWU04NVkvRyttbXVBakdZdzdSY2NZZGNveEli?= =?utf-8?B?S3NkR3h3dWNpdFJTelZJUmdBbVRYS0JLRkFxVVZzTnZUOUdHc0ZWVG43ZTVo?= =?utf-8?B?N09EeWFxamUrTEFUSGFkUT09?= X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB0143; 5:7hVRuHCwga+Ttb0meldNd2D8NQsfvMxBYUMv1EmFuMSvDQxsAodtKQeRtL+fb+tOwnQLBfRHUKgBfHpTuLwJTSJKD0euZzJzUWg7cpT96j/UXsVYgRKupU/sfd5CJjRXk8ZwquVPA+i/Lcl4wGf12Q==; 24:Ibl/ROUYMOarSfclkE2ZX2zW6Am4GopEQ/Snb52kqJugJRDslJp9MLhqgZ/7aFz5qbZw9ffjMges1NOXjLmnac+kd7+CbFIGDuVlahAcl9Q=; 20:RrDeg4dFI26Z8iiZhzEdx/dvIPAZIaAVTCZreXKmD/qigV4fEne3XtKMOU4I2Ku4VujiOxlI/+QqfAEHBiyUHQ== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Nov 2015 00:50:57.4073 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY1PR01MB0143 X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB0096; 2:uWKnOHvUy0obxmm/SVNyk3vJ0MbGtANXnd1MjtzjS352RFy2JpIAUwYdmogKyHO3IHNiUKP98UwA4ErXe1WWcOsLWFiFIB4VIgdQT/JfLKE8RaJZNmmKzvURN47Sqm+t2Ti+cGLfYJZj1aZzRCCVn15RX11VhPmXvYAVp09AUQE=; 23:7uqIxOoozMdwMwDevX7HxBjocMN/LXB6TiagiVD9MstV0cQI65y5BS+yxgXr2oN08C1XOnvJ2ZeBA9+cu9FCkDQeD9IEJNZhWkZCQI3JCv4GLe/CN7cVcPIOmeL6+DxW/e+/k5k97lARhmPQtQ1KUBW7btp1CSZGgPJwBy3OIOdjm77Q54BV3TohIi3o7Alt X-OriginatorOrg: it.aoyama.ac.jp Archived-At: Subject: Re: [Slim] Primary language tags (was "Re: draft-tomkinson comments") X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 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, 09 Nov 2015 00:51:09 -0000 On 2015/11/04 06:11, Doug Ewell wrote: >> But it is a general problem that should best be solved at its source - >> in BCP-47. Spoken and written languages are not identical, we just >> believe so at first thought. > > Language tags aren't generally meant to show what is or is not > identical. I agree, in the sense that 'identical' is extremely difficult to say for languages. There are always minor differences, even when tagged the same. > They're meant to assist searching, filtering, and selection > of tools like spell-checkers and translation engines. Those aren't > usually sensitive to distinctions between spoken and written forms. Of course searching may be sensitive to the distinction between spoken and written form, and same for filtering and selection. And spell-checking is extremely sensitive, because it doesn't apply at all to the spoken form. Probably the same for translation engines, although that's starting to change. As for searching, it not only applies to people who can hear but not see, or the other way round. As an example, if there's French and Swiss German available, I'd choose Swiss German for listening but French for reading, because I don't have any experience in reading Swiss German. This situation is somewhat special, but I hope we don't want to exclude such special situations. More generally, language classification in general and language tagging are about mutual intelligibility. Even if in the majority of cases, somebody who understands spoken language X will understand written language X, there are many cases where that doesn't apply. >> This problem makes language tags ambigous in many applications. Users >> usually want to know if they are supposed to read or listen. > > Most language-tagged content is self-evident as to its modality. An > audio recording, for example, is obviously meant to be listened to. A > text file is meant to be read, or otherwise processed as text. Language > tags don't try to state the obvious here. For content that is only in one modality, this applies. But what about content in more than one modality (video)? > I suggest joining the ietf-languages list if you feel there are > shortcomings in BCP 47 that need to be addressed, either by registering > new variants or by revising the specification. I think registering an extension is the best way to go. I think it's a good idea to inform ietf-languages@ietf.org once in a while and get feedback, but the requirement for "IETF review" would obviously be met by an RFC published by the SLIM WG. (see https://tools.ietf.org/html/rfc5646#section-3.7 for details) Regards, Martin. From nobody Sun Nov 8 22:49:59 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7033B1A6FC8 for ; Sun, 8 Nov 2015 22:49:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.099 X-Spam-Level: * X-Spam-Status: No, score=1.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 0AI336WIag0B for ; Sun, 8 Nov 2015 22:49:56 -0800 (PST) Received: from bin-vsp-out-05.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 6AA601A6FBE for ; Sun, 8 Nov 2015 22:49:55 -0800 (PST) X-Halon-ID: 15ba0407-86ae-11e5-8d6b-005056916f53 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.48] (unknown [83.209.226.9]) by bin-vsp-out-05.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Mon, 9 Nov 2015 07:49:55 +0100 (CET) To: slim@ietf.org References: <20151103125549.665a7a7059d7ee80bb4d670165c8327d.d41148fb15.wbe@email03.secureserver.net> <56391992.9030000@omnitor.se> <212ff0f6c22048e883b9eeb3c0e74672@EX13D08UWB003.ant.amazon.com> <563FE7B6.5020800@it.aoyama.ac.jp> <563FE9AA.4090108@it.aoyama.ac.jp> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <5640420B.8080702@omnitor.se> Date: Mon, 9 Nov 2015 07:49:47 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <563FE9AA.4090108@it.aoyama.ac.jp> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Slim] Primary language tags (was "Re: draft-tomkinson comments") X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 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, 09 Nov 2015 06:49:58 -0000 Den 2015-11-09 kl. 01:32, skrev Martin J. Dürst: > Sorry forgot one important additional thing: > > On 2015/11/09 09:24, Martin J. Dürst wrote: >> Hello Addison, >> >> On 2015/11/04 06:04, Phillips, Addison wrote: >> >>> As such, I guess I don't believe that there is much need to introduce >>> a script subtag merely to say that some set of strings (or collection >>> of pixels) is written. That much is usually obvious from the resource >>> itself. Introducing a subtag artificially to convey this information >>> interferes with tag matching and selection (particularly when the >>> selection is automated from existing content). And when the >>> "difference" being identified is already "obvious" to processing, it's >>> not worth the problems it causes. Use language tags to identify >>> language variation and not as a proxy for Content-Type ;-). >> >> I agree with you with respect to tagging content. But language tags are >> also about requesting content, and there it can make a huge difference >> whether something is spoken or written. > > There's also the case of subtitled video. It's spoken in one language, > and written in another. There are hacks to indicate this with the > language tags that we have now (using a script subtag on the written > one, and no script tag on the spoken one), but it's quite a stretch. [GH] And that stretch was what I proposed to use now again for distinguishing spoken from written. The lack of a differentiation between these have kept me from considering language tags for relay service selection and invocation many years now. Now that we see that there are other applications having the same problem, let us do something about it. I can see behind the arguments from the language tagging experts that there has been problems to find what you want among already set tags, so you want to keep the use of extensions low. But I cannot see that the difference between spoken and written is a minor detail that should be ignored. I think it is more discriminating for the possibility to use the content than dialect and script. Are these motivations convincing enough to start work for a modality extension to language tags? Regards Gunnar > > Regards, Martin. > > _______________________________________________ > 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 Tue Nov 10 22:54:36 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 572C01B3115 for ; Tue, 10 Nov 2015 22:54:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 gUtnB53gTEMf for ; Tue, 10 Nov 2015 22:54:32 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0681.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::681]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D23851B310A for ; Tue, 10 Nov 2015 22:54:31 -0800 (PST) Received: from HE1PR04MB1033.eurprd04.prod.outlook.com (10.162.26.142) by HE1PR04MB1035.eurprd04.prod.outlook.com (10.162.26.144) with Microsoft SMTP Server (TLS) id 15.1.318.15; Wed, 11 Nov 2015 06:54:10 +0000 Received: from HE1PR04MB1033.eurprd04.prod.outlook.com ([10.162.26.142]) by HE1PR04MB1033.eurprd04.prod.outlook.com ([10.162.26.142]) with mapi id 15.01.0318.003; Wed, 11 Nov 2015 06:54:10 +0000 From: Natasha Rooney To: =?utf-8?B?R3VubmFyIEhlbGxzdHLDtm0=?= Thread-Topic: [Slim] Handling the complex multi-media cases Thread-Index: AQHRFdukkQOmwfH0skiNbU74B2PoSp6Jj5CAgACJe4CAAKuyAIAAf0eAgAATGoCAAK9DAIAAFrcAgADtw4CAAIvVAIAAd1oAgABVXoCAAUqMgIABD9AAgABFFgCAAGqHgIAAL7AAgATSvQA= Date: Wed, 11 Nov 2015 06:54:10 +0000 Message-ID: <483C1110-AD7F-4D53-982D-A68443ADEE9E@gsma.com> References: <563818F9.2060709@alum.mit.edu> <56388C4D.4090808@omnitor.se> <56398719.7030205@omnitor.se> <21767FCE-C1BD-4C42-A07E-16BC81586073@gmail.com> <563A2A24.2020102@alum.mit.edu> <44BE7894-2944-42FE-A136-ADB629D49143@gmail.com> <563B04A5.4040407@omnitor.se> <563B79F2.1010608@alum.mit.edu> <563BDE10.5050305@omnitor.se> <563C25AD.3050801@alum.mit.edu> <563D3AF5.1020608@omnitor.se> <563E58EC.3090304@omnitor.se> <563EB249.7020909@it.aoyama.ac.jp> <563EDA4A.6050206@omnitor.se> In-Reply-To: <563EDA4A.6050206@omnitor.se> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3096.5) authentication-results: spf=none (sender IP is ) smtp.mailfrom=nrooney@gsma.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [219.108.220.186] x-microsoft-exchange-diagnostics: 1; HE1PR04MB1035; 5:yH/itsqNMhw0jmsHpOJllGOjKFAzMFnop3yxlkgUwJZS5EP/7olMHViNeFagQrh837lER9lN476DOFMYpdgz+KfJgq/5qivDBmb9kw8NV5wYs7ccpKutC0NiMmil5Qp/BySxqp06oSFKyM3DfgOeuA==; 24:PzsMXFtw6MYveqd6dbEPQoz6mfMuOo9H0wixaPTCtoGeb8c6oxG+z/fmhsMVGgtfYICD2WJDPfokZ6fLvBTGXdEC4lC++oVYmyrMJw+K24I=; 20:uVtusetDCMv6IaDpsA9hXIFmsr0KVChKuvB8fiz0/hKTbAiGbFTj9D1unoFEr2bqqgjKHP782seFlXM3G3NIQg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR04MB1035; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(260367931017790)(161861816099999); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(520078)(10201501046)(3002001); SRVR:HE1PR04MB1035; BCL:0; PCL:0; RULEID:; SRVR:HE1PR04MB1035; x-forefront-prvs: 0757EEBDCA x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(199003)(24454002)(377424004)(479174004)(377454003)(189002)(77096005)(122556002)(2950100001)(2900100001)(102836002)(15975445007)(5007970100001)(11100500001)(5004730100002)(40100003)(5008740100001)(101416001)(19580395003)(19580405001)(76176999)(50986999)(189998001)(36756003)(33656002)(97736004)(110136002)(5001960100002)(66066001)(16236675004)(5002640100001)(81156007)(83716003)(50226001)(82746002)(57306001)(87936001)(86362001)(5890100001)(106356001)(10400500002)(93886004)(106116001)(105586002)(19617315012)(92566002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR04MB1035; H:HE1PR04MB1033.eurprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: gsma.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_483C1110AD7F4D53982DA68443ADEE9Egsmacom_" MIME-Version: 1.0 X-OriginatorOrg: gsma.com X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Nov 2015 06:54:10.0246 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72a4ff82-fec3-469d-aafb-ac8276216699 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR04MB1035 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: HE1PR04MB1033.eurprd04.prod.outlook.com X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-originalclientipaddress: 219.108.220.186 X-MS-Exchange-CrossPremises-avstamp-service: 1.0 X-MS-Exchange-CrossPremises-disclaimer-hash: 78ca8040c6722e32c2f5b0a45bf37e74b9409d645a53be96aa19958e0cee0f00 X-MS-Exchange-CrossPremises-antispam-scancontext: DIR:Originating; SFV:NSPM; SKIP:0; X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-OrganizationHeadersPreserved: HE1PR04MB1035.eurprd04.prod.outlook.com Archived-At: Cc: "slim@ietf.org" Subject: Re: [Slim] Handling the complex multi-media cases X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 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, 11 Nov 2015 06:54:34 -0000 --_000_483C1110AD7F4D53982DA68443ADEE9Egsmacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGV5IGd1eXMsDQoNCkl0IHdvdWxkIGJlIGEgZ29vZCBpZGVhIHRvIGNhcHR1cmUgdGhlIHVzZSBj YXNlIGlkZW50aWZpZWQgYnkgR3VubmFyIGF0IHRoZSBtZWV0aW5nIGF0IElFVEY5NCBhbmQgZ2l2 ZW4gaW4gdGhpcyB0aHJlYWQgaW4gYSBkb2N1bWVudCwgdGhpcyB3aWxsIGFsbG93IHVzIHRvIGJl IGFibGUgdG8gcmVmZXIgdG8gdGhlbSBpbiBvbmUgcGxhY2UgcmF0aGVyIHRoYW4gcmVmZXJyaW5n IGRvd24gYSB0aHJlYWQuDQoNCkd1bm5hciAtIEkgY2FuIGJ1aWxkIHRoaXMgZG9jdW1lbnQsIHRv IGdldCBzdGFydGVkIGNhbiB5b3UganVzdCBzZW5kIGEgbWUgeW91ciBsaXN0IG9mIHVzZSBjYXNl cyB3aXRoIGFueSBhbWVuZG1lbnRzIHdoaWNoIG1heSBoYXZlIGJlZW4gaWRlbnRpZmllZCBpbiB0 aGlzIGVtYWlsIHRocmVhZD8gSSB3aWxsIHRoZW4gYWRkIHRoZW0gdG8gYSBkb2N1bWVudCB3aGlj aCB3aWxsIGJlIGluIGFuIFJGQyBmb3JtYXQuDQoNCkFmdGVyIEkgZ2V0IHRoZSBpbml0aWFsIGxp c3QgZnJvbSBHdW5uYXIgSSB3aWxsIHNlbmQgdGhlIGRvY3VtZW50IHRvIHRoZSBsaXN0IGFuZCBy ZXF1ZXN0IGFkZGl0aW9ucy4gVGhlcmUgbWF5IGJlIGEgbmVlZCB0byBwdXNoIHRoaXMgZG9jdW1l bnQgdG8gYmUgYW4gUkZDIGluIHRoZSBmdXR1cmUsIGZvciBub3cgd2Ugd2lsbCB0cmVhdCBpdCBh cyBhIG5vdGUuDQoNClRoYW5rcyBldmVyeW9uZSENCg0KTmF0YXNoYQ0KDQoNCk5hdGFzaGEgUm9v bmV5IHwgVGVjaG5vbG9naXN0LCBXZWIgYW5kIEludGVybmV0LCBXM0MgJiBJRVRGIHwgR1NNQSB8 IG5yb29uZXlAZ3NtYS5jb208bWFpbHRvOm5yb29uZXlAZ3NtYS5jb20+IHwgKzQ0ICgwKSA3NzMw IDIxOSA3NjUgfCBAdGhpc05hdGFzaGEgfCBTa3lwZTogbnJvb25leUBnc20ub3JnPG1haWx0bzpu cm9vbmV5QGdzbS5vcmc+DQpUb2t5bywgSmFwYW4NCg0KDQpPbiBOb3YgOCwgMjAxNSwgYXQgMjox NCBQTSwgR3VubmFyIEhlbGxzdHLDtm0gPGd1bm5hci5oZWxsc3Ryb21Ab21uaXRvci5zZTxtYWls dG86Z3VubmFyLmhlbGxzdHJvbUBvbW5pdG9yLnNlPj4gd3JvdGU6DQoNCg0KDQpEZW4gMjAxNS0x MS0wOCBrbC4gMDM6MjQsIHNrcmV2IE1hcnRpbiBKLiBEw7xyc3Q6DQpPbiAyMDE1LzExLzA4IDA1 OjAyLCBHdW5uYXIgSGVsbHN0csO2bSB3cm90ZToNCg0KSW4gdGhlIGRyYWZ0LCBzZWN0aW9uIDMu MiwgdGhlcmUgaXMgYSBwYXJhZ3JhcGgNCg0KV2hpY2ggZHJhZnQ/IEkgdGhvdWdodCB3ZSBhcmUg c3BlYWtpbmcgYWJvdXQNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXNs aW0tbmVnb3RpYXRpbmctaHVtYW4tbGFuZ3VhZ2UtMDANCltHSF1ZZXMsIHNvcnJ5LCBJIG1lYW50 IDYuMi4gIFRoZXJlIGlzIGFsc28gYW4gZXhwYW5zaW9uIG9mIHRoZSB0b3BpYyBpbiA2LjMuDQoN CmJ1dCB0aGVyZSdzIG5vIHNlY3Rpb24gMy4yIChTZWN0aW9uIDMgaXMgZXh0cmVtZWx5IHNob3J0 KS4NCg0KIg0KDQpJbiBhbiBvZmZlciwgZWFjaCBsYW5ndWFnZSB0YWcgdmFsdWUgTUFZIGhhdmUg YW4gYXN0ZXJpc2sgYXBwZW5kZWQgYXMNCiAgIHRoZSBsYXN0IGNoYXJhY3RlciAoYWZ0ZXIgdGhl IHJlZ2lzdHJ5IHZhbHVlKS4gIFRoZSBhc3Rlcmlzaw0KICAgaW5kaWNhdGVzIGEgcmVxdWVzdCBi eSB0aGUgY2FsbGVyIHRvIG5vdCBmYWlsIHRoZSBjYWxsIGlmIHRoZXJlIGlzIG5vDQogICBsYW5n dWFnZSBpbiBjb21tb24uIg0KDQpXaGF0IGV4YWN0bHkgaXMgbWVhbnQgd2l0aCB0aGlzPw0KDQpJ cyBpdCBzb21ldGhpbmcgbGlrZToNCg0KZW4tVVMsIGVuLUFVLCBmci1DQSwgKg0KDQooaS5lLiBl c3NlbnRpYWxseSB0aGUgc2FtZSBhcyB0aGUgSFRUUCBBY2NlcHQtTGFuZ3VhZ2UgaGVhZGVyKT8N Cg0KT3IgaXMgaXQgc29tZXRoaW5nIGxpa2UNCg0KZW4tVVMqLCBlbi1BVSosIGZyLUNBKg0KDQpU aGUgbGF0ZXIgd291bGQgYmUgdG90YWxseSBvdXQgb2YgbGluZSB3aXRoIHByZXZpb3VzIHVzZSBv ZiBsYW5ndWFnZSB0YWdzIGFuZCBzdWJ0YWdzLCBidXQgaXQncyB3aGF0IEknZCBndWVzcyBmcm9t IGEgZGlyZWN0IHJlYWRpbmcgb2YgdGhlIHRleHQuDQpbR0hdIFllcywgdGhhdCB3YXMgYWxzbyBt eSBpbnRlcnByZXRhdGlvbi4gQW5kIHdvbmRlcmluZyB3aGF0IHdhcyBtZWFudC4gQSBjb21wbGV0 ZSBzeW50YXggZGVzY3JpcHRpb24gYW5kIGV4YW1wbGUgaXMgbmVlZGVkLg0KQnV0IGFsc28gYSBk aXNjdXNzaW9uIGlmIHRoaXMgbm9uLWZhaWwgcGFyYW1ldGVyIHNob3VsZCBiZSBtZXJnZWQgd2l0 aCB0aGUgb3RoZXIgcHJpb3JpdHkgdmFsdWVzIHRoYXQgSSBwcm9wb3NlLg0KDQovR3VubmFyDQoN ClJlZ2FyZHMsICAgTWFydGluLg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KU0xJTSBtYWlsaW5nIGxpc3QNClNMSU1AaWV0Zi5vcmc8bWFpbHRvOlNM SU1AaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NsaW0N Cg0KLS0NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpHdW5uYXIg SGVsbHN0csO2bQ0KT21uaXRvcg0KZ3VubmFyLmhlbGxzdHJvbUBvbW5pdG9yLnNlPG1haWx0bzpn dW5uYXIuaGVsbHN0cm9tQG9tbml0b3Iuc2U+DQorNDYgNzA4IDIwNCAyODgNCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClNMSU0gbWFpbGluZyBsaXN0 DQpTTElNQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Ns aW0NCg0KDQpUaGlzIGVtYWlsIGFuZCBpdHMgYXR0YWNobWVudHMgYXJlIGludGVuZGVkIGZvciB0 aGUgYWJvdmUgbmFtZWQgb25seSBhbmQgbWF5IGJlIGNvbmZpZGVudGlhbC4gSWYgdGhleSBoYXZl IGNvbWUgdG8geW91IGluIGVycm9yIHlvdSBtdXN0IHRha2Ugbm8gYWN0aW9uIGJhc2VkIG9uIHRo ZW0sIG5vciBtdXN0IHlvdSBjb3B5IG9yIHNob3cgdGhlbSB0byBhbnlvbmU7IHBsZWFzZSByZXBs eSB0byB0aGlzIGVtYWlsIG9yIGNhbGwgKzQ0IDIwNyAzNTYgMDYwMCBhbmQgaGlnaGxpZ2h0IHRo ZSBlcnJvci4NCg== --_000_483C1110AD7F4D53982DA68443ADEE9Egsmacom_ Content-Type: text/html; charset="utf-8" Content-ID: <703B99901C16AC46BA6E0D6947303530@eurprd04.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGV5IGd1eXMsPGJyIGNsYXNzPSIi Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IndlYmtpdC1ibG9jay1wbGFjZWhvbGRlciI+DQo8 L2Rpdj4NCjxkaXYgYXBwbGUtY29udGVudC1lZGl0ZWQ9InRydWUiIGNsYXNzPSIiPg0KPGRpdiBz dHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFu czogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNm b3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2lu ZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHdvcmQtd3JhcDogYnJlYWst d29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVy LXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQpJdCB3b3VsZCBiZSBhIGdvb2QgaWRlYSB0byBjYXB0 dXJlIHRoZSB1c2UgY2FzZSBpZGVudGlmaWVkIGJ5IEd1bm5hciBhdCB0aGUgbWVldGluZyBhdCBJ RVRGOTQgYW5kIGdpdmVuIGluIHRoaXMgdGhyZWFkIGluIGEgZG9jdW1lbnQsIHRoaXMgd2lsbCBh bGxvdyB1cyB0byBiZSBhYmxlIHRvIHJlZmVyIHRvIHRoZW0gaW4gb25lIHBsYWNlIHJhdGhlciB0 aGFuIHJlZmVycmluZyBkb3duIGEgdGhyZWFkLiZuYnNwOzwvZGl2Pg0KPGRpdiBzdHlsZT0iY29s b3I6IHJnYigwLCAwLCAwKTsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsg dGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25l OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAt d2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHdvcmQtd3JhcDogYnJlYWstd29yZDsgLXdl YmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNw YWNlOyIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9y OiByZ2IoMCwgMCwgMCk7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRl eHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsg d2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdl YmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJr aXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFj ZTsiIGNsYXNzPSIiPg0KR3VubmFyIC0gSSBjYW4gYnVpbGQgdGhpcyBkb2N1bWVudCwgdG8gZ2V0 IHN0YXJ0ZWQgY2FuIHlvdSBqdXN0IHNlbmQgYSBtZSB5b3VyIGxpc3Qgb2YgdXNlIGNhc2VzIHdp dGggYW55IGFtZW5kbWVudHMgd2hpY2ggbWF5IGhhdmUgYmVlbiBpZGVudGlmaWVkIGluIHRoaXMg ZW1haWwgdGhyZWFkPyBJIHdpbGwgdGhlbiBhZGQgdGhlbSB0byBhIGRvY3VtZW50IHdoaWNoIHdp bGwgYmUgaW4gYW4gUkZDIGZvcm1hdC48L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwg MCwgMCk7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246 IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3Bh Y2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0 LXN0cm9rZS13aWR0aDogMHB4OyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1t b2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNz PSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAs IDApOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBz dGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNl OiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1z dHJva2Utd2lkdGg6IDBweDsgd29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9k ZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0i Ij4NCkFmdGVyIEkgZ2V0IHRoZSBpbml0aWFsIGxpc3QgZnJvbSBHdW5uYXIgSSB3aWxsIHNlbmQg dGhlIGRvY3VtZW50IHRvIHRoZSBsaXN0IGFuZCByZXF1ZXN0IGFkZGl0aW9ucy4gVGhlcmUgbWF5 IGJlIGEgbmVlZCB0byBwdXNoIHRoaXMgZG9jdW1lbnQgdG8gYmUgYW4gUkZDIGluIHRoZSBmdXR1 cmUsIGZvciBub3cgd2Ugd2lsbCB0cmVhdCBpdCBhcyBhIG5vdGUuPC9kaXY+DQo8ZGl2IHN0eWxl PSJjb2xvcjogcmdiKDAsIDAsIDApOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBh dXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06 IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAw cHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgd29yZC13cmFwOiBicmVhay13b3Jk OyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hp dGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0i Y29sb3I6IHJnYigwLCAwLCAwKTsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0 bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBu b25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4 OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHdvcmQtd3JhcDogYnJlYWstd29yZDsg LXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRl LXNwYWNlOyIgY2xhc3M9IiI+DQpUaGFua3MgZXZlcnlvbmUhPGJyIGNsYXNzPSIiPg0KPGJyIGNs YXNzPSIiPg0KTmF0YXNoYTxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0i Ij4NCk5hdGFzaGEgUm9vbmV5IHwgVGVjaG5vbG9naXN0LCBXZWIgYW5kIEludGVybmV0LCBXM0Mg JmFtcDsgSUVURiB8Jm5ic3A7R1NNQSB8IDxhIGhyZWY9Im1haWx0bzpucm9vbmV5QGdzbWEuY29t IiBjbGFzcz0iIj4NCm5yb29uZXlAZ3NtYS5jb208L2E+IHwgJiM0Mzs0NCAoMCkmbmJzcDs3NzMw IDIxOSA3NjUgfCBAdGhpc05hdGFzaGEgfCBTa3lwZTombmJzcDs8YSBocmVmPSJtYWlsdG86bnJv b25leUBnc20ub3JnIiBjbGFzcz0iIj5ucm9vbmV5QGdzbS5vcmc8L2E+Jm5ic3A7PGJyIGNsYXNz PSIiPg0KVG9reW8sIEphcGFuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxkaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFz cz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gTm92IDgsIDIwMTUsIGF0IDI6MTQgUE0sIEd1bm5hciBI ZWxsc3Ryw7ZtICZsdDs8YSBocmVmPSJtYWlsdG86Z3VubmFyLmhlbGxzdHJvbUBvbW5pdG9yLnNl IiBjbGFzcz0iIj5ndW5uYXIuaGVsbHN0cm9tQG9tbml0b3Iuc2U8L2E+Jmd0OyB3cm90ZTo8L2Rp dj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIi Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpEZW4gMjAxNS0x MS0wOCBrbC4gMDM6MjQsIHNrcmV2IE1hcnRpbiBKLiBEw7xyc3Q6PGJyIGNsYXNzPSIiPg0KPGJs b2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+T24gMjAxNS8xMS8wOCAwNTowMiwgR3VubmFy IEhlbGxzdHLDtm0gd3JvdGU6PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVv dGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+SW4gdGhlIGRyYWZ0LCBzZWN0aW9uIDMuMiwgdGhlcmUg aXMgYSBwYXJhZ3JhcGg8YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+ DQpXaGljaCBkcmFmdD8gSSB0aG91Z2h0IHdlIGFyZSBzcGVha2luZyBhYm91dDxiciBjbGFzcz0i Ij4NCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXNsaW0t bmVnb3RpYXRpbmctaHVtYW4tbGFuZ3VhZ2UtMDAiIGNsYXNzPSIiPmh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXNsaW0tbmVnb3RpYXRpbmctaHVtYW4tbGFuZ3VhZ2UtMDA8 L2E+PGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KW0dIXVllcywgc29ycnksIEkgbWVhbnQg Ni4yLiAmbmJzcDtUaGVyZSBpcyBhbHNvIGFuIGV4cGFuc2lvbiBvZiB0aGUgdG9waWMgaW4gNi4z LjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPjxiciBjbGFz cz0iIj4NCmJ1dCB0aGVyZSdzIG5vIHNlY3Rpb24gMy4yIChTZWN0aW9uIDMgaXMgZXh0cmVtZWx5 IHNob3J0KS48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJj aXRlIiBjbGFzcz0iIj4mcXVvdDs8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpJbiBhbiBv ZmZlciwgZWFjaCBsYW5ndWFnZSB0YWcgdmFsdWUgTUFZIGhhdmUgYW4gYXN0ZXJpc2sgYXBwZW5k ZWQgYXM8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDt0aGUgbGFzdCBjaGFyYWN0ZXIg KGFmdGVyIHRoZSByZWdpc3RyeSB2YWx1ZSkuICZuYnNwO1RoZSBhc3RlcmlzazxiciBjbGFzcz0i Ij4NCiZuYnNwOyZuYnNwOyZuYnNwO2luZGljYXRlcyBhIHJlcXVlc3QgYnkgdGhlIGNhbGxlciB0 byBub3QgZmFpbCB0aGUgY2FsbCBpZiB0aGVyZSBpcyBubzxiciBjbGFzcz0iIj4NCiZuYnNwOyZu YnNwOyZuYnNwO2xhbmd1YWdlIGluIGNvbW1vbi4mcXVvdDs8YnIgY2xhc3M9IiI+DQo8L2Jsb2Nr cXVvdGU+DQo8YnIgY2xhc3M9IiI+DQpXaGF0IGV4YWN0bHkgaXMgbWVhbnQgd2l0aCB0aGlzPzxi ciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCklzIGl0IHNvbWV0aGluZyBsaWtlOjxiciBjbGFz cz0iIj4NCjxiciBjbGFzcz0iIj4NCmVuLVVTLCBlbi1BVSwgZnItQ0EsICo8YnIgY2xhc3M9IiI+ DQo8YnIgY2xhc3M9IiI+DQooaS5lLiBlc3NlbnRpYWxseSB0aGUgc2FtZSBhcyB0aGUgSFRUUCBB Y2NlcHQtTGFuZ3VhZ2UgaGVhZGVyKT88YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpPciBp cyBpdCBzb21ldGhpbmcgbGlrZTxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCmVuLVVTKiwg ZW4tQVUqLCBmci1DQSo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpUaGUgbGF0ZXIgd291 bGQgYmUgdG90YWxseSBvdXQgb2YgbGluZSB3aXRoIHByZXZpb3VzIHVzZSBvZiBsYW5ndWFnZSB0 YWdzIGFuZCBzdWJ0YWdzLCBidXQgaXQncyB3aGF0IEknZCBndWVzcyBmcm9tIGEgZGlyZWN0IHJl YWRpbmcgb2YgdGhlIHRleHQuPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KW0dIXSBZZXMs IHRoYXQgd2FzIGFsc28gbXkgaW50ZXJwcmV0YXRpb24uIEFuZCB3b25kZXJpbmcgd2hhdCB3YXMg bWVhbnQuIEEgY29tcGxldGUgc3ludGF4IGRlc2NyaXB0aW9uIGFuZCBleGFtcGxlIGlzIG5lZWRl ZC48YnIgY2xhc3M9IiI+DQpCdXQgYWxzbyBhIGRpc2N1c3Npb24gaWYgdGhpcyBub24tZmFpbCBw YXJhbWV0ZXIgc2hvdWxkIGJlIG1lcmdlZCB3aXRoIHRoZSBvdGhlciBwcmlvcml0eSB2YWx1ZXMg dGhhdCBJIHByb3Bvc2UuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KL0d1bm5hcjxiciBj bGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4N ClJlZ2FyZHMsICZuYnNwOyZuYnNwO01hcnRpbi48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+ DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxiciBjbGFz cz0iIj4NClNMSU0gbWFpbGluZyBsaXN0PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0ibWFpbHRvOlNM SU1AaWV0Zi5vcmciIGNsYXNzPSIiPlNMSU1AaWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zbGltPGJyIGNsYXNzPSIiPg0KPC9i bG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KLS0gPGJyIGNsYXNzPSIiPg0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnIgY2xhc3M9IiI+DQpHdW5uYXIgSGVsbHN0 csO2bTxiciBjbGFzcz0iIj4NCk9tbml0b3I8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJtYWlsdG86 Z3VubmFyLmhlbGxzdHJvbUBvbW5pdG9yLnNlIiBjbGFzcz0iIj5ndW5uYXIuaGVsbHN0cm9tQG9t bml0b3Iuc2U8L2E+PGJyIGNsYXNzPSIiPg0KJiM0Mzs0NiA3MDggMjA0IDI4ODxiciBjbGFzcz0i Ij4NCjxiciBjbGFzcz0iIj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPGJyIGNsYXNzPSIiPg0KU0xJTSBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+DQpT TElNQGlldGYub3JnPGJyIGNsYXNzPSIiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zbGltPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPHAgc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCxzYW5z LXNlcmlmO2ZvbnQtc2l6ZToxMXB4O2NvbG9yOiM5OTk5OTk7Ij48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCxzYW5zLXNlcmlmO2NvbG9yOiM5OTk5OTk7IG1zby1m YXJlYXN0LWZvbnQtZmFtaWx5OiBBcmlhbDsgbXNvLWZhcmVhc3QtdGhlbWUtZm9udDogbWlub3It bGF0aW47IG1zby1iaWRpLWZvbnQtZmFtaWx5OiAmcXVvdDtBcmlhbCZxdW90OzsgbXNvLWFuc2kt bGFuZ3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogRU4tR0I7IG1zby1iaWRpLWxh bmd1YWdlOiBBUi1TQSI+VGhpcw0KIGVtYWlsIGFuZCBpdHMgYXR0YWNobWVudHMgYXJlIGludGVu ZGVkIGZvciB0aGUgYWJvdmUgbmFtZWQgb25seSBhbmQgbWF5IGJlIGNvbmZpZGVudGlhbC4gSWYg dGhleSBoYXZlIGNvbWUgdG8geW91IGluIGVycm9yIHlvdSBtdXN0IHRha2Ugbm8gYWN0aW9uIGJh c2VkIG9uIHRoZW0sIG5vciBtdXN0IHlvdSBjb3B5IG9yIHNob3cgdGhlbSB0byBhbnlvbmU7IHBs ZWFzZSByZXBseSB0byB0aGlzIGVtYWlsIG9yIGNhbGwgJiM0Mzs0NCAyMDcgMzU2IDA2MDANCiBh bmQgaGlnaGxpZ2h0IHRoZSBlcnJvci4gPC9zcGFuPjwvcD4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_483C1110AD7F4D53982DA68443ADEE9Egsmacom_-- From nobody Wed Nov 11 00:03:49 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 764601B3437 for ; Wed, 11 Nov 2015 00:03:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 q7hDUnh9RAmB for ; Wed, 11 Nov 2015 00:03:43 -0800 (PST) Received: from bin-vsp-out-03.atm.binero.net (bin-mail-out-06.binero.net [195.74.38.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6BEC1B3434 for ; Wed, 11 Nov 2015 00:03:42 -0800 (PST) X-Halon-ID: b3129941-884a-11e5-8d2f-0050569116f7 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.48] (unknown [83.209.226.9]) by bin-vsp-out-03.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Wed, 11 Nov 2015 09:03:31 +0100 (CET) To: Natasha Rooney References: <563818F9.2060709@alum.mit.edu> <56388C4D.4090808@omnitor.se> <56398719.7030205@omnitor.se> <21767FCE-C1BD-4C42-A07E-16BC81586073@gmail.com> <563A2A24.2020102@alum.mit.edu> <44BE7894-2944-42FE-A136-ADB629D49143@gmail.com> <563B04A5.4040407@omnitor.se> <563B79F2.1010608@alum.mit.edu> <563BDE10.5050305@omnitor.se> <563C25AD.3050801@alum.mit.edu> <563D3AF5.1020608@omnitor.se> <563E58EC.3090304@omnitor.se> <563EB249.7020909@it.aoyama.ac.jp> <563EDA4A.6050206@omnitor.se> <483C1110-AD7F-4D53-982D-A68443ADEE9E@gsma.com> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <5642F652.8060206@omnitor.se> Date: Wed, 11 Nov 2015 09:03:30 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <483C1110-AD7F-4D53-982D-A68443ADEE9E@gsma.com> Content-Type: multipart/alternative; boundary="------------060909090002050007050902" Archived-At: Cc: "slim@ietf.org" Subject: Re: [Slim] Handling the complex multi-media cases X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 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, 11 Nov 2015 08:03:46 -0000 This is a multi-part message in MIME format. --------------060909090002050007050902 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Natasha and all, Thanks for the offer, I will collect the use case sources for you. There were some in the earlier draft version also. I don't remember why they were deleted. Maybe too much thoughts on the resulting routing?? Or were they far fetched? They could also be recovered to the collection you compose. Gunnar Den 2015-11-11 kl. 07:54, skrev Natasha Rooney: > Hey guys, > > It would be a good idea to capture the use case identified by Gunnar > at the meeting at IETF94 and given in this thread in a document, this > will allow us to be able to refer to them in one place rather than > referring down a thread. > > Gunnar - I can build this document, to get started can you just send a > me your list of use cases with any amendments which may have been > identified in this email thread? I will then add them to a document > which will be in an RFC format. > > After I get the initial list from Gunnar I will send the document to > the list and request additions. There may be a need to push this > document to be an RFC in the future, for now we will treat it as a note. > > Thanks everyone! > > Natasha > > > Natasha Rooney | Technologist, Web and Internet, W3C & IETF | GSMA | > nrooney@gsma.com | +44 (0) 7730 219 765 | > @thisNatasha | Skype: nrooney@gsm.org > Tokyo, Japan > > >> On Nov 8, 2015, at 2:14 PM, Gunnar Hellström >> > wrote: >> >> >> >> Den 2015-11-08 kl. 03:24, skrev Martin J. Dürst: >>> On 2015/11/08 05:02, Gunnar Hellström wrote: >>> >>>> In the draft, section 3.2, there is a paragraph >>> >>> Which draft? I thought we are speaking about >>> https://tools.ietf.org/html/draft-ietf-slim-negotiating-human-language-00 >> [GH]Yes, sorry, I meant 6.2. There is also an expansion of the topic >> in 6.3. >>> >>> but there's no section 3.2 (Section 3 is extremely short). >>> >>>> " >>>> >>>> In an offer, each language tag value MAY have an asterisk appended as >>>> the last character (after the registry value). The asterisk >>>> indicates a request by the caller to not fail the call if there >>>> is no >>>> language in common." >>> >>> What exactly is meant with this? >>> >>> Is it something like: >>> >>> en-US, en-AU, fr-CA, * >>> >>> (i.e. essentially the same as the HTTP Accept-Language header)? >>> >>> Or is it something like >>> >>> en-US*, en-AU*, fr-CA* >>> >>> The later would be totally out of line with previous use of language >>> tags and subtags, but it's what I'd guess from a direct reading of >>> the text. >> [GH] Yes, that was also my interpretation. And wondering what was >> meant. A complete syntax description and example is needed. >> But also a discussion if this non-fail parameter should be merged >> with the other priority values that I propose. >> >> /Gunnar >>> >>> Regards, Martin. >>> >>> _______________________________________________ >>> 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 > > 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. > -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 --------------060909090002050007050902 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Natasha and all,
Thanks for the offer, I will collect the use case sources for you.
There were some in the earlier draft version also.
I don't remember why they were deleted. Maybe too much thoughts on the resulting routing??
Or were they far fetched?

They could also be recovered to the collection you compose.

Gunnar

Den 2015-11-11 kl. 07:54, skrev Natasha Rooney:
Hey guys,

It would be a good idea to capture the use case identified by Gunnar at the meeting at IETF94 and given in this thread in a document, this will allow us to be able to refer to them in one place rather than referring down a thread. 

Gunnar - I can build this document, to get started can you just send a me your list of use cases with any amendments which may have been identified in this email thread? I will then add them to a document which will be in an RFC format.

After I get the initial list from Gunnar I will send the document to the list and request additions. There may be a need to push this document to be an RFC in the future, for now we will treat it as a note.

Thanks everyone!

Natasha


Natasha Rooney | Technologist, Web and Internet, W3C & IETF | GSMA | nrooney@gsma.com | +44 (0) 7730 219 765 | @thisNatasha | Skype: nrooney@gsm.org 
Tokyo, Japan


On Nov 8, 2015, at 2:14 PM, Gunnar Hellström <gunnar.hellstrom@omnitor.se> wrote:



Den 2015-11-08 kl. 03:24, skrev Martin J. Dürst:
On 2015/11/08 05:02, Gunnar Hellström wrote:

In the draft, section 3.2, there is a paragraph

Which draft? I thought we are speaking about
https://tools.ietf.org/html/draft-ietf-slim-negotiating-human-language-00
[GH]Yes, sorry, I meant 6.2.  There is also an expansion of the topic in 6.3.

but there's no section 3.2 (Section 3 is extremely short).

"

In an offer, each language tag value MAY have an asterisk appended as
   the last character (after the registry value).  The asterisk
   indicates a request by the caller to not fail the call if there is no
   language in common."

What exactly is meant with this?

Is it something like:

en-US, en-AU, fr-CA, *

(i.e. essentially the same as the HTTP Accept-Language header)?

Or is it something like

en-US*, en-AU*, fr-CA*

The later would be totally out of line with previous use of language tags and subtags, but it's what I'd guess from a direct reading of the text.
[GH] Yes, that was also my interpretation. And wondering what was meant. A complete syntax description and example is needed.
But also a discussion if this non-fail parameter should be merged with the other priority values that I propose.

/Gunnar

Regards,   Martin.

_______________________________________________
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

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. 


-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288
--------------060909090002050007050902-- From nobody Wed Nov 18 02:44:42 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0363F1B2C02 for ; Wed, 18 Nov 2015 02:44:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 v-biaSt_eXtM for ; Wed, 18 Nov 2015 02:44:38 -0800 (PST) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0667.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::667]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EBC11B2C00 for ; Wed, 18 Nov 2015 02:44:37 -0800 (PST) Received: from HE1PR04MB1033.eurprd04.prod.outlook.com (10.162.26.142) by HE1PR04MB1035.eurprd04.prod.outlook.com (10.162.26.144) with Microsoft SMTP Server (TLS) id 15.1.325.17; Wed, 18 Nov 2015 10:44:12 +0000 Received: from HE1PR04MB1033.eurprd04.prod.outlook.com ([10.162.26.142]) by HE1PR04MB1033.eurprd04.prod.outlook.com ([10.162.26.142]) with mapi id 15.01.0325.019; Wed, 18 Nov 2015 10:44:12 +0000 From: Natasha Rooney To: =?utf-8?B?R3VubmFyIEhlbGxzdHLDtm0=?= Thread-Topic: [Slim] Handling the complex multi-media cases Thread-Index: AQHRFdukkQOmwfH0skiNbU74B2PoSp6Jj5CAgACJe4CAAKuyAIAAf0eAgAATGoCAAK9DAIAAFrcAgADtw4CAAIvVAIAAd1oAgABVXoCAAUqMgIABD9AAgABFFgCAAGqHgIAAL7AAgATSvQCAABNiAIALLTaA Date: Wed, 18 Nov 2015 10:44:12 +0000 Message-ID: <8CD947C5-D877-4E85-BEB7-8A362B7E313C@gsma.com> References: <563818F9.2060709@alum.mit.edu> <56388C4D.4090808@omnitor.se> <56398719.7030205@omnitor.se> <21767FCE-C1BD-4C42-A07E-16BC81586073@gmail.com> <563A2A24.2020102@alum.mit.edu> <44BE7894-2944-42FE-A136-ADB629D49143@gmail.com> <563B04A5.4040407@omnitor.se> <563B79F2.1010608@alum.mit.edu> <563BDE10.5050305@omnitor.se> <563C25AD.3050801@alum.mit.edu> <563D3AF5.1020608@omnitor.se> <563E58EC.3090304@omnitor.se> <563EB249.7020909@it.aoyama.ac.jp> <563EDA4A.6050206@omnitor.se> <483C1110-AD7F-4D53-982D-A68443ADEE9E@gsma.com> <5642F652.8060206@omnitor.se> In-Reply-To: <5642F652.8060206@omnitor.se> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3096.5) authentication-results: spf=none (sender IP is ) smtp.mailfrom=nrooney@gsma.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [153.209.76.42] x-microsoft-exchange-diagnostics: 1; HE1PR04MB1035; 5:yVKgA0HsMQKLylInR2+/vVcWLkWJgsTOptqb3ZxDAwOlCYIoQ9Mn7Lwjgy/a+8KwtY9eFwi7agxFZml2GPmu0VX9oAezMiaK0JVyte8IfrTJRQ2DqdLodIM0rPESisRfau9BTTt9A8+zt4gtCFp/BA==; 24:KK5d/aBVqQE70SPeM8uLC6VIeD7qq0KORfV0H4x1+iUqOHckvBfoOQMnWvQSgraszwXU+N1J+XhAgkNHodgICMXWpktHaQh6/70E2p5D8aw=; 20:9hmQ5L9q+Z9rVpw4DU7Y6k7Gw2EjSOcbPInCcHEesl0xkQt0HK+6Lz4rGMSYz9l9Fs3skDtcEAIvfCLN9+bTlw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR04MB1035; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(260367931017790); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(10201501046)(3002001); SRVR:HE1PR04MB1035; BCL:0; PCL:0; RULEID:; SRVR:HE1PR04MB1035; x-forefront-prvs: 0764C4A8CD x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(479174004)(377424004)(51914003)(189002)(199003)(377454003)(24454002)(66654002)(19580405001)(50986999)(33656002)(93886004)(66066001)(2900100001)(77096005)(2950100001)(76176999)(92566002)(19580395003)(5004730100002)(11100500001)(36756003)(122556002)(40100003)(586003)(10400500002)(5007970100001)(57306001)(87936001)(101416001)(106356001)(82746002)(83716003)(5002640100001)(105586002)(106116001)(5008740100001)(15975445007)(102836002)(16236675004)(50226001)(81156007)(189998001)(86362001)(4001150100001)(110136002)(5001960100002)(97736004)(19617315012)(5890100001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR04MB1035; H:HE1PR04MB1033.eurprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: gsma.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_8CD947C5D8774E85BEB78A362B7E313Cgsmacom_" MIME-Version: 1.0 X-OriginatorOrg: gsma.com X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Nov 2015 10:44:12.5124 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72a4ff82-fec3-469d-aafb-ac8276216699 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR04MB1035 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: HE1PR04MB1033.eurprd04.prod.outlook.com X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-originalclientipaddress: 153.209.76.42 X-MS-Exchange-CrossPremises-avstamp-service: 1.0 X-MS-Exchange-CrossPremises-disclaimer-hash: 78ca8040c6722e32c2f5b0a45bf37e74b9409d645a53be96aa19958e0cee0f00 X-MS-Exchange-CrossPremises-antispam-scancontext: DIR:Originating; SFV:NSPM; SKIP:0; X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-OrganizationHeadersPreserved: HE1PR04MB1035.eurprd04.prod.outlook.com Archived-At: Cc: "slim@ietf.org" Subject: Re: [Slim] Handling the complex multi-media cases X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 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, 18 Nov 2015 10:44:42 -0000 --_000_8CD947C5D8774E85BEB78A362B7E313Cgsmacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGV5IEd1bm5hciENCg0KT24gTm92IDExLCAyMDE1LCBhdCA1OjAzIFBNLCBHdW5uYXIgSGVsbHN0 csO2bSA8Z3VubmFyLmhlbGxzdHJvbUBvbW5pdG9yLnNlPG1haWx0bzpndW5uYXIuaGVsbHN0cm9t QG9tbml0b3Iuc2U+PiB3cm90ZToNCg0KSGkgTmF0YXNoYSBhbmQgYWxsLA0KVGhhbmtzIGZvciB0 aGUgb2ZmZXIsIEkgd2lsbCBjb2xsZWN0IHRoZSB1c2UgY2FzZSBzb3VyY2VzIGZvciB5b3UuDQoN Ck1hbnkgdGhhbmtzISBKdXN0IHNlbmQgdGhlbSBvdmVyIHdoZW5ldmVyIHlvdSBoYXZlIHRoZW0u IEkgd2lsbCBzZXR1cCB0aGUgcmVwbyBlYXJseSBuZXh0IHdlZWsgdG8gY3JlYXRlIHRoZSBkcmFm dC4NCg0KVGhlcmUgd2VyZSBzb21lIGluIHRoZSBlYXJsaWVyIGRyYWZ0IHZlcnNpb24gYWxzby4N CkkgZG9uJ3QgcmVtZW1iZXIgd2h5IHRoZXkgd2VyZSBkZWxldGVkLiBNYXliZSB0b28gbXVjaCB0 aG91Z2h0cyBvbiB0aGUgcmVzdWx0aW5nIHJvdXRpbmc/Pw0KDQpJ4oCZbSBhZnJhaWQgSSBhbSBu b3Qgc3VyZSBhYm91dCB0aGlzIC0gR3V5cyAtIGFueSByZWFzb24gd2h5IEd1bm5hcuKAmXMgdXNl IGNhc2VzIHdlcmUgdGFrZW4gZnJvbSB0aGUgZWFybGllciBkcmFmdD8gSW4gYW55IGNhc2Ugd2Ug d2lsbCBmZWVkIHRoZW0gaW50byB0aGlzIG5ldyBkcmFmdCwgc28gdGhleeKAmWxsIGhhdmUgYSBw cm9wZXIgaG9tZSENCg0KT3Igd2VyZSB0aGV5IGZhciBmZXRjaGVkPw0KDQpUaGV5IGNvdWxkIGFs c28gYmUgcmVjb3ZlcmVkIHRvIHRoZSBjb2xsZWN0aW9uIHlvdSBjb21wb3NlLg0KDQpHdW5uYXIN Cg0KRGVuIDIwMTUtMTEtMTEga2wuIDA3OjU0LCBza3JldiBOYXRhc2hhIFJvb25leToNCkhleSBn dXlzLA0KDQpJdCB3b3VsZCBiZSBhIGdvb2QgaWRlYSB0byBjYXB0dXJlIHRoZSB1c2UgY2FzZSBp ZGVudGlmaWVkIGJ5IEd1bm5hciBhdCB0aGUgbWVldGluZyBhdCBJRVRGOTQgYW5kIGdpdmVuIGlu IHRoaXMgdGhyZWFkIGluIGEgZG9jdW1lbnQsIHRoaXMgd2lsbCBhbGxvdyB1cyB0byBiZSBhYmxl IHRvIHJlZmVyIHRvIHRoZW0gaW4gb25lIHBsYWNlIHJhdGhlciB0aGFuIHJlZmVycmluZyBkb3du IGEgdGhyZWFkLg0KDQpHdW5uYXIgLSBJIGNhbiBidWlsZCB0aGlzIGRvY3VtZW50LCB0byBnZXQg c3RhcnRlZCBjYW4geW91IGp1c3Qgc2VuZCBhIG1lIHlvdXIgbGlzdCBvZiB1c2UgY2FzZXMgd2l0 aCBhbnkgYW1lbmRtZW50cyB3aGljaCBtYXkgaGF2ZSBiZWVuIGlkZW50aWZpZWQgaW4gdGhpcyBl bWFpbCB0aHJlYWQ/IEkgd2lsbCB0aGVuIGFkZCB0aGVtIHRvIGEgZG9jdW1lbnQgd2hpY2ggd2ls bCBiZSBpbiBhbiBSRkMgZm9ybWF0Lg0KDQpBZnRlciBJIGdldCB0aGUgaW5pdGlhbCBsaXN0IGZy b20gR3VubmFyIEkgd2lsbCBzZW5kIHRoZSBkb2N1bWVudCB0byB0aGUgbGlzdCBhbmQgcmVxdWVz dCBhZGRpdGlvbnMuIFRoZXJlIG1heSBiZSBhIG5lZWQgdG8gcHVzaCB0aGlzIGRvY3VtZW50IHRv IGJlIGFuIFJGQyBpbiB0aGUgZnV0dXJlLCBmb3Igbm93IHdlIHdpbGwgdHJlYXQgaXQgYXMgYSBu b3RlLg0KDQpUaGFua3MgZXZlcnlvbmUhDQoNCk5hdGFzaGENCg0KDQpOYXRhc2hhIFJvb25leSB8 IFRlY2hub2xvZ2lzdCwgV2ViIGFuZCBJbnRlcm5ldCwgVzNDICYgSUVURiB8IEdTTUEgfCBucm9v bmV5QGdzbWEuY29tPG1haWx0bzpucm9vbmV5QGdzbWEuY29tPiB8ICs0NCAoMCkgNzczMCAyMTkg NzY1IHwgQHRoaXNOYXRhc2hhIHwgU2t5cGU6IG5yb29uZXlAZ3NtLm9yZzxtYWlsdG86bnJvb25l eUBnc20ub3JnPg0KVG9reW8sIEphcGFuDQoNCg0KT24gTm92IDgsIDIwMTUsIGF0IDI6MTQgUE0s IEd1bm5hciBIZWxsc3Ryw7ZtIDxndW5uYXIuaGVsbHN0cm9tQG9tbml0b3Iuc2U8bWFpbHRvOmd1 bm5hci5oZWxsc3Ryb21Ab21uaXRvci5zZT4+IHdyb3RlOg0KDQoNCg0KRGVuIDIwMTUtMTEtMDgg a2wuIDAzOjI0LCBza3JldiBNYXJ0aW4gSi4gRMO8cnN0Og0KT24gMjAxNS8xMS8wOCAwNTowMiwg R3VubmFyIEhlbGxzdHLDtm0gd3JvdGU6DQoNCkluIHRoZSBkcmFmdCwgc2VjdGlvbiAzLjIsIHRo ZXJlIGlzIGEgcGFyYWdyYXBoDQoNCldoaWNoIGRyYWZ0PyBJIHRob3VnaHQgd2UgYXJlIHNwZWFr aW5nIGFib3V0DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1zbGltLW5l Z290aWF0aW5nLWh1bWFuLWxhbmd1YWdlLTAwDQpbR0hdWWVzLCBzb3JyeSwgSSBtZWFudCA2LjIu ICBUaGVyZSBpcyBhbHNvIGFuIGV4cGFuc2lvbiBvZiB0aGUgdG9waWMgaW4gNi4zLg0KDQpidXQg dGhlcmUncyBubyBzZWN0aW9uIDMuMiAoU2VjdGlvbiAzIGlzIGV4dHJlbWVseSBzaG9ydCkuDQoN CiINCg0KSW4gYW4gb2ZmZXIsIGVhY2ggbGFuZ3VhZ2UgdGFnIHZhbHVlIE1BWSBoYXZlIGFuIGFz dGVyaXNrIGFwcGVuZGVkIGFzDQogICB0aGUgbGFzdCBjaGFyYWN0ZXIgKGFmdGVyIHRoZSByZWdp c3RyeSB2YWx1ZSkuICBUaGUgYXN0ZXJpc2sNCiAgIGluZGljYXRlcyBhIHJlcXVlc3QgYnkgdGhl IGNhbGxlciB0byBub3QgZmFpbCB0aGUgY2FsbCBpZiB0aGVyZSBpcyBubw0KICAgbGFuZ3VhZ2Ug aW4gY29tbW9uLiINCg0KV2hhdCBleGFjdGx5IGlzIG1lYW50IHdpdGggdGhpcz8NCg0KSXMgaXQg c29tZXRoaW5nIGxpa2U6DQoNCmVuLVVTLCBlbi1BVSwgZnItQ0EsICoNCg0KKGkuZS4gZXNzZW50 aWFsbHkgdGhlIHNhbWUgYXMgdGhlIEhUVFAgQWNjZXB0LUxhbmd1YWdlIGhlYWRlcik/DQoNCk9y IGlzIGl0IHNvbWV0aGluZyBsaWtlDQoNCmVuLVVTKiwgZW4tQVUqLCBmci1DQSoNCg0KVGhlIGxh dGVyIHdvdWxkIGJlIHRvdGFsbHkgb3V0IG9mIGxpbmUgd2l0aCBwcmV2aW91cyB1c2Ugb2YgbGFu Z3VhZ2UgdGFncyBhbmQgc3VidGFncywgYnV0IGl0J3Mgd2hhdCBJJ2QgZ3Vlc3MgZnJvbSBhIGRp cmVjdCByZWFkaW5nIG9mIHRoZSB0ZXh0Lg0KW0dIXSBZZXMsIHRoYXQgd2FzIGFsc28gbXkgaW50 ZXJwcmV0YXRpb24uIEFuZCB3b25kZXJpbmcgd2hhdCB3YXMgbWVhbnQuIEEgY29tcGxldGUgc3lu dGF4IGRlc2NyaXB0aW9uIGFuZCBleGFtcGxlIGlzIG5lZWRlZC4NCkJ1dCBhbHNvIGEgZGlzY3Vz c2lvbiBpZiB0aGlzIG5vbi1mYWlsIHBhcmFtZXRlciBzaG91bGQgYmUgbWVyZ2VkIHdpdGggdGhl IG90aGVyIHByaW9yaXR5IHZhbHVlcyB0aGF0IEkgcHJvcG9zZS4NCg0KL0d1bm5hcg0KDQpSZWdh cmRzLCAgIE1hcnRpbi4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NClNMSU0gbWFpbGluZyBsaXN0DQpTTElNQGlldGYub3JnPG1haWx0bzpTTElNQGll dGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zbGltDQoNCi0t DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KR3VubmFyIEhlbGxz dHLDtm0NCk9tbml0b3INCmd1bm5hci5oZWxsc3Ryb21Ab21uaXRvci5zZTxtYWlsdG86Z3VubmFy LmhlbGxzdHJvbUBvbW5pdG9yLnNlPg0KKzQ2IDcwOCAyMDQgMjg4DQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpTTElNIG1haWxpbmcgbGlzdA0KU0xJ TUBpZXRmLm9yZzxtYWlsdG86U0xJTUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc2xpbQ0KDQoNClRoaXMgZW1haWwgYW5kIGl0cyBhdHRhY2htZW50cyBh cmUgaW50ZW5kZWQgZm9yIHRoZSBhYm92ZSBuYW1lZCBvbmx5IGFuZCBtYXkgYmUgY29uZmlkZW50 aWFsLiBJZiB0aGV5IGhhdmUgY29tZSB0byB5b3UgaW4gZXJyb3IgeW91IG11c3QgdGFrZSBubyBh Y3Rpb24gYmFzZWQgb24gdGhlbSwgbm9yIG11c3QgeW91IGNvcHkgb3Igc2hvdyB0aGVtIHRvIGFu eW9uZTsgcGxlYXNlIHJlcGx5IHRvIHRoaXMgZW1haWwgb3IgY2FsbCArNDQgMjA3IDM1NiAwNjAw IGFuZCBoaWdobGlnaHQgdGhlIGVycm9yLg0KDQoNCi0tDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KR3VubmFyIEhlbGxzdHLDtm0NCk9tbml0b3INCmd1bm5hci5o ZWxsc3Ryb21Ab21uaXRvci5zZTxtYWlsdG86Z3VubmFyLmhlbGxzdHJvbUBvbW5pdG9yLnNlPg0K KzQ2IDcwOCAyMDQgMjg4DQoNCg0KVGhpcyBlbWFpbCBhbmQgaXRzIGF0dGFjaG1lbnRzIGFyZSBp bnRlbmRlZCBmb3IgdGhlIGFib3ZlIG5hbWVkIG9ubHkgYW5kIG1heSBiZSBjb25maWRlbnRpYWwu IElmIHRoZXkgaGF2ZSBjb21lIHRvIHlvdSBpbiBlcnJvciB5b3UgbXVzdCB0YWtlIG5vIGFjdGlv biBiYXNlZCBvbiB0aGVtLCBub3IgbXVzdCB5b3UgY29weSBvciBzaG93IHRoZW0gdG8gYW55b25l OyBwbGVhc2UgcmVwbHkgdG8gdGhpcyBlbWFpbCBvciBjYWxsICs0NCAyMDcgMzU2IDA2MDAgYW5k IGhpZ2hsaWdodCB0aGUgZXJyb3IuDQo= --_000_8CD947C5D8774E85BEB78A362B7E313Cgsmacom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGV5IEd1bm5hciE8YnIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9 IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIE5vdiAxMSwgMjAxNSwgYXQgNTowMyBQTSwgR3VubmFyIEhl bGxzdHLDtm0gJmx0OzxhIGhyZWY9Im1haWx0bzpndW5uYXIuaGVsbHN0cm9tQG9tbml0b3Iuc2Ui IGNsYXNzPSIiPmd1bm5hci5oZWxsc3Ryb21Ab21uaXRvci5zZTwvYT4mZ3Q7IHdyb3RlOjwvZGl2 Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+ DQo8ZGl2IGJnY29sb3I9IiNGRkZGRkYiIHRleHQ9IiMwMDAwMDAiIGNsYXNzPSIiPkhpIE5hdGFz aGEgYW5kIGFsbCw8YnIgY2xhc3M9IiI+DQpUaGFua3MgZm9yIHRoZSBvZmZlciwgSSB3aWxsIGNv bGxlY3QgdGhlIHVzZSBjYXNlIHNvdXJjZXMgZm9yIHlvdS48YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+ TWFueSB0aGFua3MhIEp1c3Qgc2VuZCB0aGVtIG92ZXIgd2hlbmV2ZXIgeW91IGhhdmUgdGhlbS4g SSB3aWxsIHNldHVwIHRoZSByZXBvIGVhcmx5IG5leHQgd2VlayB0byBjcmVhdGUgdGhlIGRyYWZ0 LiZuYnNwOzwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xh c3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBiZ2NvbG9yPSIjRkZGRkZGIiB0ZXh0PSIjMDAw MDAwIiBjbGFzcz0iIj5UaGVyZSB3ZXJlIHNvbWUgaW4gdGhlIGVhcmxpZXIgZHJhZnQgdmVyc2lv biBhbHNvLg0KPGJyIGNsYXNzPSIiPg0KSSBkb24ndCByZW1lbWJlciB3aHkgdGhleSB3ZXJlIGRl bGV0ZWQuIE1heWJlIHRvbyBtdWNoIHRob3VnaHRzIG9uIHRoZSByZXN1bHRpbmcgcm91dGluZz8/ PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8ZGl2PknigJltIGFmcmFpZCBJIGFtIG5vdCBzdXJlIGFib3V0IHRo aXMgLSBHdXlzIC0gYW55IHJlYXNvbiB3aHkgR3VubmFy4oCZcyB1c2UgY2FzZXMgd2VyZSB0YWtl biBmcm9tIHRoZSBlYXJsaWVyIGRyYWZ0PyBJbiBhbnkgY2FzZSB3ZSB3aWxsIGZlZWQgdGhlbSBp bnRvIHRoaXMgbmV3IGRyYWZ0LCBzbyB0aGV54oCZbGwgaGF2ZSBhIHByb3BlciBob21lITwvZGl2 Pg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2 IGNsYXNzPSIiPg0KPGRpdiBiZ2NvbG9yPSIjRkZGRkZGIiB0ZXh0PSIjMDAwMDAwIiBjbGFzcz0i Ij5PciB3ZXJlIHRoZXkgZmFyIGZldGNoZWQ/PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0K VGhleSBjb3VsZCBhbHNvIGJlIHJlY292ZXJlZCB0byB0aGUgY29sbGVjdGlvbiB5b3UgY29tcG9z ZS48L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIg Y2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBiZ2NvbG9yPSIjRkZGRkZGIiB0ZXh0PSIj MDAwMDAwIiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQpHdW5uYXI8YnIgY2xhc3M9IiI+DQo8YnIg Y2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJtb3otY2l0ZS1wcmVmaXgiPkRlbiAyMDE1LTExLTExIGts LiAwNzo1NCwgc2tyZXYgTmF0YXNoYSBSb29uZXk6PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBjaXRlPSJtaWQ6NDgzQzExMTAtQUQ3Ri00RDUzLTk4MkQtQTY4NDQzQURFRTlFQGdz bWEuY29tIiB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCkhleSBndXlzLDxiciBjbGFzcz0iIj4NCjxk aXYgY2xhc3M9IiI+PGJyIGNsYXNzPSJ3ZWJraXQtYmxvY2stcGxhY2Vob2xkZXIiPg0KPC9kaXY+ DQo8ZGl2IGFwcGxlLWNvbnRlbnQtZWRpdGVkPSJ0cnVlIiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9 ImxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0 OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5v cm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9r ZS13aWR0aDogMHB4OyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBz cGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0K SXQgd291bGQgYmUgYSBnb29kIGlkZWEgdG8gY2FwdHVyZSB0aGUgdXNlIGNhc2UgaWRlbnRpZmll ZCBieSBHdW5uYXIgYXQgdGhlIG1lZXRpbmcgYXQgSUVURjk0IGFuZCBnaXZlbiBpbiB0aGlzIHRo cmVhZCBpbiBhIGRvY3VtZW50LCB0aGlzIHdpbGwgYWxsb3cgdXMgdG8gYmUgYWJsZSB0byByZWZl ciB0byB0aGVtIGluIG9uZSBwbGFjZSByYXRoZXIgdGhhbiByZWZlcnJpbmcgZG93biBhIHRocmVh ZC4mbmJzcDs8L2Rpdj4NCjxkaXYgc3R5bGU9ImxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhh bnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5z Zm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNp bmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB3b3JkLXdyYXA6IGJyZWFr LXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRl ci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IHN0 eWxlPSJsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBz dGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNl OiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1z dHJva2Utd2lkdGg6IDBweDsgd29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9k ZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0i Ij4NCkd1bm5hciAtIEkgY2FuIGJ1aWxkIHRoaXMgZG9jdW1lbnQsIHRvIGdldCBzdGFydGVkIGNh biB5b3UganVzdCBzZW5kIGEgbWUgeW91ciBsaXN0IG9mIHVzZSBjYXNlcyB3aXRoIGFueSBhbWVu ZG1lbnRzIHdoaWNoIG1heSBoYXZlIGJlZW4gaWRlbnRpZmllZCBpbiB0aGlzIGVtYWlsIHRocmVh ZD8gSSB3aWxsIHRoZW4gYWRkIHRoZW0gdG8gYSBkb2N1bWVudCB3aGljaCB3aWxsIGJlIGluIGFu IFJGQyBmb3JtYXQuPC9kaXY+DQo8ZGl2IHN0eWxlPSJsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBv cnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10 cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1z cGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgd29yZC13cmFwOiBi cmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazog YWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRp diBzdHlsZT0ibGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGln bjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1z cGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRl eHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHdvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNw LW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xh c3M9IiI+DQpBZnRlciBJIGdldCB0aGUgaW5pdGlhbCBsaXN0IGZyb20gR3VubmFyIEkgd2lsbCBz ZW5kIHRoZSBkb2N1bWVudCB0byB0aGUgbGlzdCBhbmQgcmVxdWVzdCBhZGRpdGlvbnMuIFRoZXJl IG1heSBiZSBhIG5lZWQgdG8gcHVzaCB0aGlzIGRvY3VtZW50IHRvIGJlIGFuIFJGQyBpbiB0aGUg ZnV0dXJlLCBmb3Igbm93IHdlIHdpbGwgdHJlYXQgaXQgYXMgYSBub3RlLjwvZGl2Pg0KPGRpdiBz dHlsZT0ibGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjog c3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFj ZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQt c3Ryb2tlLXdpZHRoOiAwcHg7IHdvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1v ZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImxldHRlci1zcGFjaW5nOiBu b3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4 OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRv OyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB3b3Jk LXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5l LWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KVGhhbmtzIGV2ZXJ5b25lITxi ciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCk5hdGFzaGE8YnIgY2xhc3M9IiI+DQo8YnIgY2xh c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpOYXRhc2hhIFJvb25leSB8IFRlY2hub2xvZ2lzdCwgV2Vi IGFuZCBJbnRlcm5ldCwgVzNDICZhbXA7IElFVEYgfCZuYnNwO0dTTUEgfCA8YSBtb3otZG8tbm90 LXNlbmQ9InRydWUiIGhyZWY9Im1haWx0bzpucm9vbmV5QGdzbWEuY29tIiBjbGFzcz0iIj4NCm5y b29uZXlAZ3NtYS5jb208L2E+IHwgJiM0Mzs0NCAoMCkmbmJzcDs3NzMwIDIxOSA3NjUgfCBAdGhp c05hdGFzaGEgfCBTa3lwZTombmJzcDs8YSBtb3otZG8tbm90LXNlbmQ9InRydWUiIGhyZWY9Im1h aWx0bzpucm9vbmV5QGdzbS5vcmciIGNsYXNzPSIiPm5yb29uZXlAZ3NtLm9yZzwvYT4mbmJzcDs8 YnIgY2xhc3M9IiI+DQpUb2t5bywgSmFwYW48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxibG9ja3F1b3Rl IHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBOb3YgOCwgMjAxNSwgYXQg MjoxNCBQTSwgR3VubmFyIEhlbGxzdHLDtm0gJmx0OzxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIg aHJlZj0ibWFpbHRvOmd1bm5hci5oZWxsc3Ryb21Ab21uaXRvci5zZSIgY2xhc3M9IiI+Z3VubmFy LmhlbGxzdHJvbUBvbW5pdG9yLnNlPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFw cGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+ PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KRGVuIDIwMTUtMTEtMDgga2wuIDAzOjI0LCBz a3JldiBNYXJ0aW4gSi4gRMO8cnN0OjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNp dGUiIGNsYXNzPSIiPk9uIDIwMTUvMTEvMDggMDU6MDIsIEd1bm5hciBIZWxsc3Ryw7ZtIHdyb3Rl OjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNs YXNzPSIiPkluIHRoZSBkcmFmdCwgc2VjdGlvbiAzLjIsIHRoZXJlIGlzIGEgcGFyYWdyYXBoPGJy IGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KV2hpY2ggZHJhZnQ/IEkg dGhvdWdodCB3ZSBhcmUgc3BlYWtpbmcgYWJvdXQ8YnIgY2xhc3M9IiI+DQo8YSBtb3otZG8tbm90 LXNlbmQ9InRydWUiIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm LXNsaW0tbmVnb3RpYXRpbmctaHVtYW4tbGFuZ3VhZ2UtMDAiIGNsYXNzPSIiPmh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXNsaW0tbmVnb3RpYXRpbmctaHVtYW4tbGFuZ3Vh Z2UtMDA8L2E+PGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KW0dIXVllcywgc29ycnksIEkg bWVhbnQgNi4yLiAmbmJzcDtUaGVyZSBpcyBhbHNvIGFuIGV4cGFuc2lvbiBvZiB0aGUgdG9waWMg aW4gNi4zLjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCmJ1dCB0aGVyZSdzIG5vIHNlY3Rpb24gMy4yIChTZWN0aW9uIDMgaXMgZXh0 cmVtZWx5IHNob3J0KS48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0 eXBlPSJjaXRlIiBjbGFzcz0iIj4mcXVvdDs8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpJ biBhbiBvZmZlciwgZWFjaCBsYW5ndWFnZSB0YWcgdmFsdWUgTUFZIGhhdmUgYW4gYXN0ZXJpc2sg YXBwZW5kZWQgYXM8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDt0aGUgbGFzdCBjaGFy YWN0ZXIgKGFmdGVyIHRoZSByZWdpc3RyeSB2YWx1ZSkuICZuYnNwO1RoZSBhc3RlcmlzazxiciBj bGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwO2luZGljYXRlcyBhIHJlcXVlc3QgYnkgdGhlIGNh bGxlciB0byBub3QgZmFpbCB0aGUgY2FsbCBpZiB0aGVyZSBpcyBubzxiciBjbGFzcz0iIj4NCiZu YnNwOyZuYnNwOyZuYnNwO2xhbmd1YWdlIGluIGNvbW1vbi4mcXVvdDs8YnIgY2xhc3M9IiI+DQo8 L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+DQpXaGF0IGV4YWN0bHkgaXMgbWVhbnQgd2l0aCB0 aGlzPzxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCklzIGl0IHNvbWV0aGluZyBsaWtlOjxi ciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCmVuLVVTLCBlbi1BVSwgZnItQ0EsICo8YnIgY2xh c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQooaS5lLiBlc3NlbnRpYWxseSB0aGUgc2FtZSBhcyB0aGUg SFRUUCBBY2NlcHQtTGFuZ3VhZ2UgaGVhZGVyKT88YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+ DQpPciBpcyBpdCBzb21ldGhpbmcgbGlrZTxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCmVu LVVTKiwgZW4tQVUqLCBmci1DQSo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpUaGUgbGF0 ZXIgd291bGQgYmUgdG90YWxseSBvdXQgb2YgbGluZSB3aXRoIHByZXZpb3VzIHVzZSBvZiBsYW5n dWFnZSB0YWdzIGFuZCBzdWJ0YWdzLCBidXQgaXQncyB3aGF0IEknZCBndWVzcyBmcm9tIGEgZGly ZWN0IHJlYWRpbmcgb2YgdGhlIHRleHQuPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KW0dI XSBZZXMsIHRoYXQgd2FzIGFsc28gbXkgaW50ZXJwcmV0YXRpb24uIEFuZCB3b25kZXJpbmcgd2hh dCB3YXMgbWVhbnQuIEEgY29tcGxldGUgc3ludGF4IGRlc2NyaXB0aW9uIGFuZCBleGFtcGxlIGlz IG5lZWRlZC48YnIgY2xhc3M9IiI+DQpCdXQgYWxzbyBhIGRpc2N1c3Npb24gaWYgdGhpcyBub24t ZmFpbCBwYXJhbWV0ZXIgc2hvdWxkIGJlIG1lcmdlZCB3aXRoIHRoZSBvdGhlciBwcmlvcml0eSB2 YWx1ZXMgdGhhdCBJIHByb3Bvc2UuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KL0d1bm5h cjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPjxiciBjbGFz cz0iIj4NClJlZ2FyZHMsICZuYnNwOyZuYnNwO01hcnRpbi48YnIgY2xhc3M9IiI+DQo8YnIgY2xh c3M9IiI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi ciBjbGFzcz0iIj4NClNMSU0gbWFpbGluZyBsaXN0PGJyIGNsYXNzPSIiPg0KPGEgbW96LWRvLW5v dC1zZW5kPSJ0cnVlIiBocmVmPSJtYWlsdG86U0xJTUBpZXRmLm9yZyIgY2xhc3M9IiI+U0xJTUBp ZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQo8YSBjbGFzcz0ibW96LXR4dC1saW5rLWZyZWV0ZXh0 IiBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NsaW0iPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2xpbTwvYT48YnIgY2xhc3M9IiI+DQo8 L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+DQotLSA8YnIgY2xhc3M9IiI+DQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxiciBjbGFzcz0iIj4NCkd1bm5hciBIZWxs c3Ryw7ZtPGJyIGNsYXNzPSIiPg0KT21uaXRvcjxiciBjbGFzcz0iIj4NCjxhIG1vei1kby1ub3Qt c2VuZD0idHJ1ZSIgaHJlZj0ibWFpbHRvOmd1bm5hci5oZWxsc3Ryb21Ab21uaXRvci5zZSIgY2xh c3M9IiI+Z3VubmFyLmhlbGxzdHJvbUBvbW5pdG9yLnNlPC9hPjxiciBjbGFzcz0iIj4NCiYjNDM7 NDYgNzA4IDIwNCAyODg8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxiciBjbGFzcz0iIj4NClNMSU0gbWFp bGluZyBsaXN0PGJyIGNsYXNzPSIiPg0KPGEgY2xhc3M9Im1vei10eHQtbGluay1hYmJyZXZpYXRl ZCIgaHJlZj0ibWFpbHRvOlNMSU1AaWV0Zi5vcmciPlNMSU1AaWV0Zi5vcmc8L2E+PGJyIGNsYXNz PSIiPg0KPGEgY2xhc3M9Im1vei10eHQtbGluay1mcmVldGV4dCIgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zbGltIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NsaW08L2E+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPHAgc3R5bGU9ImZvbnQtZmFtaWx5Og0K ICAgICAgICBBcmlhbCxzYW5zLXNlcmlmO2ZvbnQtc2l6ZToxMXB4O2NvbG9yOiM5OTk5OTk7IiBj bGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsc2Fucy1zZXJpZjtjb2xv cjojOTk5OTk5Ow0KICAgICAgICAgIG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiBBcmlhbDsgbXNv LWZhcmVhc3QtdGhlbWUtZm9udDoNCiAgICAgICAgICBtaW5vci1sYXRpbjsgbXNvLWJpZGktZm9u dC1mYW1pbHk6ICZxdW90O0FyaWFsJnF1b3Q7Ow0KICAgICAgICAgIG1zby1hbnNpLWxhbmd1YWdl OiBFTi1VUzsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEVOLUdCOw0KICAgICAgICAgIG1zby1iaWRp LWxhbmd1YWdlOiBBUi1TQSIgbGFuZz0iRU4tVVMiIGNsYXNzPSIiPlRoaXMNCiBlbWFpbCBhbmQg aXRzIGF0dGFjaG1lbnRzIGFyZSBpbnRlbmRlZCBmb3IgdGhlIGFib3ZlIG5hbWVkIG9ubHkgYW5k IG1heSBiZSBjb25maWRlbnRpYWwuIElmIHRoZXkgaGF2ZSBjb21lIHRvIHlvdSBpbiBlcnJvciB5 b3UgbXVzdCB0YWtlIG5vIGFjdGlvbiBiYXNlZCBvbiB0aGVtLCBub3IgbXVzdCB5b3UgY29weSBv ciBzaG93IHRoZW0gdG8gYW55b25lOyBwbGVhc2UgcmVwbHkgdG8gdGhpcyBlbWFpbCBvciBjYWxs ICYjNDM7NDQgMjA3IDM1NiAwNjAwDQogYW5kIGhpZ2hsaWdodCB0aGUgZXJyb3IuIDwvc3Bhbj48 L3A+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+DQo8cHJlIGNsYXNzPSJtb3otc2lnbmF0 dXJlIiBjb2xzPSI3MiI+LS0gDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KR3VubmFyIEhlbGxzdHLDtm0NCk9tbml0b3INCjxhIGNsYXNzPSJtb3otdHh0LWxpbmst YWJicmV2aWF0ZWQiIGhyZWY9Im1haWx0bzpndW5uYXIuaGVsbHN0cm9tQG9tbml0b3Iuc2UiPmd1 bm5hci5oZWxsc3Ryb21Ab21uaXRvci5zZTwvYT4NCiYjNDM7NDYgNzA4IDIwNCAyODg8L3ByZT4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxw IHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsc2Fucy1zZXJpZjtmb250LXNpemU6MTFweDtjb2xv cjojOTk5OTk5OyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWws c2Fucy1zZXJpZjtjb2xvcjojOTk5OTk5OyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogQXJpYWw7 IG1zby1mYXJlYXN0LXRoZW1lLWZvbnQ6IG1pbm9yLWxhdGluOyBtc28tYmlkaS1mb250LWZhbWls eTogJnF1b3Q7QXJpYWwmcXVvdDs7IG1zby1hbnNpLWxhbmd1YWdlOiBFTi1VUzsgbXNvLWZhcmVh c3QtbGFuZ3VhZ2U6IEVOLUdCOyBtc28tYmlkaS1sYW5ndWFnZTogQVItU0EiPlRoaXMNCiBlbWFp bCBhbmQgaXRzIGF0dGFjaG1lbnRzIGFyZSBpbnRlbmRlZCBmb3IgdGhlIGFib3ZlIG5hbWVkIG9u bHkgYW5kIG1heSBiZSBjb25maWRlbnRpYWwuIElmIHRoZXkgaGF2ZSBjb21lIHRvIHlvdSBpbiBl cnJvciB5b3UgbXVzdCB0YWtlIG5vIGFjdGlvbiBiYXNlZCBvbiB0aGVtLCBub3IgbXVzdCB5b3Ug Y29weSBvciBzaG93IHRoZW0gdG8gYW55b25lOyBwbGVhc2UgcmVwbHkgdG8gdGhpcyBlbWFpbCBv ciBjYWxsICYjNDM7NDQgMjA3IDM1NiAwNjAwDQogYW5kIGhpZ2hsaWdodCB0aGUgZXJyb3IuIDwv c3Bhbj48L3A+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_8CD947C5D8774E85BEB78A362B7E313Cgsmacom_-- From nobody Wed Nov 18 04:04:53 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63AF11A0116 for ; Wed, 18 Nov 2015 04:04:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.099 X-Spam-Level: * X-Spam-Status: No, score=1.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 uBjF6nHITCxo for ; Wed, 18 Nov 2015 04:04:45 -0800 (PST) Received: from bin-vsp-out-02.atm.binero.net (bin-mail-out-05.binero.net [195.74.38.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E7921A0114 for ; Wed, 18 Nov 2015 04:04:44 -0800 (PST) X-Halon-ID: 8a669664-8dec-11e5-bdaa-005056917f90 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.0.206] (unknown [217.13.240.136]) by bin-vsp-out-02.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Wed, 18 Nov 2015 13:04:37 +0100 (CET) To: slim@ietf.org References: <563818F9.2060709@alum.mit.edu> <56388C4D.4090808@omnitor.se> <56398719.7030205@omnitor.se> <21767FCE-C1BD-4C42-A07E-16BC81586073@gmail.com> <563A2A24.2020102@alum.mit.edu> <44BE7894-2944-42FE-A136-ADB629D49143@gmail.com> <563B04A5.4040407@omnitor.se> <563B79F2.1010608@alum.mit.edu> <563BDE10.5050305@omnitor.se> <563C25AD.3050801@alum.mit.edu> <563D3AF5.1020608@omnitor.se> <563E58EC.3090304@omnitor.se> <563EB249.7020909@it.aoyama.ac.jp> <563EDA4A.6050206@omnitor.se> <483C1110-AD7F-4D53-982D-A68443ADEE9E@gsma.com> <5642F652.8060206@omnitor.se> <8CD947C5-D877-4E85-BEB7-8A362B7E313C@gsma.com> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <564C6956.8040706@omnitor.se> Date: Wed, 18 Nov 2015 13:04:38 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <8CD947C5-D877-4E85-BEB7-8A362B7E313C@gsma.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Slim] Handling the complex multi-media cases X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 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, 18 Nov 2015 12:04:51 -0000 Hi, About use cases: Den 2015-11-18 kl. 11:44, skrev Natasha Rooney: >> There were some in the earlier draft version also. >> I don't remember why they were deleted. Maybe too much thoughts on >> the resulting routing?? > > I’m afraid I am not sure about this - Guys - any reason why Gunnar’s > use cases were taken from the earlier draft? In any case we will feed > them into this new draft, so they’ll have a proper home! They were not especially "mine". I might have contributed with some, but the majority came from other sources. Gunnar -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 From nobody Wed Nov 25 23:32:05 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B5CE1B2AC1 for ; Wed, 25 Nov 2015 23:32:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 QvH568V9UP-P for ; Wed, 25 Nov 2015 23:32:00 -0800 (PST) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0643.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::643]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 652C61B2AC0 for ; Wed, 25 Nov 2015 23:31:59 -0800 (PST) Received: from HE1PR04MB1033.eurprd04.prod.outlook.com (10.162.26.142) by HE1PR04MB1036.eurprd04.prod.outlook.com (10.162.26.145) with Microsoft SMTP Server (TLS) id 15.1.331.20; Thu, 26 Nov 2015 07:31:36 +0000 Received: from HE1PR04MB1033.eurprd04.prod.outlook.com ([10.162.26.142]) by HE1PR04MB1033.eurprd04.prod.outlook.com ([10.162.26.142]) with mapi id 15.01.0331.023; Thu, 26 Nov 2015 07:31:36 +0000 From: Natasha Rooney To: "slim@ietf.org" Thread-Topic: Use Cases Thread-Index: AQHRKBx6hBXnDmCFB0+guqNMwJNdTg== Date: Thu, 26 Nov 2015 07:31:35 +0000 Message-ID: References: <563818F9.2060709@alum.mit.edu> <56388C4D.4090808@omnitor.se> <56398719.7030205@omnitor.se> <21767FCE-C1BD-4C42-A07E-16BC81586073@gmail.com> <563A2A24.2020102@alum.mit.edu> <44BE7894-2944-42FE-A136-ADB629D49143@gmail.com> <563B04A5.4040407@omnitor.se> <563B79F2.1010608@alum.mit.edu> <563BDE10.5050305@omnitor.se> <563C25AD.3050801@alum.mit.edu> <563D3AF5.1020608@omnitor.se> <563E58EC.3090304@omnitor.se> <563EB249.7020909@it.aoyama.ac.jp> <563EDA4A.6050206@omnitor.se> <483C1110-AD7F-4D53-982D-A68443ADEE9E@gsma.com> <5642F652.8060206@omnitor.se> <8CD947C5-D877-4E85-BEB7-8A362B7E313C@gsma.com> <564C6956.8040706@omnitor.se> In-Reply-To: <564C6956.8040706@omnitor.se> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3096.5) authentication-results: spf=none (sender IP is ) smtp.mailfrom=nrooney@gsma.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [219.108.220.186] x-microsoft-exchange-diagnostics: 1; HE1PR04MB1036; 5:3OugiuGZWYDqTTblOMky4JTMm4lu1jyJm9FAFNz8Q6kTbPphvSgfrwU7K4w4Q1NZ1Q9C74kY2QJgfwYidtTh/2t5mcjwfRV449G0Z3JwMxc+RdZoiI6WvSPgp2/u/HuvQnw3jKxOx8PkEj92hpo/Og==; 24:92GqupBpIPqCoL2LqBbRP4aQAr1JEWm0pDg7UjNJyTMR2TWyNRnhaMPisXYYINt7Oh+D9eUO0HLtOdASjhV9D2i2Jcz/SBjCsZRymv9MOnw= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR04MB1036; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(260367931017790); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(520078)(3002001)(10201501046); SRVR:HE1PR04MB1036; BCL:0; PCL:0; RULEID:; SRVR:HE1PR04MB1036; x-forefront-prvs: 0772E5DAD5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(53754006)(377454003)(377424004)(15374003)(24454002)(189002)(199003)(16236675004)(76176999)(33656002)(5008740100001)(83716003)(19580405001)(93886004)(10400500002)(101416001)(87936001)(36756003)(189998001)(110136002)(107886002)(1220700001)(82746002)(2501003)(5001960100002)(5890100001)(1096002)(97736004)(81156007)(92566002)(2900100001)(5004730100002)(122556002)(50226001)(19617315012)(15975445007)(221733001)(5002640100001)(77096005)(6116002)(2351001)(586003)(102836003)(4001150100001)(229853001)(3846002)(2950100001)(40100003)(11100500001)(106116001)(86362001)(105586002)(106356001)(19580395003)(57306001)(50986999)(66066001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR04MB1036; H:HE1PR04MB1033.eurprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: gsma.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_D411CA5964644C73865FE85886A5EE02gsmacom_" MIME-Version: 1.0 X-OriginatorOrg: gsma.com X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Nov 2015 07:31:35.7943 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72a4ff82-fec3-469d-aafb-ac8276216699 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR04MB1036 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: HE1PR04MB1033.eurprd04.prod.outlook.com X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: Martin Thomson X-MS-Exchange-CrossPremises-originalclientipaddress: 219.108.220.186 X-MS-Exchange-CrossPremises-avstamp-service: 1.0 X-MS-Exchange-CrossPremises-disclaimer-hash: 78ca8040c6722e32c2f5b0a45bf37e74b9409d645a53be96aa19958e0cee0f00 X-MS-Exchange-CrossPremises-antispam-scancontext: DIR:Originating; SFV:NSPM; SKIP:0; X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-OrganizationHeadersPreserved: HE1PR04MB1036.eurprd04.prod.outlook.com Archived-At: Subject: [Slim] Use Cases X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 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, 26 Nov 2015 07:32:03 -0000 --_000_D411CA5964644C73865FE85886A5EE02gsmacom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi all! I have started collecting use cases within a draft format which can be foun= d here (click on "Editor's copy" to view): https://github.com/ietf-slim-wg/slim-use-cases/ Currently this is just a collections of Gunnar=92s original use cases, I am= sure I still have some to add from the rest of the mail chains. I will go = through these for the rest of this week and the next week to find some more= . I also realise that the "Contents" are rendering at the bottom of the pag= e, I will ask mt as to why that might be happening, because I am 85% sure i= t=92s not my beautiful (:/) xml! Barry - should this be labeled as an "IETF-Note"? Obviously it=92s not a dr= aft so I assume so but thought I would check! All - please submit any other use cases either on this list or send a PR to= the repo. mt - if you know why the table of contents is appearing at the bottom pleas= e do let me know! Despite what I said above I am actually pretty sire it=92= s my error! Thanks all! Natasha Natasha Rooney | Technologist, Web and Internet, W3C & IETF | GSMA | nroone= y@gsma.com | +44 (0) 7730 219 765 | @thisNatasha |= Skype: nrooney@gsm.org Tokyo, Japan On Nov 18, 2015, at 9:04 PM, Gunnar Hellstr=F6m > wrote: Hi, About use cases: Den 2015-11-18 kl. 11:44, skrev Natasha Rooney: There were some in the earlier draft version also. I don't remember why they were deleted. Maybe too much thoughts on the resu= lting routing?? I=92m afraid I am not sure about this - Guys - any reason why Gunnar=92s us= e cases were taken from the earlier draft? In any case we will feed them in= to this new draft, so they=92ll have a proper home! They were not especially "mine". I might have contributed with some, but th= e majority came from other sources. Gunnar -- ----------------------------------------- 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 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_D411CA5964644C73865FE85886A5EE02gsmacom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Hi all!

I have started collecting use cases within a draft format which can be foun= d here (click on "Editor's copy" to view):
http= s://github.com/ietf-slim-wg/slim-use-cases/

Currently this is just a collections of Gunnar=92s original use cases, I am= sure I still have some to add from the rest of the mail chains. I will go = through these for the rest of this week and the next week to find some more= . I also realise that the "Contents" are rendering at the bottom of the page, I will ask mt as to why that migh= t be happening, because I am 85% sure it=92s not my beautiful (:/) xml!

Barry - should this be labeled as an "IETF-Note"? Obviously it=92= s not a draft so I assume so but thought I would check!
All - please submit any other use cases either on this list or send a PR to= the repo.
mt - if you know why the table of contents is appearing at the bottom pleas= e do let me know! Despite what I said above I am actually pretty sire it=92= s my error!

Thanks all!

Natasha


Natasha Rooney | Technologist, Web and Internet, W3C & IETF | GSMA= | nrooney@gsma.com | +44 (0) 7730 219 765 | @thisNatasha | Skype= : nrooney@gsm.org&nb= sp;
Tokyo, Japan


On Nov 18, 2015, at 9:04 PM, Gunnar Hellstr=F6m <gunnar.hellstrom@omnitor= .se> wrote:

Hi,
About use cases:

Den 2015-11-18 kl. 11:44, skrev Natasha Rooney:
There were some in the earlier draft v= ersion also.
I don't remember why they were deleted. Maybe too much thoughts on the resu= lting routing??

I=92m afraid I am not sure about this - Guys - any reason why Gunnar=92s us= e cases were taken from the earlier draft? In any case we will feed them in= to this new draft, so they=92ll have a proper home!
They were not especially "mine". I might have contributed with so= me, but the majority came from other sources.

Gunnar

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

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