From nobody Wed Mar 2 08:38:03 2016 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 8A1B81B2C21 for ; Wed, 2 Mar 2016 08:38:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 qRjq85FbBPOx for ; Wed, 2 Mar 2016 08:37:59 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0648.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::648]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22E731B2C20 for ; Wed, 2 Mar 2016 08:37:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=GSMASSO.onmicrosoft.com; s=selector1-gsma-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=fiUOxZsYh2ZLljYSYb92FX1VLLkOZ1fB0gUP5MG5qgY=; b=d7PQrpvVIH3G81W+HPVRidQr9gnUFZlWJgh0jRl76F90oqRum3/l/itXsBdCypPdP7B9rG+TJOeHjSZL8mmXOYFFKo+nRWdYPzcB4LRjvxtj38pntEDdHiULEy9Gojq7+9WuMEoX2q31LP4P7fDLx+HT51hhcBPz9pUBKU89uog= 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.415.20; Wed, 2 Mar 2016 16:37:40 +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.0415.022; Wed, 2 Mar 2016 16:37:40 +0000 From: Natasha Rooney To: "slim@ietf.org" Thread-Topic: IETF95, Use Cases doc, and others Thread-Index: AQHRdKHWrFfpzA9kQk6IK7oBWdL6fg== Date: Wed, 2 Mar 2016 16:37:40 +0000 Message-ID: <076290F0-048C-49F4-8BF5-760109F75240@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.3112) authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=gsma.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [62.189.0.100] x-microsoft-exchange-diagnostics: 1; HE1PR04MB1035; 5:Dg69rbkKQ+nvwi9wraYL9Lgw52P1eRsxnAqpNtzfwhWefcJ2RL/XmEmp3CzXyN2L9p9WMFNCLuuT9XORlUffF+bYZHY04lPktJqAI/gs7gNyBZ46sCFeOdIVEK6Np9N4FkjsUO+x9d5zJWb1BZCNgw==; 24:np+1jj2omBRwo0RulbZdawHWGsiGdh048N7i20Ai88sDj6xEKRhu6YRyTbz2o6WKJGHSdPEYPvqMizVcUWAPeVXRtocOU/3vBZ1rlx9fPaI= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR04MB1035; x-ms-office365-filtering-correlation-id: 381d20f1-2ef5-411e-7c87-08d342b8f8bc x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:HE1PR04MB1035; BCL:0; PCL:0; RULEID:; SRVR:HE1PR04MB1035; x-forefront-prvs: 086943A159 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(53754006)(106116001)(86362001)(2906002)(50226001)(10400500002)(19580405001)(2900100001)(81156010)(77096005)(19580395003)(16236675004)(36756003)(11100500001)(1730700002)(110136002)(57306001)(19617315012)(5008740100001)(107886002)(15975445007)(586003)(1220700001)(122556002)(1096002)(5004730100002)(5890100001)(2501003)(40100003)(3846002)(5001960100004)(3660700001)(92566002)(450100001)(87936001)(50986999)(189998001)(82746002)(83716003)(2351001)(6116002)(229853001)(102836003)(33656002)(5002640100001)(3280700002)(66066001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR04MB1035; H:HE1PR04MB1033.eurprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_076290F0048C49F48BF5760109F75240gsmacom_" MIME-Version: 1.0 X-OriginatorOrg: gsma.com X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Mar 2016 16:37:40.2483 (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: 62.189.0.100 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] IETF95, Use Cases doc, and others 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, 02 Mar 2016 16:38:01 -0000 --_000_076290F0048C49F48BF5760109F75240gsmacom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all! We are 1 month and 1 day away from the start of IETF95! Gasp! We have some = work to get on with before IETF95, where we will have a very short (and hop= efully fruitful meeting!) discussing the last issues we have remaining. The IETF95 link is below for those of you who still need to book hotels: https://ietf.org/meeting/95/index.html I am going to be working on finishing the use cases document from now until= IETF95. Please submit any issues or pull requests to the github repo or te= ll me directly: https://github.com/ietf-slim-wg/slim-use-cases/ With our other two documents I believe the modality issues is still at larg= e. Can someone catch me up on the last discussions here? I remember that we= were still discussing it and no decisions had been made - is this correct?= On discussions with other IETF attendees many said that dual modality - wh= ilst supported by use cases - is awfully difficult to implement, is this th= e same as the thoughts within this group? https://datatracker.ietf.org/wg/slim/documents/ 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 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_076290F0048C49F48BF5760109F75240gsmacom_ Content-Type: text/html; charset="us-ascii" Content-ID: <836EE98DED74044F80D5000DED65E18B@eurprd04.prod.outlook.com> Content-Transfer-Encoding: quoted-printable Hi all!

We are 1 month and 1 day away from the start of IETF95! Gas= p! We have some work to get on with before IETF95, where we will have a ver= y short (and hopefully fruitful meeting!) discussing the last issues we hav= e remaining.

The IETF95 link is below for those of you who still need to= book hotels:
https://ietf.org/meeting/95/index.html 

I am going to be working on finishing the use cases documen= t from now until IETF95. Please submit any issues or pull requests to the g= ithub repo or tell me directly:
https://github.com/ietf-slim-wg/slim-use-cases/ 

With our other two documents I believe the modality issues = is still at large. Can someone catch me up on the last discussions here? I = remember that we were still discussing it and no decisions had been made - = is this correct? On discussions with other IETF attendees many said that dual modality - whilst supported by us= e cases - is awfully difficult to implement, is this the same as the though= ts within this group?
https://datatracker.ietf.org/wg/slim/documents/ 

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;


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_076290F0048C49F48BF5760109F75240gsmacom_-- From nobody Fri Mar 11 08:28:50 2016 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14E0712D83E for ; Fri, 11 Mar 2016 08:28:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gsmasso.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JQznVwINfHW4 for ; Fri, 11 Mar 2016 08:28:45 -0800 (PST) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0632.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::632]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D877712D567 for ; Fri, 11 Mar 2016 08:28:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=GSMASSO.onmicrosoft.com; s=selector1-gsma-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=bpqhFSjX0qvzJ3iCyaz5jodmPMbPyvu9J4kHh47aWCs=; b=E6saaMlZq/9Q8n/dDqePupyxI5b4fLF5GXk5nGWyrLZjwrKeC4oHKF2c3CLfRjod5vwPLRwjPmHXfmP8q1/swQss+PY7tp9xD2LSrMptBPi1aWJSbQHQGoSbnlTgNNq88XnMb/bBEuobyOJKTH7jbwCGV4Mib9AdecuS0UNfRBw= Received: from HE1PR04MB1033.eurprd04.prod.outlook.com (10.162.26.142) by HE1PR04MB1033.eurprd04.prod.outlook.com (10.162.26.142) with Microsoft SMTP Server (TLS) id 15.1.434.16; Fri, 11 Mar 2016 16:28:27 +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.0434.016; Fri, 11 Mar 2016 16:28:27 +0000 From: Natasha Rooney To: "slim@ietf.org" Thread-Topic: [Slim] IETF95, Use Cases doc, and others Thread-Index: AQHRdKHWgiYFtRxPBUSN0nxF7PVSN59UfNCA Date: Fri, 11 Mar 2016 16:28:27 +0000 Message-ID: References: <076290F0-048C-49F4-8BF5-760109F75240@gsma.com> In-Reply-To: <076290F0-048C-49F4-8BF5-760109F75240@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.3112) authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=gsma.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [87.112.202.8] x-ms-office365-filtering-correlation-id: 474f0277-bd0b-4a18-7451-08d349ca2d2d x-microsoft-exchange-diagnostics: 1; HE1PR04MB1033; 5:zUcOpX4tLseB2HZAyB1F8sLMHZUfGtTlwbzH9ApcSXvoB1eMW3bjMATRV4IDpMy29x3qOh6oCelwXaaW4s1rHzkRizQfiKM4tRMUpbsGSqkopO3oKRhKF9RiB0W0Etli2TU5olACoBCPcw2YF53FTA==; 24:3hiRFeY+XNhFjgIFw8NOOJS28hMURfomr2efh8GGp/SMuz8qmtaW+/41VpaRRGttWJTA7vFLxZQOoEuR4PbMBQGdC/eM99FZT9dusD21Y7I= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR04MB1033; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:HE1PR04MB1033; BCL:0; PCL:0; RULEID:; SRVR:HE1PR04MB1033; x-forefront-prvs: 087894CD3C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(53754006)(377454003)(24454002)(10400500002)(5002640100001)(5640700001)(107886002)(81166005)(5008740100001)(83716003)(106116001)(586003)(86362001)(2351001)(50226001)(19617315012)(11100500001)(92566002)(36756003)(2501003)(19580395003)(19580405001)(1730700002)(50986999)(3280700002)(6116002)(102836003)(3846002)(57306001)(5890100001)(82746002)(66066001)(3660700001)(77096005)(2900100001)(87936001)(450100001)(15975445007)(2906002)(16236675004)(1220700001)(5004730100002)(33656002)(122556002)(76176999)(110136002)(2950100001)(189998001)(1096002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR04MB1033; H:HE1PR04MB1033.eurprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DAB8790FC2D2446DAC2702AE4BDDF0B5gsmacom_" MIME-Version: 1.0 X-OriginatorOrg: gsma.com X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Mar 2016 16:28:27.8921 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72a4ff82-fec3-469d-aafb-ac8276216699 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR04MB1033 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: 87.112.202.8 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: HE1PR04MB1033.eurprd04.prod.outlook.com Archived-At: Subject: Re: [Slim] IETF95, Use Cases doc, and others X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 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, 11 Mar 2016 16:28:49 -0000 --_000_DAB8790FC2D2446DAC2702AE4BDDF0B5gsmacom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all! IETF95 Deadline Just a quick reminder that the IETF95 document submission deadline is comin= g up fast (March 21st). I am going to submit the use cases draft before the= n with the use cases I have collected from the last meeting. If you want to= see what we have so far then see the link below (excuse the xml): https://github.com/ietf-slim-wg/slim-use-cases/blob/master/draft-ietf-slim-= use-cases-latest.xml Our Document Status With regards to our two other documents, I believe the only issue we have i= s regarding the dual modality use case, and the difficulty of dealing with = this within real-time communications (this obviously only applies to draft-= ietf-slim-negotiating-human-language-00). My question to you all is: do you= have any other outstanding issues with either draft? If not, we should be = in a state to clean them up and publish. Bernard and I are having a chairs chat next week so we can discuss plans fo= r IETF95 and the document status, so please let us know before the end of T= uesday next week as to whether you have any issues you wish to raise. Thanks everyone! Natasha Natasha Rooney | Technologist, Web and Internet, W3C & IETF | GSMA | nroone= y@gsma.com | +44 (0) 7730 219 765 | @thisNatasha |= Skype: nrooney@gsm.org On Mar 2, 2016, at 4:37 PM, Natasha Rooney > wrote: Hi all! We are 1 month and 1 day away from the start of IETF95! Gasp! We have some = work to get on with before IETF95, where we will have a very short (and hop= efully fruitful meeting!) discussing the last issues we have remaining. The IETF95 link is below for those of you who still need to book hotels: https://ietf.org/meeting/95/index.html I am going to be working on finishing the use cases document from now until= IETF95. Please submit any issues or pull requests to the github repo or te= ll me directly: https://github.com/ietf-slim-wg/slim-use-cases/ With our other two documents I believe the modality issues is still at larg= e. Can someone catch me up on the last discussions here? I remember that we= were still discussing it and no decisions had been made - is this correct?= On discussions with other IETF attendees many said that dual modality - wh= ilst supported by use cases - is awfully difficult to implement, is this th= e same as the thoughts within this group? https://datatracker.ietf.org/wg/slim/documents/ 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 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. _______________________________________________ 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_DAB8790FC2D2446DAC2702AE4BDDF0B5gsmacom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable Hi all!

IETF95 Deadline
Just a quick reminder that the IETF95 document submission d= eadline is coming up fast (March 21st). I am going to submit the use cases draft before th= en with the use cases I have collected from the last meeting. If you want to see what we have so far then see the link= below (excuse the xml):
https://github.= com/ietf-slim-wg/slim-use-cases/blob/master/draft-ietf-slim-use-cases-lates= t.xml

Our Document Status
With regards to our two other documents, I believe the only= issue we have is regarding the dual modality use case, and the difficulty = of dealing with this within real-time communications (this obviously only a= pplies to draft-ietf-slim-negotiating-human-language-00). My question to you all is: do you have any other outstanding issues with either draft? If not, we should be in a state to clean them up and publish.

Bernard and I are having a chairs chat next week so we can = discuss plans for IETF95 and the document status, so please let us know before the end= of Tuesday next week as to whether you have any issues you wish to raise.

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&nb= sp;


On Mar 2, 2016, at 4:37 PM, Natasha Rooney <nrooney@gsma.com> wrote:

Hi all!

We are 1 month and 1 day away from the start of IETF95! Gas= p! We have some work to get on with before IETF95, where we will have a ver= y short (and hopefully fruitful meeting!) discussing the last issues we hav= e remaining.

The IETF95 link is below for those of you who still need to= book hotels:
https://ietf.org/meeting/95/index.html 

I am going to be working on finishing the use cases documen= t from now until IETF95. Please submit any issues or pull requests to the g= ithub repo or tell me directly:
https://github.com/ietf-slim-wg/slim-use-cases/ 

With our other two documents I believe the modality issues = is still at large. Can someone catch me up on the last discussions here? I = remember that we were still discussing it and no decisions had been made - = is this correct? On discussions with other IETF attendees many said that dual modality - whilst supported by us= e cases - is awfully difficult to implement, is this the same as the though= ts within this group?
https://datatracker.ietf.org/wg/slim/documents/ 

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;


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.

_______________________________________________
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_DAB8790FC2D2446DAC2702AE4BDDF0B5gsmacom_-- From nobody Sat Mar 12 01:42:12 2016 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AC2B12D585 for ; Sat, 12 Mar 2016 01:42:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T_9a2P6RVe0g for ; Sat, 12 Mar 2016 01:42:06 -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 7CF9F12D579 for ; Sat, 12 Mar 2016 01:42:05 -0800 (PST) X-Halon-ID: a93954cf-e836-11e5-be2c-0050569116f7 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.193] (unknown [87.96.161.49]) by bin-vsp-out-03.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Sat, 12 Mar 2016 10:41:56 +0100 (CET) To: slim@ietf.org References: <076290F0-048C-49F4-8BF5-760109F75240@gsma.com> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <56E3E464.2040900@omnitor.se> Date: Sat, 12 Mar 2016 10:41:56 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------030208090402090102040202" Archived-At: Subject: Re: [Slim] IETF95, Use Cases doc, and others X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 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, 12 Mar 2016 09:42:10 -0000 This is a multi-part message in MIME format. --------------030208090402090102040202 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Natasha and all, The use case collection looks good. The reasoning about implementability need a description about what version of the negotiating-human-language draft it refers to. We hope to improve, so we get "possible" on nearly all cases. It is time to act on the conclusions of the use cases. My suggestion: Add in the negotiating-human-language draft the following: 1. A coding for absolute level of preference for a modality-language combination in three levels: preferred, can-do, last-resort. Shall we explicit using words, or cryptic, using * and other special characters? 2. A clear interpreting rule, saying that for needs of two modalities, one in each direction, the directional attributes together with absolute coding of preference shall be used, including some default rule for when no absolute coding is provided. 3. A description of offer-answer handling rules, making it very clear if the attributes in the answer indicate capabilities and preferences from the point of view of the party sending the SDP, or from the point of view of the offering party. The first case would mean that "I want to talk English" and "I want to read English text" shall be answered with "I want to listen to spoken English" and "I will type English" to get a match , The second case would mean that "I want to talk English" and "I want to read English text" would be answered with "I accept that you talk English" and "I accept that you will read English text" thus sending attributes as if coded from the offering party to get a match. The first case is more evident for the user, while the second case is easier to parse and check for a match. 4. A conclusion that need for speech-to-speech relay services is out of scope and need to be solved by other indications. Do anyone have ideas for such indications? Call-Info with purpose and URI to a suitable service? Make a REFER to bring in the service? Call with a URI-list? ( Yes, it is out of scope, but I am interested to have an agreed best practice solutions for it.) Regards Gunnar Den 2016-03-11 kl. 17:28, skrev Natasha Rooney: > Hi all! > > *IETF95 Deadline* > Just a quick reminder that the IETF95 document submission deadline is > coming up fast (*March 21st*). I am going to submit the use cases > draft before then with the use cases I have collected from the last > meeting. If you want to see what we have so far then see the link > below (excuse the xml): > https://github.com/ietf-slim-wg/slim-use-cases/blob/master/draft-ietf-slim-use-cases-latest.xml > > *Our Document Status* > With regards to our two other documents, I believe the only issue we > have is regarding the dual modality use case, and the difficulty of > dealing with this within real-time communications (this obviously only > applies to draft-ietf-slim-negotiating-human-language-00). My question > to you all is: *do you have any other outstanding issues with either > draft? *If not, we should be in a state to clean them up and publish. > > Bernard and I are having a chairs chat next week so we can discuss > plans for IETF95 and the document status, so please *let us know > before the end of Tuesday next week as to whether you have any issues > you wish to raise*. > > 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 > > >> On Mar 2, 2016, at 4:37 PM, Natasha Rooney > > wrote: >> >> Hi all! >> >> We are 1 month and 1 day away from the start of IETF95! Gasp! We have >> some work to get on with before IETF95, where we will have a very >> short (and hopefully fruitful meeting!) discussing the last issues we >> have remaining. >> >> The IETF95 link is below for those of you who still need to book hotels: >> https://ietf.org/meeting/95/index.html >> >> I am going to be working on finishing the use cases document from now >> until IETF95. Please submit any issues or pull requests to the github >> repo or tell me directly: >> https://github.com/ietf-slim-wg/slim-use-cases/ >> >> With our other two documents I believe the modality issues is still >> at large. Can someone catch me up on the last discussions here? I >> remember that we were still discussing it and no decisions had been >> made - is this correct? On discussions with other IETF attendees many >> said that dual modality - whilst supported by use cases - is awfully >> difficult to implement, is this the same as the thoughts within this >> group? >> https://datatracker.ietf.org/wg/slim/documents/ >> >> 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 >> >> >> 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 > > 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 --------------030208090402090102040202 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Natasha and all,

The use case collection looks good.
The reasoning about implementability need a description about what version of the negotiating-human-language draft it refers to.  We hope to improve, so we get "possible" on nearly all cases.

It is time to act on the conclusions of the use cases.

My suggestion:
Add in the negotiating-human-language draft the following:

1. A coding for absolute level of preference for a modality-language combination in three levels: preferred, can-do, last-resort. Shall we explicit using words, or cryptic, using * and other special characters?

2. A clear interpreting rule, saying that for needs of two modalities, one in each direction, the directional attributes together with absolute coding of preference shall be used, including some default rule for when no absolute coding is provided.

3. A description of offer-answer handling rules, making it very clear if the attributes in the answer indicate capabilities and preferences from the point of view of the party sending the SDP, or from the point of view of the offering party. 
The first case would mean that "I want to talk English" and "I want to read English text"  shall be answered with "I want to listen to spoken English" and "I will type English" to get a match ,    The second case would mean that "I want to talk English" and "I want to read English text" would be answered with "I accept that you talk English" and "I accept that you will read English text" thus sending attributes as if coded from the offering party to get a match.
The first case is more evident for the user, while the second case is easier to parse and check for a match.

4. A conclusion that need for speech-to-speech relay services is out of scope and need to be solved by other indications. Do anyone have ideas for such indications? Call-Info with purpose and URI to a suitable service? Make a REFER to bring in the service? Call with a URI-list? ( Yes, it is out of scope, but I am interested to have an agreed best practice solutions for it.)

 Regards

Gunnar



Den 2016-03-11 kl. 17:28, skrev Natasha Rooney:
Hi all!

IETF95 Deadline
Just a quick reminder that the IETF95 document submission deadline is coming up fast (March 21st). I am going to submit the use cases draft before then with the use cases I have collected from the last meeting. If you want to see what we have so far then see the link below (excuse the xml):

Our Document Status
With regards to our two other documents, I believe the only issue we have is regarding the dual modality use case, and the difficulty of dealing with this within real-time communications (this obviously only applies to draft-ietf-slim-negotiating-human-language-00). My question to you all is: do you have any other outstanding issues with either draft? If not, we should be in a state to clean them up and publish.

Bernard and I are having a chairs chat next week so we can discuss plans for IETF95 and the document status, so please let us know before the end of Tuesday next week as to whether you have any issues you wish to raise.

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 


On Mar 2, 2016, at 4:37 PM, Natasha Rooney <nrooney@gsma.com> wrote:

Hi all!

We are 1 month and 1 day away from the start of IETF95! Gasp! We have some work to get on with before IETF95, where we will have a very short (and hopefully fruitful meeting!) discussing the last issues we have remaining.

The IETF95 link is below for those of you who still need to book hotels:

I am going to be working on finishing the use cases document from now until IETF95. Please submit any issues or pull requests to the github repo or tell me directly:

With our other two documents I believe the modality issues is still at large. Can someone catch me up on the last discussions here? I remember that we were still discussing it and no decisions had been made - is this correct? On discussions with other IETF attendees many said that dual modality - whilst supported by use cases - is awfully difficult to implement, is this the same as the thoughts within this group?

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 


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

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

--------------030208090402090102040202-- From nobody Sat Mar 12 14:55:47 2016 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0879212D89A for ; Sat, 12 Mar 2016 14:55:46 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IAnv2AMXUoID for ; Sat, 12 Mar 2016 14:55:43 -0800 (PST) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 98E7512D6D4 for ; Sat, 12 Mar 2016 14:55:43 -0800 (PST) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Sat, 12 Mar 2016 14:56:13 -0800 Mime-Version: 1.0 Message-Id: In-Reply-To: <56E3E464.2040900@omnitor.se> References: <076290F0-048C-49F4-8BF5-760109F75240@gsma.com> <56E3E464.2040900@omnitor.se> X-Mailer: Eudora for Mac OS X Date: Sat, 12 Mar 2016 14:53:27 -0800 To: Gunnar =?iso-8859-1?Q?Hellstr=F6m?= , slim@ietf.org From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable 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: Subject: Re: [Slim] IETF95, Use Cases doc, and others X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 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, 12 Mar 2016 22:55:46 -0000 Hi Gunnar and everyone, In the interest of keeping the draft as simple as=20 possible for the initial version, I do not think=20 we need to add the absolute level of preference=20 that you suggest. At 10:41 AM +0100 3/12/16, Gunnar Hellstr=F6m wrote: > Natasha and all, > > The use case collection looks good. > The reasoning about implementability need a=20 > description about what version of the=20 > negotiating-human-language draft it refers to.=20 > We hope to improve, so we get "possible" on=20 > nearly all cases. > > It is time to act on the conclusions of the use cases. > > My suggestion: > Add in the negotiating-human-language draft the following: > > 1. A coding for absolute level of preference=20 > for a modality-language combination in three=20 > levels: preferred, can-do, last-resort. Shall=20 > we explicit using words, or cryptic, using *=20 > and other special characters? > > 2. A clear interpreting rule, saying that for=20 > needs of two modalities, one in each direction,=20 > the directional attributes together with=20 > absolute coding of preference shall be used,=20 > including some default rule for when no=20 > absolute coding is provided. > > 3. A description of offer-answer handling=20 > rules, making it very clear if the attributes=20 > in the answer indicate capabilities and=20 > preferences from the point of view of the party=20 > sending the SDP, or from the point of view of=20 > the offering party. > The first case would mean that "I want to talk=20 > English" and "I want to read English text"=20 > shall be answered with "I want to listen to=20 > spoken English" and "I will type English" to=20 > get a match , The second case would mean that=20 > "I want to talk English" and "I want to read=20 > English text" would be answered with "I accept=20 > that you talk English" and "I accept that you=20 > will read English text" thus sending attributes=20 > as if coded from the offering party to get a=20 > match. > The first case is more evident for the user,=20 > while the second case is easier to parse and=20 > check for a match. > > 4. A conclusion that need for speech-to-speech=20 > relay services is out of scope and need to be=20 > solved by other indications. Do anyone have=20 > ideas for such indications? Call-Info with=20 > purpose and URI to a suitable service? Make a=20 > REFER to bring in the service? Call with a=20 > URI-list? ( Yes, it is out of scope, but I am=20 > interested to have an agreed best practice=20 > solutions for it.) > > Regards > > Gunnar > > > Den 2016-03-11 kl. 17:28, skrev Natasha Rooney: > >> Hi all! >> >> IETF95 Deadline >> Just a quick reminder that the IETF95 document=20 >> submission deadline is coming up fast (March=20 >> 21st). I am going to submit the use cases=20 >> draft before then with the use cases I have=20 >> collected from the last meeting. If you want=20 >> to see what we have so far then see the link=20 >> below (excuse the xml): >>=20 >> https://github.com/ietf-slim-wg/slim-use-cases/blob/= master/draft-ietf-slim-use-cases-latest.xml >> >> Our Document Status >> With regards to our two other documents, I=20 >> believe the only issue we have is regarding=20 >> the dual modality use case, and the difficulty=20 >> of dealing with this within real-time=20 >> communications (this obviously only applies to=20 >> draft-ietf-slim-negotiating-human-language-00).=20 >> My question to you all is: do you have any=20 >> other outstanding issues with either draft? If=20 >> not, we should be in a state to clean them up=20 >> and publish. >> >> Bernard and I are having a chairs chat next=20 >> week so we can discuss plans for IETF95 and=20 >> the document status, so please let us know=20 >> before the end of Tuesday next week as to=20 >> whether you have any issues you wish to raise. >> >> Thanks everyone! >> >> >> Natasha >> >> >> Natasha Rooney | Technologist, Web and=20 >> Internet, W3C & IETF | GSMA |=20 >> nrooney@gsma.com |=20 >> +44 (0) 7730 219 765 | @thisNatasha | Skype:=20 >> nrooney@gsm.org >> >> >>> On Mar 2, 2016, at 4:37 PM, Natasha Rooney=20 >>> <nrooney@gsma.com>=20 >>> wrote: >>> >>> Hi all! >>> >>> We are 1 month and 1 day away from the start=20 >>> of IETF95! Gasp! We have some work to get on=20 >>> with before IETF95, where we will have a very=20 >>> short (and hopefully fruitful meeting!)=20 >>> discussing the last issues we have remaining. >>> >>> The IETF95 link is below for those of you who still need to book hotels= : >>>=20 >>> https://ietf.org/meeting/95/inde= x.html >>> >>> I am going to be working on finishing the use=20 >>> cases document from now until IETF95. Please=20 >>> submit any issues or pull requests to the=20 >>> github repo or tell me directly: >>>=20 >>> https://github.com/ietf= -slim-wg/slim-use-cases/ >>> >>> With our other two documents I believe the=20 >>> modality issues is still at large. Can=20 >>> someone catch me up on the last discussions=20 >>> here? I remember that we were still=20 >>> discussing it and no decisions had been made=20 >>> - is this correct? On discussions with other=20 >>> IETF attendees many said that dual modality -=20 >>> whilst supported by use cases - is awfully=20 >>> difficult to implement, is this the same as=20 >>> the thoughts within this group? >>>=20 >>> https://datatracker.iet= f.org/wg/slim/documents/ >>> >>> Thanks all! >>> >>> Natasha >>> >>> Natasha Rooney | Technologist, Web and=20 >>> Internet, W3C & IETF | GSMA |=20 >>> =20 >>> nrooney@gsma.com |=20 >>> +44 (0) 7730 219 765 | @thisNatasha | Skype:=20 >>> nrooney@gsm.org >>> >>> >>> This email and its attachments are intended=20 >>> for the above named only and may be=20 >>> confidential. If they have come to you in=20 >>> error you must take no action based on them,=20 >>> nor must you copy or show them to anyone;=20 >>> please reply to this email or call +44 207=20 >>> 356 0600 and highlight the error. >>> >>> _______________________________________________ >>> SLIM mailing list >>> SLIM@ietf.org >>>=20 >>> https://www.ietf.org/mailman= /listinfo/slim >>> >> >> This email and its attachments are intended=20 >> for the above named only and may be=20 >> confidential. If they have come to you in=20 >> error you must take no action based on them,=20 >> nor must you copy or show them to anyone;=20 >> please reply to this email or call +44 207 356=20 >> 0600 and highlight the error. >> >> >> >> _______________________________________________ >> SLIM mailing list >> SLIM@ietf.org >>=20 >> https://www.ietf.org/mailman/= listinfo/slim >> > > > _______________________________________________ > 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: --------------- A great many people think they are thinking when they are really rearranging their prejudices. --William James From nobody Sun Mar 13 01:39:14 2016 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A8E112D561 for ; Sun, 13 Mar 2016 01:39:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cQEu08qQChkf for ; Sun, 13 Mar 2016 01:39:10 -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 09B9512D55E for ; Sun, 13 Mar 2016 01:39:09 -0800 (PST) X-Halon-ID: 6d6c5678-e8ff-11e5-88b9-005056917a89 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.209] (unknown [87.96.161.49]) by bin-vsp-out-01.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Sun, 13 Mar 2016 10:39:05 +0100 (CET) From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= To: Randall Gellens , slim@ietf.org References: <076290F0-048C-49F4-8BF5-760109F75240@gsma.com> <56E3E464.2040900@omnitor.se> Message-ID: <56E53534.6090208@omnitor.se> Date: Sun, 13 Mar 2016 10:39:00 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Slim] IETF95, Use Cases doc, and others X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 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, 13 Mar 2016 09:39:14 -0000 Randall, Den 2016-03-12 kl. 23:53, skrev Randall Gellens: > Hi Gunnar and everyone, > > In the interest of keeping the draft as simple as possible for the > initial version, I do not think we need to add the absolute level of > preference that you suggest. And I think the draft will not be sufficiently usable without a mechanism to indicate absolute preference in a way so that the preference between languages and modalities in different media is indicated. For example I prefer to talk and hear spoken English in audio, but can accept to type and read English text. or another example: I prefer to talk and hear spoken French in audio but can accept to sign and see French sign language in video. Without a way to make the distinction, we give no clue to the other party on why language is indicated in more than one media. Are all desired or not? And if you cannot indicate an option with lower preference then you may lose calls or get relay services invoked when they are not needed, wasting resources and making the calls less direct and less personal. We could probably do with just two levels of preference: Preferred and possible. While searching in https://tools.ietf.org/html/draft-ietf-slim-negotiating-human-language-00 for a possiblity to include that in the syntax without increasing complexity, I saw the Advisory vs Required indication by an asterisk in section 6.3. I do not expect that indication to be of much value, so I intended to propose to change its use to be a priority indicator. But it seems too tightly coupled to the use in language-matching in RFC 2616, so I abstain from proposing that and instead with hesitation propose that we include the q= factor notation from RFC 2616 for indicating preference. I suggest a change in section 6.2: -------------------------------------current text in 6.2------------------------------------------------- a=humintlang-send: a=humintlang-recv: Each can appear multiple times in an offer for a media stream. In an offer, the 'humintlang-send' values constitute a list in preference order (first is most preferred) of the languages the offerer wishes to send using the media, and the 'humintlang-recv' values constitute a list in preference order of the languages the offerer wishes to receive using the media. -------------------------------------proposed changed text in 6.2---------------------------------- a=humintlang-send:[ ";" "q" "=" qvalue ] a=humintlang-recv:[ ";" "q" "=" qvalue ] Each can appear multiple times in an offer for a media stream. In an offer the 'humintlang-send' values constitute a list of the languages the offerer wishes to send using the media, and the 'humintlang-recv' values constitute a list of the languages the offerer wishes to receive using the media. The q-values represent a preference level for using the indicated language and modality relative to all other languages and modalities indicated for the same direction in the whole SDP. The quality value defaults to "q=1" and has the same syntax and usage rules as for 'Accept-Language' in RFC 2616 [RFC2616]. If more than one language is specified for the same media and direction with the same q-value, they SHALL be listed in preference order. ---------------------------------End of change proposal.--------------------------------------------- > > At 10:41 AM +0100 3/12/16, Gunnar Hellström wrote: > >> Natasha and all, >> >> The use case collection looks good. >> The reasoning about implementability need a description about what >> version of the negotiating-human-language draft it refers to. We hope >> to improve, so we get "possible" on nearly all cases. >> >> It is time to act on the conclusions of the use cases. >> >> My suggestion: >> Add in the negotiating-human-language draft the following: >> >> 1. A coding for absolute level of preference for a modality-language >> combination in three levels: preferred, can-do, last-resort. Shall we >> explicit using words, or cryptic, using * and other special characters? Changed to q-value above >> >> 2. A clear interpreting rule, saying that for needs of two >> modalities, one in each direction, the directional attributes >> together with absolute coding of preference shall be used, including >> some default rule for when no absolute coding is provided. What is said for dual modalities in 6.2 just below the change proposal above may be sufficient. >> >> >> 3. A description of offer-answer handling rules, making it very >> clear if the attributes in the answer indicate capabilities and >> preferences from the point of view of the party sending the SDP, or >> from the point of view of the offering party. >> The first case would mean that "I want to talk English" and "I want >> to read English text" shall be answered with "I want to listen to >> spoken English" and "I will type English" to get a match , The second >> case would mean that "I want to talk English" and "I want to read >> English text" would be answered with "I accept that you talk English" >> and "I accept that you will read English text" thus sending >> attributes as if coded from the offering party to get a match. >> The first case is more evident for the user, while the second case >> is easier to parse and check for a match. In 6.2 we have the rule that both the offeror and the answering party indicate values from their own point of view. I think that is doable. >> >> 4. A conclusion that need for speech-to-speech relay services is out >> of scope and need to be solved by other indications. Do anyone have >> ideas for such indications? Call-Info with purpose and URI to a >> suitable service? Make a REFER to bring in the service? Call with a >> URI-list? ( Yes, it is out of scope, but I am interested to have an >> agreed best practice solutions for it.) We take that separately and concentrate on the preference scope to cover all modalities here. /Gunnar >> >> Regards >> >> Gunnar >> >> >> Den 2016-03-11 kl. 17:28, skrev Natasha Rooney: >> >>> Hi all! >>> >>> IETF95 Deadline >>> Just a quick reminder that the IETF95 document submission deadline >>> is coming up fast (March 21st). I am going to submit the use cases >>> draft before then with the use cases I have collected from the last >>> meeting. If you want to see what we have so far then see the link >>> below (excuse the xml): >>> >>> https://github.com/ietf-slim-wg/slim-use-cases/blob/master/draft-ietf-slim-use-cases-latest.xml >>> >>> >>> Our Document Status >>> With regards to our two other documents, I believe the only issue >>> we have is regarding the dual modality use case, and the difficulty >>> of dealing with this within real-time communications (this obviously >>> only applies to draft-ietf-slim-negotiating-human-language-00). My >>> question to you all is: do you have any other outstanding issues >>> with either draft? If not, we should be in a state to clean them up >>> and publish. >>> >>> Bernard and I are having a chairs chat next week so we can discuss >>> plans for IETF95 and the document status, so please let us know >>> before the end of Tuesday next week as to whether you have any >>> issues you wish to raise. >>> >>> 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 >>> >>> >>>> On Mar 2, 2016, at 4:37 PM, Natasha Rooney >>>> <nrooney@gsma.com> wrote: >>>> >>>> Hi all! >>>> >>>> We are 1 month and 1 day away from the start of IETF95! Gasp! We >>>> have some work to get on with before IETF95, where we will have a >>>> very short (and hopefully fruitful meeting!) discussing the last >>>> issues we have remaining. >>>> >>>> The IETF95 link is below for those of you who still need to book >>>> hotels: >>>> >>>> https://ietf.org/meeting/95/index.html >>>> >>>> >>>> I am going to be working on finishing the use cases document from >>>> now until IETF95. Please submit any issues or pull requests to the >>>> github repo or tell me directly: >>>> >>>> https://github.com/ietf-slim-wg/slim-use-cases/ >>>> >>>> >>>> With our other two documents I believe the modality issues is >>>> still at large. Can someone catch me up on the last discussions >>>> here? I remember that we were still discussing it and no decisions >>>> had been made - is this correct? On discussions with other IETF >>>> attendees many said that dual modality - whilst supported by use >>>> cases - is awfully difficult to implement, is this the same as the >>>> thoughts within this group? >>>> >>>> https://datatracker.ietf.org/wg/slim/documents/ >>>> >>>> >>>> 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 >>>> >>>> >>>> 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 >>>> >>>> >>> >>> 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 >>> >>> >> >> >> _______________________________________________ >> SLIM mailing list >> SLIM@ietf.org >> https://www.ietf.org/mailman/listinfo/slim > > -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 From nobody Mon Mar 14 18:15:36 2016 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26CF412D81C for ; Mon, 14 Mar 2016 18:15:35 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e767W3ICcbTQ for ; Mon, 14 Mar 2016 18:15:32 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 327F412D6A2 for ; Mon, 14 Mar 2016 18:15:32 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Mon, 14 Mar 2016 18:15:31 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <56E53534.6090208@omnitor.se> References: <076290F0-048C-49F4-8BF5-760109F75240@gsma.com> <56E3E464.2040900@omnitor.se> <56E53534.6090208@omnitor.se> X-Mailer: Eudora for Mac OS X Date: Mon, 14 Mar 2016 18:15:29 -0700 To: Gunnar =?iso-8859-1?Q?Hellstr=F6m?= , slim@ietf.org From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable 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: Subject: Re: [Slim] IETF95, Use Cases doc, and others X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 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, 15 Mar 2016 01:15:35 -0000 Hi Gunnar, I think adding q=3D factor is much more complexity=20 than is needed, and I remain unconvinced that we=20 must have a preference indication at the start.=20 I don't see that use cases are impossible without=20 it. It seems to me that the only difference it=20 makes is to skip establishing some requested=20 media streams if others are established. I=20 suspect that in most cases, the ones that could=20 be skipped would be the easier ones (without=20 relay/interpretation services). Having an extra=20 text or audio stream that is not used is not a=20 big deal. If we keep the draft very simple to start with,=20 then after we have some deployment experience, we=20 can create a revision or an extension that adds=20 the features that we found we need, in the way we=20 found we need them. In my experience, this is a=20 better approach than trying to think of all=20 aspects of the solution at the start, since doing=20 so inevitably adds complexity and adds features=20 in ways that turn out to not be ideal. So, I would like to avoid adding preference now,=20 but would be happy to work on an update or=20 extension in the future if we find that we need=20 it. At 10:39 AM +0100 3/13/16, Gunnar Hellstr=F6m wrote: > Randall, > > Den 2016-03-12 kl. 23:53, skrev Randall Gellens: >> Hi Gunnar and everyone, >> >> In the interest of keeping the draft as simple=20 >> as possible for the initial version, I do not=20 >> think we need to add the absolute level of=20 >> preference that you suggest. > And I think the draft will not be sufficiently=20 > usable without a mechanism to indicate absolute=20 > preference in a way so that the preference=20 > between languages and modalities in different=20 > media is indicated. > For example I prefer to talk and hear spoken=20 > English in audio, but can accept to type and=20 > read English text. > or another example: > I prefer to talk and hear spoken French in=20 > audio but can accept to sign and see French=20 > sign language in video. > > Without a way to make the distinction, we give=20 > no clue to the other party on why language is=20 > indicated in more than one media. Are all=20 > desired or not? > And if you cannot indicate an option with lower=20 > preference then you may lose calls or get relay=20 > services invoked when they are not needed,=20 > wasting resources and making the calls less=20 > direct and less personal. > > We could probably do with just two levels of=20 > preference: Preferred and possible. > While searching in=20 > https://tools.ietf.org/html/draft-ietf-slim-negotiating-human-language-00 > for a possiblity to include that in the syntax=20 > without increasing complexity, I saw the=20 > Advisory vs Required indication by an asterisk=20 > in section 6.3. > I do not expect that indication to be of much=20 > value, so I intended to propose to change its=20 > use to be a priority indicator. But it seems=20 > too tightly coupled to the use in=20 > language-matching in RFC 2616, so I abstain=20 > from proposing that and instead with hesitation=20 > propose that we include the q=3D factor notation=20 > from RFC 2616 for indicating preference. > > I suggest a change in section 6.2: > > -------------------------------------current=20 > text in=20 > 6.2------------------------------------------------- > > a=3Dhumintlang-send: > a=3Dhumintlang-recv: > > Each can appear multiple times in an offer for a media stream. > > In an offer, the 'humintlang-send' values constitute a list in > preference order (first is most preferred) of the languages the > offerer wishes to send using the media, and the 'humintlang-recv' > values constitute a list in preference order of the languages the > offerer wishes to receive using the media. > > > > -------------------------------------proposed=20 > changed text in=20 > 6.2---------------------------------- > > a=3Dhumintlang-send:[ ";" "q" "=3D" qvalue ] > > a=3Dhumintlang-recv:[ ";" "q" "=3D" qvalue ] > > > Each can appear multiple times in an offer for a media stream. > > In an offer the 'humintlang-send' values=20 > constitute a list of the languages the > offerer wishes to send using the media, and the 'humintlang-recv' > values constitute a list of the languages the > offerer wishes to receive using the media.=20 > The q-values represent a preference level > for using the indicated language and=20 > modality relative to all other languages and > modalities indicated for the same direction in the whole SDP. > The quality value defaults to "q=3D1" and has=20 > the same syntax and usage rules as for=20 > 'Accept-Language' in RFC 2616 [RFC2616]. > > If more than one language is specified for=20 > the same media and direction with the same=20 > q-value, > they SHALL be listed in preference order. > > ---------------------------------End of change=20 > proposal.--------------------------------------------- > > > > >> >> At 10:41 AM +0100 3/12/16, Gunnar Hellstr=F6m wrote: >> >>> Natasha and all, >>> >>> The use case collection looks good. >>> The reasoning about implementability need a=20 >>> description about what version of the=20 >>> negotiating-human-language draft it refers=20 >>> to. We hope to improve, so we get "possible"=20 >>> on nearly all cases. >>> >>> It is time to act on the conclusions of the use cases. >>> >>> My suggestion: >>> Add in the negotiating-human-language draft the following: >>> >>> 1. A coding for absolute level of preference=20 >>> for a modality-language combination in three=20 >>> levels: preferred, can-do, last-resort. Shall=20 >>> we explicit using words, or cryptic, using *=20 >>> and other special characters? > Changed to q-value above >>> >>> 2. A clear interpreting rule, saying that=20 >>> for needs of two modalities, one in each=20 >>> direction, the directional attributes=20 >>> together with absolute coding of preference=20 >>> shall be used, including some default rule=20 >>> for when no absolute coding is provided. > What is said for dual modalities in 6.2 just=20 > below the change proposal above may be=20 > sufficient. >>> >>> >>> 3. A description of offer-answer handling=20 >>> rules, making it very clear if the attributes=20 >>> in the answer indicate capabilities and=20 >>> preferences from the point of view of the=20 >>> party sending the SDP, or from the point of=20 >>> view of the offering party. >>> The first case would mean that "I want to=20 >>> talk English" and "I want to read English=20 >>> text" shall be answered with "I want to=20 >>> listen to spoken English" and "I will type=20 >>> English" to get a match , The second case=20 >>> would mean that "I want to talk English" and=20 >>> "I want to read English text" would be=20 >>> answered with "I accept that you talk=20 >>> English" and "I accept that you will read=20 >>> English text" thus sending attributes as if=20 >>> coded from the offering party to get a match. >>> The first case is more evident for the user,=20 >>> while the second case is easier to parse and=20 >>> check for a match. > In 6.2 we have the rule that both the offeror=20 > and the answering party indicate values from=20 > their own point of view. I think that is doable. >>> >>> 4. A conclusion that need for=20 >>> speech-to-speech relay services is out of=20 >>> scope and need to be solved by other=20 >>> indications. Do anyone have ideas for such=20 >>> indications? Call-Info with purpose and URI=20 >>> to a suitable service? Make a REFER to bring=20 >>> in the service? Call with a URI-list? ( Yes,=20 >>> it is out of scope, but I am interested to=20 >>> have an agreed best practice solutions for=20 >>> it.) > We take that separately and concentrate on the=20 > preference scope to cover all modalities here. > > /Gunnar >>> >>> Regards >>> >>> Gunnar >>> >>> >>> Den 2016-03-11 kl. 17:28, skrev Natasha Rooney: >>> >>>> Hi all! >>>> >>>> IETF95 Deadline >>>> Just a quick reminder that the IETF95=20 >>>> document submission deadline is coming up=20 >>>> fast (March 21st). I am going to submit the=20 >>>> use cases draft before then with the use=20 >>>> cases I have collected from the last=20 >>>> meeting. If you want to see what we have so=20 >>>> far then see the link below (excuse the xml): >>>> >>>>=20 >>>> https://github.com/ietf-slim-wg/slim-use-cases/blo= b/master/draft-ietf-slim-use-cases-latest.xml >>>> >>>> Our Document Status >>>> With regards to our two other documents, I=20 >>>> believe the only issue we have is regarding=20 >>>> the dual modality use case, and the=20 >>>> difficulty of dealing with this within=20 >>>> real-time communications (this obviously=20 >>>> only applies to=20 >>>> draft-ietf-slim-negotiating-human-language-00).=20 >>>> My question to you all is: do you have any=20 >>>> other outstanding issues with either draft?=20 >>>> If not, we should be in a state to clean=20 >>>> them up and publish. >>>> >>>> Bernard and I are having a chairs chat next=20 >>>> week so we can discuss plans for IETF95 and=20 >>>> the document status, so please let us know=20 >>>> before the end of Tuesday next week as to=20 >>>> whether you have any issues you wish to=20 >>>> raise. >>>> >>>> Thanks everyone! >>>> >>>> >>>> Natasha >>>> >>>> >>>> Natasha Rooney | Technologist, Web and=20 >>>> Internet, W3C & IETF | GSMA |=20 >>>> nrooney@gsma.com |=20 >>>> +44 (0) 7730 219 765 | @thisNatasha | Skype:=20 >>>> nrooney@gsm.org >>>> >>>>> On Mar 2, 2016, at 4:37 PM, Natasha Rooney=20 >>>>> <nrooney@gsma.com>=20 >>>>> wrote: >>>>> >>>>> Hi all! >>>>> >>>>> We are 1 month and 1 day away from the=20 >>>>> start of IETF95! Gasp! We have some work to=20 >>>>> get on with before IETF95, where we will=20 >>>>> have a very short (and hopefully fruitful=20 >>>>> meeting!) discussing the last issues we=20 >>>>> have remaining. >>>>> >>>>> The IETF95 link is below for those of you who still need to book hot= els: >>>>> >>>>>=20 >>>>> https://ietf.org/meeting/95/in= dex.html >>>>> >>>>> I am going to be working on finishing the=20 >>>>> use cases document from now until IETF95.=20 >>>>> Please submit any issues or pull requests=20 >>>>> to the github repo or tell me directly: >>>>> >>>>>=20 >>>>> https://github.com/ie= tf-slim-wg/slim-use-cases/ >>>>> >>>>> With our other two documents I believe the=20 >>>>> modality issues is still at large. Can=20 >>>>> someone catch me up on the last discussions=20 >>>>> here? I remember that we were still=20 >>>>> discussing it and no decisions had been=20 >>>>> made - is this correct? On discussions with=20 >>>>> other IETF attendees many said that dual=20 >>>>> modality - whilst supported by use cases -=20 >>>>> is awfully difficult to implement, is this=20 >>>>> the same as the thoughts within this group? >>>>> >>>>>=20 >>>>> https://datatracker.i= etf.org/wg/slim/documents/ >>>>> >>>>> Thanks all! >>>>> >>>>> Natasha >>>>> >>>>> Natasha Rooney | Technologist, Web and=20 >>>>> Internet, W3C & IETF | GSMA |=20 >>>>> =20 >>>>> nrooney@gsma.com |=20 >>>>> +44 (0) 7730 219 765 | @thisNatasha |=20 >>>>> Skype:=20 >>>>> nrooney@gsm.org >>>>> >>>>> >>>>> This email and its attachments are=20 >>>>> intended for the above named only and may=20 >>>>> be confidential. If they have come to you=20 >>>>> in error you must take no action based on=20 >>>>> them, nor must you copy or show them to=20 >>>>> anyone; please reply to this email or call=20 >>>>> +44 207 356 0600 and highlight the error. >>>>> >>>>> _______________________________________________ >>>>> SLIM mailing list >>>>> SLIM@ietf.org >>>>> >>>>>=20 >>>>> https://www.ietf.org/mailm= an/listinfo/slim >>>>> >>>> >>>> This email and its attachments are intended=20 >>>> for the above named only and may be=20 >>>> confidential. If they have come to you in=20 >>>> error you must take no action based on them,=20 >>>> nor must you copy or show them to anyone;=20 >>>> please reply to this email or call +44 207=20 >>>> 356 0600 and highlight the error. >>>> >>>> >>>> >>>> _______________________________________________ >>>> SLIM mailing list >>>> SLIM@ietf.org >>>> >>>>=20 >>>> https://www.ietf.org/mailma= n/listinfo/slim >>>> >>> >>> >>> _______________________________________________ >>> SLIM mailing list >>> SLIM@ietf.org >>> https://www.ietf.org/mailman/listinfo/slim >> >> > > -- > ----------------------------------------- > Gunnar Hellstr=F6m > Omnitor > gunnar.hellstrom@omnitor.se > +46 708 204 288 > > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Democracy is a beautiful thing, except for that part about letting just any old yokel vote. --Anonymous, Age 10 From nobody Tue Mar 15 16:20:56 2016 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67C9412DDB0 for ; Tue, 15 Mar 2016 16:20:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ba6xYAr0acIy for ; Tue, 15 Mar 2016 16:20:51 -0700 (PDT) Received: from bin-vsp-out-01.atm.binero.net (bin-mail-out-05.binero.net [195.74.38.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0C8A12D677 for ; Tue, 15 Mar 2016 16:20:50 -0700 (PDT) X-Halon-ID: 8ca50af4-eb04-11e5-88ba-005056917a89 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.1.95] (unknown [109.25.254.61]) by bin-vsp-out-01.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Wed, 16 Mar 2016 00:20:47 +0100 (CET) To: Randall Gellens , slim@ietf.org References: <076290F0-048C-49F4-8BF5-760109F75240@gsma.com> <56E3E464.2040900@omnitor.se> <56E53534.6090208@omnitor.se> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <56E898C9.8070100@omnitor.se> Date: Wed, 16 Mar 2016 00:20:41 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Slim] IETF95, Use Cases doc, and others X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 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, 15 Mar 2016 23:20:55 -0000 Hi Randall, Den 2016-03-15 kl. 02:15, skrev Randall Gellens: > Hi Gunnar, > > I think adding q= factor is much more complexity than is needed, and I > remain unconvinced that we must have a preference indication at the > start. I don't see that use cases are impossible without it. It seems > to me that the only difference it makes is to skip establishing some > requested media streams if others are established. I suspect that in > most cases, the ones that could be skipped would be the easier ones > (without relay/interpretation services). Having an extra text or > audio stream that is not used is not a big deal. I agree that adding the q-factor was not what I originally thought of as the solution. But since I realised that we could not reuse the * -mark of the less-needed indication of Advisory vs required for this purpose I thought it was best to reuse another already existing coding. You are welcome to propose another alternative. Because we need a preference indication that is independent of media. I have called it "absolute preference", but that might not be the best words. It can be solved with a relative preference. The important thing is that it is about preference regardless of media You have specified one preference order within each media, but that is not sufficient. It is essential to be able to specify e.g. "I prefer to speak but can accept to type". And to indicate what modality/language combination is your favourite among possible combinations. And it is not primarily about establishing media streams, it is about connecting the right persons and services to the call and have an indication in what modality and language to handle the call. With the long turn-around-times in IETF I absolutely do not want to wait one generation before we satisfy this need. Can we accept the q-factor or invent something new, e.g. "; hi" for the highest preferred ones. I think we have reduced complexity a lot anyway so that this one could stay. Regards, Gunnar > > If we keep the draft very simple to start with, then after we have > some deployment experience, we can create a revision or an extension > that adds the features that we found we need, in the way we found we > need them. In my experience, this is a better approach than trying to > think of all aspects of the solution at the start, since doing so > inevitably adds complexity and adds features in ways that turn out to > not be ideal. > > So, I would like to avoid adding preference now, but would be happy to > work on an update or extension in the future if we find that we need it. > > At 10:39 AM +0100 3/13/16, Gunnar Hellström wrote: > >> Randall, >> >> Den 2016-03-12 kl. 23:53, skrev Randall Gellens: >>> Hi Gunnar and everyone, >>> >>> In the interest of keeping the draft as simple as possible for the >>> initial version, I do not think we need to add the absolute level of >>> preference that you suggest. >> And I think the draft will not be sufficiently usable without a >> mechanism to indicate absolute preference in a way so that the >> preference between languages and modalities in different media is >> indicated. >> For example I prefer to talk and hear spoken English in audio, but >> can accept to type and read English text. >> or another example: >> I prefer to talk and hear spoken French in audio but can accept to >> sign and see French sign language in video. >> >> Without a way to make the distinction, we give no clue to the other >> party on why language is indicated in more than one media. Are all >> desired or not? >> And if you cannot indicate an option with lower preference then you >> may lose calls or get relay services invoked when they are not >> needed, wasting resources and making the calls less direct and less >> personal. >> >> We could probably do with just two levels of preference: Preferred >> and possible. >> While searching in >> https://tools.ietf.org/html/draft-ietf-slim-negotiating-human-language-00 >> for a possiblity to include that in the syntax without increasing >> complexity, I saw the Advisory vs Required indication by an asterisk >> in section 6.3. >> I do not expect that indication to be of much value, so I intended >> to propose to change its use to be a priority indicator. But it seems >> too tightly coupled to the use in language-matching in RFC 2616, so I >> abstain from proposing that and instead with hesitation propose that >> we include the q= factor notation from RFC 2616 for indicating >> preference. >> >> I suggest a change in section 6.2: >> >> -------------------------------------current text in >> 6.2------------------------------------------------- >> >> a=humintlang-send: >> a=humintlang-recv: >> >> Each can appear multiple times in an offer for a media stream. >> >> In an offer, the 'humintlang-send' values constitute a list in >> preference order (first is most preferred) of the languages the >> offerer wishes to send using the media, and the 'humintlang-recv' >> values constitute a list in preference order of the languages the >> offerer wishes to receive using the media. >> >> >> >> -------------------------------------proposed changed text in >> 6.2---------------------------------- >> >> a=humintlang-send:[ ";" "q" "=" qvalue ] >> >> a=humintlang-recv:[ ";" "q" "=" qvalue ] >> >> >> Each can appear multiple times in an offer for a media stream. >> >> In an offer the 'humintlang-send' values constitute a list of the >> languages the >> offerer wishes to send using the media, and the 'humintlang-recv' >> values constitute a list of the languages the >> offerer wishes to receive using the media. The q-values represent >> a preference level >> for using the indicated language and modality relative to all >> other languages and >> modalities indicated for the same direction in the whole SDP. >> The quality value defaults to "q=1" and has the same syntax and >> usage rules as for 'Accept-Language' in RFC 2616 [RFC2616]. >> >> If more than one language is specified for the same media and >> direction with the same q-value, >> they SHALL be listed in preference order. >> >> ---------------------------------End of change >> proposal.--------------------------------------------- >> >> >> >>> >>> At 10:41 AM +0100 3/12/16, Gunnar Hellström wrote: >>> >>>> Natasha and all, >>>> >>>> The use case collection looks good. >>>> The reasoning about implementability need a description about >>>> what version of the negotiating-human-language draft it refers to. >>>> We hope to improve, so we get "possible" on nearly all cases. >>>> >>>> It is time to act on the conclusions of the use cases. >>>> >>>> My suggestion: >>>> Add in the negotiating-human-language draft the following: >>>> >>>> 1. A coding for absolute level of preference for a >>>> modality-language combination in three levels: preferred, can-do, >>>> last-resort. Shall we explicit using words, or cryptic, using * and >>>> other special characters? >> Changed to q-value above >>>> >>>> 2. A clear interpreting rule, saying that for needs of two >>>> modalities, one in each direction, the directional attributes >>>> together with absolute coding of preference shall be used, >>>> including some default rule for when no absolute coding is provided. >> What is said for dual modalities in 6.2 just below the change >> proposal above may be sufficient. >>>> >>>> >>>> 3. A description of offer-answer handling rules, making it very >>>> clear if the attributes in the answer indicate capabilities and >>>> preferences from the point of view of the party sending the SDP, or >>>> from the point of view of the offering party. >>>> The first case would mean that "I want to talk English" and "I >>>> want to read English text" shall be answered with "I want to listen >>>> to spoken English" and "I will type English" to get a match , The >>>> second case would mean that "I want to talk English" and "I want to >>>> read English text" would be answered with "I accept that you talk >>>> English" and "I accept that you will read English text" thus >>>> sending attributes as if coded from the offering party to get a match. >>>> The first case is more evident for the user, while the second >>>> case is easier to parse and check for a match. >> In 6.2 we have the rule that both the offeror and the answering >> party indicate values from their own point of view. I think that is >> doable. >>>> >>>> 4. A conclusion that need for speech-to-speech relay services is >>>> out of scope and need to be solved by other indications. Do anyone >>>> have ideas for such indications? Call-Info with purpose and URI to >>>> a suitable service? Make a REFER to bring in the service? Call with >>>> a URI-list? ( Yes, it is out of scope, but I am interested to have >>>> an agreed best practice solutions for it.) >> We take that separately and concentrate on the preference scope to >> cover all modalities here. >> >> /Gunnar >>>> >>>> Regards >>>> >>>> Gunnar >>>> >>>> >>>> Den 2016-03-11 kl. 17:28, skrev Natasha Rooney: >>>> >>>>> Hi all! >>>>> >>>>> IETF95 Deadline >>>>> Just a quick reminder that the IETF95 document submission >>>>> deadline is coming up fast (March 21st). I am going to submit the >>>>> use cases draft before then with the use cases I have collected >>>>> from the last meeting. If you want to see what we have so far then >>>>> see the link below (excuse the xml): >>>>> >>>>> >>>>> https://github.com/ietf-slim-wg/slim-use-cases/blob/master/draft-ietf-slim-use-cases-latest.xml >>>>> >>>>> >>>>> Our Document Status >>>>> With regards to our two other documents, I believe the only >>>>> issue we have is regarding the dual modality use case, and the >>>>> difficulty of dealing with this within real-time communications >>>>> (this obviously only applies to >>>>> draft-ietf-slim-negotiating-human-language-00). My question to you >>>>> all is: do you have any other outstanding issues with either >>>>> draft? If not, we should be in a state to clean them up and publish. >>>>> >>>>> Bernard and I are having a chairs chat next week so we can >>>>> discuss plans for IETF95 and the document status, so please let us >>>>> know before the end of Tuesday next week as to whether you have >>>>> any issues you wish to raise. >>>>> >>>>> 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 >>>>> >>>>>> On Mar 2, 2016, at 4:37 PM, Natasha Rooney >>>>>> <nrooney@gsma.com> wrote: >>>>>> >>>>>> Hi all! >>>>>> >>>>>> We are 1 month and 1 day away from the start of IETF95! Gasp! >>>>>> We have some work to get on with before IETF95, where we will >>>>>> have a very short (and hopefully fruitful meeting!) discussing >>>>>> the last issues we have remaining. >>>>>> >>>>>> The IETF95 link is below for those of you who still need to >>>>>> book hotels: >>>>>> >>>>>> >>>>>> https://ietf.org/meeting/95/index.html >>>>>> >>>>>> >>>>>> I am going to be working on finishing the use cases document >>>>>> from now until IETF95. Please submit any issues or pull requests >>>>>> to the github repo or tell me directly: >>>>>> >>>>>> >>>>>> https://github.com/ietf-slim-wg/slim-use-cases/ >>>>>> >>>>>> >>>>>> With our other two documents I believe the modality issues is >>>>>> still at large. Can someone catch me up on the last discussions >>>>>> here? I remember that we were still discussing it and no >>>>>> decisions had been made - is this correct? On discussions with >>>>>> other IETF attendees many said that dual modality - whilst >>>>>> supported by use cases - is awfully difficult to implement, is >>>>>> this the same as the thoughts within this group? >>>>>> >>>>>> >>>>>> https://datatracker.ietf.org/wg/slim/documents/ >>>>>> >>>>>> >>>>>> 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 >>>>>> >>>>>> >>>>>> 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 >>>>>> >>>>>> >>>>> >>>>> 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 >>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> SLIM mailing list >>>> SLIM@ietf.org >>>> https://www.ietf.org/mailman/listinfo/slim >>> >>> >> >> -- >> ----------------------------------------- >> Gunnar Hellström >> Omnitor >> gunnar.hellstrom@omnitor.se >> +46 708 204 288 >> >> _______________________________________________ >> SLIM mailing list >> SLIM@ietf.org >> https://www.ietf.org/mailman/listinfo/slim > > -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 From nobody Tue Mar 15 22:13:20 2016 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFE1112D642 for ; Tue, 15 Mar 2016 22:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jek-jFuh2zzH for ; Tue, 15 Mar 2016 22:13:15 -0700 (PDT) Received: from bin-vsp-out-02.atm.binero.net (bin-mail-out-05.binero.net [195.74.38.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B16312D773 for ; Tue, 15 Mar 2016 22:13:14 -0700 (PDT) X-Halon-ID: c2847337-eb35-11e5-aff0-005056917f90 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.1.95] (unknown [109.25.254.61]) by bin-vsp-out-02.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Wed, 16 Mar 2016 06:13:03 +0100 (CET) To: slim@ietf.org References: <076290F0-048C-49F4-8BF5-760109F75240@gsma.com> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <56E8EB60.30707@omnitor.se> Date: Wed, 16 Mar 2016 06:13:04 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------060208000805080308050708" Archived-At: Subject: Re: [Slim] IETF95, Use Cases doc change proposals X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 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, 16 Mar 2016 05:13:19 -0000 This is a multi-part message in MIME format. --------------060208000805080308050708 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Natasha and all, I have a couple of suggestions for the use cases document: 1. In introduction, the words "real-time" and "necessary" are misspelled. 2. At the end of the introduction, I suggest the addition of: "For each use case a 'Result' is provided, indicating the implementability of the use case based on draft version draft-ietf-slim-negotiating-human-language-00 " 3. The last line in section 3, Final comments look strange and should be changed to: "There is no clear need for explicit grouping of language/modality indications." 4. In the introduction, it looks as if the document contains both real-time and non-real-time use cases. If only real-time use cases are provided, then the introduction needs adaptation. /Gunnar Den 2016-03-11 kl. 17:28, skrev Natasha Rooney: > Hi all! > > *IETF95 Deadline* > Just a quick reminder that the IETF95 document submission deadline is > coming up fast (*March 21st*). I am going to submit the use cases > draft before then with the use cases I have collected from the last > meeting. If you want to see what we have so far then see the link > below (excuse the xml): > https://github.com/ietf-slim-wg/slim-use-cases/blob/master/draft-ietf-slim-use-cases-latest.xml > > *Our Document Status* > With regards to our two other documents, I believe the only issue we > have is regarding the dual modality use case, and the difficulty of > dealing with this within real-time communications (this obviously only > applies to draft-ietf-slim-negotiating-human-language-00). My question > to you all is: *do you have any other outstanding issues with either > draft? *If not, we should be in a state to clean them up and publish. > > Bernard and I are having a chairs chat next week so we can discuss > plans for IETF95 and the document status, so please *let us know > before the end of Tuesday next week as to whether you have any issues > you wish to raise*. > > 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 > > >> On Mar 2, 2016, at 4:37 PM, Natasha Rooney > > wrote: >> >> Hi all! >> >> We are 1 month and 1 day away from the start of IETF95! Gasp! We have >> some work to get on with before IETF95, where we will have a very >> short (and hopefully fruitful meeting!) discussing the last issues we >> have remaining. >> >> The IETF95 link is below for those of you who still need to book hotels: >> https://ietf.org/meeting/95/index.html >> >> I am going to be working on finishing the use cases document from now >> until IETF95. Please submit any issues or pull requests to the github >> repo or tell me directly: >> https://github.com/ietf-slim-wg/slim-use-cases/ >> >> With our other two documents I believe the modality issues is still >> at large. Can someone catch me up on the last discussions here? I >> remember that we were still discussing it and no decisions had been >> made - is this correct? On discussions with other IETF attendees many >> said that dual modality - whilst supported by use cases - is awfully >> difficult to implement, is this the same as the thoughts within this >> group? >> https://datatracker.ietf.org/wg/slim/documents/ >> >> 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 >> >> >> 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 > > This email and its attachments are intended for the above named only > and may be confidential. If they have come to you in error you must > take no action based on them, nor must you copy or show them to > anyone; please reply to this email or call +44 207 356 0600 and > highlight the error. > > > > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 --------------060208000805080308050708 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi Natasha and all,

I have a couple of suggestions for the use cases document:

1. In introduction, the words "real-time" and "necessary" are misspelled.

2. At the end of the introduction, I suggest the addition of:
"For each use case a 'Result' is provided, indicating the implementability of the use case based on draft version  draft-ietf-slim-negotiating-human-language-00 "

3. The last line in section 3, Final comments look strange and should be changed to:
"There is no clear need for explicit grouping of language/modality indications."

4. In the introduction, it looks as if the document contains  both real-time and non-real-time use cases. If only real-time use cases are provided, then the introduction needs adaptation.

 /Gunnar
 

    

    
Den 2016-03-11 kl. 17:28, skrev Natasha
      Rooney:

    

    

      
      Hi all!
      


      

      
IETF95 Deadline

      
Just a quick reminder that the IETF95 document
        submission deadline is coming up fast (March 21st). I am going
        to submit the use cases draft before then with the use cases I
        have collected from the last meeting. If you want to see what we
        have so far then see the link below (excuse the xml):

      
      


      

      
Our Document Status

      
With regards to our two other documents, I believe
        the only issue we have is regarding the dual modality use case,
        and the difficulty of dealing with this within real-time
        communications (this obviously only applies
        to draft-ietf-slim-negotiating-human-language-00). My question
        to you all is: do
            you have any other outstanding issues with either draft?
        If not, we should be in a state to clean them up and
        publish.

      


      

      
Bernard and I are having a chairs chat next week so
        we can discuss plans for IETF95 and the document status, so
        please
        let us know before
            the end of Tuesday next week as to whether you have any
            issues you wish to raise.

      


      

      
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 

              

            

          

        

        

        

          

            
On Mar 2, 2016, at 4:37 PM, Natasha Rooney
              <nrooney@gsma.com>
              wrote:

            

            

              

                Hi all!
                


                

                
We are 1 month and 1 day away from the
                  start of IETF95! Gasp! We have some work to get on
                  with before IETF95, where we will have a very short
                  (and hopefully fruitful meeting!) discussing the last
                  issues we have remaining.

                


                

                

                  
The IETF95 link is below for those of
                    you who still need to book hotels:

                  
                  


                  

                  
I am going to be working on finishing
                    the use cases document from now until IETF95. Please
                    submit any issues or pull requests to the github
                    repo or tell me directly:

                  
                  


                  

                  
With our other two documents I believe
                    the modality issues is still at large. Can someone
                    catch me up on the last discussions here? I remember
                    that we were still discussing it and no decisions
                    had been made - is this correct? On discussions with
                    other IETF attendees many said that dual modality -
                    whilst supported by use cases - is awfully difficult
                    to implement, is this the same as the thoughts
                    within this group?

                  
                  


                  

                  
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 

                        

                      

                    

                  

                  

                

                
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

            

          

        

        

      

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

      

      

      

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


    

    

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

  


--------------060208000805080308050708--


From nobody Tue Mar 15 23:36:48 2016
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8FB612D686 for ; Tue, 15 Mar 2016 23:36:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jr61KmRHqzHM for ; Tue, 15 Mar 2016 23:36:43 -0700 (PDT)
Received: from bin-vsp-out-02.atm.binero.net (bin-mail-out-06.binero.net [195.74.38.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7972E12D539 for ; Tue, 15 Mar 2016 23:36:42 -0700 (PDT)
X-Halon-ID: 6b81fa40-eb41-11e5-aff0-005056917f90
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.1.95] (unknown [109.25.254.61]) by bin-vsp-out-02.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Wed, 16 Mar 2016 07:36:31 +0100 (CET)
To: "slim@ietf.org" 
References: <20151102160934.3160.2433.idtracker@ietfa.amsl.com>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: <56E8FEF0.10503@omnitor.se>
Date: Wed, 16 Mar 2016 07:36:32 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <20151102160934.3160.2433.idtracker@ietfa.amsl.com>
Content-Type: multipart/alternative; boundary="------------060400040607030406090406"
Archived-At: 
Subject: [Slim] Change proposals for draft-ietf-slim-negotiating-human-language-00.txt
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
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, 16 Mar 2016 06:36:46 -0000

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

In addition to the changes proposed in 
draft-ietf-slim-negotiating-human-language-00 for the preference 
regardless of media recently submitted, I have the following proposals 
for changes:

1. Change the first paragraph of section 5 from:
--------------------------------------------------------------------------------------------------

  RFC 4566   specifies an attribute 'lang' which sounds similar to what
    is needed here, the difference being that it specifies that 'a=lang'
    is declarative with the semantics of multiple 'lang' attributes being
    that all of them are used, while we want a means to negotiate which
    one is used in each stream.  This difference means that the existing
    'lang' attribute can't be used and we need to define a new attribute.
-------------------------------------------------------------------------------


to
---------------------------------------------------------------------------------------

  RFC 4566   specifies an attribute 'lang' which sounds similar to what
    is needed here. It specifies that 'a=lang'
    is declarative with the semantics of multiple 'lang' attributes being
    possible, indicating a number of possible languages in the session in
    an order of preference. Each party declares their capabilities and the
    language(s) used in the session can then be selected from the common set.
    We have however a need to specify direction of use of each language,
    and an order of preference between languages in different modalities.
    This difference means that the existing 'lang' attribute is not sufficient
    for our use and we need to complement it with definition of a new attribute.
--------------------------------------------------------------------------------------------------


2. change the last two paragraphs of section 5 from:
--------------------------------------------------------------------------------------------------------

  A recent search of RFCs and Internet Drafts turned up only one use of
    the 'lang' attribute (in a now-expired draft), and that sole use was
    coincidentally in exactly the way we need (erroniously assuming that
    the attribute was used for negotiation).  The sole use was in an
    example in a draft not directly related to language, where the
    initial invitation contains two 'a=lang' entries for a media stream
    (for English and Italian) and the OK accepts one of them (Italian).

    The example serves as evidence of the need for an SDP attribute with
    the semantics as described in this document; unfortunately, the
    existing 'lang' attribute is not it.
----------------------------------------------------------------------
to
-----------------------------------------------------------------------------
  A recent search of RFCs and Internet Drafts turned up only one use of
    the 'lang' attribute (in a now-expired draft), and that sole use was
    coincidentally in exactly the way we need.  The sole use was in an
    example in a draft not directly related to language, where the
    initial invitation contains two 'a=lang' entries for a media stream
    (for English and Italian) and the OK accepts one of them (Italian).

    This use was questioned in a discussion of that draft because of this
    sentence in RFC 4566: "Multiple lang attributes can be
       provided either at session or media level if the session
       description or media use multiple languages."
    An interpretation was that all declared languages must be used in
    the session, while the example showed use of a selection of the
    originally indicated languages. The uncertainty caused withdrawal
    of the example because it was not essential for the draft.

   However, studying the wording in RFC 4566 further, it is evident
   that a negotiation of languages was intended for the real-time case.
   When sdp is used to declare contents of a recorded session, then it
   makes sense to list the provided languages, while for a real-time
   session, it is obvious that the capabilities of the parties and the
   development of the session influence the selection of language for
   the session.
   The continuation in RFC 4566 "the order of the attributes indicates
   the order of importance of the various languages" makes it very clear
   that the list shall be seen as a list for selection and negotiation.
   The "order of importance" has no meaning if all languages must be provided.

   The conclusion is that the 'lang' attribute can be used for negotiation
   of one or more common languages to select from for use in a real-time session.
   A clarification is prepared for a possible future revision of RFC 4566.

   Thus, the 'lang' attribute satisfies our needs in many cases.

   Unfortunately, there are cases, where the users need to use different
   modalities in different directions, and when it is important to combine
   languages in different modalities. The 'lang' attribute does not have
   the details needed to cover these cases."
-------------------------------------------------------------------------------------------------

3. Change section 6 from:
-------------------------------------------------------
6 Proposed Solution

    An SDP attribute seems the natural choice to negotiate human
    (natural) language of an interactive media stream.  The attribute
    value should be a language tag perRFC 5646   [RFC5646 ] "
------------------------------------------------------------------
to
-----------------------------------------------------------------------
6 Proposed Solution
    An SDP attribute seems the natural choice to negotiate human
    (natural) language of an interactive media stream.  The attribute
    value should be a language tag perRFC 5646   [RFC5646 ]
    The new attribute can appear together with the existing 'lang'
    attribute to compose the preferred language/modality combinations
    offered or negotiated.
----------------------------------------------------------------------

  
Regards

Gunnar




Den 2015-11-02 kl. 17:09, skrev internet-drafts@ietf.org:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>   This draft is a work item of the Selection of Language for Internet Media 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/
>
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

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


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


  
    
  
  
    In addition to the changes proposed in
    draft-ietf-slim-negotiating-human-language-00 for the preference
    regardless of media recently submitted, I have the following
    proposals for changes:

    

    1. Change the first paragraph of section 5 from:

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

    
 RFC 4566 specifies an attribute 'lang' which sounds similar to what
   is needed here, the difference being that it specifies that 'a=lang'
   is declarative with the semantics of multiple 'lang' attributes being
   that all of them are used, while we want a means to negotiate which
   one is used in each stream.  This difference means that the existing
   'lang' attribute can't be used and we need to define a new attribute.  
-------------------------------------------------------------------------------


    

    to

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

    
 RFC 4566 specifies an attribute 'lang' which sounds similar to what
   is needed here. It specifies that 'a=lang'
   is declarative with the semantics of multiple 'lang' attributes being
   possible, indicating a number of possible languages in the session in
   an order of preference. Each party declares their capabilities and the
   language(s) used in the session can then be selected from the common set.
   We have however a need to specify direction of use of each language, 
   and an order of preference between languages in different modalities.
   This difference means that the existing 'lang' attribute is not sufficient 
   for our use and we need to complement it with definition of a new attribute.
--------------------------------------------------------------------------------------------------


    

    2. change the last two paragraphs of section 5 from:

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

    
 A recent search of RFCs and Internet Drafts turned up only one use of
   the 'lang' attribute (in a now-expired draft), and that sole use was
   coincidentally in exactly the way we need (erroniously assuming that
   the attribute was used for negotiation).  The sole use was in an
   example in a draft not directly related to language, where the
   initial invitation contains two 'a=lang' entries for a media stream
   (for English and Italian) and the OK accepts one of them (Italian).

   The example serves as evidence of the need for an SDP attribute with
   the semantics as described in this document; unfortunately, the
   existing 'lang' attribute is not it.
----------------------------------------------------------------------
to
-----------------------------------------------------------------------------
 A recent search of RFCs and Internet Drafts turned up only one use of
   the 'lang' attribute (in a now-expired draft), and that sole use was
   coincidentally in exactly the way we need.  The sole use was in an
   example in a draft not directly related to language, where the
   initial invitation contains two 'a=lang' entries for a media stream
   (for English and Italian) and the OK accepts one of them (Italian).

   This use was questioned in a discussion of that draft because of this
   sentence in RFC 4566: "Multiple lang attributes can be
      provided either at session or media level if the session
      description or media use multiple languages."
   An interpretation was that all declared languages must be used in 
   the session, while the example showed use of a selection of the 
   originally indicated languages. The uncertainty caused withdrawal 
   of the example because it was not essential for the draft.

  However, studying the wording in RFC 4566 further, it is evident 
  that a negotiation of languages was intended for the real-time case. 
  When sdp is used to declare contents of a recorded session, then it 
  makes sense to list the provided languages, while for a real-time 
  session, it is obvious that the capabilities of the parties and the 
  development of the session influence the selection of language for 
  the session.
  The continuation in RFC 4566 "the order of the attributes indicates 
  the order of importance of the various languages" makes it very clear
  that the list shall be seen as a list for selection and negotiation. 
  The "order of importance" has no meaning if all languages must be provided.

  The conclusion is that the 'lang' attribute can be used for negotiation 
  of one or more common languages to select from for use in a real-time session. 
  A clarification is prepared for a possible future revision of RFC 4566. 

  Thus, the 'lang' attribute satisfies our needs in many cases.

  Unfortunately, there are cases, where the users need to use different 
  modalities in different directions, and when it is important to combine 
  languages in different modalities. The 'lang' attribute does not have 
  the details needed to cover these cases."
-------------------------------------------------------------------------------------------------

3. Change section 6 from:
-------------------------------------------------------
6 Proposed Solution

    
   An SDP attribute seems the natural choice to negotiate human
   (natural) language of an interactive media stream.  The attribute
   value should be a language tag per RFC 5646 [RFC5646] "
------------------------------------------------------------------
to
-----------------------------------------------------------------------
6 Proposed Solution
   An SDP attribute seems the natural choice to negotiate human
   (natural) language of an interactive media stream.  The attribute
   value should be a language tag per RFC 5646 [RFC5646]
   The new attribute can appear together with the existing 'lang' 
   attribute to compose the preferred language/modality combinations 
   offered or negotiated.
----------------------------------------------------------------------

 
Regards

Gunnar




     

    

    
Den 2015-11-02 kl. 17:09, skrev
      internet-drafts@ietf.org:

    

    

      
A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Selection of Language for Internet Media 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/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


    

    

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

  


--------------060400040607030406090406--


From nobody Wed Mar 16 11:27:47 2016
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F4D012DA7B for ; Wed, 16 Mar 2016 11:27:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ijqaxcw4_7vP for ; Wed, 16 Mar 2016 11:27:44 -0700 (PDT)
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 9968312DA08 for ; Wed, 16 Mar 2016 11:27:44 -0700 (PDT)
Received: from localhost ([72.167.218.134]) by p3plwbeout03-05.prod.phx3.secureserver.net with bizsmtp id WiTk1s0022uaRjc01iTknm; Wed, 16 Mar 2016 11:27:44 -0700
X-SID: WiTk1s0022uaRjc01
Received: (qmail 9613 invoked by uid 99); 16 Mar 2016 18:27:44 -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.16.13
Message-Id: <20160316112742.665a7a7059d7ee80bb4d670165c8327d.b35a9939dc.wbe@email03.secureserver.net>
From: "Doug Ewell" 
To: slim@ietf.org
Date: Wed, 16 Mar 2016 11:27:42 -0700
Mime-Version: 1.0
Archived-At: 
Subject: Re: [Slim] IETF95, Use Cases doc, and others
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
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, 16 Mar 2016 18:27:46 -0000

Gunnar Hellstr=C3=B6m wrote:=0A=0A> With the long turn-around-times in IETF=
 I absolutely do not want to=0A> wait one generation before we satisfy this=
 need.=0A=0AAmong the leading causes of long turnaround times among working=
 groups=0Aare (a) unresolved disagreements about WG scope and (b) efforts t=
o=0Aenhance the deliverable(s) by covering every possible scenario.=0A=0A--=
=0ADoug Ewell | http://ewellic.org | Thornton, CO =F0=9F=87=BA=F0=9F=87=B8=
=0A


From nobody Wed Mar 16 11:38:26 2016
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F87912DA9A for ; Wed, 16 Mar 2016 11:38:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WICAwR7Bf4Lj for ; Wed, 16 Mar 2016 11:38:18 -0700 (PDT)
Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::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 0366912DA8C for ; Wed, 16 Mar 2016 11:38:18 -0700 (PDT)
Received: by mail-qg0-x235.google.com with SMTP id u110so50947543qge.3 for ; Wed, 16 Mar 2016 11:38:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=cLWKev2uxo25A+HCJFT8slDoEQ7Ckny2hD1brfqSFc4=; b=QhjSbweqaIuZ/kGSGuHYydtLJaxhbKg3vwr1qEVzUJbzK5JJBnd83t9yHvDzVBaElm NNdpOI+ndQaZKxbV/qX1ziQPsLoyohuHO1h78xmClMktSH2wEFMb6qlVcgwKszUC2Fhv KABar9f+gCSRWiyghfo14Q9Nl4FyuQi+lUcxfoTJeA2QT1FwhmxRSKwSlu5/VOW16JLI XaIM+c/+JEpd1SVAnEUAl7PYruJ0SXC7KIVpO6aNSrHpecGa9kqPjB7IcttrV9NFouEY R9kzrpTdcqz5lNk853M92iAygaRQQUb93cpqrq5CjLWs6M9E3N/rqk5OaeK+iZbswsLG m6hw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=cLWKev2uxo25A+HCJFT8slDoEQ7Ckny2hD1brfqSFc4=; b=LijcHgD8DPWbi0IuN2lcFdIFq52xyfgXCWJr8KCR7N4V25MufkACJYKxoHBlenCY7s ep1u8dvYWDF0x5orHV7WGH0fhQug0uJ4Ha8s0ycWBX0Xx2BTUp9WpDmeYV6d39WFKqX7 rGztnUJLsFxI9ANWfkjXc1T2BD42MrsZ22dimSJ0L7Prqw9O+a1AdApiDJ2jilN+ES8A DKApTlDW9Oxi9sf9WQ+280YmI3wHgJ2Gafof4UOggjzWONg2vjOgQ3NS9BJ/Yay+ysE5 lx3VcbiVMHfWfiLq3DSCp9GTTIlyhBPmJtuzfFWgpEosR8xhKJyrulnoNPA74EUFRnXI VFCA==
X-Gm-Message-State: AD7BkJJAF9s6gUOQXu+dvhn+gDS3vy0IGgxrr0vXxzhcINddNV4TodiMCgeZh6wyrDhqzg==
X-Received: by 10.140.231.80 with SMTP id b77mr8206562qhc.56.1458153497020; Wed, 16 Mar 2016 11:38:17 -0700 (PDT)
Received: from [10.33.192.66] ([156.154.81.54]) by smtp.gmail.com with ESMTPSA id i67sm2014335qhi.45.2016.03.16.11.38.14 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 16 Mar 2016 11:38:16 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_D8E1F4B5-CAF0-4FA7-B93A-E4D6EC4C0E8D"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Brian Rosen 
In-Reply-To: <56E898C9.8070100@omnitor.se>
Date: Wed, 16 Mar 2016 14:38:11 -0400
Message-Id: 
References: <076290F0-048C-49F4-8BF5-760109F75240@gsma.com>  <56E3E464.2040900@omnitor.se>  <56E53534.6090208@omnitor.se>  <56E898C9.8070100@omnitor.se>
To: =?utf-8?Q?Gunnar_Hellstr=C3=B6m?= 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: slim@ietf.org, Randall Gellens 
Subject: Re: [Slim] IETF95, Use Cases doc, and others
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
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, 16 Mar 2016 18:38:24 -0000

--Apple-Mail=_D8E1F4B5-CAF0-4FA7-B93A-E4D6EC4C0E8D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

I really don=92t think that the complexity this introduces is worth the =
benefit, and I would prefer not to include it.  I also don=92t think it =
works.  You want a grouping of media and language, with a preference on =
the grouping, not a simple priority on language.

Brian

> On Mar 15, 2016, at 7:20 PM, Gunnar Hellstr=F6m =
 wrote:
>=20
> Hi Randall,
>=20
> Den 2016-03-15 kl. 02:15, skrev Randall Gellens:
>> Hi Gunnar,
>>=20
>> I think adding q=3D factor is much more complexity than is needed, =
and I remain unconvinced that we must have a preference indication at =
the start. I don't see that use cases are impossible without it.  It =
seems to me that the only difference it makes is to skip establishing =
some requested media streams if others are established.  I suspect that =
in most cases, the ones that could be skipped would be the easier ones =
(without relay/interpretation services).  Having an extra text or audio =
stream that is not used is not a big deal.
> I agree that adding the q-factor was not what I originally thought of =
as the solution.  But since I realised that we could not reuse the * =
-mark of the less-needed indication of Advisory vs required for this =
purpose I thought it was best to reuse another already existing coding. =
You are welcome to propose another alternative.
> Because we need a preference indication that is independent of media. =
I have called it "absolute preference", but that might not be the best =
words. It can be solved with a relative preference. The important thing =
is that it is about preference regardless of media
> You have specified one preference order within each media, but that is =
not sufficient.
> It is essential to be able to specify e.g. "I prefer to speak but can =
accept to type".
> And to indicate what modality/language combination is your favourite =
among possible combinations.
>=20
> And it is not primarily about establishing media streams, it is about =
connecting the right persons and services to the call and have an =
indication in what modality and language to handle the call.
>=20
> With the long turn-around-times in IETF I absolutely do not want to =
wait one generation before we satisfy this need.
>=20
> Can we accept the q-factor or invent something new, e.g.  "; hi" for =
the highest preferred ones.
>=20
> I think we have reduced complexity a lot anyway so that this one could =
stay.
>=20
> Regards,
> Gunnar
>=20
>>=20
>> If we keep the draft very simple to start with, then after we have =
some deployment experience, we can create a revision or an extension =
that adds the features that we found we need, in the way we found we =
need them.  In my experience, this is a better approach than trying to =
think of all aspects of the solution at the start, since doing so =
inevitably adds complexity and adds features in ways that turn out to =
not be ideal.
>>=20
>> So, I would like to avoid adding preference now, but would be happy =
to work on an update or extension in the future if we find that we need =
it.
>>=20
>> At 10:39 AM +0100 3/13/16, Gunnar Hellstr=F6m wrote:
>>=20
>>> Randall,
>>>=20
>>> Den 2016-03-12 kl. 23:53, skrev Randall Gellens:
>>>> Hi Gunnar and everyone,
>>>>=20
>>>> In the interest of keeping the draft as simple as possible for the =
initial version, I do not think we need to add the absolute level of =
preference that you suggest.
>>> And I think the draft will not be sufficiently usable without a =
mechanism to indicate absolute preference in a way so that the =
preference between languages and modalities in different media is =
indicated.
>>> For example I prefer to talk and hear spoken English in audio, but =
can accept to type and read English text.
>>> or another example:
>>> I prefer to talk and hear spoken French in audio but can accept to =
sign and see French sign language in video.
>>>=20
>>> Without a way to make the distinction, we give no clue to the other =
party on why language is indicated in more than one media. Are all =
desired or not?
>>> And if you cannot indicate an option with lower preference then you =
may lose calls or get relay services invoked when they are not needed, =
wasting resources and making the calls less direct and less personal.
>>>=20
>>> We could probably do with just two levels of preference: Preferred =
and possible.
>>> While searching in =
https://tools.ietf.org/html/draft-ietf-slim-negotiating-human-language-00
>>> for a possiblity to include that in the syntax without increasing =
complexity, I saw the Advisory vs Required indication by an asterisk in =
section 6.3.
>>> I do not expect that indication to be of much value,  so I intended =
to propose to change its use to be a priority indicator. But it seems =
too tightly coupled to the use in language-matching in RFC 2616, so I =
abstain from proposing that and instead with hesitation propose that we =
include the q=3D factor notation from RFC 2616 for indicating =
preference.
>>>=20
>>> I suggest a change in section 6.2:
>>>=20
>>> -------------------------------------current text in =
6.2-------------------------------------------------
>>>=20
>>>       a=3Dhumintlang-send:
>>>       a=3Dhumintlang-recv:
>>>=20
>>>    Each can appear multiple times in an offer for a media stream.
>>>=20
>>>    In an offer, the 'humintlang-send' values constitute a list in
>>>    preference order (first is most preferred) of the languages the
>>>    offerer wishes to send using the media, and the 'humintlang-recv'
>>>    values constitute a list in preference order of the languages the
>>>    offerer wishes to receive using the media.
>>>=20
>>>=20
>>>=20
>>> -------------------------------------proposed changed text in =
6.2----------------------------------
>>>=20
>>>       a=3Dhumintlang-send:[ ";" "q" "=3D" qvalue ]
>>>=20
>>>       a=3Dhumintlang-recv:[ ";" "q" "=3D" qvalue ]
>>>=20
>>>=20
>>>    Each can appear multiple times in an offer for a media stream.
>>>=20
>>>    In an offer the 'humintlang-send' values constitute a list of the =
languages the
>>>    offerer wishes to send using the media, and the 'humintlang-recv'
>>>    values constitute a list of the languages the
>>>    offerer wishes to receive using the media. The q-values represent =
a preference level
>>>    for using the indicated language and modality relative to all =
other languages and
>>>    modalities indicated for the same direction in the whole SDP.
>>>    The quality value defaults to "q=3D1" and has the same syntax and =
usage rules as for 'Accept-Language' in RFC 2616 [RFC2616].
>>>=20
>>>    If more than one language is specified for the same media and =
direction with the same q-value,
>>>    they SHALL be listed in preference order.
>>>=20
>>> ---------------------------------End of change =
proposal.---------------------------------------------
>>>=20
>>>=20
>>>=20
>>>>=20
>>>> At 10:41 AM +0100 3/12/16, Gunnar Hellstr=F6m wrote:
>>>>=20
>>>>>  Natasha and all,
>>>>>=20
>>>>>  The use case collection looks good.
>>>>>  The reasoning about implementability need a description about =
what version of the negotiating-human-language draft it refers to. We =
hope to improve, so we get "possible" on nearly all cases.
>>>>>=20
>>>>>  It is time to act on the conclusions of the use cases.
>>>>>=20
>>>>>  My suggestion:
>>>>>  Add in the negotiating-human-language draft the following:
>>>>>=20
>>>>>  1. A coding for absolute level of preference for a =
modality-language combination in three levels: preferred, can-do, =
last-resort. Shall we explicit using words, or cryptic, using * and =
other special characters?
>>> Changed to q-value above
>>>>>=20
>>>>>  2. A clear interpreting rule, saying that for needs of two =
modalities, one in each direction, the directional attributes together =
with absolute coding of preference shall be used, including some default =
rule for when no absolute coding is provided.
>>> What is said for dual modalities in 6.2 just below the change =
proposal above may be sufficient.
>>>>>=20
>>>>>=20
>>>>>  3. A description of offer-answer handling rules, making it very =
clear if the attributes in the answer indicate capabilities and =
preferences from the point of view of the party sending the SDP, or from =
the point of view of the offering party.
>>>>>  The first case would mean that "I want to talk English" and "I =
want to read English text" shall be answered with "I want to listen to =
spoken English" and "I will type English" to get a match , The second =
case would mean that "I want to talk English" and "I want to read =
English text" would be answered with "I accept that you talk English" =
and "I accept that you will read English text" thus sending attributes =
as if coded from the offering party to get a match.
>>>>>  The first case is more evident for the user, while the second =
case is easier to parse and check for a match.
>>> In 6.2 we have the rule that both the offeror and the answering =
party indicate values from their own point of view. I think that is =
doable.
>>>>>=20
>>>>>  4. A conclusion that need for speech-to-speech relay services is =
out of scope and need to be solved by other indications. Do anyone have =
ideas for such indications? Call-Info with purpose and URI to a suitable =
service? Make a REFER to bring in the service? Call with a URI-list? ( =
Yes, it is out of scope, but I am interested to have an agreed best =
practice solutions for it.)
>>> We take that separately and concentrate on the preference scope to =
cover all modalities here.
>>>=20
>>> /Gunnar
>>>>>=20
>>>>>  Regards
>>>>>=20
>>>>>  Gunnar
>>>>>=20
>>>>>=20
>>>>>  Den 2016-03-11 kl. 17:28, skrev Natasha Rooney:
>>>>>=20
>>>>>>  Hi all!
>>>>>>=20
>>>>>>  IETF95 Deadline
>>>>>>  Just a quick reminder that the IETF95 document submission =
deadline is coming up fast (March 21st). I am going to submit the use =
cases draft before then with the use cases I have collected from the =
last meeting. If you want to see what we have so far then see the link =
below (excuse the xml):
>>>>>>=20
>>>>>>=20
>>>>>> =
https://github.com/ietf-slim-wg/slim-use-cases/blob=
/master/draft-ietf-slim-use-cases-latest.xml=20
>>>>>>=20
>>>>>>  Our Document Status
>>>>>>  With regards to our two other documents, I believe the only =
issue we have is regarding the dual modality use case, and the =
difficulty of dealing with this within real-time communications (this =
obviously only applies to =
draft-ietf-slim-negotiating-human-language-00). My question to you all =
is: do you have any other outstanding issues with either draft? If not, =
we should be in a state to clean them up and publish.
>>>>>>=20
>>>>>>  Bernard and I are having a chairs chat next week so we can =
discuss plans for IETF95 and the document status, so please let us know =
before the end of Tuesday next week as to whether you have any issues =
you wish to raise.
>>>>>>=20
>>>>>>  Thanks everyone!
>>>>>>=20
>>>>>>=20
>>>>>>  Natasha
>>>>>>=20
>>>>>>=20
>>>>>>  Natasha Rooney | Technologist, Web and Internet, W3C & IETF | =
GSMA |  nrooney@gsma.com | +44 (0) 7730 219 765 =
| @thisNatasha | Skype: nrooney@gsm.org
>>>>>>=20
>>>>>>>  On Mar 2, 2016, at 4:37 PM, Natasha Rooney =
<nrooney@gsma.com> wrote:
>>>>>>>=20
>>>>>>>  Hi all!
>>>>>>>=20
>>>>>>>  We are 1 month and 1 day away from the start of IETF95! Gasp! =
We have some work to get on with before IETF95, where we will have a =
very short (and hopefully fruitful meeting!) discussing the last issues =
we have remaining.
>>>>>>>=20
>>>>>>>  The IETF95 link is below for those of you who still need to =
book hotels:
>>>>>>>=20
>>>>>>>=20
>>>>>>> =
https://ietf.org/meeting/95/index.=
html=20
>>>>>>>=20
>>>>>>>  I am going to be working on finishing the use cases document =
from now until IETF95. Please submit any issues or pull requests to the =
github repo or tell me directly:
>>>>>>>=20
>>>>>>>=20
>>>>>>> =
https://github.com/ietf-s=
lim-wg/slim-use-cases/=20
>>>>>>>=20
>>>>>>>  With our other two documents I believe the modality issues is =
still at large. Can someone catch me up on the last discussions here? I =
remember that we were still discussing it and no decisions had been made =
- is this correct? On discussions with other IETF attendees many said =
that dual modality - whilst supported by use cases - is awfully =
difficult to implement, is this the same as the thoughts within this =
group?
>>>>>>>=20
>>>>>>>=20
>>>>>>> =
https://datatracker.ietf.=
org/wg/slim/documents/=20
>>>>>>>=20
>>>>>>>  Thanks all!
>>>>>>>=20
>>>>>>>  Natasha
>>>>>>>=20
>>>>>>>  Natasha Rooney | Technologist, Web and Internet, W3C & IETF | =
GSMA |  =
nrooney@gsma.com | +44 (0) 7730 219 765 | =
@thisNatasha | Skype: nrooney@gsm.org
>>>>>>>=20
>>>>>>>=20
>>>>>>>  This email and its attachments are intended for the above named =
only and may be confidential. If they have come to you in error you must =
take no action based on them, nor must you copy or show them to anyone; =
please reply to this email or call +44 207 356 0600 and highlight the =
error.
>>>>>>>=20
>>>>>>>  _______________________________________________
>>>>>>>  SLIM mailing list
>>>>>>> SLIM@ietf.org
>>>>>>>=20
>>>>>>>=20
>>>>>>> =
https://www.ietf.org/mailman/l=
istinfo/slim=20
>>>>>>>=20
>>>>>>=20
>>>>>>  This email and its attachments are intended for the above named =
only and may be confidential. If they have come to you in error you must =
take no action based on them, nor must you copy or show them to anyone; =
please reply to this email or call +44 207 356 0600 and highlight the =
error.
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>  _______________________________________________
>>>>>>  SLIM mailing list
>>>>>> SLIM@ietf.org
>>>>>>=20
>>>>>>=20
>>>>>> =
https://www.ietf.org/mailman/l=
istinfo/slim=20
>>>>>>=20
>>>>>=20
>>>>>=20
>>>>>  _______________________________________________
>>>>>  SLIM mailing list
>>>>> SLIM@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/slim
>>>>=20
>>>>=20
>>>=20
>>> --
>>> -----------------------------------------
>>> Gunnar Hellstr=F6m
>>> Omnitor
>>> gunnar.hellstrom@omnitor.se
>>> +46 708 204 288
>>>=20
>>> _______________________________________________
>>> SLIM mailing list
>>> SLIM@ietf.org
>>> https://www.ietf.org/mailman/listinfo/slim
>>=20
>>=20
>=20
> --=20
> -----------------------------------------
> Gunnar Hellstr=F6m
> Omnitor
> gunnar.hellstrom@omnitor.se 
> +46 708 204 288
>=20
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org 
> https://www.ietf.org/mailman/listinfo/slim =


--Apple-Mail=_D8E1F4B5-CAF0-4FA7-B93A-E4D6EC4C0E8D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

I really don=92t think that the complexity this introduces is =
worth the benefit, and I would prefer not to include it.  I also =
don=92t think it works.  You want a grouping of media and language, =
with a preference on the grouping, not a simple priority on =
language.

Brian

On Mar 15, 2016, at 7:20 PM, =
Gunnar Hellstr=F6m <gunnar.hellstrom@omnitor.se> wrote:

Hi Randall,

Den 2016-03-15 kl. 02:15, skrev Randall =
Gellens:
Hi =
Gunnar,

I think adding q=3D factor is much =
more complexity than is needed, and I remain unconvinced that we must =
have a preference indication at the start. I don't see that use cases =
are impossible without it.  It seems to me that the only difference =
it makes is to skip establishing some requested media streams if others =
are established.  I suspect that in most cases, the ones that could =
be skipped would be the easier ones (without relay/interpretation =
services).  Having an extra text or audio stream that is not used =
is not a big deal.
I agree that adding the =
q-factor was not what I originally thought of as the solution.  But =
since I realised that we could not reuse the * -mark of the less-needed =
indication of Advisory vs required for this purpose I thought it was =
best to reuse another already existing coding. You are welcome to =
propose another alternative.
Because we need a preference indication that is =
independent of media. I have called it "absolute preference", but that =
might not be the best words. It can be solved with a relative =
preference. The important thing is that it is about preference =
regardless of media
You have specified one preference order within =
each media, but that is not sufficient.
It is essential to be able to specify =
e.g. "I prefer to speak but can accept to type".
And to indicate what =
modality/language combination is your favourite among possible =
combinations.

And it is not primarily =
about establishing media streams, it is about connecting the right =
persons and services to the call and have an indication in what modality =
and language to handle the call.

With the long turn-around-times in IETF I =
absolutely do not want to wait one generation before we satisfy this =
need.

Can we accept the q-factor =
or invent something new, e.g.  "; hi" for the highest preferred =
ones.

I think we have reduced =
complexity a lot anyway so that this one could stay.

Regards,
Gunnar


If we keep the draft very simple to start with, then after we =
have some deployment experience, we can create a revision or an =
extension that adds the features that we found we need, in the way we =
found we need them.  In my experience, this is a better approach =
than trying to think of all aspects of the solution at the start, since =
doing so inevitably adds complexity and adds features in ways that turn =
out to not be ideal.

So, I would like to =
avoid adding preference now, but would be happy to work on an update or =
extension in the future if we find that we need it.

At 10:39 AM +0100 3/13/16, Gunnar Hellstr=F6m wrote:

Randall,
Den 2016-03-12 kl. 23:53, skrev Randall =
Gellens:
Hi Gunnar =
and everyone,

In the interest of keeping =
the draft as simple as possible for the initial version, I do not think =
we need to add the absolute level of preference that you suggest.
And I think the draft will not be sufficiently =
usable without a mechanism to indicate absolute preference in a way so =
that the preference between languages and modalities in different media =
is indicated.
For example I prefer to talk and hear spoken =
English in audio, but can accept to type and read English text.
or another example:
I prefer to talk and hear =
spoken French in audio but can accept to sign and see French sign =
language in video.

Without a way to make =
the distinction, we give no clue to the other party on why language is =
indicated in more than one media. Are all desired or not?
And if you cannot indicate an option with lower preference =
then you may lose calls or get relay services invoked when they are not =
needed, wasting resources and making the calls less direct and less =
personal.

We could probably do with just =
two levels of preference: Preferred and possible.
While =
searching in https://tools.ietf.org/html/draft-ietf-slim-negotiating-human-l=
anguage-00
for a possiblity to include that in the =
syntax without increasing complexity, I saw the Advisory vs Required =
indication by an asterisk in section 6.3.
I do not expect =
that indication to be of much value,  so I intended to propose to =
change its use to be a priority indicator. But it seems too tightly =
coupled to the use in language-matching in RFC 2616, so I abstain from =
proposing that and instead with hesitation propose that we include the =
q=3D factor notation from RFC 2616 for indicating preference.

I suggest a change in section 6.2:

-------------------------------------current =
text in 6.2-------------------------------------------------

      a=3Dhumintlang-send:<lan=
guage tag>
      a=3Dhumintlang-recv:<lan=
guage tag>

   Each can =
appear multiple times in an offer for a media stream.

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



-------------------------------------proposed changed text in =
6.2----------------------------------

      a=3Dhumintlang-send:<lan=
guage tag>[ ";" "q" "=3D" qvalue ]

      a=3Dhumintlang-recv:<lan=
guage tag>[ ";" "q" "=3D" qvalue ]


   Each can appear multiple times in an offer =
for a media stream.

   In an =
offer the 'humintlang-send' values constitute a list of the languages =
the
   offerer wishes to send using the =
media, and the 'humintlang-recv'
   values =
constitute a list of the languages the
   offerer wishes to receive using the media. =
The q-values represent a preference level
   for using the indicated language and =
modality relative to all other languages and
   modalities indicated for the same direction =
in the whole SDP.
   The quality value =
defaults to "q=3D1" and has the same syntax and usage rules as for =
'Accept-Language' in RFC 2616 [RFC2616].

   If more than one language is specified for =
the same media and direction with the same q-value,
   they SHALL be listed in preference =
order.

---------------------------------End =
of change proposal.---------------------------------------------




At 10:41 AM +0100 3/12/16, =
Gunnar Hellstr=F6m wrote:

 Natasha and all,

 The use case collection looks good.
 The reasoning about implementability need a description =
about what version of the negotiating-human-language draft it refers to. =
We hope to improve, so we get "possible" on nearly all cases.

 It is time to act on the conclusions of =
the use cases.

 My suggestion:
 Add in the negotiating-human-language draft the =
following:

 1. A coding for absolute =
level of preference for a modality-language combination in three levels: =
preferred, can-do, last-resort. Shall we explicit using words, or =
cryptic, using * and other special characters?
Changed to q-value above

 2. A clear interpreting rule, saying =
that for needs of two modalities, one in each direction, the directional =
attributes together with absolute coding of preference shall be used, =
including some default rule for when no absolute coding is provided.
What is said for dual modalities in =
6.2 just below the change proposal above may be sufficient.


 3. A description of =
offer-answer handling rules, making it very clear if the attributes in =
the answer indicate capabilities and preferences from the point of view =
of the party sending the SDP, or from the point of view of the offering =
party.
 The first case would mean that "I want to =
talk English" and "I want to read English text" shall be answered with =
"I want to listen to spoken English" and "I will type English" to get a =
match , The second case would mean that "I want to talk English" and "I =
want to read English text" would be answered with "I accept that you =
talk English" and "I accept that you will read English text" thus =
sending attributes as if coded from the offering party to get a =
match.
 The first case is more evident for the user, =
while the second case is easier to parse and check for a match.
In 6.2 we have the rule that both =
the offeror and the answering party indicate values from their own point =
of view. I think that is doable.

 4. =
A conclusion that need for speech-to-speech relay services is out of =
scope and need to be solved by other indications. Do anyone have ideas =
for such indications? Call-Info with purpose and URI to a suitable =
service? Make a REFER to bring in the service? Call with a URI-list? ( =
Yes, it is out of scope, but I am interested to have an agreed best =
practice solutions for it.)
We =
take that separately and concentrate on the preference scope to cover =
all modalities here.

/Gunnar

 Regards

 Gunnar


 Den 2016-03-11 kl. 17:28, skrev Natasha Rooney:

 Hi =
all!

 IETF95 Deadline
 Just a quick reminder that the IETF95 document =
submission deadline is coming up fast (March 21st). I am going to submit =
the use cases draft before then with the use cases I have collected from =
the last meeting. If you want to see what we have so far then see the =
link below (excuse the xml):


<https://github.com/ietf-slim-wg/slim-use-cases/blob/master/draf=
t-ietf-slim-use-cases-latest.xml>https://github.com/ietf-slim-wg/slim-use-cases/blob/master/draf=
t-ietf-slim-use-cases-latest.xml 

 Our Document Status
 With regards to =
our two other documents, I believe the only issue we have is regarding =
the dual modality use case, and the difficulty of dealing with this =
within real-time communications (this obviously only applies to =
draft-ietf-slim-negotiating-human-language-00). My question to you all =
is: do you have any other outstanding issues with either draft? If not, =
we should be in a state to clean them up and publish.

 Bernard and I are having a chairs chat next week so we =
can discuss plans for IETF95 and the document status, so please let us =
know before the end of Tuesday next week as to whether you have any =
issues you wish to raise.

 Thanks =
everyone!


 Natasha


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

 On =
Mar 2, 2016, at 4:37 PM, Natasha Rooney <<mailto:nrooney@gsma.com>nrooney@gsma.com> =
wrote:

 Hi all!

 We are 1 month and 1 day away from the start of IETF95! =
Gasp! We have some work to get on with before IETF95, where we will have =
a very short (and hopefully fruitful meeting!) discussing the last =
issues we have remaining.

 The IETF95 =
link is below for those of you who still need to book hotels:


<https://ietf.org/meeting/95/index.html>https://ietf.org/meeting/95/index.html 

 I am going to be working on finishing the use cases =
document from now until IETF95. Please submit any issues or pull =
requests to the github repo or tell me directly:


<https://github.com/ietf-slim-wg/slim-use-cases/>https://github.com/ietf-slim-wg/slim-use-cases/ 

 With our other two documents I believe the modality =
issues is still at large. Can someone catch me up on the last =
discussions here? I remember that we were still discussing it and no =
decisions had been made - is this correct? On discussions with other =
IETF attendees many said that dual modality - whilst supported by use =
cases - is awfully difficult to implement, is this the same as the =
thoughts within this group?


<https://datatracker.ietf.org/wg/slim/documents/>https://datatracker.ietf.org/wg/slim/documents/ 

 Thanks all!

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


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

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


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


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



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


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



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



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

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



-- 
-----------------------------------------
Gunnar Hellstr=F6mOmnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288

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

=

--Apple-Mail=_D8E1F4B5-CAF0-4FA7-B93A-E4D6EC4C0E8D--


From nobody Wed Mar 16 11:52:36 2016
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54E3112DAA7 for ; Wed, 16 Mar 2016 11:52:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pYC3lGTWo9kP for ; Wed, 16 Mar 2016 11:52:30 -0700 (PDT)
Received: from bin-vsp-out-03.atm.binero.net (bin-mail-out-06.binero.net [195.74.38.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFFD112D59D for ; Wed, 16 Mar 2016 11:52:29 -0700 (PDT)
X-Halon-ID: 3538aded-eba8-11e5-be2d-0050569116f7
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.1.95] (unknown [109.25.254.61]) by bin-vsp-out-03.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Wed, 16 Mar 2016 19:52:17 +0100 (CET)
To: Brian Rosen 
References: <076290F0-048C-49F4-8BF5-760109F75240@gsma.com>  <56E3E464.2040900@omnitor.se>  <56E53534.6090208@omnitor.se>  <56E898C9.8070100@omnitor.se> 
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: <56E9AB61.2080505@omnitor.se>
Date: Wed, 16 Mar 2016 19:52:17 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------070603070807080908070408"
Archived-At: 
Cc: slim@ietf.org, Randall Gellens 
Subject: Re: [Slim] IETF95, Use Cases doc, and others
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
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, 16 Mar 2016 18:52:35 -0000

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

Den 2016-03-16 kl. 19:38, skrev Brian Rosen:
> I really don’t think that the complexity this introduces is worth the 
> benefit, and I would prefer not to include it.  I also don’t think it 
> works.  You want a grouping of media and language, with a preference 
> on the grouping, not a simple priority on language.
SDP groupings would introduce even more complexity and we would not see 
any implementations.

What we need is a grouping rule saying that if a language and modality 
is indicated for one direction and a certain level of preference, then 
it shall be regarded to be preferred to be used together with a language 
and modality in the other direction with the same level of preference.

It will be easy to parse for matches according to that rule.

Are there any suggestions for preference coding other than q=  ?

Gunnar
>
> Brian
>
>> On Mar 15, 2016, at 7:20 PM, Gunnar Hellström 
>> > wrote:
>>
>> Hi Randall,
>>
>> Den 2016-03-15 kl. 02:15, skrev Randall Gellens:
>>> Hi Gunnar,
>>>
>>> I think adding q= factor is much more complexity than is needed, and 
>>> I remain unconvinced that we must have a preference indication at 
>>> the start. I don't see that use cases are impossible without it.  It 
>>> seems to me that the only difference it makes is to skip 
>>> establishing some requested media streams if others are established. 
>>>  I suspect that in most cases, the ones that could be skipped would 
>>> be the easier ones (without relay/interpretation services).  Having 
>>> an extra text or audio stream that is not used is not a big deal.
>> I agree that adding the q-factor was not what I originally thought of 
>> as the solution.  But since I realised that we could not reuse the * 
>> -mark of the less-needed indication of Advisory vs required for this 
>> purpose I thought it was best to reuse another already existing 
>> coding. You are welcome to propose another alternative.
>> Because we need a preference indication that is independent of media. 
>> I have called it "absolute preference", but that might not be the 
>> best words. It can be solved with a relative preference. The 
>> important thing is that it is about preference regardless of media
>> You have specified one preference order within each media, but that 
>> is not sufficient.
>> It is essential to be able to specify e.g. "I prefer to speak but can 
>> accept to type".
>> And to indicate what modality/language combination is your favourite 
>> among possible combinations.
>>
>> And it is not primarily about establishing media streams, it is about 
>> connecting the right persons and services to the call and have an 
>> indication in what modality and language to handle the call.
>>
>> With the long turn-around-times in IETF I absolutely do not want to 
>> wait one generation before we satisfy this need.
>>
>> Can we accept the q-factor or invent something new, e.g.  "; hi" for 
>> the highest preferred ones.
>>
>> I think we have reduced complexity a lot anyway so that this one 
>> could stay.
>>
>> Regards,
>> Gunnar
>>
>>>
>>> If we keep the draft very simple to start with, then after we have 
>>> some deployment experience, we can create a revision or an extension 
>>> that adds the features that we found we need, in the way we found we 
>>> need them.  In my experience, this is a better approach than trying 
>>> to think of all aspects of the solution at the start, since doing so 
>>> inevitably adds complexity and adds features in ways that turn out 
>>> to not be ideal.
>>>
>>> So, I would like to avoid adding preference now, but would be happy 
>>> to work on an update or extension in the future if we find that we 
>>> need it.
>>>
>>> At 10:39 AM +0100 3/13/16, Gunnar Hellström wrote:
>>>
>>>> Randall,
>>>>
>>>> Den 2016-03-12 kl. 23:53, skrev Randall Gellens:
>>>>> Hi Gunnar and everyone,
>>>>>
>>>>> In the interest of keeping the draft as simple as possible for the 
>>>>> initial version, I do not think we need to add the absolute level 
>>>>> of preference that you suggest.
>>>> And I think the draft will not be sufficiently usable without a 
>>>> mechanism to indicate absolute preference in a way so that the 
>>>> preference between languages and modalities in different media is 
>>>> indicated.
>>>> For example I prefer to talk and hear spoken English in audio, but 
>>>> can accept to type and read English text.
>>>> or another example:
>>>> I prefer to talk and hear spoken French in audio but can accept to 
>>>> sign and see French sign language in video.
>>>>
>>>> Without a way to make the distinction, we give no clue to the other 
>>>> party on why language is indicated in more than one media. Are all 
>>>> desired or not?
>>>> And if you cannot indicate an option with lower preference then you 
>>>> may lose calls or get relay services invoked when they are not 
>>>> needed, wasting resources and making the calls less direct and less 
>>>> personal.
>>>>
>>>> We could probably do with just two levels of preference: Preferred 
>>>> and possible.
>>>> While searching in 
>>>> https://tools.ietf.org/html/draft-ietf-slim-negotiating-human-language-00
>>>> for a possiblity to include that in the syntax without increasing 
>>>> complexity, I saw the Advisory vs Required indication by an 
>>>> asterisk in section 6.3.
>>>> I do not expect that indication to be of much value,  so I intended 
>>>> to propose to change its use to be a priority indicator. But it 
>>>> seems too tightly coupled to the use in language-matching in RFC 
>>>> 2616, so I abstain from proposing that and instead with hesitation 
>>>> propose that we include the q= factor notation from RFC 2616 for 
>>>> indicating preference.
>>>>
>>>> I suggest a change in section 6.2:
>>>>
>>>> -------------------------------------current text in 
>>>> 6.2-------------------------------------------------
>>>>
>>>>       a=humintlang-send:
>>>>       a=humintlang-recv:
>>>>
>>>>    Each can appear multiple times in an offer for a media stream.
>>>>
>>>>    In an offer, the 'humintlang-send' values constitute a list in
>>>>    preference order (first is most preferred) of the languages the
>>>>    offerer wishes to send using the media, and the 'humintlang-recv'
>>>>    values constitute a list in preference order of the languages the
>>>>    offerer wishes to receive using the media.
>>>>
>>>>
>>>>
>>>> -------------------------------------proposed changed text in 
>>>> 6.2----------------------------------
>>>>
>>>>       a=humintlang-send:[ ";" "q" "=" qvalue ]
>>>>
>>>>       a=humintlang-recv:[ ";" "q" "=" qvalue ]
>>>>
>>>>
>>>>    Each can appear multiple times in an offer for a media stream.
>>>>
>>>>    In an offer the 'humintlang-send' values constitute a list of 
>>>> the languages the
>>>>    offerer wishes to send using the media, and the 'humintlang-recv'
>>>>    values constitute a list of the languages the
>>>>    offerer wishes to receive using the media. The q-values 
>>>> represent a preference level
>>>>    for using the indicated language and modality relative to all 
>>>> other languages and
>>>>    modalities indicated for the same direction in the whole SDP.
>>>>    The quality value defaults to "q=1" and has the same syntax and 
>>>> usage rules as for 'Accept-Language' in RFC 2616 [RFC2616].
>>>>
>>>>    If more than one language is specified for the same media and 
>>>> direction with the same q-value,
>>>>    they SHALL be listed in preference order.
>>>>
>>>> ---------------------------------End of change 
>>>> proposal.---------------------------------------------
>>>>
>>>>
>>>>
>>>>>
>>>>> At 10:41 AM +0100 3/12/16, Gunnar Hellström wrote:
>>>>>
>>>>>>  Natasha and all,
>>>>>>
>>>>>>  The use case collection looks good.
>>>>>>  The reasoning about implementability need a description about 
>>>>>> what version of the negotiating-human-language draft it refers 
>>>>>> to. We hope to improve, so we get "possible" on nearly all cases.
>>>>>>
>>>>>>  It is time to act on the conclusions of the use cases.
>>>>>>
>>>>>>  My suggestion:
>>>>>>  Add in the negotiating-human-language draft the following:
>>>>>>
>>>>>>  1. A coding for absolute level of preference for a 
>>>>>> modality-language combination in three levels: preferred, can-do, 
>>>>>> last-resort. Shall we explicit using words, or cryptic, using * 
>>>>>> and other special characters?
>>>> Changed to q-value above
>>>>>>
>>>>>>  2. A clear interpreting rule, saying that for needs of two 
>>>>>> modalities, one in each direction, the directional attributes 
>>>>>> together with absolute coding of preference shall be used, 
>>>>>> including some default rule for when no absolute coding is provided.
>>>> What is said for dual modalities in 6.2 just below the change 
>>>> proposal above may be sufficient.
>>>>>>
>>>>>>
>>>>>>  3. A description of offer-answer handling rules, making it very 
>>>>>> clear if the attributes in the answer indicate capabilities and 
>>>>>> preferences from the point of view of the party sending the SDP, 
>>>>>> or from the point of view of the offering party.
>>>>>>  The first case would mean that "I want to talk English" and "I 
>>>>>> want to read English text" shall be answered with "I want to 
>>>>>> listen to spoken English" and "I will type English" to get a 
>>>>>> match , The second case would mean that "I want to talk English" 
>>>>>> and "I want to read English text" would be answered with "I 
>>>>>> accept that you talk English" and "I accept that you will read 
>>>>>> English text" thus sending attributes as if coded from the 
>>>>>> offering party to get a match.
>>>>>>  The first case is more evident for the user, while the second 
>>>>>> case is easier to parse and check for a match.
>>>> In 6.2 we have the rule that both the offeror and the answering 
>>>> party indicate values from their own point of view. I think that is 
>>>> doable.
>>>>>>
>>>>>>  4. A conclusion that need for speech-to-speech relay services is 
>>>>>> out of scope and need to be solved by other indications. Do 
>>>>>> anyone have ideas for such indications? Call-Info with purpose 
>>>>>> and URI to a suitable service? Make a REFER to bring in the 
>>>>>> service? Call with a URI-list? ( Yes, it is out of scope, but I 
>>>>>> am interested to have an agreed best practice solutions for it.)
>>>> We take that separately and concentrate on the preference scope to 
>>>> cover all modalities here.
>>>>
>>>> /Gunnar
>>>>>>
>>>>>>  Regards
>>>>>>
>>>>>>  Gunnar
>>>>>>
>>>>>>
>>>>>>  Den 2016-03-11 kl. 17:28, skrev Natasha Rooney:
>>>>>>
>>>>>>>  Hi all!
>>>>>>>
>>>>>>>  IETF95 Deadline
>>>>>>>  Just a quick reminder that the IETF95 document submission 
>>>>>>> deadline is coming up fast (March 21st). I am going to submit 
>>>>>>> the use cases draft before then with the use cases I have 
>>>>>>> collected from the last meeting. If you want to see what we have 
>>>>>>> so far then see the link below (excuse the xml):
>>>>>>>
>>>>>>>
>>>>>>> https://github.com/ietf-slim-wg/slim-use-cases/blob/master/draft-ietf-slim-use-cases-latest.xml
>>>>>>>
>>>>>>>  Our Document Status
>>>>>>>  With regards to our two other documents, I believe the only 
>>>>>>> issue we have is regarding the dual modality use case, and the 
>>>>>>> difficulty of dealing with this within real-time communications 
>>>>>>> (this obviously only applies to 
>>>>>>> draft-ietf-slim-negotiating-human-language-00). My question to 
>>>>>>> you all is: do you have any other outstanding issues with either 
>>>>>>> draft? If not, we should be in a state to clean them up and publish.
>>>>>>>
>>>>>>>  Bernard and I are having a chairs chat next week so we can 
>>>>>>> discuss plans for IETF95 and the document status, so please let 
>>>>>>> us know before the end of Tuesday next week as to whether you 
>>>>>>> have any issues you wish to raise.
>>>>>>>
>>>>>>>  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 
>>>>>>> 
>>>>>>>
>>>>>>>>  On Mar 2, 2016, at 4:37 PM, Natasha Rooney 
>>>>>>>> <nrooney@gsma.com 
>>>>>>>> > wrote:
>>>>>>>>
>>>>>>>>  Hi all!
>>>>>>>>
>>>>>>>>  We are 1 month and 1 day away from the start of IETF95! Gasp! 
>>>>>>>> We have some work to get on with before IETF95, where we will 
>>>>>>>> have a very short (and hopefully fruitful meeting!) discussing 
>>>>>>>> the last issues we have remaining.
>>>>>>>>
>>>>>>>>  The IETF95 link is below for those of you who still need to 
>>>>>>>> book hotels:
>>>>>>>>
>>>>>>>>
>>>>>>>> https://ietf.org/meeting/95/index.html
>>>>>>>>
>>>>>>>>  I am going to be working on finishing the use cases document 
>>>>>>>> from now until IETF95. Please submit any issues or pull 
>>>>>>>> requests to the github repo or tell me directly:
>>>>>>>>
>>>>>>>>
>>>>>>>> https://github.com/ietf-slim-wg/slim-use-cases/
>>>>>>>>
>>>>>>>>  With our other two documents I believe the modality issues is 
>>>>>>>> still at large. Can someone catch me up on the last discussions 
>>>>>>>> here? I remember that we were still discussing it and no 
>>>>>>>> decisions had been made - is this correct? On discussions with 
>>>>>>>> other IETF attendees many said that dual modality - whilst 
>>>>>>>> supported by use cases - is awfully difficult to implement, is 
>>>>>>>> this the same as the thoughts within this group?
>>>>>>>>
>>>>>>>>
>>>>>>>> https://datatracker.ietf.org/wg/slim/documents/
>>>>>>>>
>>>>>>>>  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 
>>>>>>>> 
>>>>>>>>
>>>>>>>>
>>>>>>>>  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
>>>>>>>>
>>>>>>>
>>>>>>>  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
>>>>>>>
>>>>>>
>>>>>>
>>>>>>  _______________________________________________
>>>>>>  SLIM mailing list
>>>>>> SLIM@ietf.org 
>>>>>> https://www.ietf.org/mailman/listinfo/slim
>>>>>
>>>>>
>>>>
>>>> --
>>>> -----------------------------------------
>>>> Gunnar Hellström
>>>> Omnitor
>>>> gunnar.hellstrom@omnitor.se 
>>>> +46 708 204 288
>>>>
>>>> _______________________________________________
>>>> SLIM mailing list
>>>> SLIM@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/slim
>>>
>>>
>>
>> --
>> -----------------------------------------
>> Gunnar Hellström
>> Omnitor
>> gunnar.hellstrom@omnitor.se 
>> +46 708 204 288
>>
>> _______________________________________________
>> SLIM mailing list
>> SLIM@ietf.org 
>> https://www.ietf.org/mailman/listinfo/slim
>

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


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


  
    
  
  
    Den 2016-03-16 kl. 19:38, skrev Brian Rosen:

    

      
      I really don’t think that the complexity this introduces is worth
      the benefit, and I would prefer not to include it.  I also don’t
      think it works.  You want a grouping of media and language, with a
      preference on the grouping, not a simple priority on language.

    SDP groupings would introduce even more complexity and we would not
    see any implementations.

    

    What we need is a grouping rule saying that if a language and
    modality is indicated for one direction and a certain level of
    preference, then it shall be regarded to be preferred to be used
    together with a language and modality in the other direction with
    the same level of preference. 

    

    It will be easy to parse for matches according to that rule.

    

    Are there any suggestions for preference coding other than q=  ?

    

    Gunnar

    

      


      

      
Brian

      


        

          

            
On Mar 15, 2016, at 7:20 PM, Gunnar Hellström
              <gunnar.hellstrom@omnitor.se>
              wrote:

            

            
Hi
                Randall,

              

              Den 2016-03-15 kl.
                02:15, skrev Randall Gellens:

              
Hi Gunnar,

                

                I think adding q= factor is much more complexity than is
                needed, and I remain unconvinced that we must have a
                preference indication at the start. I don't see that use
                cases are impossible without it.  It seems to me that
                the only difference it makes is to skip establishing
                some requested media streams if others are established.
                 I suspect that in most cases, the ones that could be
                skipped would be the easier ones (without
                relay/interpretation services).  Having an extra text or
                audio stream that is not used is not a big deal.

              

              I agree that
                adding the q-factor was not what I originally thought of
                as the solution.  But since I realised that we could not
                reuse the * -mark of the less-needed indication of
                Advisory vs required for this purpose I thought it was
                best to reuse another already existing coding. You are
                welcome to propose another alternative.

              Because we need a
                preference indication that is independent of media. I
                have called it "absolute preference", but that might not
                be the best words. It can be solved with a relative
                preference. The important thing is that it is about
                preference regardless of media

              You have specified
                one preference order within each media, but that is not
                sufficient.

              It is essential to
                be able to specify e.g. "I prefer to speak but can
                accept to type".

              And to indicate
                what modality/language combination is your favourite
                among possible combinations.

              

              And it is not
                primarily about establishing media streams, it is about
                connecting the right persons and services to the call
                and have an indication in what modality and language to
                handle the call.

              

              With the long
                turn-around-times in IETF I absolutely do not want to
                wait one generation before we satisfy this need.

              

              Can we accept the
                q-factor or invent something new, e.g.  "; hi" for the
                highest preferred ones.

              

              I think we have
                reduced complexity a lot anyway so that this one could
                stay.

              

              Regards,

              Gunnar

              

              


                If we keep the draft very simple to start with, then
                after we have some deployment experience, we can create
                a revision or an extension that adds the features that
                we found we need, in the way we found we need them.  In
                my experience, this is a better approach than trying to
                think of all aspects of the solution at the start, since
                doing so inevitably adds complexity and adds features in
                ways that turn out to not be ideal.

                

                So, I would like to avoid adding preference now, but
                would be happy to work on an update or extension in the
                future if we find that we need it.

                

                At 10:39 AM +0100 3/13/16, Gunnar Hellström wrote:

                

                
Randall,

                  

                  Den 2016-03-12 kl. 23:53, skrev Randall Gellens:

                  
Hi Gunnar and
                    everyone,

                    

                    In the interest of keeping the draft as simple as
                    possible for the initial version, I do not think we
                    need to add the absolute level of preference that
                    you suggest.

                  

                  And I think the draft will not be sufficiently usable
                  without a mechanism to indicate absolute preference in
                  a way so that the preference between languages and
                  modalities in different media is indicated.

                  For example I prefer to talk and hear spoken English
                  in audio, but can accept to type and read English
                  text.

                  or another example:

                  I prefer to talk and hear spoken French in audio but
                  can accept to sign and see French sign language in
                  video.

                  

                  Without a way to make the distinction, we give no clue
                  to the other party on why language is indicated in
                  more than one media. Are all desired or not?

                  And if you cannot indicate an option with lower
                  preference then you may lose calls or get relay
                  services invoked when they are not needed, wasting
                  resources and making the calls less direct and less
                  personal.

                  

                  We could probably do with just two levels of
                  preference: Preferred and possible.

                  While searching in https://tools.ietf.org/html/draft-ietf-slim-negotiating-human-language-00

                  for a possiblity to include that in the syntax without
                  increasing complexity, I saw the Advisory vs Required
                  indication by an asterisk in section 6.3.

                  I do not expect that indication to be of much value,
                   so I intended to propose to change its use to be a
                  priority indicator. But it seems too tightly coupled
                  to the use in language-matching in RFC 2616, so I
                  abstain from proposing that and instead with
                  hesitation propose that we include the q= factor
                  notation from RFC 2616 for indicating preference.

                  

                  I suggest a change in section 6.2:

                  

                  -------------------------------------current text in
                  6.2-------------------------------------------------

                  

                        a=humintlang-send:<language tag>

                        a=humintlang-recv:<language tag>

                  

                     Each can appear multiple times in an offer for a
                  media stream.

                  

                     In an offer, the 'humintlang-send' values
                  constitute a list in

                     preference order (first is most preferred) of the
                  languages the

                     offerer wishes to send using the media, and the
                  'humintlang-recv'

                     values constitute a list in preference order of the
                  languages the

                     offerer wishes to receive using the media.

                  

                  

                  

                  -------------------------------------proposed changed
                  text in 6.2----------------------------------

                  

                        a=humintlang-send:<language tag>[ ";" "q"
                  "=" qvalue ]

                  

                        a=humintlang-recv:<language tag>[ ";" "q"
                  "=" qvalue ]

                  

                  

                     Each can appear multiple times in an offer for a
                  media stream.

                  

                     In an offer the 'humintlang-send' values constitute
                  a list of the languages the

                     offerer wishes to send using the media, and the
                  'humintlang-recv'

                     values constitute a list of the languages the

                     offerer wishes to receive using the media. The
                  q-values represent a preference level

                     for using the indicated language and modality
                  relative to all other languages and

                     modalities indicated for the same direction in the
                  whole SDP.

                     The quality value defaults to "q=1" and has the
                  same syntax and usage rules as for 'Accept-Language'
                  in RFC 2616 [RFC2616].

                  

                     If more than one language is specified for the same
                  media and direction with the same q-value,

                     they SHALL be listed in preference order.

                  

                  ---------------------------------End of change
                  proposal.---------------------------------------------

                  

                  

                  

                  


                    At 10:41 AM +0100 3/12/16, Gunnar Hellström wrote:

                    

                    
 Natasha and all,

                      

                       The use case collection looks good.

                       The reasoning about implementability need a
                      description about what version of the
                      negotiating-human-language draft it refers to. We
                      hope to improve, so we get "possible" on nearly
                      all cases.

                      

                       It is time to act on the conclusions of the use
                      cases.

                      

                       My suggestion:

                       Add in the negotiating-human-language draft the
                      following:

                      

                       1. A coding for absolute level of preference for
                      a modality-language combination in three levels:
                      preferred, can-do, last-resort. Shall we explicit
                      using words, or cryptic, using * and other special
                      characters?

                    

                  

                  Changed to q-value above

                  

                    


                       2. A clear interpreting rule, saying that for
                      needs of two modalities, one in each direction,
                      the directional attributes together with absolute
                      coding of preference shall be used, including some
                      default rule for when no absolute coding is
                      provided.

                    

                  

                  What is said for dual modalities in 6.2 just below the
                  change proposal above may be sufficient.

                  

                    


                      

                       3. A description of offer-answer handling rules,
                      making it very clear if the attributes in the
                      answer indicate capabilities and preferences from
                      the point of view of the party sending the SDP, or
                      from the point of view of the offering party.

                       The first case would mean that "I want to talk
                      English" and "I want to read English text" shall
                      be answered with "I want to listen to spoken
                      English" and "I will type English" to get a match
                      , The second case would mean that "I want to talk
                      English" and "I want to read English text" would
                      be answered with "I accept that you talk English"
                      and "I accept that you will read English text"
                      thus sending attributes as if coded from the
                      offering party to get a match.

                       The first case is more evident for the user,
                      while the second case is easier to parse and check
                      for a match.

                    

                  

                  In 6.2 we have the rule that both the offeror and the
                  answering party indicate values from their own point
                  of view. I think that is doable.

                  

                    


                       4. A conclusion that need for speech-to-speech
                      relay services is out of scope and need to be
                      solved by other indications. Do anyone have ideas
                      for such indications? Call-Info with purpose and
                      URI to a suitable service? Make a REFER to bring
                      in the service? Call with a URI-list? ( Yes, it is
                      out of scope, but I am interested to have an
                      agreed best practice solutions for it.)

                    

                  

                  We take that separately and concentrate on the
                  preference scope to cover all modalities here.

                  

                  /Gunnar

                  

                    


                       Regards

                      

                       Gunnar

                      

                      

                       Den 2016-03-11 kl. 17:28, skrev Natasha Rooney:

                      

                      
 Hi all!

                        

                         IETF95 Deadline

                         Just a quick reminder that the IETF95 document
                        submission deadline is coming up fast (March
                        21st). I am going to submit the use cases draft
                        before then with the use cases I have collected
                        from the last meeting. If you want to see what
                        we have so far then see the link below (excuse
                        the xml):

                        

                        

                        <https://github.com/ietf-slim-wg/slim-use-cases/blob/master/draft-ietf-slim-use-cases-latest.xml>https://github.com/ietf-slim-wg/slim-use-cases/blob/master/draft-ietf-slim-use-cases-latest.xml 

                        

                         Our Document Status

                         With regards to our two other documents, I
                        believe the only issue we have is regarding the
                        dual modality use case, and the difficulty of
                        dealing with this within real-time
                        communications (this obviously only applies to
                        draft-ietf-slim-negotiating-human-language-00).
                        My question to you all is: do you have any other
                        outstanding issues with either draft? If not, we
                        should be in a state to clean them up and
                        publish.

                        

                         Bernard and I are having a chairs chat next
                        week so we can discuss plans for IETF95 and the
                        document status, so please let us know before
                        the end of Tuesday next week as to whether you
                        have any issues you wish to raise.

                        

                         Thanks everyone!

                        

                        

                         Natasha

                        

                        

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

                        

                        
 On Mar 2,
                          2016, at 4:37 PM, Natasha Rooney <<mailto:nrooney@gsma.com>nrooney@gsma.com>
                          wrote:

                          

                           Hi all!

                          

                           We are 1 month and 1 day away from the start
                          of IETF95! Gasp! We have some work to get on
                          with before IETF95, where we will have a very
                          short (and hopefully fruitful meeting!)
                          discussing the last issues we have remaining.

                          

                           The IETF95 link is below for those of you who
                          still need to book hotels:

                          

                          

                          <https://ietf.org/meeting/95/index.html>https://ietf.org/meeting/95/index.html 

                          

                           I am going to be working on finishing the use
                          cases document from now until IETF95. Please
                          submit any issues or pull requests to the
                          github repo or tell me directly:

                          

                          

                          <https://github.com/ietf-slim-wg/slim-use-cases/>https://github.com/ietf-slim-wg/slim-use-cases/ 

                          

                           With our other two documents I believe the
                          modality issues is still at large. Can someone
                          catch me up on the last discussions here? I
                          remember that we were still discussing it and
                          no decisions had been made - is this correct?
                          On discussions with other IETF attendees many
                          said that dual modality - whilst supported by
                          use cases - is awfully difficult to implement,
                          is this the same as the thoughts within this
                          group?

                          

                          

                          <https://datatracker.ietf.org/wg/slim/documents/>https://datatracker.ietf.org/wg/slim/documents/ 

                          

                           Thanks all!

                          

                           Natasha

                          

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

                          

                          

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

                          

 _______________________________________________

                           SLIM mailing list

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

                          

                          

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

                          

                        

                        

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

                        

                        

                        

                         _______________________________________________

                         SLIM mailing list

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

                        

                        

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

                        

                      

                      

                      

                       _______________________________________________

                       SLIM mailing list

                      SLIM@ietf.org

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

                    

                    

                    

                  

                  

                  --

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

                  Gunnar Hellström

                  Omnitor

                  gunnar.hellstrom@omnitor.se

                  +46 708 204 288

                  

                  _______________________________________________

                  SLIM mailing list

                  SLIM@ietf.org

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

                

                

                

              

              

              -- 

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

              Gunnar Hellström

              Omnitor

              gunnar.hellstrom@omnitor.se

              +46 708 204 288

              

              _______________________________________________

              SLIM mailing list

              SLIM@ietf.org

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

          

        

        

      

    

    

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

  


--------------070603070807080908070408--


From nobody Wed Mar 16 11:59:38 2016
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3F0612D505 for ; Wed, 16 Mar 2016 11:59:36 -0700 (PDT)
X-Quarantine-ID: 
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q1iO-_x05JYT for ; Wed, 16 Mar 2016 11:59:33 -0700 (PDT)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id E99D912D5EE for ; Wed, 16 Mar 2016 11:59:32 -0700 (PDT)
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Wed, 16 Mar 2016 11:59:32 -0700
Mime-Version: 1.0
Message-Id: 
In-Reply-To: 
References: <076290F0-048C-49F4-8BF5-760109F75240@gsma.com>  <56E3E464.2040900@omnitor.se>  <56E53534.6090208@omnitor.se>  <56E898C9.8070100@omnitor.se> 
X-Mailer: Eudora for Mac OS X
Date: Wed, 16 Mar 2016 11:59:29 -0700
To: slim@ietf.org
From: Randall Gellens 
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
Content-Transfer-Encoding: quoted-printable
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: 
Subject: Re: [Slim] IETF95, Use Cases doc, and others
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
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, 16 Mar 2016 18:59:37 -0000

Thank you, Doug and Brian, for your thoughts.

Based on the discussion, I propose that we do not=20
add an additional preference mechanism to the=20
draft.


At 2:38 PM -0400 3/16/16, Brian Rosen wrote:

>  I really don't think that the complexity this=20
> introduces is worth the benefit, and I would=20
> prefer not to include it.  I also don't think=20
> it works.  You want a grouping of media and=20
> language, with a preference on the grouping,=20
> not a simple priority on language.
>
>  Brian
>
>>  On Mar 15, 2016, at 7:20 PM, Gunnar Hellstr=F6m=20
>> <gunnar.hellstrom@omnitor.se>=20
>> wrote:
>>
>>  Hi Randall,
>>
>>  Den 2016-03-15 kl. 02:15, skrev Randall Gellens:
>>
>>>  Hi Gunnar,
>>>
>>>  I think adding q=3D factor is much more=20
>>> complexity than is needed, and I remain=20
>>> unconvinced that we must have a preference=20
>>> indication at the start. I don't see that use=20
>>> cases are impossible without it.  It seems to=20
>>> me that the only difference it makes is to=20
>>> skip establishing some requested media=20
>>> streams if others are established.  I suspect=20
>>> that in most cases, the ones that could be=20
>>> skipped would be the easier ones (without=20
>>> relay/interpretation services).  Having an=20
>>> extra text or audio stream that is not used=20
>>> is not a big deal.
>>>
>>  I agree that adding the q-factor was not what=20
>> I originally thought of as the solution.  But=20
>> since I realised that we could not reuse the *=20
>> -mark of the less-needed indication of=20
>> Advisory vs required for this purpose I=20
>> thought it was best to reuse another already=20
>> existing coding. You are welcome to propose=20
>> another alternative.
>>  Because we need a preference indication that=20
>> is independent of media. I have called it=20
>> "absolute preference", but that might not be=20
>> the best words. It can be solved with a=20
>> relative preference. The important thing is=20
>> that it is about preference regardless of media
>>  You have specified one preference order within=20
>> each media, but that is not sufficient.
>>  It is essential to be able to specify e.g. "I=20
>> prefer to speak but can accept to type".
>>  And to indicate what modality/language=20
>> combination is your favourite among possible=20
>> combinations.
>>
>>  And it is not primarily about establishing=20
>> media streams, it is about connecting the=20
>> right persons and services to the call and=20
>> have an indication in what modality and=20
>> language to handle the call.
>>
>>  With the long turn-around-times in IETF I=20
>> absolutely do not want to wait one generation=20
>> before we satisfy this need.
>>
>>  Can we accept the q-factor or invent something=20
>> new, e.g.  "; hi" for the highest preferred=20
>> ones.
>>
>>  I think we have reduced complexity a lot anyway so that this one could s=
tay.
>>
>>  Regards,
>>  Gunnar
>>
>>>
>>>  If we keep the draft very simple to start=20
>>> with, then after we have some deployment=20
>>> experience, we can create a revision or an=20
>>> extension that adds the features that we=20
>>> found we need, in the way we found we need=20
>>> them.  In my experience, this is a better=20
>>> approach than trying to think of all aspects=20
>>> of the solution at the start, since doing so=20
>>> inevitably adds complexity and adds features=20
>>> in ways that turn out to not be ideal.
>>>
>>>  So, I would like to avoid adding preference=20
>>> now, but would be happy to work on an update=20
>>> or extension in the future if we find that we=20
>>> need it.
>>>
>>>  At 10:39 AM +0100 3/13/16, Gunnar Hellstr=F6m wrote:
>>>
>>>>  Randall,
>>>>
>>>>  Den 2016-03-12 kl. 23:53, skrev Randall Gellens:
>>>>
>>>>>  Hi Gunnar and everyone,
>>>>>
>>>>>  In the interest of keeping the draft as=20
>>>>> simple as possible for the initial version,=20
>>>>> I do not think we need to add the absolute=20
>>>>> level of preference that you suggest.
>>>>>
>>>>  And I think the draft will not be=20
>>>> sufficiently usable without a mechanism to=20
>>>> indicate absolute preference in a way so=20
>>>> that the preference between languages and=20
>>>> modalities in different media is indicated.
>>>>  For example I prefer to talk and hear spoken=20
>>>> English in audio, but can accept to type and=20
>>>> read English text.
>>>>  or another example:
>>>>  I prefer to talk and hear spoken French in=20
>>>> audio but can accept to sign and see French=20
>>>> sign language in video.
>>>>
>>>>  Without a way to make the distinction, we=20
>>>> give no clue to the other party on why=20
>>>> language is indicated in more than one=20
>>>> media. Are all desired or not?
>>>>  And if you cannot indicate an option with=20
>>>> lower preference then you may lose calls or=20
>>>> get relay services invoked when they are not=20
>>>> needed, wasting resources and making the=20
>>>> calls less direct and less personal.
>>>>
>>>>  We could probably do with just two levels of=20
>>>> preference: Preferred and possible.
>>>>  While searching in=20
>>>> https://tools.ietf.org/html/draft-ietf-slim-negotiating-human-language-0=
0
>>>>  for a possiblity to include that in the=20
>>>> syntax without increasing complexity, I saw=20
>>>> the Advisory vs Required indication by an=20
>>>> asterisk in section 6.3.
>>>>  I do not expect that indication to be of=20
>>>> much value,  so I intended to propose to=20
>>>> change its use to be a priority indicator.=20
>>>> But it seems too tightly coupled to the use=20
>>>> in language-matching in RFC 2616, so I=20
>>>> abstain from proposing that and instead with=20
>>>> hesitation propose that we include the q=3D=20
>>>> factor notation from RFC 2616 for indicating=20
>>>> preference.
>>>>
>>>>  I suggest a change in section 6.2:
>>>>
>>>>  -------------------------------------current=20
>>>> text in=20
>>>> 6.2-------------------------------------------------
>>>>
>>>>        a=3Dhumintlang-send:
>>>>        a=3Dhumintlang-recv:
>>>>
>>>>     Each can appear multiple times in an offer for a media stream.
>>>>
>>>>     In an offer, the 'humintlang-send' values constitute a list in
>>>>     preference order (first is most preferred) of the languages the
>>>>     offerer wishes to send using the media, and the 'humintlang-recv'
>>>>     values constitute a list in preference order of the languages the
>>>>     offerer wishes to receive using the media.
>>>>
>>>>
>>>>
>>>>=20
>>>> -------------------------------------proposed=20
>>>> changed text in=20
>>>> 6.2----------------------------------
>>>>
>>>>        a=3Dhumintlang-send:[ ";" "q" "=3D" qvalue ]
>>>>
>>>>        a=3Dhumintlang-recv:[ ";" "q" "=3D" qvalue ]
>>>>
>>>>
>>>>     Each can appear multiple times in an offer for a media stream.
>>>>
>>>>     In an offer the 'humintlang-send' values=20
>>>> constitute a list of the languages the
>>>>     offerer wishes to send using the media, and the 'humintlang-recv'
>>>>     values constitute a list of the languages the
>>>>     offerer wishes to receive using the=20
>>>> media. The q-values represent a preference=20
>>>> level
>>>>     for using the indicated language and=20
>>>> modality relative to all other languages and
>>>>     modalities indicated for the same direction in the whole SDP.
>>>>     The quality value defaults to "q=3D1" and=20
>>>> has the same syntax and usage rules as for=20
>>>> 'Accept-Language' in RFC 2616 [RFC2616].
>>>>
>>>>     If more than one language is specified=20
>>>> for the same media and direction with the=20
>>>> same q-value,
>>>>     they SHALL be listed in preference order.
>>>>
>>>>  ---------------------------------End of=20
>>>> change=20
>>>> proposal.---------------------------------------------
>>>>
>>>>
>>>>>
>>>>>  At 10:41 AM +0100 3/12/16, Gunnar Hellstr=F6m wrote:
>>>>>
>>>>>>   Natasha and all,
>>>>>>
>>>>>>   The use case collection looks good.
>>>>>>   The reasoning about implementability need=20
>>>>>> a description about what version of the=20
>>>>>> negotiating-human-language draft it refers=20
>>>>>> to. We hope to improve, so we get=20
>>>>>> "possible" on nearly all cases.
>>>>>>
>>>>>>   It is time to act on the conclusions of the use cases.
>>>>>>
>>>>>>   My suggestion:
>>>>>>   Add in the negotiating-human-language draft the following:
>>>>>>
>>>>>>   1. A coding for absolute level of=20
>>>>>> preference for a modality-language=20
>>>>>> combination in three levels: preferred,=20
>>>>>> can-do, last-resort. Shall we explicit=20
>>>>>> using words, or cryptic, using * and other=20
>>>>>> special characters?
>>>>>>
>>>>  Changed to q-value above
>>>>
>>>>>>
>>>>>>   2. A clear interpreting rule, saying that=20
>>>>>> for needs of two modalities, one in each=20
>>>>>> direction, the directional attributes=20
>>>>>> together with absolute coding of=20
>>>>>> preference shall be used, including some=20
>>>>>> default rule for when no absolute coding=20
>>>>>> is provided.
>>>>>>
>>>>  What is said for dual modalities in 6.2 just=20
>>>> below the change proposal above may be=20
>>>> sufficient.
>>>>
>>>>>>
>>>>>>
>>>>>>   3. A description of offer-answer handling=20
>>>>>> rules, making it very clear if the=20
>>>>>> attributes in the answer indicate=20
>>>>>> capabilities and preferences from the=20
>>>>>> point of view of the party sending the=20
>>>>>> SDP, or from the point of view of the=20
>>>>>> offering party.
>>>>>>   The first case would mean that "I want to=20
>>>>>> talk English" and "I want to read English=20
>>>>>> text" shall be answered with "I want to=20
>>>>>> listen to spoken English" and "I will type=20
>>>>>> English" to get a match , The second case=20
>>>>>> would mean that "I want to talk English"=20
>>>>>> and "I want to read English text" would be=20
>>>>>> answered with "I accept that you talk=20
>>>>>> English" and "I accept that you will read=20
>>>>>> English text" thus sending attributes as=20
>>>>>> if coded from the offering party to get a=20
>>>>>> match.
>>>>>>   The first case is more evident for the=20
>>>>>> user, while the second case is easier to=20
>>>>>> parse and check for a match.
>>>>>>
>>>>  In 6.2 we have the rule that both the=20
>>>> offeror and the answering party indicate=20
>>>> values from their own point of view. I think=20
>>>> that is doable.
>>>>
>>>>>>
>>>>>>   4. A conclusion that need for=20
>>>>>> speech-to-speech relay services is out of=20
>>>>>> scope and need to be solved by other=20
>>>>>> indications. Do anyone have ideas for such=20
>>>>>> indications? Call-Info with purpose and=20
>>>>>> URI to a suitable service? Make a REFER to=20
>>>>>> bring in the service? Call with a=20
>>>>>> URI-list? ( Yes, it is out of scope, but I=20
>>>>>> am interested to have an agreed best=20
>>>>>> practice solutions for it.)
>>>>>>
>>>>  We take that separately and concentrate on=20
>>>> the preference scope to cover all modalities=20
>>>> here.
>>>>
>>>>  /Gunnar
>>>>
>>>>>>
>>>>>>   Regards
>>>>>>
>>>>>>   Gunnar
>>>>>>
>>>>>>
>>>>>>   Den 2016-03-11 kl. 17:28, skrev Natasha Rooney:
>>>>>>
>>>>>>>   Hi all!
>>>>>>>
>>>>>>>   IETF95 Deadline
>>>>>>>   Just a quick reminder that the IETF95=20
>>>>>>> document submission deadline is coming up=20
>>>>>>> fast (March 21st). I am going to submit=20
>>>>>>> the use cases draft before then with the=20
>>>>>>> use cases I have collected from the last=20
>>>>>>> meeting. If you want to see what we have=20
>>>>>>> so far then see the link below (excuse=20
>>>>>>> the xml):
>>>>>>>
>>>>>>>
>>>>>>>=20
>>>>>>> <https://github.com/ietf-slim-wg/slim-use-cases=
/blob/master/draft-ietf-slim-use-cases-latest.xml>https=
://github.com/ietf-slim-wg/slim-use-cases/blob/master/draft-ietf-slim-use-ca=
ses-latest.xml 
>>>>>>>
>>>>>>>   Our Document Status
>>>>>>>   With regards to our two other documents,=20
>>>>>>> I believe the only issue we have is=20
>>>>>>> regarding the dual modality use case, and=20
>>>>>>> the difficulty of dealing with this=20
>>>>>>> within real-time communications (this=20
>>>>>>> obviously only applies to=20
>>>>>>> draft-ietf-slim-negotiating-human-language-00).=20
>>>>>>> My question to you all is: do you have=20
>>>>>>> any other outstanding issues with either=20
>>>>>>> draft? If not, we should be in a state to=20
>>>>>>> clean them up and publish.
>>>>>>>
>>>>>>>   Bernard and I are having a chairs chat=20
>>>>>>> next week so we can discuss plans for=20
>>>>>>> IETF95 and the document status, so please=20
>>>>>>> let us know before the end of Tuesday=20
>>>>>>> next week as to whether you have any=20
>>>>>>> issues you wish to raise.
>>>>>>>
>>>>>>>   Thanks everyone!
>>>>>>>
>>>>>>>
>>>>>>>   Natasha
>>>>>>>
>>>>>>>
>>>>>>>   Natasha Rooney | Technologist, Web and=20
>>>>>>> Internet, W3C & IETF | GSMA |=20
>>>>>>> <mailto:nrooney@gsma.com>=20
>>>>>>> nrooney@gsma.com=20
>>>>>>> | +44 (0) 7730 219 765 | @thisNatasha |=20
>>>>>>> Skype:=20
>>>>>>> <mailto:nrooney@gsm.org>nrooney@gsm.org
>>>>>>>
>>>>>>>>   On Mar 2, 2016, at 4:37 PM, Natasha=20
>>>>>>>> Rooney=20
>>>>>>>> <<mailto:nrooney@gsma.com>nrooney@gsma.com>=20
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>   Hi all!
>>>>>>>>
>>>>>>>>   We are 1 month and 1 day away from the=20
>>>>>>>> start of IETF95! Gasp! We have some work=20
>>>>>>>> to get on with before IETF95, where we=20
>>>>>>>> will have a very short (and hopefully=20
>>>>>>>> fruitful meeting!) discussing the last=20
>>>>>>>> issues we have remaining.
>>>>>>>>
>>>>>>>>   The IETF95 link is below for those of=20
>>>>>>>> you who still need to book hotels:
>>>>>>>>
>>>>>>>>
>>>>>>>>=20
>>>>>>>> <https://ietf.org/meeting/9=
5/index.html>https://ietf.org/meetin=
g/95/index.html 
>>>>>>>>
>>>>>>>>   I am going to be working on finishing=20
>>>>>>>> the use cases document from now until=20
>>>>>>>> IETF95. Please submit any issues or pull=20
>>>>>>>> requests to the github repo or tell me=20
>>>>>>>> directly:
>>>>>>>>
>>>>>>>>
>>>>>>>>=20
>>>>>>>> <https://github.co=
m/ietf-slim-wg/slim-use-cases/>https://github.com/ietf-slim-wg/slim-use-cases/ 
>>>>>>>>
>>>>>>>>   With our other two documents I believe=20
>>>>>>>> the modality issues is still at large.=20
>>>>>>>> Can someone catch me up on the last=20
>>>>>>>> discussions here? I remember that we=20
>>>>>>>> were still discussing it and no=20
>>>>>>>> decisions had been made - is this=20
>>>>>>>> correct? On discussions with other IETF=20
>>>>>>>> attendees many said that dual modality -=20
>>>>>>>> whilst supported by use cases - is=20
>>>>>>>> awfully difficult to implement, is this=20
>>>>>>>> the same as the thoughts within this=20
>>>>>>>> group?
>>>>>>>>
>>>>>>>>
>>>>>>>>=20
>>>>>>>> <https://datatrack=
er.ietf.org/wg/slim/documents/>https://datatracker.ietf.org/wg/slim/documents/ 
>>>>>>>>
>>>>>>>>   Thanks all!
>>>>>>>>
>>>>>>>>   Natasha
>>>>>>>>
>>>>>>>>   Natasha Rooney | Technologist, Web and=20
>>>>>>>> Internet, W3C & IETF | GSMA |=20
>>>>>>>> <mailto:nrooney@gsma.com>=20
>>>>>>>> <mailto:nrooney@gsma.com>nrooney@gsma.com=20
>>>>>>>> | +44 (0) 7730 219 765 | @thisNatasha |=20
>>>>>>>> Skype:=20
>>>>>>>> <mailto:nrooney@gsm.org>nrooney@gsm.org
>>>>>>>>
>>>>>>>>
>>>>>>>>   This email and its attachments are=20
>>>>>>>> intended for the above named only and=20
>>>>>>>> may be confidential. If they have come=20
>>>>>>>> to you in error you must take no action=20
>>>>>>>> based on them, nor must you copy or show=20
>>>>>>>> them to anyone; please reply to this=20
>>>>>>>> email or call +44 207 356 0600 and=20
>>>>>>>> highlight the error.
>>>>>>>>
>>>>>>>>   _______________________________________________
>>>>>>>>   SLIM mailing list
>>>>>>>>=20
>>>>>>>> <mailto:SLIM@ietf.org>S=
LIM@ietf.org
>>>>>>>>
>>>>>>>>
>>>>>>>>=20
>>>>>>>> <https://www.ietf.org/m=
ailman/listinfo/slim>https://www=
=2Eietf.org/mailman/listinfo/slim 
>>>>>>>>
>>>>>>>
>>>>>>>   This email and its attachments are=20
>>>>>>> intended for the above named only and may=20
>>>>>>> be confidential. If they have come to you=20
>>>>>>> in error you must take no action based on=20
>>>>>>> them, nor must you copy or show them to=20
>>>>>>> anyone; please reply to this email or=20
>>>>>>> call +44 207 356 0600 and highlight the=20
>>>>>>> error.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>   _______________________________________________
>>>>>>>   SLIM mailing list
>>>>>>>=20
>>>>>>> <mailto:SLIM@ietf.org>SL=
IM@ietf.org
>>>>>>>
>>>>>>>
>>>>>>>=20
>>>>>>> <https://www.ietf.org/ma=
ilman/listinfo/slim>https://www.=
ietf.org/mailman/listinfo/slim 
>>>>>>>
>>>>>>
>>>>>>
>>>>>>   _______________________________________________
>>>>>>   SLIM mailing list
>>>>>>  SLIM@ietf.org
>>>>>>  https://www.ietf.org/mailman/listinfo/slim
>>>>>>
>>>>>
>>>>>
>>>>
>>>>  --
>>>>  -----------------------------------------
>>>>  Gunnar Hellstr=F6m
>>>>  Omnitor
>>>>  gunnar.hellstrom@omnitor.se
>>>>  +46 708 204 288
>>>>
>>>>  _______________________________________________
>>>>  SLIM mailing list
>>>>  SLIM@ietf.org
>>>>  https://www.ietf.org/mailman/listinfo/slim
>>>>
>>>
>>>
>>
>>  -- 
>>  -----------------------------------------
>>  Gunnar Hellstr=F6m
>>  Omnitor
>>  gunnar.hellstrom@omnitor.se
>>  +46 708 204 288
>>
>>  _______________________________________________
>>  SLIM mailing list
>>  SLIM@ietf.org
>>=20
>> https://www.ietf.org/mailman/=
listinfo/slim
>>
>
>
>  _______________________________________________
>  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: ---------------
It takes a wonderful brain and exquisite senses to produce a few
stupid ideas.                                        --Santayana


From nobody Wed Mar 16 13:02:31 2016
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4971612D6AA for ; Wed, 16 Mar 2016 13:02:30 -0700 (PDT)
X-Quarantine-ID: 
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FkkcieKYYklc for ; Wed, 16 Mar 2016 13:02:26 -0700 (PDT)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 8892512D695 for ; Wed, 16 Mar 2016 13:02:26 -0700 (PDT)
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Wed, 16 Mar 2016 13:02:25 -0700
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <56E9AB61.2080505@omnitor.se>
References: <076290F0-048C-49F4-8BF5-760109F75240@gsma.com>  <56E3E464.2040900@omnitor.se>  <56E53534.6090208@omnitor.se>  <56E898C9.8070100@omnitor.se>  <56E9AB61.2080505@omnitor.se>
X-Mailer: Eudora for Mac OS X
Date: Wed, 16 Mar 2016 13:02:22 -0700
To: Gunnar =?iso-8859-1?Q?Hellstr=F6m?=  , Brian Rosen 
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-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
Archived-At: 
Cc: slim@ietf.org
Subject: Re: [Slim] IETF95, Use Cases doc, and others
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
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, 16 Mar 2016 20:02:30 -0000

I think we can proceed without a new preference=20
mechanism.  As I see it, the worst case is we end=20
up with unused media streams.

At 7:52 PM +0100 3/16/16, Gunnar Hellstr=F6m wrote:

>  Den 2016-03-16 kl. 19:38, skrev Brian Rosen:
>
>>  I really don't think that the complexity this=20
>> introduces is worth the benefit, and I would=20
>> prefer not to include it. I also don't think=20
>> it works. You want a grouping of media and=20
>> language, with a preference on the grouping,=20
>> not a simple priority on language.
>>
>  SDP groupings would introduce even more=20
> complexity and we would not see any=20
> implementations.
>
>  What we need is a grouping rule saying that if=20
> a language and modality is indicated for one=20
> direction and a certain level of preference,=20
> then it shall be regarded to be preferred to be=20
> used together with a language and modality in=20
> the other direction with the same level of=20
> preference.
>
>  It will be easy to parse for matches according to that rule.
>
>  Are there any suggestions for preference coding other than q=3D ?
>
>  Gunnar
>
>>
>>  Brian
>>
>>>  On Mar 15, 2016, at 7:20 PM, Gunnar Hellstr=F6m=20
>>> <gunnar.hellstrom@omnitor.se>=20
>>> wrote:
>>>
>>>  Hi Randall,
>>>
>>>  Den 2016-03-15 kl. 02:15, skrev Randall Gellens:
>>>
>>>>  Hi Gunnar,
>>>>
>>>>  I think adding q=3D factor is much more=20
>>>> complexity than is needed, and I remain=20
>>>> unconvinced that we must have a preference=20
>>>> indication at the start. I don't see that=20
>>>> use cases are impossible without it. It=20
>>>> seems to me that the only difference it=20
>>>> makes is to skip establishing some requested=20
>>>> media streams if others are established. I=20
>>>> suspect that in most cases, the ones that=20
>>>> could be skipped would be the easier ones=20
>>>> (without relay/interpretation services).=20
>>>> Having an extra text or audio stream that is=20
>>>> not used is not a big deal.
>>>>
>>>  I agree that adding the q-factor was not what=20
>>> I originally thought of as the solution. But=20
>>> since I realised that we could not reuse the=20
>>> * -mark of the less-needed indication of=20
>>> Advisory vs required for this purpose I=20
>>> thought it was best to reuse another already=20
>>> existing coding. You are welcome to propose=20
>>> another alternative.
>>>  Because we need a preference indication that=20
>>> is independent of media. I have called it=20
>>> "absolute preference", but that might not be=20
>>> the best words. It can be solved with a=20
>>> relative preference. The important thing is=20
>>> that it is about preference regardless of=20
>>> media
>>>  You have specified one preference order=20
>>> within each media, but that is not sufficient.
>>>  It is essential to be able to specify e.g. "I=20
>>> prefer to speak but can accept to type".
>>>  And to indicate what modality/language=20
>>> combination is your favourite among possible=20
>>> combinations.
>>>
>>>  And it is not primarily about establishing=20
>>> media streams, it is about connecting the=20
>>> right persons and services to the call and=20
>>> have an indication in what modality and=20
>>> language to handle the call.
>>>
>>>  With the long turn-around-times in IETF I=20
>>> absolutely do not want to wait one generation=20
>>> before we satisfy this need.
>>>
>>>  Can we accept the q-factor or invent=20
>>> something new, e.g. "; hi" for the highest=20
>>> preferred ones.
>>>
>>>  I think we have reduced complexity a lot=20
>>> anyway so that this one could stay.
>>>
>>>  Regards,
>>>  Gunnar
>>>
>>>>
>>>>  If we keep the draft very simple to start=20
>>>> with, then after we have some deployment=20
>>>> experience, we can create a revision or an=20
>>>> extension that adds the features that we=20
>>>> found we need, in the way we found we need=20
>>>> them. In my experience, this is a better=20
>>>> approach than trying to think of all aspects=20
>>>> of the solution at the start, since doing so=20
>>>> inevitably adds complexity and adds features=20
>>>> in ways that turn out to not be ideal.
>>>>
>>>>  So, I would like to avoid adding preference=20
>>>> now, but would be happy to work on an update=20
>>>> or extension in the future if we find that=20
>>>> we need it.
>>>>
>>>>  At 10:39 AM +0100 3/13/16, Gunnar Hellstr=F6m wrote:
>>>>
>>>>>  Randall,
>>>>>
>>>>>  Den 2016-03-12 kl. 23:53, skrev Randall Gellens:
>>>>>
>>>>>>  Hi Gunnar and everyone,
>>>>>>
>>>>>>  In the interest of keeping the draft as=20
>>>>>> simple as possible for the initial=20
>>>>>> version, I do not think we need to add the=20
>>>>>> absolute level of preference that you=20
>>>>>> suggest.
>>>>>>
>>>>>  And I think the draft will not be=20
>>>>> sufficiently usable without a mechanism to=20
>>>>> indicate absolute preference in a way so=20
>>>>> that the preference between languages and=20
>>>>> modalities in different media is indicated.
>>>>>  For example I prefer to talk and hear=20
>>>>> spoken English in audio, but can accept to=20
>>>>> type and read English text.
>>>>>  or another example:
>>>>>  I prefer to talk and hear spoken French in=20
>>>>> audio but can accept to sign and see French=20
>>>>> sign language in video.
>>>>>
>>>>>  Without a way to make the distinction, we=20
>>>>> give no clue to the other party on why=20
>>>>> language is indicated in more than one=20
>>>>> media. Are all desired or not?
>>>>>  And if you cannot indicate an option with=20
>>>>> lower preference then you may lose calls or=20
>>>>> get relay services invoked when they are=20
>>>>> not needed, wasting resources and making=20
>>>>> the calls less direct and less personal.
>>>>>
>>>>>  We could probably do with just two levels=20
>>>>> of preference: Preferred and possible.
>>>>>  While searching in=20
>>>>> https://tools.ietf.org/html/draft-ietf-slim-negotiating-human-language-=
00
>>>>>  for a possiblity to include that in the=20
>>>>> syntax without increasing complexity, I saw=20
>>>>> the Advisory vs Required indication by an=20
>>>>> asterisk in section 6.3.
>>>>>  I do not expect that indication to be of=20
>>>>> much value, so I intended to propose to=20
>>>>> change its use to be a priority indicator.=20
>>>>> But it seems too tightly coupled to the use=20
>>>>> in language-matching in RFC 2616, so I=20
>>>>> abstain from proposing that and instead=20
>>>>> with hesitation propose that we include the=20
>>>>> q=3D factor notation from RFC 2616 for=20
>>>>> indicating preference.
>>>>>
>>>>>  I suggest a change in section 6.2:
>>>>>
>>>>>=20
>>>>> -------------------------------------current=20
>>>>> text in=20
>>>>> 6.2-------------------------------------------------
>>>>>
>>>>>  a=3Dhumintlang-send:
>>>>>  a=3Dhumintlang-recv:
>>>>>
>>>>>  Each can appear multiple times in an offer for a media stream.
>>>>>
>>>>>  In an offer, the 'humintlang-send' values constitute a list in
>>>>>  preference order (first is most preferred) of the languages the
>>>>>  offerer wishes to send using the media, and the 'humintlang-recv'
>>>>>  values constitute a list in preference order of the languages the
>>>>>  offerer wishes to receive using the media.
>>>>>
>>>>>
>>>>>
>>>>>=20
>>>>> -------------------------------------proposed=20
>>>>> changed text in=20
>>>>> 6.2----------------------------------
>>>>>
>>>>>  a=3Dhumintlang-send:[ ";" "q" "=3D" qvalue ]
>>>>>
>>>>>  a=3Dhumintlang-recv:[ ";" "q" "=3D" qvalue ]
>>>>>
>>>>>
>>>>>  Each can appear multiple times in an offer for a media stream.
>>>>>
>>>>>  In an offer the 'humintlang-send' values=20
>>>>> constitute a list of the languages the
>>>>>  offerer wishes to send using the media, and the 'humintlang-recv'
>>>>>  values constitute a list of the languages the
>>>>>  offerer wishes to receive using the media.=20
>>>>> The q-values represent a preference level
>>>>>  for using the indicated language and=20
>>>>> modality relative to all other languages and
>>>>>  modalities indicated for the same direction in the whole SDP.
>>>>>  The quality value defaults to "q=3D1" and has=20
>>>>> the same syntax and usage rules as for=20
>>>>> 'Accept-Language' in RFC 2616 [RFC2616].
>>>>>
>>>>>  If more than one language is specified for=20
>>>>> the same media and direction with the same=20
>>>>> q-value,
>>>>>  they SHALL be listed in preference order.
>>>>>
>>>>>  ---------------------------------End of=20
>>>>> change=20
>>>>> proposal.---------------------------------------------
>>>>>
>>>>>
>>>>>>
>>>>>>  At 10:41 AM +0100 3/12/16, Gunnar Hellstr=F6m wrote:
>>>>>>
>>>>>>>  Natasha and all,
>>>>>>>
>>>>>>>  The use case collection looks good.
>>>>>>>  The reasoning about implementability need=20
>>>>>>> a description about what version of the=20
>>>>>>> negotiating-human-language draft it=20
>>>>>>> refers to. We hope to improve, so we get=20
>>>>>>> "possible" on nearly all cases.
>>>>>>>
>>>>>>>  It is time to act on the conclusions of the use cases.
>>>>>>>
>>>>>>>  My suggestion:
>>>>>>>  Add in the negotiating-human-language draft the following:
>>>>>>>
>>>>>>>  1. A coding for absolute level of=20
>>>>>>> preference for a modality-language=20
>>>>>>> combination in three levels: preferred,=20
>>>>>>> can-do, last-resort. Shall we explicit=20
>>>>>>> using words, or cryptic, using * and=20
>>>>>>> other special characters?
>>>>>>>
>>>>>  Changed to q-value above
>>>>>
>>>>>>>
>>>>>>>  2. A clear interpreting rule, saying that=20
>>>>>>> for needs of two modalities, one in each=20
>>>>>>> direction, the directional attributes=20
>>>>>>> together with absolute coding of=20
>>>>>>> preference shall be used, including some=20
>>>>>>> default rule for when no absolute coding=20
>>>>>>> is provided.
>>>>>>>
>>>>>  What is said for dual modalities in 6.2=20
>>>>> just below the change proposal above may be=20
>>>>> sufficient.
>>>>>
>>>>>>>
>>>>>>>
>>>>>>>  3. A description of offer-answer handling=20
>>>>>>> rules, making it very clear if the=20
>>>>>>> attributes in the answer indicate=20
>>>>>>> capabilities and preferences from the=20
>>>>>>> point of view of the party sending the=20
>>>>>>> SDP, or from the point of view of the=20
>>>>>>> offering party.
>>>>>>>  The first case would mean that "I want to=20
>>>>>>> talk English" and "I want to read English=20
>>>>>>> text" shall be answered with "I want to=20
>>>>>>> listen to spoken English" and "I will=20
>>>>>>> type English" to get a match , The second=20
>>>>>>> case would mean that "I want to talk=20
>>>>>>> English" and "I want to read English=20
>>>>>>> text" would be answered with "I accept=20
>>>>>>> that you talk English" and "I accept that=20
>>>>>>> you will read English text" thus sending=20
>>>>>>> attributes as if coded from the offering=20
>>>>>>> party to get a match.
>>>>>>>  The first case is more evident for the=20
>>>>>>> user, while the second case is easier to=20
>>>>>>> parse and check for a match.
>>>>>>>
>>>>>  In 6.2 we have the rule that both the=20
>>>>> offeror and the answering party indicate=20
>>>>> values from their own point of view. I=20
>>>>> think that is doable.
>>>>>
>>>>>>>
>>>>>>>  4. A conclusion that need for=20
>>>>>>> speech-to-speech relay services is out of=20
>>>>>>> scope and need to be solved by other=20
>>>>>>> indications. Do anyone have ideas for=20
>>>>>>> such indications? Call-Info with purpose=20
>>>>>>> and URI to a suitable service? Make a=20
>>>>>>> REFER to bring in the service? Call with=20
>>>>>>> a URI-list? ( Yes, it is out of scope,=20
>>>>>>> but I am interested to have an agreed=20
>>>>>>> best practice solutions for it.)
>>>>>>>
>>>>>  We take that separately and concentrate on=20
>>>>> the preference scope to cover all=20
>>>>> modalities here.
>>>>>
>>>>>  /Gunnar
>>>>>
>>>>>>>
>>>>>>>  Regards
>>>>>>>
>>>>>>>  Gunnar
>>>>>>>
>>>>>>>
>>>>>>>  Den 2016-03-11 kl. 17:28, skrev Natasha Rooney:
>>>>>>>
>>>>>>>>  Hi all!
>>>>>>>>
>>>>>>>>  IETF95 Deadline
>>>>>>>>  Just a quick reminder that the IETF95=20
>>>>>>>> document submission deadline is coming=20
>>>>>>>> up fast (March 21st). I am going to=20
>>>>>>>> submit the use cases draft before then=20
>>>>>>>> with the use cases I have collected from=20
>>>>>>>> the last meeting. If you want to see=20
>>>>>>>> what we have so far then see the link=20
>>>>>>>> below (excuse the xml):
>>>>>>>>
>>>>>>>>
>>>>>>>>=20
>>>>>>>> <https://github.com/ietf-slim-wg/slim-use-case=
s/blob/master/draft-ietf-slim-use-cases-latest.xml><>https://github.com/ietf=
-slim-wg/slim-use-cases/blob/master/draft-ietf-slim-use-cases-latest.xml
>>>>>>>>
>>>>>>>>  Our Document Status
>>>>>>>>  With regards to our two other documents,=20
>>>>>>>> I believe the only issue we have is=20
>>>>>>>> regarding the dual modality use case,=20
>>>>>>>> and the difficulty of dealing with this=20
>>>>>>>> within real-time communications (this=20
>>>>>>>> obviously only applies to=20
>>>>>>>> draft-ietf-slim-negotiating-human-language-00).=20
>>>>>>>> My question to you all is: do you have=20
>>>>>>>> any other outstanding issues with either=20
>>>>>>>> draft? If not, we should be in a state=20
>>>>>>>> to clean them up and publish.
>>>>>>>>
>>>>>>>>  Bernard and I are having a chairs chat=20
>>>>>>>> next week so we can discuss plans for=20
>>>>>>>> IETF95 and the document status, so=20
>>>>>>>> please let us know before the end of=20
>>>>>>>> Tuesday next week as to whether you have=20
>>>>>>>> any issues you wish to raise.
>>>>>>>>
>>>>>>>>  Thanks everyone!
>>>>>>>>
>>>>>>>>
>>>>>>>>  Natasha
>>>>>>>>
>>>>>>>>
>>>>>>>>  Natasha Rooney | Technologist, Web and=20
>>>>>>>> Internet, W3C & IETF | GSMA |=20
>>>>>>>> <<>mailto:nrooney@gsma.com>=20
>>>>>>>> nrooney@gsma.com=20
>>>>>>>> | +44 (0) 7730 219 765 | @thisNatasha |=20
>>>>>>>> Skype:=20
>>>>>>>> <mailto:nrooney@gsm.org><>nrooney@gsm.org
>>>>>>>>
>>>>>>>>>  On Mar 2, 2016, at 4:37 PM, Natasha=20
>>>>>>>>> Rooney=20
>>>>>>>>> <<<>mailto:nrooney@gsma.com><>nrooney@gsma.com>=20
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>  Hi all!
>>>>>>>>>
>>>>>>>>>  We are 1 month and 1 day away from the=20
>>>>>>>>> start of IETF95! Gasp! We have some=20
>>>>>>>>> work to get on with before IETF95,=20
>>>>>>>>> where we will have a very short (and=20
>>>>>>>>> hopefully fruitful meeting!) discussing=20
>>>>>>>>> the last issues we have remaining.
>>>>>>>>>
>>>>>>>>>  The IETF95 link is below for those of=20
>>>>>>>>> you who still need to book hotels:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>=20
>>>>>>>>> <https://ietf.org/meeting/=
95/index.html><>https://ietf.org/meeting/95/index.html
>>>>>>>>>
>>>>>>>>>  I am going to be working on finishing=20
>>>>>>>>> the use cases document from now until=20
>>>>>>>>> IETF95. Please submit any issues or=20
>>>>>>>>> pull requests to the github repo or=20
>>>>>>>>> tell me directly:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>=20
>>>>>>>>> <https://github.c=
om/ietf-slim-wg/slim-use-cases/><>https://github.com/ietf-slim-wg/slim-use-c=
ases/
>>>>>>>>>
>>>>>>>>>  With our other two documents I believe=20
>>>>>>>>> the modality issues is still at large.=20
>>>>>>>>> Can someone catch me up on the last=20
>>>>>>>>> discussions here? I remember that we=20
>>>>>>>>> were still discussing it and no=20
>>>>>>>>> decisions had been made - is this=20
>>>>>>>>> correct? On discussions with other IETF=20
>>>>>>>>> attendees many said that dual modality=20
>>>>>>>>> - whilst supported by use cases - is=20
>>>>>>>>> awfully difficult to implement, is this=20
>>>>>>>>> the same as the thoughts within this=20
>>>>>>>>> group?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>=20
>>>>>>>>> <https://datatrac=
ker.ietf.org/wg/slim/documents/><>https://datatracker.ietf.org/wg/slim/docum=
ents/
>>>>>>>>>
>>>>>>>>>  Thanks all!
>>>>>>>>>
>>>>>>>>>  Natasha
>>>>>>>>>
>>>>>>>>>  Natasha Rooney | Technologist, Web and=20
>>>>>>>>> Internet, W3C & IETF | GSMA |=20
>>>>>>>>> <<>mailto:nrooney@gsma.com>=20
>>>>>>>>> <mailto:nrooney@gsma.com><>nrooney@gsma.c=
om=20
>>>>>>>>> | +44 (0) 7730 219 765 | @thisNatasha |=20
>>>>>>>>> Skype:=20
>>>>>>>>> <mailto:nrooney@gsm.org><>nrooney@gsm.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>  This email and its attachments are=20
>>>>>>>>> intended for the above named only and=20
>>>>>>>>> may be confidential. If they have come=20
>>>>>>>>> to you in error you must take no action=20
>>>>>>>>> based on them, nor must you copy or=20
>>>>>>>>> show them to anyone; please reply to=20
>>>>>>>>> this email or call +44 207 356 0600 and=20
>>>>>>>>> highlight the error.
>>>>>>>>>
>>>>>>>>>  _______________________________________________
>>>>>>>>>  SLIM mailing list
>>>>>>>>>  <mailto:SLIM@ietf.org><>SLIM@ietf.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>=20
>>>>>>>>> <https://www.ietf.org/=
mailman/listinfo/slim><>https://www.ietf.org/mailman/listinfo/slim
>>>>>>>>>
>>>>>>>>
>>>>>>>>  This email and its attachments are=20
>>>>>>>> intended for the above named only and=20
>>>>>>>> may be confidential. If they have come=20
>>>>>>>> to you in error you must take no action=20
>>>>>>>> based on them, nor must you copy or show=20
>>>>>>>> them to anyone; please reply to this=20
>>>>>>>> email or call +44 207 356 0600 and=20
>>>>>>>> highlight the error.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>  _______________________________________________
>>>>>>>>  SLIM mailing list
>>>>>>>>  <mailto:SLIM@ietf.org><>SLIM@ietf.org
>>>>>>>>
>>>>>>>>
>>>>>>>>=20
>>>>>>>> <https://www.ietf.org/m=
ailman/listinfo/slim><>https://www.ietf.org/mailman/listinfo/slim
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>  _______________________________________________
>>>>>>>  SLIM mailing list
>>>>>>>  SLIM@ietf.org
>>>>>>>=20
>>>>>>> https://www.ietf.org/mai=
lman/listinfo/slim
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>  --
>>>>>  -----------------------------------------
>>>>>  Gunnar Hellstr=F6m
>>>>>  Omnitor
>>>>>  gunnar.hellstrom@omnitor.se
>>>>>  +46 708 204 288
>>>>>
>>>>>  _______________________________________________
>>>>>  SLIM mailing list
>>>>>  SLIM@ietf.org
>>>>>=20
>>>>> https://www.ietf.org/mailm=
an/listinfo/slim
>>>>>
>>>>
>>>>
>>>
>>>  --
>>>  -----------------------------------------
>>>  Gunnar Hellstr=F6m
>>>  Omnitor
>>>  gunnar.hellstrom@omnitor.se
>>>  +46 708 204 288
>>>
>>>  _______________________________________________
>>>  SLIM mailing list
>>>  SLIM@ietf.org
>>>=20
>>> https://www.ietf.org/mailman=
/listinfo/slim
>>>
>>
>
>  --
>  -----------------------------------------
>  Gunnar Hellstr=F6m
>  Omnitor
>  gunnar.hellstrom@omnitor.se
>  +46 708 204 288
>
>  _______________________________________________
>  SLIM mailing list
>  SLIM@ietf.org
>  https://www.ietf.org/mailman/listinfo/slim


-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
If Murphy's Law can go wrong, it will.


From nobody Wed Mar 16 14:13:42 2016
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 606DA12D62C for ; Wed, 16 Mar 2016 14:13:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oo89ZQGPNkNJ for ; Wed, 16 Mar 2016 14:13:34 -0700 (PDT)
Received: from bin-vsp-out-03.atm.binero.net (bin-mail-out-05.binero.net [195.74.38.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E94212D545 for ; Wed, 16 Mar 2016 14:13:33 -0700 (PDT)
X-Halon-ID: eaab2f30-ebbb-11e5-be2d-0050569116f7
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.1.95] (unknown [109.25.254.61]) by bin-vsp-out-03.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Wed, 16 Mar 2016 22:13:23 +0100 (CET)
To: slim@ietf.org
References: <076290F0-048C-49F4-8BF5-760109F75240@gsma.com>  <56E3E464.2040900@omnitor.se>  <56E53534.6090208@omnitor.se>  <56E898C9.8070100@omnitor.se>  <56E9AB61.2080505@omnitor.se> 
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: <56E9CC73.2030200@omnitor.se>
Date: Wed, 16 Mar 2016 22:13:23 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [Slim] IETF95, Use Cases doc, and others
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
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, 16 Mar 2016 21:13:39 -0000

Den 2016-03-16 kl. 21:02, skrev Randall Gellens:
> I think we can proceed without a new preference mechanism.  As I see 
> it, the worst case is we end up with unused media streams.
This is not about negotiating media streams, it is about having the 
right people taking the calls and adding additional services when needed.
Please read the use cases document again and understand why we need the 
preference indication to be across modalities.
The idea of the use case document was to make clear what was supported 
and not with the different mechanisms, so that we could create and 
include sufficient mechanisms to cover the use cases we find that we 
want to support.

I am satisfied with leaving invocation of speech-to-speech relay 
services without support from our mechanisms, but not the other use cases.

Today ETSI published a report where among other things there is quite 
high hopes tied to SLIM for providing pieces for the solution of getting 
the right parties involved in emergency service calls.
See 
http://www.etsi.org/deliver/etsi_tr/103200_103299/103201/01.01.01_60/tr_103201v010101p.pdf

So, we have expectations on us.

Gunnar

>
> At 7:52 PM +0100 3/16/16, Gunnar Hellström wrote:
>
>>  Den 2016-03-16 kl. 19:38, skrev Brian Rosen:
>>
>>>  I really don't think that the complexity this introduces is worth 
>>> the benefit, and I would prefer not to include it. I also don't 
>>> think it works. You want a grouping of media and language, with a 
>>> preference on the grouping, not a simple priority on language.
>>>
>>  SDP groupings would introduce even more complexity and we would not 
>> see any implementations.
>>
>>  What we need is a grouping rule saying that if a language and 
>> modality is indicated for one direction and a certain level of 
>> preference, then it shall be regarded to be preferred to be used 
>> together with a language and modality in the other direction with the 
>> same level of preference.
>>
>>  It will be easy to parse for matches according to that rule.
>>
>>  Are there any suggestions for preference coding other than q= ?
>>
>>  Gunnar
>>
>>>
>>>  Brian
>>>
>>>>  On Mar 15, 2016, at 7:20 PM, Gunnar Hellström 
>>>> <gunnar.hellstrom@omnitor.se> 
>>>> wrote:
>>>>
>>>>  Hi Randall,
>>>>
>>>>  Den 2016-03-15 kl. 02:15, skrev Randall Gellens:
>>>>
>>>>>  Hi Gunnar,
>>>>>
>>>>>  I think adding q= factor is much more complexity than is needed, 
>>>>> and I remain unconvinced that we must have a preference indication 
>>>>> at the start. I don't see that use cases are impossible without 
>>>>> it. It seems to me that the only difference it makes is to skip 
>>>>> establishing some requested media streams if others are 
>>>>> established. I suspect that in most cases, the ones that could be 
>>>>> skipped would be the easier ones (without relay/interpretation 
>>>>> services). Having an extra text or audio stream that is not used 
>>>>> is not a big deal.
>>>>>
>>>>  I agree that adding the q-factor was not what I originally thought 
>>>> of as the solution. But since I realised that we could not reuse 
>>>> the * -mark of the less-needed indication of Advisory vs required 
>>>> for this purpose I thought it was best to reuse another already 
>>>> existing coding. You are welcome to propose another alternative.
>>>>  Because we need a preference indication that is independent of 
>>>> media. I have called it "absolute preference", but that might not 
>>>> be the best words. It can be solved with a relative preference. The 
>>>> important thing is that it is about preference regardless of media
>>>>  You have specified one preference order within each media, but 
>>>> that is not sufficient.
>>>>  It is essential to be able to specify e.g. "I prefer to speak but 
>>>> can accept to type".
>>>>  And to indicate what modality/language combination is your 
>>>> favourite among possible combinations.
>>>>
>>>>  And it is not primarily about establishing media streams, it is 
>>>> about connecting the right persons and services to the call and 
>>>> have an indication in what modality and language to handle the call.
>>>>
>>>>  With the long turn-around-times in IETF I absolutely do not want 
>>>> to wait one generation before we satisfy this need.
>>>>
>>>>  Can we accept the q-factor or invent something new, e.g. "; hi" 
>>>> for the highest preferred ones.
>>>>
>>>>  I think we have reduced complexity a lot anyway so that this one 
>>>> could stay.
>>>>
>>>>  Regards,
>>>>  Gunnar
>>>>
>>>>>
>>>>>  If we keep the draft very simple to start with, then after we 
>>>>> have some deployment experience, we can create a revision or an 
>>>>> extension that adds the features that we found we need, in the way 
>>>>> we found we need them. In my experience, this is a better approach 
>>>>> than trying to think of all aspects of the solution at the start, 
>>>>> since doing so inevitably adds complexity and adds features in 
>>>>> ways that turn out to not be ideal.
>>>>>
>>>>>  So, I would like to avoid adding preference now, but would be 
>>>>> happy to work on an update or extension in the future if we find 
>>>>> that we need it.
>>>>>
>>>>>  At 10:39 AM +0100 3/13/16, Gunnar Hellström wrote:
>>>>>
>>>>>>  Randall,
>>>>>>
>>>>>>  Den 2016-03-12 kl. 23:53, skrev Randall Gellens:
>>>>>>
>>>>>>>  Hi Gunnar and everyone,
>>>>>>>
>>>>>>>  In the interest of keeping the draft as simple as possible for 
>>>>>>> the initial version, I do not think we need to add the absolute 
>>>>>>> level of preference that you suggest.
>>>>>>>
>>>>>>  And I think the draft will not be sufficiently usable without a 
>>>>>> mechanism to indicate absolute preference in a way so that the 
>>>>>> preference between languages and modalities in different media is 
>>>>>> indicated.
>>>>>>  For example I prefer to talk and hear spoken English in audio, 
>>>>>> but can accept to type and read English text.
>>>>>>  or another example:
>>>>>>  I prefer to talk and hear spoken French in audio but can accept 
>>>>>> to sign and see French sign language in video.
>>>>>>
>>>>>>  Without a way to make the distinction, we give no clue to the 
>>>>>> other party on why language is indicated in more than one media. 
>>>>>> Are all desired or not?
>>>>>>  And if you cannot indicate an option with lower preference then 
>>>>>> you may lose calls or get relay services invoked when they are 
>>>>>> not needed, wasting resources and making the calls less direct 
>>>>>> and less personal.
>>>>>>
>>>>>>  We could probably do with just two levels of preference: 
>>>>>> Preferred and possible.
>>>>>>  While searching in 
>>>>>> https://tools.ietf.org/html/draft-ietf-slim-negotiating-human-language-00
>>>>>>  for a possiblity to include that in the syntax without 
>>>>>> increasing complexity, I saw the Advisory vs Required indication 
>>>>>> by an asterisk in section 6.3.
>>>>>>  I do not expect that indication to be of much value, so I 
>>>>>> intended to propose to change its use to be a priority indicator. 
>>>>>> But it seems too tightly coupled to the use in language-matching 
>>>>>> in RFC 2616, so I abstain from proposing that and instead with 
>>>>>> hesitation propose that we include the q= factor notation from 
>>>>>> RFC 2616 for indicating preference.
>>>>>>
>>>>>>  I suggest a change in section 6.2:
>>>>>>
>>>>>>
>>>>>> -------------------------------------current text in 
>>>>>> 6.2-------------------------------------------------
>>>>>>
>>>>>>  a=humintlang-send:
>>>>>>  a=humintlang-recv:
>>>>>>
>>>>>>  Each can appear multiple times in an offer for a media stream.
>>>>>>
>>>>>>  In an offer, the 'humintlang-send' values constitute a list in
>>>>>>  preference order (first is most preferred) of the languages the
>>>>>>  offerer wishes to send using the media, and the 'humintlang-recv'
>>>>>>  values constitute a list in preference order of the languages the
>>>>>>  offerer wishes to receive using the media.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> -------------------------------------proposed changed text in 
>>>>>> 6.2----------------------------------
>>>>>>
>>>>>>  a=humintlang-send:[ ";" "q" "=" qvalue ]
>>>>>>
>>>>>>  a=humintlang-recv:[ ";" "q" "=" qvalue ]
>>>>>>
>>>>>>
>>>>>>  Each can appear multiple times in an offer for a media stream.
>>>>>>
>>>>>>  In an offer the 'humintlang-send' values constitute a list of 
>>>>>> the languages the
>>>>>>  offerer wishes to send using the media, and the 'humintlang-recv'
>>>>>>  values constitute a list of the languages the
>>>>>>  offerer wishes to receive using the media. The q-values 
>>>>>> represent a preference level
>>>>>>  for using the indicated language and modality relative to all 
>>>>>> other languages and
>>>>>>  modalities indicated for the same direction in the whole SDP.
>>>>>>  The quality value defaults to "q=1" and has the same syntax and 
>>>>>> usage rules as for 'Accept-Language' in RFC 2616 [RFC2616].
>>>>>>
>>>>>>  If more than one language is specified for the same media and 
>>>>>> direction with the same q-value,
>>>>>>  they SHALL be listed in preference order.
>>>>>>
>>>>>>  ---------------------------------End of change 
>>>>>> proposal.---------------------------------------------
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>  At 10:41 AM +0100 3/12/16, Gunnar Hellström wrote:
>>>>>>>
>>>>>>>>  Natasha and all,
>>>>>>>>
>>>>>>>>  The use case collection looks good.
>>>>>>>>  The reasoning about implementability need a description about 
>>>>>>>> what version of the negotiating-human-language draft it refers 
>>>>>>>> to. We hope to improve, so we get "possible" on nearly all cases.
>>>>>>>>
>>>>>>>>  It is time to act on the conclusions of the use cases.
>>>>>>>>
>>>>>>>>  My suggestion:
>>>>>>>>  Add in the negotiating-human-language draft the following:
>>>>>>>>
>>>>>>>>  1. A coding for absolute level of preference for a 
>>>>>>>> modality-language combination in three levels: preferred, 
>>>>>>>> can-do, last-resort. Shall we explicit using words, or cryptic, 
>>>>>>>> using * and other special characters?
>>>>>>>>
>>>>>>  Changed to q-value above
>>>>>>
>>>>>>>>
>>>>>>>>  2. A clear interpreting rule, saying that for needs of two 
>>>>>>>> modalities, one in each direction, the directional attributes 
>>>>>>>> together with absolute coding of preference shall be used, 
>>>>>>>> including some default rule for when no absolute coding is 
>>>>>>>> provided.
>>>>>>>>
>>>>>>  What is said for dual modalities in 6.2 just below the change 
>>>>>> proposal above may be sufficient.
>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>  3. A description of offer-answer handling rules, making it 
>>>>>>>> very clear if the attributes in the answer indicate 
>>>>>>>> capabilities and preferences from the point of view of the 
>>>>>>>> party sending the SDP, or from the point of view of the 
>>>>>>>> offering party.
>>>>>>>>  The first case would mean that "I want to talk English" and "I 
>>>>>>>> want to read English text" shall be answered with "I want to 
>>>>>>>> listen to spoken English" and "I will type English" to get a 
>>>>>>>> match , The second case would mean that "I want to talk 
>>>>>>>> English" and "I want to read English text" would be answered 
>>>>>>>> with "I accept that you talk English" and "I accept that you 
>>>>>>>> will read English text" thus sending attributes as if coded 
>>>>>>>> from the offering party to get a match.
>>>>>>>>  The first case is more evident for the user, while the second 
>>>>>>>> case is easier to parse and check for a match.
>>>>>>>>
>>>>>>  In 6.2 we have the rule that both the offeror and the answering 
>>>>>> party indicate values from their own point of view. I think that 
>>>>>> is doable.
>>>>>>
>>>>>>>>
>>>>>>>>  4. A conclusion that need for speech-to-speech relay services 
>>>>>>>> is out of scope and need to be solved by other indications. Do 
>>>>>>>> anyone have ideas for such indications? Call-Info with purpose 
>>>>>>>> and URI to a suitable service? Make a REFER to bring in the 
>>>>>>>> service? Call with a URI-list? ( Yes, it is out of scope, but I 
>>>>>>>> am interested to have an agreed best practice solutions for it.)
>>>>>>>>
>>>>>>  We take that separately and concentrate on the preference scope 
>>>>>> to cover all modalities here.
>>>>>>
>>>>>>  /Gunnar
>>>>>>
>>>>>>>>
>>>>>>>>  Regards
>>>>>>>>
>>>>>>>>  Gunnar
>>>>>>>>
>>>>>>>>
>>>>>>>>  Den 2016-03-11 kl. 17:28, skrev Natasha Rooney:
>>>>>>>>
>>>>>>>>>  Hi all!
>>>>>>>>>
>>>>>>>>>  IETF95 Deadline
>>>>>>>>>  Just a quick reminder that the IETF95 document submission 
>>>>>>>>> deadline is coming up fast (March 21st). I am going to submit 
>>>>>>>>> the use cases draft before then with the use cases I have 
>>>>>>>>> collected from the last meeting. If you want to see what we 
>>>>>>>>> have so far then see the link below (excuse the xml):
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> <https://github.com/ietf-slim-wg/slim-use-cases/blob/master/draft-ietf-slim-use-cases-latest.xml><>https://github.com/ietf-slim-wg/slim-use-cases/blob/master/draft-ietf-slim-use-cases-latest.xml 
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>  Our Document Status
>>>>>>>>>  With regards to our two other documents, I believe the only 
>>>>>>>>> issue we have is regarding the dual modality use case, and the 
>>>>>>>>> difficulty of dealing with this within real-time 
>>>>>>>>> communications (this obviously only applies to 
>>>>>>>>> draft-ietf-slim-negotiating-human-language-00). My question to 
>>>>>>>>> you all is: do you have any other outstanding issues with 
>>>>>>>>> either draft? If not, we should be in a state to clean them up 
>>>>>>>>> and publish.
>>>>>>>>>
>>>>>>>>>  Bernard and I are having a chairs chat next week so we can 
>>>>>>>>> discuss plans for IETF95 and the document status, so please 
>>>>>>>>> let us know before the end of Tuesday next week as to whether 
>>>>>>>>> you have any issues you wish to raise.
>>>>>>>>>
>>>>>>>>>  Thanks everyone!
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>  Natasha
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>  Natasha Rooney | Technologist, Web and Internet, W3C & IETF | 
>>>>>>>>> GSMA | <<>mailto:nrooney@gsma.com> 
>>>>>>>>> nrooney@gsma.com | +44 (0) 7730 219 
>>>>>>>>> 765 | @thisNatasha | Skype: 
>>>>>>>>> <mailto:nrooney@gsm.org><>nrooney@gsm.org
>>>>>>>>>
>>>>>>>>>>  On Mar 2, 2016, at 4:37 PM, Natasha Rooney 
>>>>>>>>>> <<<>mailto:nrooney@gsma.com><>nrooney@gsma.com> wrote:
>>>>>>>>>>
>>>>>>>>>>  Hi all!
>>>>>>>>>>
>>>>>>>>>>  We are 1 month and 1 day away from the start of IETF95! 
>>>>>>>>>> Gasp! We have some work to get on with before IETF95, where 
>>>>>>>>>> we will have a very short (and hopefully fruitful meeting!) 
>>>>>>>>>> discussing the last issues we have remaining.
>>>>>>>>>>
>>>>>>>>>>  The IETF95 link is below for those of you who still need to 
>>>>>>>>>> book hotels:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> <https://ietf.org/meeting/95/index.html><>https://ietf.org/meeting/95/index.html 
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>  I am going to be working on finishing the use cases document 
>>>>>>>>>> from now until IETF95. Please submit any issues or pull 
>>>>>>>>>> requests to the github repo or tell me directly:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> <https://github.com/ietf-slim-wg/slim-use-cases/><>https://github.com/ietf-slim-wg/slim-use-cases/ 
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>  With our other two documents I believe the modality issues 
>>>>>>>>>> is still at large. Can someone catch me up on the last 
>>>>>>>>>> discussions here? I remember that we were still discussing it 
>>>>>>>>>> and no decisions had been made - is this correct? On 
>>>>>>>>>> discussions with other IETF attendees many said that dual 
>>>>>>>>>> modality - whilst supported by use cases - is awfully 
>>>>>>>>>> difficult to implement, is this the same as the thoughts 
>>>>>>>>>> within this group?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> <https://datatracker.ietf.org/wg/slim/documents/><>https://datatracker.ietf.org/wg/slim/documents/ 
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>  Thanks all!
>>>>>>>>>>
>>>>>>>>>>  Natasha
>>>>>>>>>>
>>>>>>>>>>  Natasha Rooney | Technologist, Web and Internet, W3C & IETF 
>>>>>>>>>> | GSMA | <<>mailto:nrooney@gsma.com> 
>>>>>>>>>> <mailto:nrooney@gsma.com><>nrooney@gsma.com 
>>>>>>>>>> | +44 (0) 7730 219 765 | @thisNatasha | Skype: 
>>>>>>>>>> <mailto:nrooney@gsm.org><>nrooney@gsm.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>  This email and its attachments are intended for the above 
>>>>>>>>>> named only and may be confidential. If they have come to you 
>>>>>>>>>> in error you must take no action based on them, nor must you 
>>>>>>>>>> copy or show them to anyone; please reply to this email or 
>>>>>>>>>> call +44 207 356 0600 and highlight the error.
>>>>>>>>>>
>>>>>>>>>>  _______________________________________________
>>>>>>>>>>  SLIM mailing list
>>>>>>>>>>  <mailto:SLIM@ietf.org><>SLIM@ietf.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> <https://www.ietf.org/mailman/listinfo/slim><>https://www.ietf.org/mailman/listinfo/slim 
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>  This email and its attachments are intended for the above 
>>>>>>>>> named only and may be confidential. If they have come to you 
>>>>>>>>> in error you must take no action based on them, nor must you 
>>>>>>>>> copy or show them to anyone; please reply to this email or 
>>>>>>>>> call +44 207 356 0600 and highlight the error.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>  _______________________________________________
>>>>>>>>>  SLIM mailing list
>>>>>>>>>  <mailto:SLIM@ietf.org><>SLIM@ietf.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> <https://www.ietf.org/mailman/listinfo/slim><>https://www.ietf.org/mailman/listinfo/slim 
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>  _______________________________________________
>>>>>>>>  SLIM mailing list
>>>>>>>>  SLIM@ietf.org
>>>>>>>>
>>>>>>>> https://www.ietf.org/mailman/listinfo/slim 
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>  --
>>>>>>  -----------------------------------------
>>>>>>  Gunnar Hellström
>>>>>>  Omnitor
>>>>>>  gunnar.hellstrom@omnitor.se
>>>>>>  +46 708 204 288
>>>>>>
>>>>>>  _______________________________________________
>>>>>>  SLIM mailing list
>>>>>>  SLIM@ietf.org
>>>>>>
>>>>>> https://www.ietf.org/mailman/listinfo/slim 
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>  --
>>>>  -----------------------------------------
>>>>  Gunnar Hellström
>>>>  Omnitor
>>>>  gunnar.hellstrom@omnitor.se
>>>>  +46 708 204 288
>>>>
>>>>  _______________________________________________
>>>>  SLIM mailing list
>>>>  SLIM@ietf.org
>>>>
>>>> https://www.ietf.org/mailman/listinfo/slim 
>>>>
>>>>
>>>
>>
>>  --
>>  -----------------------------------------
>>  Gunnar Hellström
>>  Omnitor
>>  gunnar.hellstrom@omnitor.se
>>  +46 708 204 288
>>
>>  _______________________________________________
>>  SLIM mailing list
>>  SLIM@ietf.org
>>  https://www.ietf.org/mailman/listinfo/slim
>
>

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


From nobody Thu Mar 17 08:41:12 2016
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 178F412D5BA for ; Thu, 17 Mar 2016 08:41:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level: 
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gsmasso.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ILF46n1I5qpq for ; Thu, 17 Mar 2016 08:41:06 -0700 (PDT)
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0044.outbound.protection.outlook.com [104.47.1.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64F5712D56D for ; Thu, 17 Mar 2016 08:41:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=GSMASSO.onmicrosoft.com; s=selector1-gsma-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=P3p4iZPQ+jSqsompkjpWujzoBlJh8MoZiJ8JRYyXQ14=; b=Vpj0MFHaxCIJ3hN2M0+s4Uvid8IlwegzCP42oDcwJRUMgBr+javXcdVNIUB0ceGoNOTTbNnJjV7LhRJD/WsiHtychna0e3bKGYUr8xRuxb3+5FmbXEySkk5PcjCH3HAe8oUD0l19gG1pMIGZglxobQ1s5JiPuj1guQT/7V2ilJg=
Received: from DB5PR04MB1029.eurprd04.prod.outlook.com (10.161.199.143) by DB5PR04MB1030.eurprd04.prod.outlook.com (10.161.199.144) with Microsoft SMTP Server (TLS) id 15.1.434.16; Thu, 17 Mar 2016 15:41:04 +0000
Received: from DB5PR04MB1029.eurprd04.prod.outlook.com ([10.161.199.143]) by DB5PR04MB1029.eurprd04.prod.outlook.com ([10.161.199.143]) with mapi id 15.01.0434.020; Thu, 17 Mar 2016 15:41:04 +0000
From: Natasha Rooney 
To: "slim@ietf.org" 
Thread-Topic: IETF95 Attendance
Thread-Index: AQHRgGNqANnShy0aLk+cueil7eTTng==
Date: Thu, 17 Mar 2016 15:41:04 +0000
Message-ID: <3ABD322A-13A7-4567-9744-5B34373ED43B@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.3112)
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=gsma.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [62.189.0.100]
x-ms-office365-filtering-correlation-id: a6a77e55-841c-41f9-2e5e-08d34e7a8c9c
x-microsoft-exchange-diagnostics: 1; DB5PR04MB1030; 5:00ll0UZ4qdao+v6RM/YOVolwYTeHsoJWKtpnVJ0RbM9Mi0/XJgLK8KzgL+JArrxRBUVtQEcc8lbI/IY3sby3S1REZUlc86kCgB16c4pORqCVw1Z6xunYG4fSbpfRtvIMlh6wJ+0P78AxjnMulu0iOA==; 24:M1qABzdD+gvcEABW8XrLZluvuuolFcQHhg2fKHbHUyfW/G0D3rHLil3rrfBWDk3cEmRxTVGBsc3U04myHcPBi/zu0vsP2j+lfZPMs2fFsXo=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB5PR04MB1030;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:DB5PR04MB1030; BCL:0; PCL:0; RULEID:; SRVR:DB5PR04MB1030; 
x-forefront-prvs: 0884AAA693
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(53754006)(86362001)(5640700001)(2900100001)(1730700002)(586003)(83716003)(87936001)(50986999)(10400500002)(107886002)(189998001)(1220700001)(82746002)(5890100001)(1096002)(2906002)(5008740100001)(102836003)(6116002)(11100500001)(3660700001)(2501003)(3846002)(19580395003)(77096005)(19580405001)(3280700002)(81166005)(57306001)(450100001)(36756003)(33656002)(2351001)(5004730100002)(50226001)(229853001)(5002640100001)(106116001)(122556002)(110136002)(92566002)(66066001)(16236675004); DIR:OUT; SFP:1101; SCL:1; SRVR:DB5PR04MB1030; H:DB5PR04MB1029.eurprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_3ABD322A13A7456797445B34373ED43Bgsmacom_"
MIME-Version: 1.0
X-OriginatorOrg: gsma.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Mar 2016 15:41:04.0456 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72a4ff82-fec3-469d-aafb-ac8276216699
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR04MB1030
X-MS-Exchange-CrossPremises-AuthAs: Internal
X-MS-Exchange-CrossPremises-AuthMechanism: 04
X-MS-Exchange-CrossPremises-AuthSource: DB5PR04MB1029.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: 62.189.0.100
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: DB5PR04MB1030.eurprd04.prod.outlook.com
Archived-At: 
Subject: [Slim] IETF95 Attendance
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
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, 17 Mar 2016 15:41:11 -0000

--_000_3ABD322A13A7456797445B34373ED43Bgsmacom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgYWxsIQ0KDQpJdCB3b3VsZCBiZSBnb29kIHRvIGdhaW4gYW4gdW5kZXJzdGFuZGluZyBvZiBh
dHRlbmRhbmNlIGF0IG91ciBtZWV0aW5nIGF0IElFVEY5NS4gUGxlYXNlIGNhbiB5b3UgbGV0IG1l
IGtub3cgaWYgeW914oCZcmUgY29taW5nIHRvIElFVEY5NS4gSnVzdCBhIHNpbXBsZSAiSeKAmW0g
Y29taW5nIiBlbWFpbCB3aWxsIHN1ZmZpY2UhIElmIHlvdSBoYXZlIHRvbGQgbWUgYWxyZWFkeSB0
aGVuIHlvdSBkb27igJl0IG5lZWQgdG8gbGV0IG1lIGtub3cgYWdhaW4uDQoNClRoYW5rcyENCg0K
TmF0YXNoYQ0KDQoNCk5hdGFzaGEgUm9vbmV5IHwgVGVjaG5vbG9naXN0LCBXZWIgYW5kIEludGVy
bmV0LCBXM0MgJiBJRVRGIHwgR1NNQSB8IG5yb29uZXlAZ3NtYS5jb208bWFpbHRvOm5yb29uZXlA
Z3NtYS5jb20+IHwgKzQ0ICgwKSA3NzMwIDIxOSA3NjUgfCBAdGhpc05hdGFzaGEgfCBTa3lwZTog
bnJvb25leUBnc20ub3JnPG1haWx0bzpucm9vbmV5QGdzbS5vcmc+DQoNCg0KDQpUaGlzIGVtYWls
IGFuZCBpdHMgYXR0YWNobWVudHMgYXJlIGludGVuZGVkIGZvciB0aGUgYWJvdmUgbmFtZWQgb25s
eSBhbmQgbWF5IGJlIGNvbmZpZGVudGlhbC4gSWYgdGhleSBoYXZlIGNvbWUgdG8geW91IGluIGVy
cm9yIHlvdSBtdXN0IHRha2Ugbm8gYWN0aW9uIGJhc2VkIG9uIHRoZW0sIG5vciBtdXN0IHlvdSBj
b3B5IG9yIHNob3cgdGhlbSB0byBhbnlvbmU7IHBsZWFzZSByZXBseSB0byB0aGlzIGVtYWlsIG9y
IGNhbGwgKzQ0IDIwNyAzNTYgMDYwMCBhbmQgaGlnaGxpZ2h0IHRoZSBlcnJvci4NCg==

--_000_3ABD322A13A7456797445B34373ED43Bgsmacom_
Content-Type: text/html; charset="utf-8"
Content-ID: <30B2B6E6971C144D805A460F6375B6C3@eurprd04.prod.outlook.com>
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy
ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGkgYWxsITxiciBjbGFzcz0iIj4N
CjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSJ3ZWJraXQtYmxvY2stcGxhY2Vob2xkZXIiPg0KPC9k
aXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgbGV0
dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRl
eHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFs
OyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdp
ZHRoOiAwcHg7IHdvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNl
OyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQo8ZGl2
IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBo
YW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFu
c2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFj
aW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgd29yZC13cmFwOiBicmVh
ay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0
ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkl0IHdvdWxkIGJlIGdvb2QgdG8gZ2FpbiBhbiB1
bmRlcnN0YW5kaW5nIG9mIGF0dGVuZGFuY2UgYXQgb3VyIG1lZXRpbmcgYXQgSUVURjk1Lg0KPGIg
Y2xhc3M9IiI+UGxlYXNlIGNhbiB5b3UgbGV0IG1lIGtub3cgaWYgeW914oCZcmUgY29taW5nIHRv
IElFVEY5NTwvYj4uIEp1c3QgYSBzaW1wbGUgJnF1b3Q7SeKAmW0gY29taW5nJnF1b3Q7IGVtYWls
IHdpbGwgc3VmZmljZSEgSWYgeW91IGhhdmUgdG9sZCBtZSBhbHJlYWR5IHRoZW4geW91IGRvbuKA
mXQgbmVlZCB0byBsZXQgbWUga25vdyBhZ2Fpbi48L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiBy
Z2IoMCwgMCwgMCk7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQt
YWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hp
dGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtp
dC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQt
bmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsi
IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdi
KDAsIDAsIDApOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFs
aWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRl
LXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQt
dGV4dC1zdHJva2Utd2lkdGg6IDBweDsgd29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5i
c3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBj
bGFzcz0iIj4NClRoYW5rcyE8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpOYXRhc2hhPGJy
IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KTmF0YXNoYSBSb29uZXkg
fCBUZWNobm9sb2dpc3QsIFdlYiBhbmQgSW50ZXJuZXQsIFczQyAmYW1wOyBJRVRGIHwmbmJzcDtH
U01BIHwgPGEgaHJlZj0ibWFpbHRvOm5yb29uZXlAZ3NtYS5jb20iIGNsYXNzPSIiPg0KbnJvb25l
eUBnc21hLmNvbTwvYT4gfCAmIzQzOzQ0ICgwKSZuYnNwOzc3MzAgMjE5IDc2NSB8IEB0aGlzTmF0
YXNoYSB8IFNreXBlOiZuYnNwOzxhIGhyZWY9Im1haWx0bzpucm9vbmV5QGdzbS5vcmciIGNsYXNz
PSIiPm5yb29uZXlAZ3NtLm9yZzwvYT4mbmJzcDs8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8cCBzdHlsZT0iZm9udC1m
YW1pbHk6IEFyaWFsLHNhbnMtc2VyaWY7Zm9udC1zaXplOjExcHg7Y29sb3I6Izk5OTk5OTsiPjxz
cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLHNhbnMtc2VyaWY7Y29s
b3I6Izk5OTk5OTsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IEFyaWFsOyBtc28tZmFyZWFzdC10
aGVtZS1mb250OiBtaW5vci1sYXRpbjsgbXNvLWJpZGktZm9udC1mYW1pbHk6ICZxdW90O0FyaWFs
JnF1b3Q7OyBtc28tYW5zaS1sYW5ndWFnZTogRU4tVVM7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBF
Ti1HQjsgbXNvLWJpZGktbGFuZ3VhZ2U6IEFSLVNBIj5UaGlzDQogZW1haWwgYW5kIGl0cyBhdHRh
Y2htZW50cyBhcmUgaW50ZW5kZWQgZm9yIHRoZSBhYm92ZSBuYW1lZCBvbmx5IGFuZCBtYXkgYmUg
Y29uZmlkZW50aWFsLiBJZiB0aGV5IGhhdmUgY29tZSB0byB5b3UgaW4gZXJyb3IgeW91IG11c3Qg
dGFrZSBubyBhY3Rpb24gYmFzZWQgb24gdGhlbSwgbm9yIG11c3QgeW91IGNvcHkgb3Igc2hvdyB0
aGVtIHRvIGFueW9uZTsgcGxlYXNlIHJlcGx5IHRvIHRoaXMgZW1haWwgb3IgY2FsbCAmIzQzOzQ0
IDIwNyAzNTYgMDYwMA0KIGFuZCBoaWdobGlnaHQgdGhlIGVycm9yLiA8L3NwYW4+PC9wPg0KPC9i
b2R5Pg0KPC9odG1sPg0K

--_000_3ABD322A13A7456797445B34373ED43Bgsmacom_--


From nobody Thu Mar 17 08:41:24 2016
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAFAB12D98D for ; Thu, 17 Mar 2016 08:41:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.911
X-Spam-Level: 
X-Spam-Status: No, score=-2.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gsmasso.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M84xo-z5bI8w for ; Thu, 17 Mar 2016 08:41:20 -0700 (PDT)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0060.outbound.protection.outlook.com [104.47.2.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A0E112D93D for ; Thu, 17 Mar 2016 08:41:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=GSMASSO.onmicrosoft.com; s=selector1-gsma-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/AEmMJQGNHZ/LGkiuMgoSNGz2NkuwUg2ZSYvMZTNQ/c=; b=ualD3fEEqFBGHZwKemFgy+v3MIxo/LJRDlR91dWrl+Xfh/XwHOd9O4+4dzOw9fFdpV/hblKrea3uU4uhb2eBrt3SxFGIoIngLpJmydSD6U1yiHf9cOj5SL5nIYjcdODNijVKZD6cULDYLu7duvW5/iR6IPp4+xrst2+K9pLGSY0=
Received: from DB5PR04MB1029.eurprd04.prod.outlook.com (10.161.199.143) by DB5PR04MB1030.eurprd04.prod.outlook.com (10.161.199.144) with Microsoft SMTP Server (TLS) id 15.1.434.16; Thu, 17 Mar 2016 15:41:17 +0000
Received: from DB5PR04MB1029.eurprd04.prod.outlook.com ([10.161.199.143]) by DB5PR04MB1029.eurprd04.prod.outlook.com ([10.161.199.143]) with mapi id 15.01.0434.020; Thu, 17 Mar 2016 15:41:17 +0000
From: Natasha Rooney 
To: =?Windows-1252?Q?Gunnar_Hellstr=F6m?= 
Thread-Topic: [Slim] IETF95, Use Cases doc change proposals
Thread-Index: AQHRf0KRsL/HJAlX8E6oKO6tAb70SZ9dyF0A
Date: Thu, 17 Mar 2016 15:41:17 +0000
Message-ID: <90AF8946-999C-4C05-8AD1-E9A17DA009E9@gsma.com>
References: <076290F0-048C-49F4-8BF5-760109F75240@gsma.com>  <56E8EB60.30707@omnitor.se>
In-Reply-To: <56E8EB60.30707@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.3112)
authentication-results: omnitor.se; dkim=none (message not signed) header.d=none;omnitor.se; dmarc=none action=none header.from=gsma.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [62.189.0.100]
x-ms-office365-filtering-correlation-id: d92fdac8-a03b-4953-aa2e-08d34e7a9492
x-microsoft-exchange-diagnostics: 1; DB5PR04MB1030; 5:mdS0qOl7S4fvtSlftURNYOgVVpJ/INqOrXn2Ext4xQ40rr/aNRyw0Ol79bNrz3SurtmLij0XtW9aeFaj4I5XKFnuNIcNzF6vQU7NZJUA2bP73FTbaBxMLxptZEHegknUb025G3h9aM2uUDPIbexmJw==; 24:md4ZvAdmv/9WKS0t+CwMwByj5SqUoSF+oKimivepiQE470ZXD8QyC437j7zM6FhTjBBwmf/H/4W3qWqEWVhBAgh8ICacc/YL7WY/zMvlnfQ=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB5PR04MB1030;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:DB5PR04MB1030; BCL:0; PCL:0; RULEID:; SRVR:DB5PR04MB1030; 
x-forefront-prvs: 0884AAA693
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(24454002)(377454003)(377424004)(53754006)(86362001)(2900100001)(2950100001)(586003)(83716003)(87936001)(50986999)(76176999)(10400500002)(189998001)(1220700001)(82746002)(5890100001)(1096002)(2906002)(5008740100001)(102836003)(6116002)(4326007)(11100500001)(3660700001)(3846002)(15975445007)(19580395003)(77096005)(19580405001)(3280700002)(81166005)(57306001)(36756003)(33656002)(5004730100002)(50226001)(5002640100001)(19617315012)(106116001)(122556002)(110136002)(92566002)(66066001)(16236675004); DIR:OUT; SFP:1101; SCL:1; SRVR:DB5PR04MB1030; H:DB5PR04MB1029.eurprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_90AF8946999C4C058AD1E9A17DA009E9gsmacom_"
MIME-Version: 1.0
X-OriginatorOrg: gsma.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Mar 2016 15:41:17.3425 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72a4ff82-fec3-469d-aafb-ac8276216699
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR04MB1030
X-MS-Exchange-CrossPremises-AuthAs: Internal
X-MS-Exchange-CrossPremises-AuthMechanism: 04
X-MS-Exchange-CrossPremises-AuthSource: DB5PR04MB1029.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: 62.189.0.100
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: DB5PR04MB1030.eurprd04.prod.outlook.com
Archived-At: 
Cc: "slim@ietf.org" 
Subject: Re: [Slim] IETF95, Use Cases doc change proposals
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
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, 17 Mar 2016 15:41:23 -0000

--_000_90AF8946999C4C058AD1E9A17DA009E9gsmacom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Changes have now been included with the PR from Bernard. Thanks Bernard and=
 Gunnar!

Natasha


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


On Mar 16, 2016, at 5:13 AM, Gunnar Hellstr=F6m > wrote:

Hi Natasha and all,

I have a couple of suggestions for the use cases document:

1. In introduction, the words "real-time" and "necessary" are misspelled.

2. At the end of the introduction, I suggest the addition of:
"For each use case a 'Result' is provided, indicating the implementability =
of the use case based on draft version  draft-ietf-slim-negotiating-human-l=
anguage-00 "

3. The last line in section 3, Final comments look strange and should be ch=
anged to:
"There is no clear need for explicit grouping of language/modality indicati=
ons."

4. In the introduction, it looks as if the document contains  both real-tim=
e and non-real-time use cases. If only real-time use cases are provided, th=
en the introduction needs adaptation.

 /Gunnar

Den 2016-03-11 kl. 17:28, skrev Natasha Rooney:
Hi all!

IETF95 Deadline
Just a quick reminder that the IETF95 document submission deadline is comin=
g up fast (March 21st). I am going to submit the use cases draft before the=
n with the use cases I have collected from the last meeting. If you want to=
 see what we have so far then see the link below (excuse the xml):
https://github.com/ietf-slim-wg/slim-use-cases/blob/master/draft-ietf-slim-=
use-cases-latest.xml

Our Document Status
With regards to our two other documents, I believe the only issue we have i=
s regarding the dual modality use case, and the difficulty of dealing with =
this within real-time communications (this obviously only applies to draft-=
ietf-slim-negotiating-human-language-00). My question to you all is: do you=
 have any other outstanding issues with either draft? If not, we should be =
in a state to clean them up and publish.

Bernard and I are having a chairs chat next week so we can discuss plans fo=
r IETF95 and the document status, so please let us know before the end of T=
uesday next week as to whether you have any issues you wish to raise.

Thanks everyone!

Natasha


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


On Mar 2, 2016, at 4:37 PM, Natasha Rooney > wrote:

Hi all!

We are 1 month and 1 day away from the start of IETF95! Gasp! We have some =
work to get on with before IETF95, where we will have a very short (and hop=
efully fruitful meeting!) discussing the last issues we have remaining.

The IETF95 link is below for those of you who still need to book hotels:
https://ietf.org/meeting/95/index.html

I am going to be working on finishing the use cases document from now until=
 IETF95. Please submit any issues or pull requests to the github repo or te=
ll me directly:
https://github.com/ietf-slim-wg/slim-use-cases/

With our other two documents I believe the modality issues is still at larg=
e. Can someone catch me up on the last discussions here? I remember that we=
 were still discussing it and no decisions had been made - is this correct?=
 On discussions with other IETF attendees many said that dual modality - wh=
ilst supported by use cases - is awfully difficult to implement, is this th=
e same as the thoughts within this group?
https://datatracker.ietf.org/wg/slim/documents/

Thanks all!

Natasha

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



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

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



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



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

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


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_90AF8946999C4C058AD1E9A17DA009E9gsmacom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <1225C4AE62377A4E96A83335818309C2@eurprd04.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable






Changes have now been included with the PR from Bernard. Thanks Bernard and=
 Gunnar!









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;
















On Mar 16, 2016, at 5:13 AM, Gunnar Hellstr=F6m <gunnar.hellstrom@omnitor=
.se> wrote:






Hi Natasha and all,


I have a couple of suggestions for the use cases document:



1. In introduction, the words "real-time" and "necessary&quo=
t; are misspelled.



2. At the end of the introduction, I suggest the addition of:

"For each use case a 'Result' is provided, indicating the implementabi=
lity of the use case based on draft version 

draft-ietf-slim-negotiating-human-language-00 "



3. The last line in section 3, Final comments look strange and should be ch=
anged to:

"There
 is no clear need for explicit grouping of language/modality indications.&q=
uot;



4. In the introduction, it looks as if the document contains  both rea=
l-time and non-real-time use cases. If only real-time use cases are provide=
d, then the introduction needs adaptation.



 /Gunnar







Den 2016-03-11 kl. 17:28, skrev Natasha Roon=
ey:





Hi all!






IETF95 Deadline


Just a quick reminder that the IETF95 document submission d=
eadline is coming up fast (March 21st). I am going to submit the use cases draft before th=
en with the use cases I have collected from
 the last meeting. If you want to see what we have so far then see the link=
 below (excuse the xml):


https://github.com/ietf-slim-wg/slim-use-cases/blob/master/draft-=
ietf-slim-use-cases-latest.xml







Our Document Status


With regards to our two other documents, I believe the only=
 issue we have is regarding the dual modality use case, and the difficulty =
of dealing with this within real-time communications (this obviously only a=
pplies to draft-ietf-slim-negotiating-human-language-00).
 My question to you all is: do you have any other outstanding issues with either draft?
If not, we should be in a state to clean them up and publish.







Bernard and I are having a chairs chat next week so we can =
discuss plans for IETF95 and the document status, so please
let us know before the end=
 of Tuesday next week as to whether you have any issues you wish to raise.







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 
















On Mar 2, 2016, at 4:37 PM, Natasha Rooney <nrooney@gsma.co=
m> wrote:







Hi all!






We are 1 month and 1 day away from the start of IETF95! Gas=
p! We have some work to get on with before IETF95, where we will have a ver=
y short (and hopefully fruitful meeting!) discussing the last issues we hav=
e remaining.









The IETF95 link is below for those of you who still need to=
 book hotels:


https://ietf.org/meeting/95/index.html =
;







I am going to be working on finishing the use cases documen=
t from now until IETF95. Please submit any issues or pull requests to the g=
ithub repo or tell me directly:


https://github.com/ietf-slim-wg/slim-u=
se-cases/ 







With our other two documents I believe the modality issues =
is still at large. Can someone catch me up on the last discussions here? I =
remember that we were still discussing it and no decisions had been made - =
is this correct? On discussions with
 other IETF attendees many said that dual modality - whilst supported by us=
e cases - is awfully difficult to implement, is this the same as the though=
ts within this group?


https://datatracker.ietf.org/wg/slim/d=
ocuments/ 







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 















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. 



_______________________________________________

SLIM mailing list

SLIM@i=
etf.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. 




 


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







--=20
-----------------------------------------
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_90AF8946999C4C058AD1E9A17DA009E9gsmacom_--


From nobody Sun Mar 20 01:35:18 2016
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA6A712D6E6 for ; Sun, 20 Mar 2016 01:35:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5m6F0ml3KPcb for ; Sun, 20 Mar 2016 01:35:14 -0700 (PDT)
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 469CE12D6A5 for ; Sun, 20 Mar 2016 01:35:12 -0700 (PDT)
X-Halon-ID: a29af2d3-ee76-11e5-b13e-005056917c0c
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.11] (unknown [87.96.161.49]) by bin-vsp-out-04.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Sun, 20 Mar 2016 09:35:00 +0100 (CET)
To: slim@ietf.org
References: <20151102160934.3160.2433.idtracker@ietfa.amsl.com> <56E8FEF0.10503@omnitor.se>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: <56EE60B5.8080702@omnitor.se>
Date: Sun, 20 Mar 2016 09:35:01 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <56E8FEF0.10503@omnitor.se>
Content-Type: multipart/alternative; boundary="------------000507010103030404050506"
Archived-At: 
Subject: Re: [Slim] Change proposals for draft-ietf-slim-negotiating-human-language-00.txt
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
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, 20 Mar 2016 08:35:18 -0000

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

Randall and all,

Did you accept the change proposal in the previous mail on this subject?
It reverts the reasoning in section 5 about the current sdp 'lang' 
attribute in RFC4566.

It is not logical to say that the 'lang' attribute describes a series of 
languages that all must be used in the session.
One clear evidence that it is meant for selection by negotiation is that 
RFC4566 says that multiple 'lang' attributes is a list in order of 
importance.
If all were required to be used, the order of importance has no 
relevance on SDP level.

The main conclusion is then that the current 'lang' attribute is usable 
for all simple cases in conversational sessions with symmetric use of 
the same language/modality in both directions and with only one medium 
specified for language use.



(It is less clear what is meant if the 'lang' attribute is used for more 
than one medium or on session level and one or more media.
Is it a promise from the offering part to provide simultaneous 
interpretation or an offer to select one alternative.
So that would need a clarification for the 'lang' attribute as well as 
for the 'humintlang-' attributes.)


Regards
Gunnar


Den 2016-03-16 kl. 07:36, skrev Gunnar Hellström:
> In addition to the changes proposed in 
> draft-ietf-slim-negotiating-human-language-00 for the preference 
> regardless of media recently submitted, I have the following proposals 
> for changes:
>
> 1. Change the first paragraph of section 5 from:
> --------------------------------------------------------------------------------------------------
>   RFC 4566   specifies an attribute 'lang' which sounds similar to what
>     is needed here, the difference being that it specifies that 'a=lang'
>     is declarative with the semantics of multiple 'lang' attributes being
>     that all of them are used, while we want a means to negotiate which
>     one is used in each stream.  This difference means that the existing
>     'lang' attribute can't be used and we need to define a new attribute.
> -------------------------------------------------------------------------------
>
> to
> ---------------------------------------------------------------------------------------
>   RFC 4566   specifies an attribute 'lang' which sounds similar to what
>     is needed here. It specifies that 'a=lang'
>     is declarative with the semantics of multiple 'lang' attributes being
>     possible, indicating a number of possible languages in the session in
>     an order of preference. Each party declares their capabilities and the
>     language(s) used in the session can then be selected from the common set.
>     We have however a need to specify direction of use of each language,
>     and an order of preference between languages in different modalities.
>     This difference means that the existing 'lang' attribute is not sufficient
>     for our use and we need to complement it with definition of a new attribute.
> --------------------------------------------------------------------------------------------------
>
> 2. change the last two paragraphs of section 5 from:
> --------------------------------------------------------------------------------------------------------
>   A recent search of RFCs and Internet Drafts turned up only one use of
>     the 'lang' attribute (in a now-expired draft), and that sole use was
>     coincidentally in exactly the way we need (erroniously assuming that
>     the attribute was used for negotiation).  The sole use was in an
>     example in a draft not directly related to language, where the
>     initial invitation contains two 'a=lang' entries for a media stream
>     (for English and Italian) and the OK accepts one of them (Italian).
>
>     The example serves as evidence of the need for an SDP attribute with
>     the semantics as described in this document; unfortunately, the
>     existing 'lang' attribute is not it.
> ----------------------------------------------------------------------
> to
> -----------------------------------------------------------------------------
>   A recent search of RFCs and Internet Drafts turned up only one use of
>     the 'lang' attribute (in a now-expired draft), and that sole use was
>     coincidentally in exactly the way we need.  The sole use was in an
>     example in a draft not directly related to language, where the
>     initial invitation contains two 'a=lang' entries for a media stream
>     (for English and Italian) and the OK accepts one of them (Italian).
>
>     This use was questioned in a discussion of that draft because of this
>     sentence in RFC 4566: "Multiple lang attributes can be
>        provided either at session or media level if the session
>        description or media use multiple languages."
>     An interpretation was that all declared languages must be used in
>     the session, while the example showed use of a selection of the
>     originally indicated languages. The uncertainty caused withdrawal
>     of the example because it was not essential for the draft.
>
>    However, studying the wording in RFC 4566 further, it is evident
>    that a negotiation of languages was intended for the real-time case.
>    When sdp is used to declare contents of a recorded session, then it
>    makes sense to list the provided languages, while for a real-time
>    session, it is obvious that the capabilities of the parties and the
>    development of the session influence the selection of language for
>    the session.
>    The continuation in RFC 4566 "the order of the attributes indicates
>    the order of importance of the various languages" makes it very clear
>    that the list shall be seen as a list for selection and negotiation.
>    The "order of importance" has no meaning if all languages must be provided.
>
>    The conclusion is that the 'lang' attribute can be used for negotiation
>    of one or more common languages to select from for use in a real-time session.
>    A clarification is prepared for a possible future revision of RFC 4566.
>
>    Thus, the 'lang' attribute satisfies our needs in many cases.
>
>    Unfortunately, there are cases, where the users need to use different
>    modalities in different directions, and when it is important to combine
>    languages in different modalities. The 'lang' attribute does not have
>    the details needed to cover these cases."
> -------------------------------------------------------------------------------------------------
>
> 3. Change section 6 from:
> -------------------------------------------------------
> 6 Proposed Solution
>     An SDP attribute seems the natural choice to negotiate human
>     (natural) language of an interactive media stream.  The attribute
>     value should be a language tag perRFC 5646   [RFC5646 ] "
> ------------------------------------------------------------------
> to
> -----------------------------------------------------------------------
> 6 Proposed Solution
>     An SDP attribute seems the natural choice to negotiate human
>     (natural) language of an interactive media stream.  The attribute
>     value should be a language tag perRFC 5646   [RFC5646 ]
>     The new attribute can appear together with the existing 'lang'
>     attribute to compose the preferred language/modality combinations
>     offered or negotiated.
> ----------------------------------------------------------------------
>
>   
> Regards
>
> Gunnar
>
>
>
>
> Den 2015-11-02 kl. 17:09, skrev internet-drafts@ietf.org:
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>   This draft is a work item of the Selection of Language for Internet Media 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/
>>
>> _______________________________________________
>> I-D-Announce mailing list
>> I-D-Announce@ietf.org
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> Internet-Draft directories:http://www.ietf.org/shadow.html
>> orftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
> -- 
> -----------------------------------------
> Gunnar Hellström
> Omnitor
> gunnar.hellstrom@omnitor.se
> +46 708 204 288
>
>
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim

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


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


  
    
  
  
    Randall and all,

    

    Did you accept the change proposal in the previous mail on this
    subject?

    It reverts the reasoning in section 5 about the current sdp 'lang'
    attribute in RFC4566.

    

    It is not logical to say that the 'lang' attribute describes a
    series of languages that all must be used in the session.

    One clear evidence that it is meant for selection by negotiation is
    that RFC4566 says that multiple 'lang' attributes is a list in order
    of importance.

    If all were required to be used, the order of importance has no
    relevance on SDP level. 

    

    The main conclusion is then that the current 'lang' attribute is
    usable for all simple cases in conversational sessions with
    symmetric use of the same language/modality in both directions and
    with only one medium specified for language use. 

    

    

    

    (It is less clear what is meant if the 'lang' attribute is used for
    more than one medium or on session level and one or more media.

    Is it a promise from the offering part to provide simultaneous
    interpretation or an offer to select one alternative.  

    So that would need a clarification for the 'lang' attribute as well
    as for the 'humintlang-' attributes.)

    

    

    Regards

    Gunnar

    

    

    
Den 2016-03-16 kl. 07:36, skrev Gunnar
      Hellström:

    

    

      
      In addition to the changes proposed in
      draft-ietf-slim-negotiating-human-language-00 for the preference
      regardless of media recently submitted, I have the following
      proposals for changes:

      

      1. Change the first paragraph of section 5 from:

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

      
 RFC 4566 specifies an attribute 'lang' which sounds similar to what
   is needed here, the difference being that it specifies that 'a=lang'
   is declarative with the semantics of multiple 'lang' attributes being
   that all of them are used, while we want a means to negotiate which
   one is used in each stream.  This difference means that the existing
   'lang' attribute can't be used and we need to define a new attribute.  
-------------------------------------------------------------------------------


      

      to

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

      
 RFC 4566 specifies an attribute 'lang' which sounds similar to what
   is needed here. It specifies that 'a=lang'
   is declarative with the semantics of multiple 'lang' attributes being
   possible, indicating a number of possible languages in the session in
   an order of preference. Each party declares their capabilities and the
   language(s) used in the session can then be selected from the common set.
   We have however a need to specify direction of use of each language, 
   and an order of preference between languages in different modalities.
   This difference means that the existing 'lang' attribute is not sufficient 
   for our use and we need to complement it with definition of a new attribute.
--------------------------------------------------------------------------------------------------


      

      2. change the last two paragraphs of section 5 from:

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

      
 A recent search of RFCs and Internet Drafts turned up only one use of
   the 'lang' attribute (in a now-expired draft), and that sole use was
   coincidentally in exactly the way we need (erroniously assuming that
   the attribute was used for negotiation).  The sole use was in an
   example in a draft not directly related to language, where the
   initial invitation contains two 'a=lang' entries for a media stream
   (for English and Italian) and the OK accepts one of them (Italian).

   The example serves as evidence of the need for an SDP attribute with
   the semantics as described in this document; unfortunately, the
   existing 'lang' attribute is not it.
----------------------------------------------------------------------
to
-----------------------------------------------------------------------------
 A recent search of RFCs and Internet Drafts turned up only one use of
   the 'lang' attribute (in a now-expired draft), and that sole use was
   coincidentally in exactly the way we need.  The sole use was in an
   example in a draft not directly related to language, where the
   initial invitation contains two 'a=lang' entries for a media stream
   (for English and Italian) and the OK accepts one of them (Italian).

   This use was questioned in a discussion of that draft because of this
   sentence in RFC 4566: "Multiple lang attributes can be
      provided either at session or media level if the session
      description or media use multiple languages."
   An interpretation was that all declared languages must be used in 
   the session, while the example showed use of a selection of the 
   originally indicated languages. The uncertainty caused withdrawal 
   of the example because it was not essential for the draft.

  However, studying the wording in RFC 4566 further, it is evident 
  that a negotiation of languages was intended for the real-time case. 
  When sdp is used to declare contents of a recorded session, then it 
  makes sense to list the provided languages, while for a real-time 
  session, it is obvious that the capabilities of the parties and the 
  development of the session influence the selection of language for 
  the session.
  The continuation in RFC 4566 "the order of the attributes indicates 
  the order of importance of the various languages" makes it very clear
  that the list shall be seen as a list for selection and negotiation. 
  The "order of importance" has no meaning if all languages must be provided.

  The conclusion is that the 'lang' attribute can be used for negotiation 
  of one or more common languages to select from for use in a real-time session. 
  A clarification is prepared for a possible future revision of RFC 4566. 

  Thus, the 'lang' attribute satisfies our needs in many cases.

  Unfortunately, there are cases, where the users need to use different 
  modalities in different directions, and when it is important to combine 
  languages in different modalities. The 'lang' attribute does not have 
  the details needed to cover these cases."
-------------------------------------------------------------------------------------------------

3. Change section 6 from:
-------------------------------------------------------
6 Proposed Solution

      
   An SDP attribute seems the natural choice to negotiate human
   (natural) language of an interactive media stream.  The attribute
   value should be a language tag per RFC 5646 [RFC5646] "
------------------------------------------------------------------
to
-----------------------------------------------------------------------
6 Proposed Solution
   An SDP attribute seems the natural choice to negotiate human
   (natural) language of an interactive media stream.  The attribute
   value should be a language tag per RFC 5646 [RFC5646]
   The new attribute can appear together with the existing 'lang' 
   attribute to compose the preferred language/modality combinations 
   offered or negotiated.
----------------------------------------------------------------------

 
Regards

Gunnar




       

      

      
Den 2015-11-02 kl. 17:09, skrev internet-drafts@ietf.org:

      

      

        
A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Selection of Language for Internet Media 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/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


      

      

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

      

      

      

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


    

    

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

  


--------------000507010103030404050506--


From nobody Sun Mar 20 12:27:47 2016
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 DE30312DD8F; Fri, 11 Mar 2016 15:05:44 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "\"IETF Secretariat\"" 
To: , 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.16.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160311230544.15028.43289.idtracker@ietfa.amsl.com>
Date: Fri, 11 Mar 2016 15:05:44 -0800
Archived-At: 
X-Mailman-Approved-At: Sun, 20 Mar 2016 12:27:44 -0700
Cc: slim@ietf.org, barryleiba@computer.org
Subject: [Slim] slim - Requested session has been scheduled for IETF 95
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Mar 2016 23:05:45 -0000

Dear N Rooney,

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

slim Session 1 (1:30:00)
    Thursday, Afternoon Session II 1620-1720
    Room Name: Quebracho B size: 75
    ---------------------------------------------
    


Request Information:


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

Number of Sessions: 1
Length of Session(s):  1.5 Hours
Number of Attendees: 20
Conflicts to Avoid: 
 First Priority: ecrit




Special Requests:
  Currently our chair cannot attend due to a clash with him needing to talk at another event (he is attending remotely), is there any way we can change to another time?
---------------------------------------------------------


From nobody Sun Mar 20 12:28:51 2016
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 9E65912D624; Wed,  9 Mar 2016 05:50:27 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "\"IETF Meeting Session Request Tool\"" 
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.16.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160309135027.22762.30966.idtracker@ietfa.amsl.com>
Date: Wed, 09 Mar 2016 05:50:27 -0800
Archived-At: 
X-Mailman-Approved-At: Sun, 20 Mar 2016 12:28:51 -0700
Cc: slim@ietf.org, barryleiba@computer.org, nrooney@gsma.com, slim-chairs@ietf.org
Subject: [Slim] slim - Update to a Meeting Session Request for IETF 95
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 09 Mar 2016 13:50:27 -0000

An update to a meeting session request has just been submitted by Natasha Rooney, a Chair of the slim working group.


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

Number of Sessions: 1
Length of Session(s):  1.5 Hours
Number of Attendees: 20
Conflicts to Avoid: 
 First Priority: ecrit




Special Requests:
  Currently our chair cannot attend due to a clash with him needing to talk at another event (he is attending remotely), is there any way we can change to another time?
---------------------------------------------------------


From nobody Sun Mar 20 17:35:10 2016
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDF0B12D7E9 for ; Sun, 20 Mar 2016 17:35:09 -0700 (PDT)
X-Quarantine-ID: 
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -0.002
X-Spam-Level: 
X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ryd0y8FDUoih for ; Sun, 20 Mar 2016 17:35:08 -0700 (PDT)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 49B6812D52E for ; Sun, 20 Mar 2016 17:35:08 -0700 (PDT)
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Sun, 20 Mar 2016 17:35:07 -0700
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <56E8FEF0.10503@omnitor.se>
References: <20151102160934.3160.2433.idtracker@ietfa.amsl.com> <56E8FEF0.10503@omnitor.se>
X-Mailer: Eudora for Mac OS X
Date: Sun, 20 Mar 2016 17:32:21 -0700
To: Gunnar =?iso-8859-1?Q?Hellstr=F6m?=  , "slim@ietf.org" 
From: Randall Gellens 
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
Content-Transfer-Encoding: quoted-printable
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: 
Subject: Re: [Slim] Change proposals for draft-ietf-slim-negotiating-human-language-00.txt
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
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, 21 Mar 2016 00:35:10 -0000

Hi Gunnar,

Thanks very much for your comments.  Please see in-line:

At 7:36 AM +0100 3/16/16, Gunnar Hellstr=F6m wrote:

>  In addition to the changes proposed in=20
> draft-ietf-slim-negotiating-human-language-00=20
> for the preference regardless of media recently=20
> submitted, I have the following proposals for=20
> changes:
>
>  1. Change the first paragraph of section 5 from:
>=20
> --------------------------------------------------------------------------=
------------------------
>   RFC 4566=20
> specifies an attribute 'lang' which sounds=20
> similar to what
>     is needed here, the difference being that it specifies that 'a=3Dlang'
>     is declarative with the semantics of multiple 'lang' attributes being
>     that all of them are used, while we want a means to negotiate which
>     one is used in each stream.  This difference means that the existing
>     'lang' attribute can't be used and we need to define a new attribute. 
>=20
> --------------------------------------------------------------------------=
-----
>
>  to
>=20
> --------------------------------------------------------------------------=
-------------
>   RFC 4566=20
> specifies an attribute 'lang' which sounds=20
> similar to what
>     is needed here. It specifies that 'a=3Dlang'
>     is declarative with the semantics of multiple 'lang' attributes being
>     possible, indicating a number of possible languages in the session in
>     an order of preference. Each party declares their capabilities and the
>     language(s) used in the session can then be selected from the common s=
et.
>     We have however a need to specify direction of use of each language,
>     and an order of preference between languages in different modalities.
>     This difference means that the existing 'lang' attribute is not suffic=
ient
>     for our use and we need to complement it=20
> with definition of a new attribute.
>=20
> --------------------------------------------------------------------------=
------------------------

I disagree.  I've reread the text in the draft=20
and in RFC 4566 multiple times.  However, I added=20
clarifying wording to the draft.

>
>  2. change the last two paragraphs of section 5 from:
>=20
> --------------------------------------------------------------------------=
------------------------------
>   A recent search of RFCs and Internet Drafts turned up only one use of
>     the 'lang' attribute (in a now-expired draft), and that sole use was
>     coincidentally in exactly the way we need (erroniously assuming that
>     the attribute was used for negotiation).  The sole use was in an
>     example in a draft not directly related to language, where the
>     initial invitation contains two 'a=3Dlang' entries for a media stream
>     (for English and Italian) and the OK accepts one of them (Italian).
>
>     The example serves as evidence of the need for an SDP attribute with
>     the semantics as described in this document; unfortunately, the
>     existing 'lang' attribute is not it.
>  ----------------------------------------------------------------------
>  to
>  -------------------------------------------------------------------------=
----
>   A recent search of RFCs and Internet Drafts turned up only one use of
>     the 'lang' attribute (in a now-expired draft), and that sole use was
>     coincidentally in exactly the way we need.  The sole use was in an
>     example in a draft not directly related to language, where the
>     initial invitation contains two 'a=3Dlang' entries for a media stream
>     (for English and Italian) and the OK accepts one of them (Italian).
>
>     This use was questioned in a discussion of that draft because of this
>     sentence in RFC 4566: "Multiple lang attributes can be
>        provided either at session or media level if the session
>        description or media use multiple languages."
>     An interpretation was that all declared languages must be used in
>     the session, while the example showed use of a selection of the
>     originally indicated languages. The uncertainty caused withdrawal
>     of the example because it was not essential for the draft.
>
>    However, studying the wording in RFC 4566 further, it is evident
>    that a negotiation of languages was intended for the real-time case.
>    When sdp is used to declare contents of a recorded session, then it
>    makes sense to list the provided languages, while for a real-time
>    session, it is obvious that the capabilities of the parties and the
>    development of the session influence the selection of language for
>    the session.
>    The continuation in RFC 4566 "the order of the attributes indicates
>    the order of importance of the various languages" makes it very clear
>    that the list shall be seen as a list for selection and negotiation.
>    The "order of importance" has no meaning if all languages must be provi=
ded.
>
>    The conclusion is that the 'lang' attribute can be used for negotiation
>    of one or more common languages to select=20
> from for use in a real-time session.
>    A clarification is prepared for a possible future revision of RFC 4566.
>
>    Thus, the 'lang' attribute satisfies our needs in many cases.
>
>    Unfortunately, there are cases, where the users need to use different
>    modalities in different directions, and when it is important to combine
>    languages in different modalities. The 'lang' attribute does not have
>    the details needed to cover these cases."
>=20
> --------------------------------------------------------------------------=
-----------------------

While I disagree with your interpretation, I=20
don't think it's needed to go into this level of=20
detail at this point in the draft, so I left it=20
unchanged.


>
>  3. Change section 6 from:
>  -------------------------------------------------------
>  6 Proposed Solution
>     An SDP attribute seems the natural choice to negotiate human
>     (natural) language of an interactive media stream.  The attribute
>     value should be a language tag per=20
> RFC 5646=20
> [RFC5646] "
>  ------------------------------------------------------------------
>  to
>  -----------------------------------------------------------------------
>  6 Proposed Solution
>     An SDP attribute seems the natural choice to negotiate human
>     (natural) language of an interactive media stream.  The attribute
>     value should be a language tag per=20
> RFC 5646=20
> [RFC5646]
>     The new attribute can appear together with the existing 'lang'
>     attribute to compose the preferred language/modality combinations
>     offered or negotiated.
>  ----------------------------------------------------------------------

I don't think we have consensus on doing this, so I left it unchanged.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Citizens for corrupt government, unclean water, higher taxes,
unsafe streets, and poor schools.


From nobody Sun Mar 20 23:19:51 2016
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87E4712D68B for ; Sun, 20 Mar 2016 23:19:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FXLcxxqXip9s for ; Sun, 20 Mar 2016 23:19:46 -0700 (PDT)
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 3259612D603 for ; Sun, 20 Mar 2016 23:19:46 -0700 (PDT)
X-Halon-ID: e1554be7-ef2c-11e5-b13e-005056917c0c
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.4] (unknown [87.96.161.49]) by bin-vsp-out-04.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Mon, 21 Mar 2016 07:19:34 +0100 (CET)
To: Randall Gellens , "slim@ietf.org" 
References: <20151102160934.3160.2433.idtracker@ietfa.amsl.com> <56E8FEF0.10503@omnitor.se> 
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: <56EF9277.7040306@omnitor.se>
Date: Mon, 21 Mar 2016 07:19:35 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [Slim] Change proposals for draft-ietf-slim-negotiating-human-language-00.txt
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
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, 21 Mar 2016 06:19:49 -0000

Randall,

I think it is unfair to RFC 4566 and RFC 3264 that we force an 
interpretation of the use of the 'lang' attribute on them that we do not 
agree on.

If we do not come to an agreement, we could instead just refrain from 
documenting an interpretation of how the 'lang' attribute works and  
conclude with

"Unfortunately, there are cases, where the users need to use different
    modalities in different directions, and when it is important to combine
    languages in different modalities. The 'lang' attribute does not have
    the details needed to cover these cases."

We must also make sure that we do not make the same kind of 
unders-pecification as apparently has been done in RFC 4566.
We need to describe what it means if we have language indications for 
the same direction in two (or more) media.
Shall it be understood as an indication that
     1) I am prepared to use both in the session or that
     2) I require both to be used or that
     3) I am not prepared to use both but offer them for selection.
If the normal interpretation is that it is for selection of one, how is 
the preference for one or the other indicated?
And if the normal interpretation is for a selection, how do we then 
indicate the case when we really strongly prefer to get both. ( e.g. 
voice plus captions ).

We also need to describe how use of both 'lang' and 'humintlang-' 
attributes in the same sdp shall be interpreted.

Regards

Gunnar


Den 2016-03-21 kl. 01:32, skrev Randall Gellens:
> Hi Gunnar,
>
> Thanks very much for your comments.  Please see in-line:
>
> At 7:36 AM +0100 3/16/16, Gunnar Hellström wrote:
>
>>  In addition to the changes proposed in 
>> draft-ietf-slim-negotiating-human-language-00 for the preference 
>> regardless of media recently submitted, I have the following 
>> proposals for changes:
>>
>>  1. Change the first paragraph of section 5 from:
>>
>> -------------------------------------------------------------------------------------------------- 
>>
>>   RFC 4566 specifies an 
>> attribute 'lang' which sounds similar to what
>>     is needed here, the difference being that it specifies that 'a=lang'
>>     is declarative with the semantics of multiple 'lang' attributes 
>> being
>>     that all of them are used, while we want a means to negotiate which
>>     one is used in each stream.  This difference means that the existing
>>     'lang' attribute can't be used and we need to define a new 
>> attribute.
>> ------------------------------------------------------------------------------- 
>>
>>
>>  to
>>
>> --------------------------------------------------------------------------------------- 
>>
>>   RFC 4566 specifies an 
>> attribute 'lang' which sounds similar to what
>>     is needed here. It specifies that 'a=lang'
>>     is declarative with the semantics of multiple 'lang' attributes 
>> being
>>     possible, indicating a number of possible languages in the 
>> session in
>>     an order of preference. Each party declares their capabilities 
>> and the
>>     language(s) used in the session can then be selected from the 
>> common set.
>>     We have however a need to specify direction of use of each language,
>>     and an order of preference between languages in different 
>> modalities.
>>     This difference means that the existing 'lang' attribute is not 
>> sufficient
>>     for our use and we need to complement it with definition of a new 
>> attribute.
>>
>> -------------------------------------------------------------------------------------------------- 
>>
>
> I disagree.  I've reread the text in the draft and in RFC 4566 
> multiple times.  However, I added clarifying wording to the draft.
>
>>
>>  2. change the last two paragraphs of section 5 from:
>>
>> -------------------------------------------------------------------------------------------------------- 
>>
>>   A recent search of RFCs and Internet Drafts turned up only one use of
>>     the 'lang' attribute (in a now-expired draft), and that sole use was
>>     coincidentally in exactly the way we need (erroniously assuming that
>>     the attribute was used for negotiation).  The sole use was in an
>>     example in a draft not directly related to language, where the
>>     initial invitation contains two 'a=lang' entries for a media stream
>>     (for English and Italian) and the OK accepts one of them (Italian).
>>
>>     The example serves as evidence of the need for an SDP attribute with
>>     the semantics as described in this document; unfortunately, the
>>     existing 'lang' attribute is not it.
>>  ----------------------------------------------------------------------
>>  to
>>  ----------------------------------------------------------------------------- 
>>
>>   A recent search of RFCs and Internet Drafts turned up only one use of
>>     the 'lang' attribute (in a now-expired draft), and that sole use was
>>     coincidentally in exactly the way we need.  The sole use was in an
>>     example in a draft not directly related to language, where the
>>     initial invitation contains two 'a=lang' entries for a media stream
>>     (for English and Italian) and the OK accepts one of them (Italian).
>>
>>     This use was questioned in a discussion of that draft because of 
>> this
>>     sentence in RFC 4566: "Multiple lang attributes can be
>>        provided either at session or media level if the session
>>        description or media use multiple languages."
>>     An interpretation was that all declared languages must be used in
>>     the session, while the example showed use of a selection of the
>>     originally indicated languages. The uncertainty caused withdrawal
>>     of the example because it was not essential for the draft.
>>
>>    However, studying the wording in RFC 4566 further, it is evident
>>    that a negotiation of languages was intended for the real-time case.
>>    When sdp is used to declare contents of a recorded session, then it
>>    makes sense to list the provided languages, while for a real-time
>>    session, it is obvious that the capabilities of the parties and the
>>    development of the session influence the selection of language for
>>    the session.
>>    The continuation in RFC 4566 "the order of the attributes indicates
>>    the order of importance of the various languages" makes it very clear
>>    that the list shall be seen as a list for selection and negotiation.
>>    The "order of importance" has no meaning if all languages must be 
>> provided.
>>
>>    The conclusion is that the 'lang' attribute can be used for 
>> negotiation
>>    of one or more common languages to select from for use in a 
>> real-time session.
>>    A clarification is prepared for a possible future revision of RFC 
>> 4566.
>>
>>    Thus, the 'lang' attribute satisfies our needs in many cases.
>>
>>    Unfortunately, there are cases, where the users need to use different
>>    modalities in different directions, and when it is important to 
>> combine
>>    languages in different modalities. The 'lang' attribute does not have
>>    the details needed to cover these cases."
>>
>> ------------------------------------------------------------------------------------------------- 
>>
>
> While I disagree with your interpretation, I don't think it's needed 
> to go into this level of detail at this point in the draft, so I left 
> it unchanged.
>
>
>>
>>  3. Change section 6 from:
>>  -------------------------------------------------------
>>  6 Proposed Solution
>>     An SDP attribute seems the natural choice to negotiate human
>>     (natural) language of an interactive media stream.  The attribute
>>     value should be a language tag per 
>> RFC 5646 
>> [RFC5646] "
>>  ------------------------------------------------------------------
>>  to
>>  -----------------------------------------------------------------------
>>  6 Proposed Solution
>>     An SDP attribute seems the natural choice to negotiate human
>>     (natural) language of an interactive media stream.  The attribute
>>     value should be a language tag per 
>> RFC 5646 
>> [RFC5646]
>>     The new attribute can appear together with the existing 'lang'
>>     attribute to compose the preferred language/modality combinations
>>     offered or negotiated.
>>  ----------------------------------------------------------------------
>
> I don't think we have consensus on doing this, so I left it unchanged.
>

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


From nobody Mon Mar 21 07:37:12 2016
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CED2C12D849 for ; Mon, 21 Mar 2016 07:37:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.935
X-Spam-Level: 
X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vaeo82OwJSL6 for ; Mon, 21 Mar 2016 07:37:10 -0700 (PDT)
Received: from resqmta-ch2-09v.sys.comcast.net (resqmta-ch2-09v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:41]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 108E912D6AC for ; Mon, 21 Mar 2016 07:37:10 -0700 (PDT)
Received: from resomta-ch2-13v.sys.comcast.net ([69.252.207.109]) by resqmta-ch2-09v.sys.comcast.net with comcast id YeWm1s0072N9P4d01ed9Vh; Mon, 21 Mar 2016 14:37:09 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-13v.sys.comcast.net with comcast id Yed81s00H3KdFy101ed8B6; Mon, 21 Mar 2016 14:37:09 +0000
To: slim@ietf.org
References: <20151102160934.3160.2433.idtracker@ietfa.amsl.com> <56E8FEF0.10503@omnitor.se>  <56EF9277.7040306@omnitor.se>
From: Paul Kyzivat 
Message-ID: <56F00713.5020408@alum.mit.edu>
Date: Mon, 21 Mar 2016 10:37:07 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.7.0
MIME-Version: 1.0
In-Reply-To: <56EF9277.7040306@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=1458571029; bh=an3/wS/UlBTPiAwWOQW/Mo1/JHAuS17lY+yjL5qLCZs=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=TT4wrxkqBCZvf08OReebuqHbjpwgFXjiS7eJ09xITe02FjdoR6/dR5r5awrbW/Fqr uOvKetKHemHuHVDTTNgL795JM9ydKyI0wIf0wBUqQmJ1KDFk0G6/EWE4MSO9fYkR0I dBcWmr5VXX+wvsTOi0VzbbIl+2KwVls/TV+I2lNB5gCgQIOSOaut9qanJ2e+ZAhykh C0d1WpjcXYsFdNWaG+8nOdWv4HCP4BhYr3pxbeVCtnx7M4jVi1PzbeT1uBRLSo0gzk Qcxt0/bcmPo9N2fpfn9CeC45V9lenD8Kz0ONyO7tGhVi6KgMqr0ASX7DbNSaiNOT2q 7s4TIoXb3Ptnw==
Archived-At: 
Subject: Re: [Slim] Change proposals for draft-ietf-slim-negotiating-human-language-00.txt
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
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, 21 Mar 2016 14:37:12 -0000

In case you don't know, there is an rfc4566bis in progress.

If there is a problem with the precision of the definition of a=lang, it 
is possible to get it refined in 4566bis. However this will be 
constrained by backward compatibility issues. So it can probably be 
*clarified* as long as there isn't a lot of disagreement about what it 
means.

	Thanks,
	Paul

On 3/21/16 2:19 AM, Gunnar Hellström wrote:
> Randall,
>
> I think it is unfair to RFC 4566 and RFC 3264 that we force an
> interpretation of the use of the 'lang' attribute on them that we do not
> agree on.
>
> If we do not come to an agreement, we could instead just refrain from
> documenting an interpretation of how the 'lang' attribute works and
> conclude with
>
> "Unfortunately, there are cases, where the users need to use different
>     modalities in different directions, and when it is important to combine
>     languages in different modalities. The 'lang' attribute does not have
>     the details needed to cover these cases."
>
> We must also make sure that we do not make the same kind of
> unders-pecification as apparently has been done in RFC 4566.
> We need to describe what it means if we have language indications for
> the same direction in two (or more) media.
> Shall it be understood as an indication that
>      1) I am prepared to use both in the session or that
>      2) I require both to be used or that
>      3) I am not prepared to use both but offer them for selection.
> If the normal interpretation is that it is for selection of one, how is
> the preference for one or the other indicated?
> And if the normal interpretation is for a selection, how do we then
> indicate the case when we really strongly prefer to get both. ( e.g.
> voice plus captions ).
>
> We also need to describe how use of both 'lang' and 'humintlang-'
> attributes in the same sdp shall be interpreted.
>
> Regards
>
> Gunnar
>
>
> Den 2016-03-21 kl. 01:32, skrev Randall Gellens:
>> Hi Gunnar,
>>
>> Thanks very much for your comments.  Please see in-line:
>>
>> At 7:36 AM +0100 3/16/16, Gunnar Hellström wrote:
>>
>>>  In addition to the changes proposed in
>>> draft-ietf-slim-negotiating-human-language-00 for the preference
>>> regardless of media recently submitted, I have the following
>>> proposals for changes:
>>>
>>>  1. Change the first paragraph of section 5 from:
>>>
>>> --------------------------------------------------------------------------------------------------
>>>
>>>   RFC 4566 specifies an
>>> attribute 'lang' which sounds similar to what
>>>     is needed here, the difference being that it specifies that 'a=lang'
>>>     is declarative with the semantics of multiple 'lang' attributes
>>> being
>>>     that all of them are used, while we want a means to negotiate which
>>>     one is used in each stream.  This difference means that the existing
>>>     'lang' attribute can't be used and we need to define a new
>>> attribute.
>>> -------------------------------------------------------------------------------
>>>
>>>
>>>  to
>>>
>>> ---------------------------------------------------------------------------------------
>>>
>>>   RFC 4566 specifies an
>>> attribute 'lang' which sounds similar to what
>>>     is needed here. It specifies that 'a=lang'
>>>     is declarative with the semantics of multiple 'lang' attributes
>>> being
>>>     possible, indicating a number of possible languages in the
>>> session in
>>>     an order of preference. Each party declares their capabilities
>>> and the
>>>     language(s) used in the session can then be selected from the
>>> common set.
>>>     We have however a need to specify direction of use of each language,
>>>     and an order of preference between languages in different
>>> modalities.
>>>     This difference means that the existing 'lang' attribute is not
>>> sufficient
>>>     for our use and we need to complement it with definition of a new
>>> attribute.
>>>
>>> --------------------------------------------------------------------------------------------------
>>>
>>
>> I disagree.  I've reread the text in the draft and in RFC 4566
>> multiple times.  However, I added clarifying wording to the draft.
>>
>>>
>>>  2. change the last two paragraphs of section 5 from:
>>>
>>> --------------------------------------------------------------------------------------------------------
>>>
>>>   A recent search of RFCs and Internet Drafts turned up only one use of
>>>     the 'lang' attribute (in a now-expired draft), and that sole use was
>>>     coincidentally in exactly the way we need (erroniously assuming that
>>>     the attribute was used for negotiation).  The sole use was in an
>>>     example in a draft not directly related to language, where the
>>>     initial invitation contains two 'a=lang' entries for a media stream
>>>     (for English and Italian) and the OK accepts one of them (Italian).
>>>
>>>     The example serves as evidence of the need for an SDP attribute with
>>>     the semantics as described in this document; unfortunately, the
>>>     existing 'lang' attribute is not it.
>>>  ----------------------------------------------------------------------
>>>  to
>>>  -----------------------------------------------------------------------------
>>>
>>>   A recent search of RFCs and Internet Drafts turned up only one use of
>>>     the 'lang' attribute (in a now-expired draft), and that sole use was
>>>     coincidentally in exactly the way we need.  The sole use was in an
>>>     example in a draft not directly related to language, where the
>>>     initial invitation contains two 'a=lang' entries for a media stream
>>>     (for English and Italian) and the OK accepts one of them (Italian).
>>>
>>>     This use was questioned in a discussion of that draft because of
>>> this
>>>     sentence in RFC 4566: "Multiple lang attributes can be
>>>        provided either at session or media level if the session
>>>        description or media use multiple languages."
>>>     An interpretation was that all declared languages must be used in
>>>     the session, while the example showed use of a selection of the
>>>     originally indicated languages. The uncertainty caused withdrawal
>>>     of the example because it was not essential for the draft.
>>>
>>>    However, studying the wording in RFC 4566 further, it is evident
>>>    that a negotiation of languages was intended for the real-time case.
>>>    When sdp is used to declare contents of a recorded session, then it
>>>    makes sense to list the provided languages, while for a real-time
>>>    session, it is obvious that the capabilities of the parties and the
>>>    development of the session influence the selection of language for
>>>    the session.
>>>    The continuation in RFC 4566 "the order of the attributes indicates
>>>    the order of importance of the various languages" makes it very clear
>>>    that the list shall be seen as a list for selection and negotiation.
>>>    The "order of importance" has no meaning if all languages must be
>>> provided.
>>>
>>>    The conclusion is that the 'lang' attribute can be used for
>>> negotiation
>>>    of one or more common languages to select from for use in a
>>> real-time session.
>>>    A clarification is prepared for a possible future revision of RFC
>>> 4566.
>>>
>>>    Thus, the 'lang' attribute satisfies our needs in many cases.
>>>
>>>    Unfortunately, there are cases, where the users need to use different
>>>    modalities in different directions, and when it is important to
>>> combine
>>>    languages in different modalities. The 'lang' attribute does not have
>>>    the details needed to cover these cases."
>>>
>>> -------------------------------------------------------------------------------------------------
>>>
>>
>> While I disagree with your interpretation, I don't think it's needed
>> to go into this level of detail at this point in the draft, so I left
>> it unchanged.
>>
>>
>>>
>>>  3. Change section 6 from:
>>>  -------------------------------------------------------
>>>  6 Proposed Solution
>>>     An SDP attribute seems the natural choice to negotiate human
>>>     (natural) language of an interactive media stream.  The attribute
>>>     value should be a language tag per
>>> RFC 5646
>>> [RFC5646] "
>>>  ------------------------------------------------------------------
>>>  to
>>>  -----------------------------------------------------------------------
>>>  6 Proposed Solution
>>>     An SDP attribute seems the natural choice to negotiate human
>>>     (natural) language of an interactive media stream.  The attribute
>>>     value should be a language tag per
>>> RFC 5646
>>> [RFC5646]
>>>     The new attribute can appear together with the existing 'lang'
>>>     attribute to compose the preferred language/modality combinations
>>>     offered or negotiated.
>>>  ----------------------------------------------------------------------
>>
>> I don't think we have consensus on doing this, so I left it unchanged.
>>
>


From nobody Mon Mar 21 09:15:00 2016
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 AE68112D585; Mon, 21 Mar 2016 09:14:56 -0700 (PDT)
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.17.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160321161456.31933.65175.idtracker@ietfa.amsl.com>
Date: Mon, 21 Mar 2016 09:14:56 -0700
Archived-At: 
Cc: slim@ietf.org
Subject: [Slim] I-D Action: draft-ietf-slim-negotiating-human-language-01.txt
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Mar 2016 16:14:56 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Selection of Language for Internet Media of the IETF.

        Title           : Negotiating Human Language in Real-Time Communications
        Author          : Randall Gellens
	Filename        : draft-ietf-slim-negotiating-human-language-01.txt
	Pages           : 18
	Date            : 2016-03-21

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

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


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Mon Mar 21 09:53:58 2016
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A36612D5A7 for ; Mon, 21 Mar 2016 09:53:55 -0700 (PDT)
X-Quarantine-ID: 
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JGDWGQSipp7W for ; Mon, 21 Mar 2016 09:53:53 -0700 (PDT)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 0A5CD12D512 for ; Mon, 21 Mar 2016 09:53:53 -0700 (PDT)
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Mon, 21 Mar 2016 09:53:52 -0700
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <56EF9277.7040306@omnitor.se>
References: <20151102160934.3160.2433.idtracker@ietfa.amsl.com> <56E8FEF0.10503@omnitor.se>  <56EF9277.7040306@omnitor.se>
X-Mailer: Eudora for Mac OS X
Date: Mon, 21 Mar 2016 09:53:49 -0700
To: Gunnar =?iso-8859-1?Q?Hellstr=F6m?=  , "slim@ietf.org" 
From: Randall Gellens 
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
Content-Transfer-Encoding: quoted-printable
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: 
Subject: Re: [Slim] Change proposals for draft-ietf-slim-negotiating-human-language-00.txt
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
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, 21 Mar 2016 16:53:55 -0000

Hi Gunnar,

I do not believe we are forcing an interpretation=20
on RFC 4566, rather, the drafts says, in an=20
explanatory aside in parentheses, how the authors=20
interpret it.  This is quite far from a normative=20
statement.

I have re-read the text on language=20
directionality within a media stream, and I do=20
not see that we have an interoperability problem.=20
It's possible that multiple streams with a=20
language in the same direction are established,=20
and it's possible that not all of them are=20
actually used (e.g., if higher priority streams=20
are established, perhaps the lower priority ones=20
are not used).  I don't see that as causing an=20
interoperability problem.

I could add a statement that both 'lang' and=20
'humintlang-' attributes should not be used in=20
the same stream, due to potential confusion.

At 7:19 AM +0100 3/21/16, Gunnar Hellstr=F6m wrote:

>  Randall,
>
>  I think it is unfair to RFC 4566 and RFC 3264=20
> that we force an interpretation of the use of=20
> the 'lang' attribute on them that we do not=20
> agree on.
>
>  If we do not come to an agreement, we could=20
> instead just refrain from documenting an=20
> interpretation of how the 'lang' attribute=20
> works and  conclude with
>
>  "Unfortunately, there are cases, where the users need to use different
>     modalities in different directions, and when it is important to combin=
e
>     languages in different modalities. The 'lang' attribute does not have
>     the details needed to cover these cases."
>
>  We must also make sure that we do not make the=20
> same kind of unders-pecification as apparently=20
> has been done in RFC 4566.
>  We need to describe what it means if we have=20
> language indications for the same direction in=20
> two (or more) media.
>  Shall it be understood as an indication that
>      1) I am prepared to use both in the session or that
>      2) I require both to be used or that
>      3) I am not prepared to use both but offer them for selection.
>  If the normal interpretation is that it is for=20
> selection of one, how is the preference for one=20
> or the other indicated?
>  And if the normal interpretation is for a=20
> selection, how do we then indicate the case=20
> when we really strongly prefer to get both. (=20
> e.g. voice plus captions ).
>
>  We also need to describe how use of both 'lang'=20
> and 'humintlang-' attributes in the same sdp=20
> shall be interpreted.
>
>  Regards
>
>  Gunnar
>
>
>  Den 2016-03-21 kl. 01:32, skrev Randall Gellens:
>>  Hi Gunnar,
>>
>>  Thanks very much for your comments.  Please see in-line:
>>
>>  At 7:36 AM +0100 3/16/16, Gunnar Hellstr=F6m wrote:
>>
>>>   In addition to the changes proposed in=20
>>> draft-ietf-slim-negotiating-human-language-00=20
>>> for the preference regardless of media=20
>>> recently submitted, I have the following=20
>>> proposals for changes:
>>>
>>>   1. Change the first paragraph of section 5 from:
>>>
>>>=20
>>> ------------------------------------------------------------------------=
--------------------------
>>>    RFC=20
>>> 4566 specifies an attribute 'lang' which=20
>>> sounds similar to what
>>>      is needed here, the difference being that it specifies that 'a=3Dla=
ng'
>>>      is declarative with the semantics of multiple 'lang' attributes bei=
ng
>>>      that all of them are used, while we want a means to negotiate which
>>>      one is used in each stream.  This difference means that the existin=
g
>>>      'lang' attribute can't be used and we need to define a new attribut=
e.
>>>=20
>>> ------------------------------------------------------------------------=
-------
>>>
>>>   to
>>>
>>>=20
>>> ------------------------------------------------------------------------=
---------------
>>>    RFC=20
>>> 4566 specifies an attribute 'lang' which=20
>>> sounds similar to what
>>>      is needed here. It specifies that 'a=3Dlang'
>>>      is declarative with the semantics of multiple 'lang' attributes bei=
ng
>>>      possible, indicating a number of possible languages in the session =
in
>>>      an order of preference. Each party declares their capabilities and =
the
>>>      language(s) used in the session can then=20
>>> be selected from the common set.
>>>      We have however a need to specify direction of use of each language=
,
>>>      and an order of preference between languages in different modalitie=
s.
>>>      This difference means that the existing=20
>>> 'lang' attribute is not sufficient
>>>      for our use and we need to complement it=20
>>> with definition of a new attribute.
>>>
>>>=20
>>> ------------------------------------------------------------------------=
--------------------------
>>
>>  I disagree.  I've reread the text in the draft=20
>> and in RFC 4566 multiple times.  However, I=20
>> added clarifying wording to the draft.
>>
>>>
>>>   2. change the last two paragraphs of section 5 from:
>>>
>>>=20
>>> ------------------------------------------------------------------------=
--------------------------------
>>>    A recent search of RFCs and Internet Drafts turned up only one use of
>>>      the 'lang' attribute (in a now-expired draft), and that sole use wa=
s
>>>      coincidentally in exactly the way we need (erroniously assuming tha=
t
>>>      the attribute was used for negotiation).  The sole use was in an
>>>      example in a draft not directly related to language, where the
>>>      initial invitation contains two 'a=3Dlang' entries for a media stre=
am
>>>      (for English and Italian) and the OK accepts one of them (Italian).
>>>
>>>      The example serves as evidence of the need for an SDP attribute wit=
h
>>>      the semantics as described in this document; unfortunately, the
>>>      existing 'lang' attribute is not it.
>>>   ----------------------------------------------------------------------
>>>   to
>>>=20
>>> ------------------------------------------------------------------------=
-----
>>>    A recent search of RFCs and Internet Drafts turned up only one use of
>>>      the 'lang' attribute (in a now-expired draft), and that sole use wa=
s
>>>      coincidentally in exactly the way we need.  The sole use was in an
>>>      example in a draft not directly related to language, where the
>>>      initial invitation contains two 'a=3Dlang' entries for a media stre=
am
>>>      (for English and Italian) and the OK accepts one of them (Italian).
>>>
>>>      This use was questioned in a discussion of that draft because of th=
is
>>>      sentence in RFC 4566: "Multiple lang attributes can be
>>>         provided either at session or media level if the session
>>>         description or media use multiple languages."
>>>      An interpretation was that all declared languages must be used in
>>>      the session, while the example showed use of a selection of the
>>>      originally indicated languages. The uncertainty caused withdrawal
>>>      of the example because it was not essential for the draft.
>>>
>>>     However, studying the wording in RFC 4566 further, it is evident
>>>     that a negotiation of languages was intended for the real-time case.
>>>     When sdp is used to declare contents of a recorded session, then it
>>>     makes sense to list the provided languages, while for a real-time
>>>     session, it is obvious that the capabilities of the parties and the
>>>     development of the session influence the selection of language for
>>>     the session.
>>>     The continuation in RFC 4566 "the order of the attributes indicates
>>>     the order of importance of the various languages" makes it very clea=
r
>>>     that the list shall be seen as a list for selection and negotiation.
>>>     The "order of importance" has no meaning=20
>>> if all languages must be provided.
>>>
>>>     The conclusion is that the 'lang' attribute can be used for negotiat=
ion
>>>     of one or more common languages to select=20
>>> from for use in a real-time session.
>>>     A clarification is prepared for a possible future revision of RFC 45=
66.
>>>
>>>     Thus, the 'lang' attribute satisfies our needs in many cases.
>>>
>>>     Unfortunately, there are cases, where the users need to use differen=
t
>>>     modalities in different directions, and when it is important to comb=
ine
>>>     languages in different modalities. The 'lang' attribute does not hav=
e
>>>     the details needed to cover these cases."
>>>
>>>=20
>>> ------------------------------------------------------------------------=
-------------------------
>>
>>  While I disagree with your interpretation, I=20
>> don't think it's needed to go into this level=20
>> of detail at this point in the draft, so I=20
>> left it unchanged.
>>
>>>
>>>   3. Change section 6 from:
>>>   -------------------------------------------------------
>>>   6 Proposed Solution
>>>      An SDP attribute seems the natural choice to negotiate human
>>>      (natural) language of an interactive media stream.  The attribute
>>>      value should be a language tag per=20
>>> RFC 5646=20
>>> [RFC5646]=20
>>> "
>>>   ------------------------------------------------------------------
>>>   to
>>>   ----------------------------------------------------------------------=
-
>>>   6 Proposed Solution
>>>      An SDP attribute seems the natural choice to negotiate human
>>>      (natural) language of an interactive media stream.  The attribute
>>>      value should be a language tag per=20
>>> RFC 5646=20
>>> [RFC5646]
>>>      The new attribute can appear together with the existing 'lang'
>>>      attribute to compose the preferred language/modality combinations
>>>      offered or negotiated.
>>>   ----------------------------------------------------------------------
>>
>>  I don't think we have consensus on doing this, so I left it unchanged.
>>
>
>  --
>  -----------------------------------------
>  Gunnar Hellstr=F6m
>  Omnitor
>  gunnar.hellstrom@omnitor.se
>  +46 708 204 288
>
>  _______________________________________________
>  SLIM mailing list
>  SLIM@ietf.org
>  https://www.ietf.org/mailman/listinfo/slim


-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
It is much easier to suggest solutions
when you know nothing about the problem.


From nobody Mon Mar 21 09:56:03 2016
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D534A12D5A7 for ; Mon, 21 Mar 2016 09:56:02 -0700 (PDT)
X-Quarantine-ID: 
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g3i9R5krGDgW for ; Mon, 21 Mar 2016 09:56:01 -0700 (PDT)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id CCE6312D8E0 for ; Mon, 21 Mar 2016 09:55:52 -0700 (PDT)
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Mon, 21 Mar 2016 09:55:52 -0700
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <56F00713.5020408@alum.mit.edu>
References: <20151102160934.3160.2433.idtracker@ietfa.amsl.com> <56E8FEF0.10503@omnitor.se>  <56EF9277.7040306@omnitor.se> <56F00713.5020408@alum.mit.edu>
X-Mailer: Eudora for Mac OS X
Date: Mon, 21 Mar 2016 09:55:50 -0700
To: Paul Kyzivat , slim@ietf.org
From: Randall Gellens 
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
Content-Transfer-Encoding: quoted-printable
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: 
Subject: Re: [Slim] Change proposals for draft-ietf-slim-negotiating-human-language-00.txt
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
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, 21 Mar 2016 16:56:03 -0000

Hi Paul,

It would probably be a good idea to add=20
clarification on the use of 'lang' for a media.=20
Depending on timing, it may be possible to=20
clarify 'lang' with respect to 'humintlang' so=20
that there is no confusion.

At 10:37 AM -0400 3/21/16, Paul Kyzivat wrote:

>  In case you don't know, there is an rfc4566bis in progress.
>
>  If there is a problem with the precision of the=20
> definition of a=3Dlang, it is possible to get it=20
> refined in 4566bis. However this will be=20
> constrained by backward compatibility issues.=20
> So it can probably be *clarified* as long as=20
> there isn't a lot of disagreement about what it=20
> means.
>
>  	Thanks,
>  	Paul
>
>  On 3/21/16 2:19 AM, Gunnar Hellstr=F6m wrote:
>>  Randall,
>>
>>  I think it is unfair to RFC 4566 and RFC 3264 that we force an
>>  interpretation of the use of the 'lang' attribute on them that we do not
>>  agree on.
>>
>>  If we do not come to an agreement, we could instead just refrain from
>>  documenting an interpretation of how the 'lang' attribute works and
>>  conclude with
>>
>>  "Unfortunately, there are cases, where the users need to use different
>>      modalities in different directions, and when it is important to comb=
ine
>>      languages in different modalities. The 'lang' attribute does not hav=
e
>>      the details needed to cover these cases."
>>
>>  We must also make sure that we do not make the same kind of
>>  unders-pecification as apparently has been done in RFC 4566.
>>  We need to describe what it means if we have language indications for
>>  the same direction in two (or more) media.
>>  Shall it be understood as an indication that
>>       1) I am prepared to use both in the session or that
>>       2) I require both to be used or that
>>       3) I am not prepared to use both but offer them for selection.
>>  If the normal interpretation is that it is for selection of one, how is
>>  the preference for one or the other indicated?
>>  And if the normal interpretation is for a selection, how do we then
>>  indicate the case when we really strongly prefer to get both. ( e.g.
>>  voice plus captions ).
>>
>>  We also need to describe how use of both 'lang' and 'humintlang-'
>>  attributes in the same sdp shall be interpreted.
>>
>>  Regards
>>
>>  Gunnar
>>
>>
>>  Den 2016-03-21 kl. 01:32, skrev Randall Gellens:
>>>  Hi Gunnar,
>>>
>>>  Thanks very much for your comments.  Please see in-line:
>>>
>>>  At 7:36 AM +0100 3/16/16, Gunnar Hellstr=F6m wrote:
>>>
>>>>   In addition to the changes proposed in
>>>>  draft-ietf-slim-negotiating-human-language-00 for the preference
>>>>  regardless of media recently submitted, I have the following
>>>>  proposals for changes:
>>>>
>>>>   1. Change the first paragraph of section 5 from:
>>>>
>>>>=20
>>>> -----------------------------------------------------------------------=
---------------------------
>>>>
>>>>    RFC 4566 specifies an
>>>>  attribute 'lang' which sounds similar to what
>>>>      is needed here, the difference being that it specifies that 'a=3Dl=
ang'
>>>>      is declarative with the semantics of multiple 'lang' attributes
>>>>  being
>>>>      that all of them are used, while we want a means to negotiate whic=
h
>>>>      one is used in each stream.  This difference means that the existi=
ng
>>>>      'lang' attribute can't be used and we need to define a new
>>>>  attribute.
>>>>=20
>>>> -----------------------------------------------------------------------=
--------
>>>>
>>>>
>>>>   to
>>>>
>>>>=20
>>>> -----------------------------------------------------------------------=
----------------
>>>>
>>>>    RFC 4566 specifies an
>>>>  attribute 'lang' which sounds similar to what
>>>>      is needed here. It specifies that 'a=3Dlang'
>>>>      is declarative with the semantics of multiple 'lang' attributes
>>>>  being
>>>>      possible, indicating a number of possible languages in the
>>>>  session in
>>>>      an order of preference. Each party declares their capabilities
>>>>  and the
>>>>      language(s) used in the session can then be selected from the
>>>>  common set.
>>>>      We have however a need to specify direction of use of each languag=
e,
>>>>      and an order of preference between languages in different
>>>>  modalities.
>>>>      This difference means that the existing 'lang' attribute is not
>>>>  sufficient
>>>>      for our use and we need to complement it with definition of a new
>>>>  attribute.
>>>>
>>>>=20
>>>> -----------------------------------------------------------------------=
---------------------------
>>>>
>>>
>>>  I disagree.  I've reread the text in the draft and in RFC 4566
>>>  multiple times.  However, I added clarifying wording to the draft.
>>>
>>>>
>>>>   2. change the last two paragraphs of section 5 from:
>>>>
>>>>=20
>>>> -----------------------------------------------------------------------=
---------------------------------
>>>>
>>>>    A recent search of RFCs and Internet Drafts turned up only one use o=
f
>>>>      the 'lang' attribute (in a now-expired draft), and that sole use w=
as
>>>>      coincidentally in exactly the way we need (erroniously assuming th=
at
>>>>      the attribute was used for negotiation).  The sole use was in an
>>>>      example in a draft not directly related to language, where the
>>>>      initial invitation contains two 'a=3Dlang' entries for a media str=
eam
>>>>      (for English and Italian) and the OK accepts one of them (Italian)=
=2E
>>>>
>>>>      The example serves as evidence of the need for an SDP attribute wi=
th
>>>>      the semantics as described in this document; unfortunately, the
>>>>      existing 'lang' attribute is not it.
>>>>   ---------------------------------------------------------------------=
-
>>>>   to
>>>>=20
>>>> -----------------------------------------------------------------------=
------
>>>>
>>>>    A recent search of RFCs and Internet Drafts turned up only one use o=
f
>>>>      the 'lang' attribute (in a now-expired draft), and that sole use w=
as
>>>>      coincidentally in exactly the way we need.  The sole use was in an
>>>>      example in a draft not directly related to language, where the
>>>>      initial invitation contains two 'a=3Dlang' entries for a media str=
eam
>>>>      (for English and Italian) and the OK accepts one of them (Italian)=
=2E
>>>>
>>>>      This use was questioned in a discussion of that draft because of
>>>>  this
>>>>      sentence in RFC 4566: "Multiple lang attributes can be
>>>>         provided either at session or media level if the session
>>>>         description or media use multiple languages."
>>>>      An interpretation was that all declared languages must be used in
>>>>      the session, while the example showed use of a selection of the
>>>>      originally indicated languages. The uncertainty caused withdrawal
>>>>      of the example because it was not essential for the draft.
>>>>
>>>>     However, studying the wording in RFC 4566 further, it is evident
>>>>     that a negotiation of languages was intended for the real-time case=
=2E
>>>>     When sdp is used to declare contents of a recorded session, then it
>>>>     makes sense to list the provided languages, while for a real-time
>>>>     session, it is obvious that the capabilities of the parties and the
>>>>     development of the session influence the selection of language for
>>>>     the session.
>>>>     The continuation in RFC 4566 "the order of the attributes indicates
>>>>     the order of importance of the various languages" makes it very cle=
ar
>>>>     that the list shall be seen as a list for selection and negotiation=
=2E
>>>>     The "order of importance" has no meaning if all languages must be
>>>>  provided.
>>>>
>>>>     The conclusion is that the 'lang' attribute can be used for
>>>>  negotiation
>>>>     of one or more common languages to select from for use in a
>>>>  real-time session.
>>>>     A clarification is prepared for a possible future revision of RFC
>>>>  4566.
>>>>
>>>>     Thus, the 'lang' attribute satisfies our needs in many cases.
>>>>
>>>>     Unfortunately, there are cases, where the users need to use differe=
nt
>>>>     modalities in different directions, and when it is important to
>>>>  combine
>>>>     languages in different modalities. The 'lang' attribute does not ha=
ve
>>>>     the details needed to cover these cases."
>>>>
>>>>=20
>>>> -----------------------------------------------------------------------=
--------------------------
>>>>
>>>
>>>  While I disagree with your interpretation, I don't think it's needed
>>>  to go into this level of detail at this point in the draft, so I left
>>>  it unchanged.
>>>
>>>>
>>>>   3. Change section 6 from:
>>>>   -------------------------------------------------------
>>>>   6 Proposed Solution
>>>>      An SDP attribute seems the natural choice to negotiate human
>>>>      (natural) language of an interactive media stream.  The attribute
>>>>      value should be a language tag per
>>>>  RFC 5646
>>>>  [RFC5646] "
>>>>   ------------------------------------------------------------------
>>>>   to
>>>>   ---------------------------------------------------------------------=
--
>>>>   6 Proposed Solution
>>>>      An SDP attribute seems the natural choice to negotiate human
>>>>      (natural) language of an interactive media stream.  The attribute
>>>>      value should be a language tag per
>>>>  RFC 5646
>>>>  [RFC5646]
>>>>      The new attribute can appear together with the existing 'lang'
>>>>      attribute to compose the preferred language/modality combinations
>>>>      offered or negotiated.
>>>>   ---------------------------------------------------------------------=
-
>>>
>>>  I don't think we have consensus on doing this, so I left it unchanged.
>>>
>>
>
>  _______________________________________________
>  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: ---------------
The fact that a believer is happier than a skeptic is no more to the
point than the fact that a drunken man is happier than a sober one.
    --George Bernard Shaw


From nobody Mon Mar 21 10:10:51 2016
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1114612D892 for ; Mon, 21 Mar 2016 10:10:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.935
X-Spam-Level: 
X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SzKdDpEYPRfk for ; Mon, 21 Mar 2016 10:10:47 -0700 (PDT)
Received: from resqmta-ch2-01v.sys.comcast.net (resqmta-ch2-01v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:33]) (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 4003E12D916 for ; Mon, 21 Mar 2016 10:10:47 -0700 (PDT)
Received: from resomta-ch2-14v.sys.comcast.net ([69.252.207.110]) by comcast with SMTP id i3K2aC7WTBGW6i3LqaF5L1; Mon, 21 Mar 2016 17:10:46 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1458580246; bh=NtNyzMVKesBjY4ls/cxKOU2jQA5MaWlnCdYMS+PHuh0=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=iWPBAJqBJbr32Zgxs+JZ9zUYSxzRlupCtOuBJcAsFeL9qD200n/zQK/BvDTMYDbpa zN5ljdHv/NIkAj0+/QZrh20oi5yLEPLuG7cDddKiqGjx/b0NCs2doIoNkl2qYgtXwi HxcE1kmFV5CD4fz5X1i/feJxE1yrtgl666k3yC9GGP7ozoNlDW7py6zmkoSLSkYYN5 mr3DaTP5Eosj1Z21cMzBwxiSHYTgCsNdScxIIwBAOnVdRld/OZ4jH9BGaTHGeDuln/ zp54JgQhS2yvUbW4tcHU0bUL3RWWmRsztpHIx+UtCZT5DA5lL6g5LGE6AjGdAJty3u plMsjrdyYPGpQ==
Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-14v.sys.comcast.net with comcast id YhAl1s00T3KdFy101hAmhR; Mon, 21 Mar 2016 17:10:46 +0000
To: Randall Gellens , slim@ietf.org
References: <20151102160934.3160.2433.idtracker@ietfa.amsl.com> <56E8FEF0.10503@omnitor.se>  <56EF9277.7040306@omnitor.se> <56F00713.5020408@alum.mit.edu> 
From: Paul Kyzivat 
Message-ID: <56F02B14.8040809@alum.mit.edu>
Date: Mon, 21 Mar 2016 13:10:44 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.7.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [Slim] Change proposals for draft-ietf-slim-negotiating-human-language-00.txt
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
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, 21 Mar 2016 17:10:49 -0000

On 3/21/16 12:55 PM, Randall Gellens wrote:
> Hi Paul,
>
> It would probably be a good idea to add clarification on the use of
> 'lang' for a media. Depending on timing, it may be possible to clarify
> 'lang' with respect to 'humintlang' so that there is no confusion.

It isn't clear to me when work on 4566bis will wrapup. It has been going 
on for several years now. (But it *seems* to be coming to an end.)

It might be hard for it to reference humintlang without incorporating 
the definition into the bis. But it should certainly be possible to 
circumscribe the scope of 'lang' and indicate that some other attribute 
might be defined for another scope.

	Thanks,
	Paul

> At 10:37 AM -0400 3/21/16, Paul Kyzivat wrote:
>
>>  In case you don't know, there is an rfc4566bis in progress.
>>
>>  If there is a problem with the precision of the definition of a=lang,
>> it is possible to get it refined in 4566bis. However this will be
>> constrained by backward compatibility issues. So it can probably be
>> *clarified* as long as there isn't a lot of disagreement about what it
>> means.
>>
>>      Thanks,
>>      Paul
>>
>>  On 3/21/16 2:19 AM, Gunnar Hellström wrote:
>>>  Randall,
>>>
>>>  I think it is unfair to RFC 4566 and RFC 3264 that we force an
>>>  interpretation of the use of the 'lang' attribute on them that we do
>>> not
>>>  agree on.
>>>
>>>  If we do not come to an agreement, we could instead just refrain from
>>>  documenting an interpretation of how the 'lang' attribute works and
>>>  conclude with
>>>
>>>  "Unfortunately, there are cases, where the users need to use different
>>>      modalities in different directions, and when it is important to
>>> combine
>>>      languages in different modalities. The 'lang' attribute does not
>>> have
>>>      the details needed to cover these cases."
>>>
>>>  We must also make sure that we do not make the same kind of
>>>  unders-pecification as apparently has been done in RFC 4566.
>>>  We need to describe what it means if we have language indications for
>>>  the same direction in two (or more) media.
>>>  Shall it be understood as an indication that
>>>       1) I am prepared to use both in the session or that
>>>       2) I require both to be used or that
>>>       3) I am not prepared to use both but offer them for selection.
>>>  If the normal interpretation is that it is for selection of one, how is
>>>  the preference for one or the other indicated?
>>>  And if the normal interpretation is for a selection, how do we then
>>>  indicate the case when we really strongly prefer to get both. ( e.g.
>>>  voice plus captions ).
>>>
>>>  We also need to describe how use of both 'lang' and 'humintlang-'
>>>  attributes in the same sdp shall be interpreted.
>>>
>>>  Regards
>>>
>>>  Gunnar
>>>
>>>
>>>  Den 2016-03-21 kl. 01:32, skrev Randall Gellens:
>>>>  Hi Gunnar,
>>>>
>>>>  Thanks very much for your comments.  Please see in-line:
>>>>
>>>>  At 7:36 AM +0100 3/16/16, Gunnar Hellström wrote:
>>>>
>>>>>   In addition to the changes proposed in
>>>>>  draft-ietf-slim-negotiating-human-language-00 for the preference
>>>>>  regardless of media recently submitted, I have the following
>>>>>  proposals for changes:
>>>>>
>>>>>   1. Change the first paragraph of section 5 from:
>>>>>
>>>>>
>>>>> --------------------------------------------------------------------------------------------------
>>>>>
>>>>>
>>>>>    RFC 4566 specifies an
>>>>>  attribute 'lang' which sounds similar to what
>>>>>      is needed here, the difference being that it specifies that
>>>>> 'a=lang'
>>>>>      is declarative with the semantics of multiple 'lang' attributes
>>>>>  being
>>>>>      that all of them are used, while we want a means to negotiate
>>>>> which
>>>>>      one is used in each stream.  This difference means that the
>>>>> existing
>>>>>      'lang' attribute can't be used and we need to define a new
>>>>>  attribute.
>>>>>
>>>>> -------------------------------------------------------------------------------
>>>>>
>>>>>
>>>>>
>>>>>   to
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------------------------
>>>>>
>>>>>
>>>>>    RFC 4566 specifies an
>>>>>  attribute 'lang' which sounds similar to what
>>>>>      is needed here. It specifies that 'a=lang'
>>>>>      is declarative with the semantics of multiple 'lang' attributes
>>>>>  being
>>>>>      possible, indicating a number of possible languages in the
>>>>>  session in
>>>>>      an order of preference. Each party declares their capabilities
>>>>>  and the
>>>>>      language(s) used in the session can then be selected from the
>>>>>  common set.
>>>>>      We have however a need to specify direction of use of each
>>>>> language,
>>>>>      and an order of preference between languages in different
>>>>>  modalities.
>>>>>      This difference means that the existing 'lang' attribute is not
>>>>>  sufficient
>>>>>      for our use and we need to complement it with definition of a new
>>>>>  attribute.
>>>>>
>>>>>
>>>>> --------------------------------------------------------------------------------------------------
>>>>>
>>>>>
>>>>
>>>>  I disagree.  I've reread the text in the draft and in RFC 4566
>>>>  multiple times.  However, I added clarifying wording to the draft.
>>>>
>>>>>
>>>>>   2. change the last two paragraphs of section 5 from:
>>>>>
>>>>>
>>>>> --------------------------------------------------------------------------------------------------------
>>>>>
>>>>>
>>>>>    A recent search of RFCs and Internet Drafts turned up only one
>>>>> use of
>>>>>      the 'lang' attribute (in a now-expired draft), and that sole
>>>>> use was
>>>>>      coincidentally in exactly the way we need (erroniously
>>>>> assuming that
>>>>>      the attribute was used for negotiation).  The sole use was in an
>>>>>      example in a draft not directly related to language, where the
>>>>>      initial invitation contains two 'a=lang' entries for a media
>>>>> stream
>>>>>      (for English and Italian) and the OK accepts one of them
>>>>> (Italian).
>>>>>
>>>>>      The example serves as evidence of the need for an SDP
>>>>> attribute with
>>>>>      the semantics as described in this document; unfortunately, the
>>>>>      existing 'lang' attribute is not it.
>>>>>
>>>>> ----------------------------------------------------------------------
>>>>>   to
>>>>>
>>>>> -----------------------------------------------------------------------------
>>>>>
>>>>>
>>>>>    A recent search of RFCs and Internet Drafts turned up only one
>>>>> use of
>>>>>      the 'lang' attribute (in a now-expired draft), and that sole
>>>>> use was
>>>>>      coincidentally in exactly the way we need.  The sole use was
>>>>> in an
>>>>>      example in a draft not directly related to language, where the
>>>>>      initial invitation contains two 'a=lang' entries for a media
>>>>> stream
>>>>>      (for English and Italian) and the OK accepts one of them
>>>>> (Italian).
>>>>>
>>>>>      This use was questioned in a discussion of that draft because of
>>>>>  this
>>>>>      sentence in RFC 4566: "Multiple lang attributes can be
>>>>>         provided either at session or media level if the session
>>>>>         description or media use multiple languages."
>>>>>      An interpretation was that all declared languages must be used in
>>>>>      the session, while the example showed use of a selection of the
>>>>>      originally indicated languages. The uncertainty caused withdrawal
>>>>>      of the example because it was not essential for the draft.
>>>>>
>>>>>     However, studying the wording in RFC 4566 further, it is evident
>>>>>     that a negotiation of languages was intended for the real-time
>>>>> case.
>>>>>     When sdp is used to declare contents of a recorded session,
>>>>> then it
>>>>>     makes sense to list the provided languages, while for a real-time
>>>>>     session, it is obvious that the capabilities of the parties and
>>>>> the
>>>>>     development of the session influence the selection of language for
>>>>>     the session.
>>>>>     The continuation in RFC 4566 "the order of the attributes
>>>>> indicates
>>>>>     the order of importance of the various languages" makes it very
>>>>> clear
>>>>>     that the list shall be seen as a list for selection and
>>>>> negotiation.
>>>>>     The "order of importance" has no meaning if all languages must be
>>>>>  provided.
>>>>>
>>>>>     The conclusion is that the 'lang' attribute can be used for
>>>>>  negotiation
>>>>>     of one or more common languages to select from for use in a
>>>>>  real-time session.
>>>>>     A clarification is prepared for a possible future revision of RFC
>>>>>  4566.
>>>>>
>>>>>     Thus, the 'lang' attribute satisfies our needs in many cases.
>>>>>
>>>>>     Unfortunately, there are cases, where the users need to use
>>>>> different
>>>>>     modalities in different directions, and when it is important to
>>>>>  combine
>>>>>     languages in different modalities. The 'lang' attribute does
>>>>> not have
>>>>>     the details needed to cover these cases."
>>>>>
>>>>>
>>>>> -------------------------------------------------------------------------------------------------
>>>>>
>>>>>
>>>>
>>>>  While I disagree with your interpretation, I don't think it's needed
>>>>  to go into this level of detail at this point in the draft, so I left
>>>>  it unchanged.
>>>>
>>>>>
>>>>>   3. Change section 6 from:
>>>>>   -------------------------------------------------------
>>>>>   6 Proposed Solution
>>>>>      An SDP attribute seems the natural choice to negotiate human
>>>>>      (natural) language of an interactive media stream.  The attribute
>>>>>      value should be a language tag per
>>>>>  RFC 5646
>>>>>  [RFC5646] "
>>>>>   ------------------------------------------------------------------
>>>>>   to
>>>>>
>>>>> -----------------------------------------------------------------------
>>>>>
>>>>>   6 Proposed Solution
>>>>>      An SDP attribute seems the natural choice to negotiate human
>>>>>      (natural) language of an interactive media stream.  The attribute
>>>>>      value should be a language tag per
>>>>>  RFC 5646
>>>>>  [RFC5646]
>>>>>      The new attribute can appear together with the existing 'lang'
>>>>>      attribute to compose the preferred language/modality combinations
>>>>>      offered or negotiated.
>>>>>
>>>>> ----------------------------------------------------------------------
>>>>
>>>>  I don't think we have consensus on doing this, so I left it unchanged.
>>>>
>>>
>>
>>  _______________________________________________
>>  SLIM mailing list
>>  SLIM@ietf.org
>>  https://www.ietf.org/mailman/listinfo/slim
>
>


From nobody Mon Mar 21 10:29:37 2016
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 CD9C412D661; Mon, 21 Mar 2016 10:29:32 -0700 (PDT)
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.17.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160321172932.31965.57565.idtracker@ietfa.amsl.com>
Date: Mon, 21 Mar 2016 10:29:32 -0700
Archived-At: 
Cc: slim@ietf.org
Subject: [Slim] I-D Action: draft-ietf-slim-use-cases-00.txt
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Mar 2016 17:29:33 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Selection of Language for Internet Media of the IETF.

        Title           : SLIM Use Cases
        Author          : Natasha Rooney
	Filename        : draft-ietf-slim-use-cases-00.txt
	Pages           : 6
	Date            : 2016-03-21

Abstract:
   Use cases for selection of language for internet media.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-slim-use-cases/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-slim-use-cases-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 Mar 21 12:42:47 2016
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24DD912DAD5 for ; Mon, 21 Mar 2016 12:42:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ryROwDKsTVb for ; Mon, 21 Mar 2016 12:42:41 -0700 (PDT)
Received: from bin-vsp-out-03.atm.binero.net (vsp-unauthed02.binero.net [195.74.38.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDA6112DAA8 for ; Mon, 21 Mar 2016 12:42:36 -0700 (PDT)
X-Halon-ID: 09d97d44-ef9d-11e5-be2d-0050569116f7
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.8] (unknown [87.96.161.49]) by bin-vsp-out-03.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Mon, 21 Mar 2016 20:42:25 +0100 (CET)
To: slim@ietf.org
References: <20151102160934.3160.2433.idtracker@ietfa.amsl.com> <56E8FEF0.10503@omnitor.se>  <56EF9277.7040306@omnitor.se> <56F00713.5020408@alum.mit.edu>  <56F02B14.8040809@alum.mit.edu>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: <56F04EA0.3010403@omnitor.se>
Date: Mon, 21 Mar 2016 20:42:24 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <56F02B14.8040809@alum.mit.edu>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [Slim] Change proposals for draft-ietf-slim-negotiating-human-language-00.txt
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
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, 21 Mar 2016 19:42:44 -0000

Den 2016-03-21 kl. 18:10, skrev Paul Kyzivat:
> On 3/21/16 12:55 PM, Randall Gellens wrote:
>> Hi Paul,
>>
>> It would probably be a good idea to add clarification on the use of
>> 'lang' for a media. Depending on timing, it may be possible to clarify
>> 'lang' with respect to 'humintlang' so that there is no confusion.
>
> It isn't clear to me when work on 4566bis will wrapup. It has been 
> going on for several years now. (But it *seems* to be coming to an end.)
>
> It might be hard for it to reference humintlang without incorporating 
> the definition into the bis. But it should certainly be possible to 
> circumscribe the scope of 'lang' and indicate that some other 
> attribute might be defined for another scope.
I have communicated in the mmusic list and indicated the need to clarify 
the use of 'lang' in 4566bis.
I think it was in November or December. A wording was accepted that 
makes it clear that multiple languages means a selection and an answer 
can select what to use.
But I am afraid that I only discussed the issue of all or selection, and 
not what we discussed today, about the need to indicate preferences 
between languages in different media and the need to specify what it 
means to have languages in multiple media. ( is it for selection or a 
required combination )

Gunnar
>
>
>     Thanks,
>     Paul
>
>> At 10:37 AM -0400 3/21/16, Paul Kyzivat wrote:
>>
>>>  In case you don't know, there is an rfc4566bis in progress.
>>>
>>>  If there is a problem with the precision of the definition of a=lang,
>>> it is possible to get it refined in 4566bis. However this will be
>>> constrained by backward compatibility issues. So it can probably be
>>> *clarified* as long as there isn't a lot of disagreement about what it
>>> means.
>>>
>>>      Thanks,
>>>      Paul
>>>
>>>  On 3/21/16 2:19 AM, Gunnar Hellström wrote:
>>>>  Randall,
>>>>
>>>>  I think it is unfair to RFC 4566 and RFC 3264 that we force an
>>>>  interpretation of the use of the 'lang' attribute on them that we do
>>>> not
>>>>  agree on.
>>>>
>>>>  If we do not come to an agreement, we could instead just refrain from
>>>>  documenting an interpretation of how the 'lang' attribute works and
>>>>  conclude with
>>>>
>>>>  "Unfortunately, there are cases, where the users need to use 
>>>> different
>>>>      modalities in different directions, and when it is important to
>>>> combine
>>>>      languages in different modalities. The 'lang' attribute does not
>>>> have
>>>>      the details needed to cover these cases."
>>>>
>>>>  We must also make sure that we do not make the same kind of
>>>>  unders-pecification as apparently has been done in RFC 4566.
>>>>  We need to describe what it means if we have language indications for
>>>>  the same direction in two (or more) media.
>>>>  Shall it be understood as an indication that
>>>>       1) I am prepared to use both in the session or that
>>>>       2) I require both to be used or that
>>>>       3) I am not prepared to use both but offer them for selection.
>>>>  If the normal interpretation is that it is for selection of one, 
>>>> how is
>>>>  the preference for one or the other indicated?
>>>>  And if the normal interpretation is for a selection, how do we then
>>>>  indicate the case when we really strongly prefer to get both. ( e.g.
>>>>  voice plus captions ).
>>>>
>>>>  We also need to describe how use of both 'lang' and 'humintlang-'
>>>>  attributes in the same sdp shall be interpreted.
>>>>
>>>>  Regards
>>>>
>>>>  Gunnar
>>>>
>>>>
>>>>  Den 2016-03-21 kl. 01:32, skrev Randall Gellens:
>>>>>  Hi Gunnar,
>>>>>
>>>>>  Thanks very much for your comments.  Please see in-line:
>>>>>
>>>>>  At 7:36 AM +0100 3/16/16, Gunnar Hellström wrote:
>>>>>
>>>>>>   In addition to the changes proposed in
>>>>>>  draft-ietf-slim-negotiating-human-language-00 for the preference
>>>>>>  regardless of media recently submitted, I have the following
>>>>>>  proposals for changes:
>>>>>>
>>>>>>   1. Change the first paragraph of section 5 from:
>>>>>>
>>>>>>
>>>>>> -------------------------------------------------------------------------------------------------- 
>>>>>>
>>>>>>
>>>>>>
>>>>>>    RFC 4566 specifies an
>>>>>>  attribute 'lang' which sounds similar to what
>>>>>>      is needed here, the difference being that it specifies that
>>>>>> 'a=lang'
>>>>>>      is declarative with the semantics of multiple 'lang' attributes
>>>>>>  being
>>>>>>      that all of them are used, while we want a means to negotiate
>>>>>> which
>>>>>>      one is used in each stream.  This difference means that the
>>>>>> existing
>>>>>>      'lang' attribute can't be used and we need to define a new
>>>>>>  attribute.
>>>>>>
>>>>>> ------------------------------------------------------------------------------- 
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>   to
>>>>>>
>>>>>>
>>>>>> --------------------------------------------------------------------------------------- 
>>>>>>
>>>>>>
>>>>>>
>>>>>>    RFC 4566 specifies an
>>>>>>  attribute 'lang' which sounds similar to what
>>>>>>      is needed here. It specifies that 'a=lang'
>>>>>>      is declarative with the semantics of multiple 'lang' attributes
>>>>>>  being
>>>>>>      possible, indicating a number of possible languages in the
>>>>>>  session in
>>>>>>      an order of preference. Each party declares their capabilities
>>>>>>  and the
>>>>>>      language(s) used in the session can then be selected from the
>>>>>>  common set.
>>>>>>      We have however a need to specify direction of use of each
>>>>>> language,
>>>>>>      and an order of preference between languages in different
>>>>>>  modalities.
>>>>>>      This difference means that the existing 'lang' attribute is not
>>>>>>  sufficient
>>>>>>      for our use and we need to complement it with definition of 
>>>>>> a new
>>>>>>  attribute.
>>>>>>
>>>>>>
>>>>>> -------------------------------------------------------------------------------------------------- 
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>  I disagree.  I've reread the text in the draft and in RFC 4566
>>>>>  multiple times.  However, I added clarifying wording to the draft.
>>>>>
>>>>>>
>>>>>>   2. change the last two paragraphs of section 5 from:
>>>>>>
>>>>>>
>>>>>> -------------------------------------------------------------------------------------------------------- 
>>>>>>
>>>>>>
>>>>>>
>>>>>>    A recent search of RFCs and Internet Drafts turned up only one
>>>>>> use of
>>>>>>      the 'lang' attribute (in a now-expired draft), and that sole
>>>>>> use was
>>>>>>      coincidentally in exactly the way we need (erroniously
>>>>>> assuming that
>>>>>>      the attribute was used for negotiation).  The sole use was 
>>>>>> in an
>>>>>>      example in a draft not directly related to language, where the
>>>>>>      initial invitation contains two 'a=lang' entries for a media
>>>>>> stream
>>>>>>      (for English and Italian) and the OK accepts one of them
>>>>>> (Italian).
>>>>>>
>>>>>>      The example serves as evidence of the need for an SDP
>>>>>> attribute with
>>>>>>      the semantics as described in this document; unfortunately, the
>>>>>>      existing 'lang' attribute is not it.
>>>>>>
>>>>>> ---------------------------------------------------------------------- 
>>>>>>
>>>>>>   to
>>>>>>
>>>>>> ----------------------------------------------------------------------------- 
>>>>>>
>>>>>>
>>>>>>
>>>>>>    A recent search of RFCs and Internet Drafts turned up only one
>>>>>> use of
>>>>>>      the 'lang' attribute (in a now-expired draft), and that sole
>>>>>> use was
>>>>>>      coincidentally in exactly the way we need.  The sole use was
>>>>>> in an
>>>>>>      example in a draft not directly related to language, where the
>>>>>>      initial invitation contains two 'a=lang' entries for a media
>>>>>> stream
>>>>>>      (for English and Italian) and the OK accepts one of them
>>>>>> (Italian).
>>>>>>
>>>>>>      This use was questioned in a discussion of that draft 
>>>>>> because of
>>>>>>  this
>>>>>>      sentence in RFC 4566: "Multiple lang attributes can be
>>>>>>         provided either at session or media level if the session
>>>>>>         description or media use multiple languages."
>>>>>>      An interpretation was that all declared languages must be 
>>>>>> used in
>>>>>>      the session, while the example showed use of a selection of the
>>>>>>      originally indicated languages. The uncertainty caused 
>>>>>> withdrawal
>>>>>>      of the example because it was not essential for the draft.
>>>>>>
>>>>>>     However, studying the wording in RFC 4566 further, it is evident
>>>>>>     that a negotiation of languages was intended for the real-time
>>>>>> case.
>>>>>>     When sdp is used to declare contents of a recorded session,
>>>>>> then it
>>>>>>     makes sense to list the provided languages, while for a 
>>>>>> real-time
>>>>>>     session, it is obvious that the capabilities of the parties and
>>>>>> the
>>>>>>     development of the session influence the selection of 
>>>>>> language for
>>>>>>     the session.
>>>>>>     The continuation in RFC 4566 "the order of the attributes
>>>>>> indicates
>>>>>>     the order of importance of the various languages" makes it very
>>>>>> clear
>>>>>>     that the list shall be seen as a list for selection and
>>>>>> negotiation.
>>>>>>     The "order of importance" has no meaning if all languages 
>>>>>> must be
>>>>>>  provided.
>>>>>>
>>>>>>     The conclusion is that the 'lang' attribute can be used for
>>>>>>  negotiation
>>>>>>     of one or more common languages to select from for use in a
>>>>>>  real-time session.
>>>>>>     A clarification is prepared for a possible future revision of 
>>>>>> RFC
>>>>>>  4566.
>>>>>>
>>>>>>     Thus, the 'lang' attribute satisfies our needs in many cases.
>>>>>>
>>>>>>     Unfortunately, there are cases, where the users need to use
>>>>>> different
>>>>>>     modalities in different directions, and when it is important to
>>>>>>  combine
>>>>>>     languages in different modalities. The 'lang' attribute does
>>>>>> not have
>>>>>>     the details needed to cover these cases."
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------------------------- 
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>  While I disagree with your interpretation, I don't think it's needed
>>>>>  to go into this level of detail at this point in the draft, so I 
>>>>> left
>>>>>  it unchanged.
>>>>>
>>>>>>
>>>>>>   3. Change section 6 from:
>>>>>> -------------------------------------------------------
>>>>>>   6 Proposed Solution
>>>>>>      An SDP attribute seems the natural choice to negotiate human
>>>>>>      (natural) language of an interactive media stream. The 
>>>>>> attribute
>>>>>>      value should be a language tag per
>>>>>>  RFC 5646
>>>>>>  [RFC5646] "
>>>>>> ------------------------------------------------------------------
>>>>>>   to
>>>>>>
>>>>>> ----------------------------------------------------------------------- 
>>>>>>
>>>>>>
>>>>>>   6 Proposed Solution
>>>>>>      An SDP attribute seems the natural choice to negotiate human
>>>>>>      (natural) language of an interactive media stream. The 
>>>>>> attribute
>>>>>>      value should be a language tag per
>>>>>>  RFC 5646
>>>>>>  [RFC5646]
>>>>>>      The new attribute can appear together with the existing 'lang'
>>>>>>      attribute to compose the preferred language/modality 
>>>>>> combinations
>>>>>>      offered or negotiated.
>>>>>>
>>>>>> ---------------------------------------------------------------------- 
>>>>>>
>>>>>
>>>>>  I don't think we have consensus on doing this, so I left it 
>>>>> unchanged.
>>>>>
>>>>
>>>
>>>  _______________________________________________
>>>  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


From nobody Mon Mar 21 13:48:09 2016
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5316012D93E for ; Mon, 21 Mar 2016 13:48:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FobujafzItqg for ; Mon, 21 Mar 2016 13:48:05 -0700 (PDT)
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 37BCF12DB61 for ; Mon, 21 Mar 2016 13:48:05 -0700 (PDT)
X-Halon-ID: 2e802b8f-efa6-11e5-b13e-005056917c0c
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.8] (unknown [87.96.161.49]) by bin-vsp-out-04.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Mon, 21 Mar 2016 21:47:52 +0100 (CET)
To: slim@ietf.org
References: <20151102160934.3160.2433.idtracker@ietfa.amsl.com> <56E8FEF0.10503@omnitor.se>  <56EF9277.7040306@omnitor.se> 
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: <56F05DF9.2080802@omnitor.se>
Date: Mon, 21 Mar 2016 21:47:53 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [Slim] Change proposals for draft-ietf-slim-negotiating-human-language-00.txt
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
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, 21 Mar 2016 20:48:08 -0000

Hi Randall,
Den 2016-03-21 kl. 17:53, skrev Randall Gellens:
> Hi Gunnar,
>
> I do not believe we are forcing an interpretation on RFC 4566, rather, 
> the drafts says, in an explanatory aside in parentheses, how the 
> authors interpret it.  This is quite far from a normative statement.
It will be documented anyway, and just as you looked at the discussion 
around the STOX - example and got influenced by it, there is a risk that 
we spread more uncertainty in the topic or lead others to make unlogical 
conclusions.
Let it be sufficient to say that 'lang' does not have the detailing we need.
>
>
> I have re-read the text on language directionality within a media 
> stream, and I do not see that we have an interoperability problem. 
> It's possible that multiple streams with a language in the same 
> direction are established, and it's possible that not all of them are 
> actually used (e.g., if higher priority streams are established, 
> perhaps the lower priority ones are not used).  I don't see that as 
> causing an interoperability problem.
See use cases 2.3, 2.4, 2.5 and 2.6 in the use-case document just 
published by Natasha. Thanks!
Only 2.3 is solved by the current specification. The other needs 
cross-media preferences.
They could need media and language grouping as well, but I prefer that 
we try to solve that with a rule saying that languages in different 
media specified on the same preference level shall be seen as a group 
that is required together, while languages in different media specified 
with different preference levels specify single languages provided for 
selection.


Note also that the primary function of these attributes are not to guide 
which media streams shall be accepted and activated, it is usually good 
with media streams even if they are not used for language.
The function I see as the main purpose is to make sure that the caller 
gets in contact with a person with the right language competence and if 
needed a suitable relay service is invoked in the call in order to cover 
any gaps in language coverage.
Of course a media stream must not be excluded that is needed for the 
selected language combination.  But the opposite should not happen - 
that a media stream is ignored because it is not needed for language 
communication.

>
>
> I could add a statement that both 'lang' and 'humintlang-' attributes 
> should not be used in the same stream, due to potential confusion.
Yes, if we cannot agree on how to interpret 'lang', it would be a solution.
But the problem is also between media. 'lang' in one medium and 
'humintlang' in another is also undefined if it represents an offered 
selection, or a required combination and if selection, what preference 
levels do they represent?
We must then also think about the conflict between 'lang' on session 
level and 'humintlang' on media level.


/Gunnar
>
> At 7:19 AM +0100 3/21/16, Gunnar Hellström wrote:
>
>>  Randall,
>>
>>  I think it is unfair to RFC 4566 and RFC 3264 that we force an 
>> interpretation of the use of the 'lang' attribute on them that we do 
>> not agree on.
>>
>>  If we do not come to an agreement, we could instead just refrain 
>> from documenting an interpretation of how the 'lang' attribute works 
>> and  conclude with
>>
>>  "Unfortunately, there are cases, where the users need to use different
>>     modalities in different directions, and when it is important to 
>> combine
>>     languages in different modalities. The 'lang' attribute does not 
>> have
>>     the details needed to cover these cases."
>>
>>  We must also make sure that we do not make the same kind of 
>> unders-pecification as apparently has been done in RFC 4566.
>>  We need to describe what it means if we have language indications 
>> for the same direction in two (or more) media.
>>  Shall it be understood as an indication that
>>      1) I am prepared to use both in the session or that
>>      2) I require both to be used or that
>>      3) I am not prepared to use both but offer them for selection.
>>  If the normal interpretation is that it is for selection of one, how 
>> is the preference for one or the other indicated?
>>  And if the normal interpretation is for a selection, how do we then 
>> indicate the case when we really strongly prefer to get both. ( e.g. 
>> voice plus captions ).
>>
>>  We also need to describe how use of both 'lang' and 'humintlang-' 
>> attributes in the same sdp shall be interpreted.
>>
>>  Regards
>>
>>  Gunnar
>>
>>
>>  Den 2016-03-21 kl. 01:32, skrev Randall Gellens:
>>>  Hi Gunnar,
>>>
>>>  Thanks very much for your comments.  Please see in-line:
>>>
>>>  At 7:36 AM +0100 3/16/16, Gunnar Hellström wrote:
>>>
>>>>   In addition to the changes proposed in 
>>>> draft-ietf-slim-negotiating-human-language-00 for the preference 
>>>> regardless of media recently submitted, I have the following 
>>>> proposals for changes:
>>>>
>>>>   1. Change the first paragraph of section 5 from:
>>>>
>>>>
>>>> -------------------------------------------------------------------------------------------------- 
>>>>
>>>>    RFC 4566 specifies an 
>>>> attribute 'lang' which sounds similar to what
>>>>      is needed here, the difference being that it specifies that 
>>>> 'a=lang'
>>>>      is declarative with the semantics of multiple 'lang' 
>>>> attributes being
>>>>      that all of them are used, while we want a means to negotiate 
>>>> which
>>>>      one is used in each stream.  This difference means that the 
>>>> existing
>>>>      'lang' attribute can't be used and we need to define a new 
>>>> attribute.
>>>>
>>>> ------------------------------------------------------------------------------- 
>>>>
>>>>
>>>>   to
>>>>
>>>>
>>>> --------------------------------------------------------------------------------------- 
>>>>
>>>>    RFC 4566 specifies an 
>>>> attribute 'lang' which sounds similar to what
>>>>      is needed here. It specifies that 'a=lang'
>>>>      is declarative with the semantics of multiple 'lang' 
>>>> attributes being
>>>>      possible, indicating a number of possible languages in the 
>>>> session in
>>>>      an order of preference. Each party declares their capabilities 
>>>> and the
>>>>      language(s) used in the session can then be selected from the 
>>>> common set.
>>>>      We have however a need to specify direction of use of each 
>>>> language,
>>>>      and an order of preference between languages in different 
>>>> modalities.
>>>>      This difference means that the existing 'lang' attribute is 
>>>> not sufficient
>>>>      for our use and we need to complement it with definition of a 
>>>> new attribute.
>>>>
>>>>
>>>> -------------------------------------------------------------------------------------------------- 
>>>>
>>>
>>>  I disagree.  I've reread the text in the draft and in RFC 4566 
>>> multiple times.  However, I added clarifying wording to the draft.
>>>
>>>>
>>>>   2. change the last two paragraphs of section 5 from:
>>>>
>>>>
>>>> -------------------------------------------------------------------------------------------------------- 
>>>>
>>>>    A recent search of RFCs and Internet Drafts turned up only one 
>>>> use of
>>>>      the 'lang' attribute (in a now-expired draft), and that sole 
>>>> use was
>>>>      coincidentally in exactly the way we need (erroniously 
>>>> assuming that
>>>>      the attribute was used for negotiation).  The sole use was in an
>>>>      example in a draft not directly related to language, where the
>>>>      initial invitation contains two 'a=lang' entries for a media 
>>>> stream
>>>>      (for English and Italian) and the OK accepts one of them 
>>>> (Italian).
>>>>
>>>>      The example serves as evidence of the need for an SDP 
>>>> attribute with
>>>>      the semantics as described in this document; unfortunately, the
>>>>      existing 'lang' attribute is not it.
>>>> ----------------------------------------------------------------------
>>>>   to
>>>>
>>>> ----------------------------------------------------------------------------- 
>>>>
>>>>    A recent search of RFCs and Internet Drafts turned up only one 
>>>> use of
>>>>      the 'lang' attribute (in a now-expired draft), and that sole 
>>>> use was
>>>>      coincidentally in exactly the way we need.  The sole use was 
>>>> in an
>>>>      example in a draft not directly related to language, where the
>>>>      initial invitation contains two 'a=lang' entries for a media 
>>>> stream
>>>>      (for English and Italian) and the OK accepts one of them 
>>>> (Italian).
>>>>
>>>>      This use was questioned in a discussion of that draft because 
>>>> of this
>>>>      sentence in RFC 4566: "Multiple lang attributes can be
>>>>         provided either at session or media level if the session
>>>>         description or media use multiple languages."
>>>>      An interpretation was that all declared languages must be used in
>>>>      the session, while the example showed use of a selection of the
>>>>      originally indicated languages. The uncertainty caused withdrawal
>>>>      of the example because it was not essential for the draft.
>>>>
>>>>     However, studying the wording in RFC 4566 further, it is evident
>>>>     that a negotiation of languages was intended for the real-time 
>>>> case.
>>>>     When sdp is used to declare contents of a recorded session, 
>>>> then it
>>>>     makes sense to list the provided languages, while for a real-time
>>>>     session, it is obvious that the capabilities of the parties and 
>>>> the
>>>>     development of the session influence the selection of language for
>>>>     the session.
>>>>     The continuation in RFC 4566 "the order of the attributes 
>>>> indicates
>>>>     the order of importance of the various languages" makes it very 
>>>> clear
>>>>     that the list shall be seen as a list for selection and 
>>>> negotiation.
>>>>     The "order of importance" has no meaning if all languages must 
>>>> be provided.
>>>>
>>>>     The conclusion is that the 'lang' attribute can be used for 
>>>> negotiation
>>>>     of one or more common languages to select from for use in a 
>>>> real-time session.
>>>>     A clarification is prepared for a possible future revision of 
>>>> RFC 4566.
>>>>
>>>>     Thus, the 'lang' attribute satisfies our needs in many cases.
>>>>
>>>>     Unfortunately, there are cases, where the users need to use 
>>>> different
>>>>     modalities in different directions, and when it is important to 
>>>> combine
>>>>     languages in different modalities. The 'lang' attribute does 
>>>> not have
>>>>     the details needed to cover these cases."
>>>>
>>>>
>>>> ------------------------------------------------------------------------------------------------- 
>>>>
>>>
>>>  While I disagree with your interpretation, I don't think it's 
>>> needed to go into this level of detail at this point in the draft, 
>>> so I left it unchanged.
>>>
>>>>
>>>>   3. Change section 6 from:
>>>>   -------------------------------------------------------
>>>>   6 Proposed Solution
>>>>      An SDP attribute seems the natural choice to negotiate human
>>>>      (natural) language of an interactive media stream.  The attribute
>>>>      value should be a language tag per 
>>>> RFC 5646 
>>>> [RFC5646] "
>>>> ------------------------------------------------------------------
>>>>   to
>>>> ----------------------------------------------------------------------- 
>>>>
>>>>   6 Proposed Solution
>>>>      An SDP attribute seems the natural choice to negotiate human
>>>>      (natural) language of an interactive media stream.  The attribute
>>>>      value should be a language tag per 
>>>> RFC 5646 
>>>> [RFC5646]
>>>>      The new attribute can appear together with the existing 'lang'
>>>>      attribute to compose the preferred language/modality combinations
>>>>      offered or negotiated.
>>>> ----------------------------------------------------------------------
>>>
>>>  I don't think we have consensus on doing this, so I left it unchanged.
>>>
>>
>>  --
>>  -----------------------------------------
>>  Gunnar Hellström
>>  Omnitor
>>  gunnar.hellstrom@omnitor.se
>>  +46 708 204 288
>>
>>  _______________________________________________
>>  SLIM mailing list
>>  SLIM@ietf.org
>>  https://www.ietf.org/mailman/listinfo/slim
>
>

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


From nobody Mon Mar 21 14:40:21 2016
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9C2B12D094 for ; Mon, 21 Mar 2016 14:40:19 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gsmasso.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o4VJDT_gXBI9 for ; Mon, 21 Mar 2016 14:40:17 -0700 (PDT)
Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0647.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::647]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 432EE12D093 for ; Mon, 21 Mar 2016 14:40:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=GSMASSO.onmicrosoft.com; s=selector1-gsma-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=EW8+Emb6ODqpEt1nuWJsEe+Jat0+ZqZHBmGg+NcSlCY=; b=cIZEATkQcvc6GB4cj+ZLipD8lP7jqc1p//234+vp+O0HLtwBgBV/oJMYCMA4gQf1QUavAbzY/S1sMw90zaq73ftZc41cXSZSEieu8LCOAchzujWTJughJcat6eHTGTHmRTfV0tFs3bYvZ1M3FvIbdoDcOc5pDkj+k6c7Zi0coGM=
Received: from DB5PR04MB1029.eurprd04.prod.outlook.com (10.161.199.143) by DB5PR04MB1032.eurprd04.prod.outlook.com (10.161.199.146) with Microsoft SMTP Server (TLS) id 15.1.434.16; Mon, 21 Mar 2016 21:40:00 +0000
Received: from DB5PR04MB1029.eurprd04.prod.outlook.com ([10.161.199.143]) by DB5PR04MB1029.eurprd04.prod.outlook.com ([10.161.199.143]) with mapi id 15.01.0434.021; Mon, 21 Mar 2016 21:40:00 +0000
From: Natasha Rooney 
To: "slim@ietf.org" 
Thread-Topic: New drafts
Thread-Index: AQHRg7o4sezkurY6CEesI0E9tprK8A==
Date: Mon, 21 Mar 2016 21:40:00 +0000
Message-ID: <0834B9F0-D705-42BF-B65A-BEDC0620CBCB@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.3112)
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=gsma.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [18.111.17.192]
x-ms-office365-filtering-correlation-id: 689f36f2-1295-404a-0ed1-08d351d15ad7
x-microsoft-exchange-diagnostics: 1; DB5PR04MB1032; 5:+G2VPLJURqCIlqZXuFI20fpCahsf/DW1/vrDUDWLWA6+aZpHipfOGsgjY9UCXH8bmdzjv/evbVYYXR1Kyx7W+BdtNULeRjN3tfIheHagKLfvPU/JJ8BhqpSxFFMfC29/tY0Z/M9chy1s9aMVAhW+tg==; 24:Ey7Bm6buBaCFsRb60oqSnbu72AgeBVF7wNkzcQ1+9wUgVWd0aVa9pRC+oXjgR7l/XKEBQXZLhOkxyGhwNaE7mda3om6LDPpC/P4xsYpgL/M=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB5PR04MB1032;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:DB5PR04MB1032; BCL:0; PCL:0; RULEID:; SRVR:DB5PR04MB1032; 
x-forefront-prvs: 0888B1D284
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(53754006)(122556002)(3660700001)(5004730100002)(3480700003)(5002640100001)(1096002)(82746002)(3280700002)(77096005)(1220700001)(19580405001)(19580395003)(57306001)(586003)(1730700002)(16236675004)(3846002)(102836003)(6116002)(92566002)(2906002)(36756003)(221733001)(10400500002)(229853001)(106116001)(2900100001)(2351001)(50226001)(86362001)(5890100001)(5008740100001)(87936001)(33656002)(66066001)(110136002)(107886002)(83716003)(450100001)(189998001)(11100500001)(81166005)(50986999)(2501003)(5640700001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB5PR04MB1032; H:DB5PR04MB1029.eurprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_0834B9F0D70542BFB65ABEDC0620CBCBgsmacom_"
MIME-Version: 1.0
X-OriginatorOrg: gsma.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Mar 2016 21:40:00.2492 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72a4ff82-fec3-469d-aafb-ac8276216699
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR04MB1032
X-MS-Exchange-CrossPremises-AuthAs: Internal
X-MS-Exchange-CrossPremises-AuthMechanism: 04
X-MS-Exchange-CrossPremises-AuthSource: DB5PR04MB1029.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: 18.111.17.192
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: DB5PR04MB1032.eurprd04.prod.outlook.com
Archived-At: 
Subject: [Slim] New drafts
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
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, 21 Mar 2016 21:40:20 -0000

--_000_0834B9F0D70542BFB65ABEDC0620CBCBgsmacom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgYWxsLA0KDQpXZSBoYXZlIHR3byBuZXcgZHJhZnQgdXBsb2FkcyB0byBvdXIgZG9jdW1lbnRz
IGxpc3Q6DQoNCmRyYWZ0LWlldGYtc2xpbS1uZWdvdGlhdGluZy1odW1hbi1sYW5ndWFnZS0wMQ0K
TmVnb3RpYXRpbmcgSHVtYW4gTGFuZ3VhZ2UgaW4gUmVhbC1UaW1lIENvbW11bmljYXRpb25zDQpO
aWsgYW5kIE5hdGhhbmllbCBoYXZlIHdvcmtlZCBvbiBhIG5ldyB2ZXJzaW9uIG9mIHRoZSBkb2N1
bWVudCwgcGxlYXNlIHJldmlldyB3aGVuIHlvdSBjYW4gKHByaW9yIHRvIElFVEY5NSBpZiBwb3Nz
aWJsZSEpDQoNCmRyYWZ0LWlldGYtc2xpbS11c2UtY2FzZXMtMDANClNMSU0gVXNlIENhc2VzDQpJ
IGhhdmUgYWRkZWQgc29tZSB0ZXh0IHRvIHRoZSB1c2UgY2FzZXMgZG9jdW1lbnQgdG8gbWFrZSBp
dCBhIGxpdHRsZSBtb3JlIHJlYWRlciBmcmllbmRseS4gSSBoYXZlIG5vdGljZWQgc29tZSB0eXBl
cyBhbHJlYWR5LCBJ4oCZbGwgZ2V0IHdvcmtpbmcgb24gdGhvc2Ugc28gdGhlIGRvYyBpcyBwZXJm
ZWN0IGZvciA5NS4NCg0KVGhhbmtzIGFsbCENCg0KTmF0YXNoYQ0KDQoNCk5hdGFzaGEgUm9vbmV5
IHwgVGVjaG5vbG9naXN0LCBXZWIgYW5kIEludGVybmV0LCBXM0MgJiBJRVRGIHwgR1NNQSB8IG5y
b29uZXlAZ3NtYS5jb208bWFpbHRvOm5yb29uZXlAZ3NtYS5jb20+IHwgKzQ0ICgwKSA3NzMwIDIx
OSA3NjUgfCBAdGhpc05hdGFzaGEgfCBTa3lwZTogbnJvb25leUBnc20ub3JnPG1haWx0bzpucm9v
bmV5QGdzbS5vcmc+DQoNCg0KDQpUaGlzIGVtYWlsIGFuZCBpdHMgYXR0YWNobWVudHMgYXJlIGlu
dGVuZGVkIGZvciB0aGUgYWJvdmUgbmFtZWQgb25seSBhbmQgbWF5IGJlIGNvbmZpZGVudGlhbC4g
SWYgdGhleSBoYXZlIGNvbWUgdG8geW91IGluIGVycm9yIHlvdSBtdXN0IHRha2Ugbm8gYWN0aW9u
IGJhc2VkIG9uIHRoZW0sIG5vciBtdXN0IHlvdSBjb3B5IG9yIHNob3cgdGhlbSB0byBhbnlvbmU7
IHBsZWFzZSByZXBseSB0byB0aGlzIGVtYWlsIG9yIGNhbGwgKzQ0IDIwNyAzNTYgMDYwMCBhbmQg
aGlnaGxpZ2h0IHRoZSBlcnJvci4NCg==

--_000_0834B9F0D70542BFB65ABEDC0620CBCBgsmacom_
Content-Type: text/html; charset="utf-8"
Content-ID: <38B5CDD425DD484F962C5DBC12F91821@eurprd04.prod.outlook.com>
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy
ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGkgYWxsLA0KPGRpdiBjbGFzcz0i
Ij48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+V2UgaGF2ZSB0d28gbmV3IGRy
YWZ0IHVwbG9hZHMgdG8gb3VyIGRvY3VtZW50cyBsaXN0OjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48
YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGIgY2xhc3M9IiI+ZHJhZnQtaWV0
Zi1zbGltLW5lZ290aWF0aW5nLWh1bWFuLWxhbmd1YWdlLTAxJm5ic3A7PGJyIGNsYXNzPSIiPg0K
TmVnb3RpYXRpbmcgSHVtYW4gTGFuZ3VhZ2UgaW4gUmVhbC1UaW1lIENvbW11bmljYXRpb25zPC9i
PjxiciBjbGFzcz0iIj4NCk5payBhbmQgTmF0aGFuaWVsIGhhdmUgd29ya2VkIG9uIGEgbmV3IHZl
cnNpb24gb2YgdGhlIGRvY3VtZW50LCBwbGVhc2UgcmV2aWV3IHdoZW4geW91IGNhbiAocHJpb3Ig
dG8gSUVURjk1IGlmIHBvc3NpYmxlISk8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIi
Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiIGNsYXNzPSIiPmRyYWZ0LWlldGYtc2xpbS11c2Ut
Y2FzZXMtMDAmbmJzcDs8YnIgY2xhc3M9IiI+DQpTTElNIFVzZSBDYXNlczwvYj48YnIgY2xhc3M9
IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgbGV0
dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRl
eHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFs
OyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdp
ZHRoOiAwcHg7IHdvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNl
OyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQo8ZGl2
IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBo
YW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFu
c2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFj
aW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgd29yZC13cmFwOiBicmVh
ay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0
ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkkgaGF2ZSBhZGRlZCBzb21lIHRleHQgdG8gdGhl
IHVzZSBjYXNlcyBkb2N1bWVudCB0byBtYWtlIGl0IGEgbGl0dGxlIG1vcmUgcmVhZGVyIGZyaWVu
ZGx5LiBJIGhhdmUgbm90aWNlZCBzb21lIHR5cGVzIGFscmVhZHksIEnigJlsbCBnZXQgd29ya2lu
ZyBvbiB0aG9zZSBzbyB0aGUgZG9jIGlzIHBlcmZlY3QgZm9yIDk1LjxiciBjbGFzcz0iIj4NCjxi
ciBjbGFzcz0iIj4NClRoYW5rcyBhbGwhPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KTmF0
YXNoYTxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCk5hdGFzaGEg
Um9vbmV5IHwgVGVjaG5vbG9naXN0LCBXZWIgYW5kIEludGVybmV0LCBXM0MgJmFtcDsgSUVURiB8
Jm5ic3A7R1NNQSB8IDxhIGhyZWY9Im1haWx0bzpucm9vbmV5QGdzbWEuY29tIiBjbGFzcz0iIj4N
Cm5yb29uZXlAZ3NtYS5jb208L2E+IHwgJiM0Mzs0NCAoMCkmbmJzcDs3NzMwIDIxOSA3NjUgfCBA
dGhpc05hdGFzaGEgfCBTa3lwZTombmJzcDs8YSBocmVmPSJtYWlsdG86bnJvb25leUBnc20ub3Jn
IiBjbGFzcz0iIj5ucm9vbmV5QGdzbS5vcmc8L2E+Jm5ic3A7PGJyIGNsYXNzPSIiPg0KPGJyIGNs
YXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8
cCBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLHNhbnMtc2VyaWY7Zm9udC1zaXplOjExcHg7Y29s
b3I6Izk5OTk5OTsiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFs
LHNhbnMtc2VyaWY7Y29sb3I6Izk5OTk5OTsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IEFyaWFs
OyBtc28tZmFyZWFzdC10aGVtZS1mb250OiBtaW5vci1sYXRpbjsgbXNvLWJpZGktZm9udC1mYW1p
bHk6ICZxdW90O0FyaWFsJnF1b3Q7OyBtc28tYW5zaS1sYW5ndWFnZTogRU4tVVM7IG1zby1mYXJl
YXN0LWxhbmd1YWdlOiBFTi1HQjsgbXNvLWJpZGktbGFuZ3VhZ2U6IEFSLVNBIj5UaGlzDQogZW1h
aWwgYW5kIGl0cyBhdHRhY2htZW50cyBhcmUgaW50ZW5kZWQgZm9yIHRoZSBhYm92ZSBuYW1lZCBv
bmx5IGFuZCBtYXkgYmUgY29uZmlkZW50aWFsLiBJZiB0aGV5IGhhdmUgY29tZSB0byB5b3UgaW4g
ZXJyb3IgeW91IG11c3QgdGFrZSBubyBhY3Rpb24gYmFzZWQgb24gdGhlbSwgbm9yIG11c3QgeW91
IGNvcHkgb3Igc2hvdyB0aGVtIHRvIGFueW9uZTsgcGxlYXNlIHJlcGx5IHRvIHRoaXMgZW1haWwg
b3IgY2FsbCAmIzQzOzQ0IDIwNyAzNTYgMDYwMA0KIGFuZCBoaWdobGlnaHQgdGhlIGVycm9yLiA8
L3NwYW4+PC9wPg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_0834B9F0D70542BFB65ABEDC0620CBCBgsmacom_--


From nobody Mon Mar 21 14:49:15 2016
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5360912D0B1 for ; Mon, 21 Mar 2016 14:49:14 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gsmasso.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G_yyVhH9OlMQ for ; Mon, 21 Mar 2016 14:49:12 -0700 (PDT)
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 746C212D0BC for ; Mon, 21 Mar 2016 14:49:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=GSMASSO.onmicrosoft.com; s=selector1-gsma-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=+B56CO+K79/I9YbnpzkZk2P5YgO6hyPYPCqyuWM6Nfo=; b=ExZFRhE2Jx/1KtQK6yRWf8BW+VMbcecKp4QL1Qj4Xsgx6P9zEMmfm/4eC1BfsJL4Zx9+NaXOQzkzIdBL70bjuMoju/fWQzSZbOwf7fLf5v2sX1g0YAOTrV9POaMf2yMrBY3zlgOWmWovLQjWIU795ysn8+4WH7i98OPH/FuZZN0=
Received: from DB5PR04MB1029.eurprd04.prod.outlook.com (10.161.199.143) by DB5PR04MB1030.eurprd04.prod.outlook.com (10.161.199.144) with Microsoft SMTP Server (TLS) id 15.1.434.16; Mon, 21 Mar 2016 21:48:49 +0000
Received: from DB5PR04MB1029.eurprd04.prod.outlook.com ([10.161.199.143]) by DB5PR04MB1029.eurprd04.prod.outlook.com ([10.161.199.143]) with mapi id 15.01.0434.021; Mon, 21 Mar 2016 21:48:49 +0000
From: Natasha Rooney 
To: "slim@ietf.org" 
Thread-Topic: [Slim] New drafts
Thread-Index: AQHRg7o4V7rGe8/kfkGgMcQexEsOwZ9kb3EA
Date: Mon, 21 Mar 2016 21:48:49 +0000
Message-ID: <42239F35-E308-40DA-BDA4-F5464F5D4C7E@gsma.com>
References: <0834B9F0-D705-42BF-B65A-BEDC0620CBCB@gsma.com>
In-Reply-To: <0834B9F0-D705-42BF-B65A-BEDC0620CBCB@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.3112)
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=gsma.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [18.111.17.192]
x-ms-office365-filtering-correlation-id: 6cb66c9f-9446-4974-4f46-08d351d29639
x-microsoft-exchange-diagnostics: 1; DB5PR04MB1030; 5:OL6QtgCvwQKO44IATgLP9iA3t0K+/YqNFr5t+GqcpIMHYg5mUbXL+ePUpesGnsxlRkgKczGZvwOeJe0kcAX7YdypJ9d64h5aZWsO42wd4UtQ8DetftenuFxJQv7vJwdFVe+cm+ss4hiz1qJ2WZ1b6A==; 24:0H8Gr6lJRt5PKJXaDXNu7C4+w1CP7qcNm7t3jxH0OY885RLULZm8E7PGI5HfNQ5Ps7EgC/rt5RDAFpGOr2YOZV8jjY1ouNM6y9Gq6Ee0OwU=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB5PR04MB1030;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:DB5PR04MB1030; BCL:0; PCL:0; RULEID:; SRVR:DB5PR04MB1030; 
x-forefront-prvs: 0888B1D284
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(24454002)(377454003)(53754006)(2501003)(5890100001)(106116001)(3660700001)(92566002)(3280700002)(2351001)(16236675004)(82746002)(5640700001)(81166005)(50226001)(33656002)(19617315012)(2950100001)(2900100001)(15975445007)(5008740100001)(107886002)(110136002)(189998001)(36756003)(11100500001)(77096005)(19580405001)(19580395003)(1730700002)(5002640100001)(122556002)(1096002)(1220700001)(5004730100002)(10400500002)(586003)(83716003)(87936001)(6116002)(76176999)(86362001)(102836003)(2906002)(450100001)(57306001)(3846002)(66066001)(50986999); DIR:OUT; SFP:1101; SCL:1; SRVR:DB5PR04MB1030; H:DB5PR04MB1029.eurprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_42239F35E30840DABDA4F5464F5D4C7Egsmacom_"
MIME-Version: 1.0
X-OriginatorOrg: gsma.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Mar 2016 21:48:49.3285 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72a4ff82-fec3-469d-aafb-ac8276216699
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR04MB1030
X-MS-Exchange-CrossPremises-AuthAs: Internal
X-MS-Exchange-CrossPremises-AuthMechanism: 04
X-MS-Exchange-CrossPremises-AuthSource: DB5PR04MB1029.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: 18.111.17.192
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: DB5PR04MB1030.eurprd04.prod.outlook.com
Archived-At: 
Subject: Re: [Slim] New drafts
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
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, 21 Mar 2016 21:49:14 -0000

--_000_42239F35E30840DABDA4F5464F5D4C7Egsmacom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

QXBvbG9naWVzLCBJIGZvcmdvdCB0aGUgbGluayB0byB0aGUgZG9jdW1lbnRzIGluIGRhdGF0cmFj
a2VyIGluIHRoZSBsYXN0IG1haWwuDQoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvd2cv
c2xpbS9kb2N1bWVudHMvDQoNCk5hdGFzaGENCg0KDQpOYXRhc2hhIFJvb25leSB8IFRlY2hub2xv
Z2lzdCwgV2ViIGFuZCBJbnRlcm5ldCwgVzNDICYgSUVURiB8IEdTTUEgfCBucm9vbmV5QGdzbWEu
Y29tPG1haWx0bzpucm9vbmV5QGdzbWEuY29tPiB8ICs0NCAoMCkgNzczMCAyMTkgNzY1IHwgQHRo
aXNOYXRhc2hhIHwgU2t5cGU6IG5yb29uZXlAZ3NtLm9yZzxtYWlsdG86bnJvb25leUBnc20ub3Jn
Pg0KDQoNCk9uIE1hciAyMSwgMjAxNiwgYXQgNTo0MCBQTSwgTmF0YXNoYSBSb29uZXkgPG5yb29u
ZXlAZ3NtYS5jb208bWFpbHRvOm5yb29uZXlAZ3NtYS5jb20+PiB3cm90ZToNCg0KSGkgYWxsLA0K
DQpXZSBoYXZlIHR3byBuZXcgZHJhZnQgdXBsb2FkcyB0byBvdXIgZG9jdW1lbnRzIGxpc3Q6DQoN
CmRyYWZ0LWlldGYtc2xpbS1uZWdvdGlhdGluZy1odW1hbi1sYW5ndWFnZS0wMQ0KTmVnb3RpYXRp
bmcgSHVtYW4gTGFuZ3VhZ2UgaW4gUmVhbC1UaW1lIENvbW11bmljYXRpb25zDQpOaWsgYW5kIE5h
dGhhbmllbCBoYXZlIHdvcmtlZCBvbiBhIG5ldyB2ZXJzaW9uIG9mIHRoZSBkb2N1bWVudCwgcGxl
YXNlIHJldmlldyB3aGVuIHlvdSBjYW4gKHByaW9yIHRvIElFVEY5NSBpZiBwb3NzaWJsZSEpDQoN
CmRyYWZ0LWlldGYtc2xpbS11c2UtY2FzZXMtMDANClNMSU0gVXNlIENhc2VzDQpJIGhhdmUgYWRk
ZWQgc29tZSB0ZXh0IHRvIHRoZSB1c2UgY2FzZXMgZG9jdW1lbnQgdG8gbWFrZSBpdCBhIGxpdHRs
ZSBtb3JlIHJlYWRlciBmcmllbmRseS4gSSBoYXZlIG5vdGljZWQgc29tZSB0eXBlcyBhbHJlYWR5
LCBJ4oCZbGwgZ2V0IHdvcmtpbmcgb24gdGhvc2Ugc28gdGhlIGRvYyBpcyBwZXJmZWN0IGZvciA5
NS4NCg0KVGhhbmtzIGFsbCENCg0KTmF0YXNoYQ0KDQoNCk5hdGFzaGEgUm9vbmV5IHwgVGVjaG5v
bG9naXN0LCBXZWIgYW5kIEludGVybmV0LCBXM0MgJiBJRVRGIHwgR1NNQSB8IG5yb29uZXlAZ3Nt
YS5jb208bWFpbHRvOm5yb29uZXlAZ3NtYS5jb20+IHwgKzQ0ICgwKSA3NzMwIDIxOSA3NjUgfCBA
dGhpc05hdGFzaGEgfCBTa3lwZTogbnJvb25leUBnc20ub3JnPG1haWx0bzpucm9vbmV5QGdzbS5v
cmc+DQoNCg0KDQpUaGlzIGVtYWlsIGFuZCBpdHMgYXR0YWNobWVudHMgYXJlIGludGVuZGVkIGZv
ciB0aGUgYWJvdmUgbmFtZWQgb25seSBhbmQgbWF5IGJlIGNvbmZpZGVudGlhbC4gSWYgdGhleSBo
YXZlIGNvbWUgdG8geW91IGluIGVycm9yIHlvdSBtdXN0IHRha2Ugbm8gYWN0aW9uIGJhc2VkIG9u
IHRoZW0sIG5vciBtdXN0IHlvdSBjb3B5IG9yIHNob3cgdGhlbSB0byBhbnlvbmU7IHBsZWFzZSBy
ZXBseSB0byB0aGlzIGVtYWlsIG9yIGNhbGwgKzQ0IDIwNyAzNTYgMDYwMCBhbmQgaGlnaGxpZ2h0
IHRoZSBlcnJvci4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18NClNMSU0gbWFpbGluZyBsaXN0DQpTTElNQGlldGYub3JnPG1haWx0bzpTTElNQGlldGYu
b3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zbGltDQoNCg0KVGhp
cyBlbWFpbCBhbmQgaXRzIGF0dGFjaG1lbnRzIGFyZSBpbnRlbmRlZCBmb3IgdGhlIGFib3ZlIG5h
bWVkIG9ubHkgYW5kIG1heSBiZSBjb25maWRlbnRpYWwuIElmIHRoZXkgaGF2ZSBjb21lIHRvIHlv
dSBpbiBlcnJvciB5b3UgbXVzdCB0YWtlIG5vIGFjdGlvbiBiYXNlZCBvbiB0aGVtLCBub3IgbXVz
dCB5b3UgY29weSBvciBzaG93IHRoZW0gdG8gYW55b25lOyBwbGVhc2UgcmVwbHkgdG8gdGhpcyBl
bWFpbCBvciBjYWxsICs0NCAyMDcgMzU2IDA2MDAgYW5kIGhpZ2hsaWdodCB0aGUgZXJyb3IuDQo=

--_000_42239F35E30840DABDA4F5464F5D4C7Egsmacom_
Content-Type: text/html; charset="utf-8"
Content-ID: <1F22401C70BDCA4BA714B07670B01619@eurprd04.prod.outlook.com>
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy
ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KQXBvbG9naWVzLCBJIGZvcmdvdCB0
aGUgbGluayB0byB0aGUgZG9jdW1lbnRzIGluIGRhdGF0cmFja2VyIGluIHRoZSBsYXN0IG1haWwu
PGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IndlYmtpdC1ibG9jay1wbGFj
ZWhvbGRlciI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdi
KDAsIDAsIDApOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFs
aWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRl
LXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQt
dGV4dC1zdHJva2Utd2lkdGg6IDBweDsgd29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5i
c3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBj
bGFzcz0iIj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGxldHRlci1zcGFjaW5n
OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDog
MHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBh
dXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB3
b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1s
aW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6
Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy93Zy9zbGltL2RvY3VtZW50cy8iIGNsYXNzPSIiPmh0dHBz
Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvd2cvc2xpbS9kb2N1bWVudHMvPC9hPjxiciBjbGFzcz0i
Ij4NCjxiciBjbGFzcz0iIj4NCk5hdGFzaGE8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8
YnIgY2xhc3M9IiI+DQpOYXRhc2hhIFJvb25leSB8IFRlY2hub2xvZ2lzdCwgV2ViIGFuZCBJbnRl
cm5ldCwgVzNDICZhbXA7IElFVEYgfCZuYnNwO0dTTUEgfCA8YSBocmVmPSJtYWlsdG86bnJvb25l
eUBnc21hLmNvbSIgY2xhc3M9IiI+DQpucm9vbmV5QGdzbWEuY29tPC9hPiB8ICYjNDM7NDQgKDAp
Jm5ic3A7NzczMCAyMTkgNzY1IHwgQHRoaXNOYXRhc2hhIHwgU2t5cGU6Jm5ic3A7PGEgaHJlZj0i
bWFpbHRvOm5yb29uZXlAZ3NtLm9yZyIgY2xhc3M9IiI+bnJvb25leUBnc20ub3JnPC9hPiZuYnNw
OzxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxi
ciBjbGFzcz0iIj4NCjxkaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxk
aXYgY2xhc3M9IiI+T24gTWFyIDIxLCAyMDE2LCBhdCA1OjQwIFBNLCBOYXRhc2hhIFJvb25leSAm
bHQ7PGEgaHJlZj0ibWFpbHRvOm5yb29uZXlAZ3NtYS5jb20iIGNsYXNzPSIiPm5yb29uZXlAZ3Nt
YS5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2Ut
bmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13
b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXIt
d2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkhpIGFsbCwNCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNz
PSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPldlIGhhdmUgdHdvIG5ldyBkcmFmdCB1cGxvYWRz
IHRvIG91ciBkb2N1bWVudHMgbGlzdDo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIi
Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiIGNsYXNzPSIiPmRyYWZ0LWlldGYtc2xpbS1uZWdv
dGlhdGluZy1odW1hbi1sYW5ndWFnZS0wMSZuYnNwOzxiciBjbGFzcz0iIj4NCk5lZ290aWF0aW5n
IEh1bWFuIExhbmd1YWdlIGluIFJlYWwtVGltZSBDb21tdW5pY2F0aW9uczwvYj48YnIgY2xhc3M9
IiI+DQpOaWsgYW5kIE5hdGhhbmllbCBoYXZlIHdvcmtlZCBvbiBhIG5ldyB2ZXJzaW9uIG9mIHRo
ZSBkb2N1bWVudCwgcGxlYXNlIHJldmlldyB3aGVuIHlvdSBjYW4gKHByaW9yIHRvIElFVEY5NSBp
ZiBwb3NzaWJsZSEpPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0K
PGRpdiBjbGFzcz0iIj48YiBjbGFzcz0iIj5kcmFmdC1pZXRmLXNsaW0tdXNlLWNhc2VzLTAwJm5i
c3A7PGJyIGNsYXNzPSIiPg0KU0xJTSBVc2UgQ2FzZXM8L2I+PGJyIGNsYXNzPSIiPg0KPGRpdiBj
bGFzcz0iIj4NCjxkaXYgc3R5bGU9ImxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1
dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTog
bm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBw
eDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7
IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0
ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsg
b3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQt
dHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQt
c3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHdvcmQtd3JhcDog
YnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6
IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQpJIGhhdmUgYWRkZWQgc29tZSB0ZXh0IHRv
IHRoZSB1c2UgY2FzZXMgZG9jdW1lbnQgdG8gbWFrZSBpdCBhIGxpdHRsZSBtb3JlIHJlYWRlciBm
cmllbmRseS4gSSBoYXZlIG5vdGljZWQgc29tZSB0eXBlcyBhbHJlYWR5LCBJ4oCZbGwgZ2V0IHdv
cmtpbmcgb24gdGhvc2Ugc28gdGhlIGRvYyBpcyBwZXJmZWN0IGZvciA5NS48YnIgY2xhc3M9IiI+
DQo8YnIgY2xhc3M9IiI+DQpUaGFua3MgYWxsITxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4N
Ck5hdGFzaGE8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpOYXRh
c2hhIFJvb25leSB8IFRlY2hub2xvZ2lzdCwgV2ViIGFuZCBJbnRlcm5ldCwgVzNDICZhbXA7IElF
VEYgfCZuYnNwO0dTTUEgfCA8YSBocmVmPSJtYWlsdG86bnJvb25leUBnc21hLmNvbSIgY2xhc3M9
IiI+DQpucm9vbmV5QGdzbWEuY29tPC9hPiB8ICYjNDM7NDQgKDApJm5ic3A7NzczMCAyMTkgNzY1
IHwgQHRoaXNOYXRhc2hhIHwgU2t5cGU6Jm5ic3A7PGEgaHJlZj0ibWFpbHRvOm5yb29uZXlAZ3Nt
Lm9yZyIgY2xhc3M9IiI+bnJvb25leUBnc20ub3JnPC9hPiZuYnNwOzxiciBjbGFzcz0iIj4NCjxi
ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2
Pg0KPHAgc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCxzYW5zLXNlcmlmO2ZvbnQtc2l6ZToxMXB4
O2NvbG9yOiM5OTk5OTk7IiBjbGFzcz0iIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt
ZmFtaWx5OiBBcmlhbCxzYW5zLXNlcmlmO2NvbG9yOiM5OTk5OTk7IG1zby1mYXJlYXN0LWZvbnQt
ZmFtaWx5OiBBcmlhbDsgbXNvLWZhcmVhc3QtdGhlbWUtZm9udDogbWlub3ItbGF0aW47IG1zby1i
aWRpLWZvbnQtZmFtaWx5OiAmcXVvdDtBcmlhbCZxdW90OzsgbXNvLWFuc2ktbGFuZ3VhZ2U6IEVO
LVVTOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogRU4tR0I7IG1zby1iaWRpLWxhbmd1YWdlOiBBUi1T
QSIgY2xhc3M9IiI+VGhpcw0KIGVtYWlsIGFuZCBpdHMgYXR0YWNobWVudHMgYXJlIGludGVuZGVk
IGZvciB0aGUgYWJvdmUgbmFtZWQgb25seSBhbmQgbWF5IGJlIGNvbmZpZGVudGlhbC4gSWYgdGhl
eSBoYXZlIGNvbWUgdG8geW91IGluIGVycm9yIHlvdSBtdXN0IHRha2Ugbm8gYWN0aW9uIGJhc2Vk
IG9uIHRoZW0sIG5vciBtdXN0IHlvdSBjb3B5IG9yIHNob3cgdGhlbSB0byBhbnlvbmU7IHBsZWFz
ZSByZXBseSB0byB0aGlzIGVtYWlsIG9yIGNhbGwgJiM0Mzs0NCAyMDcgMzU2IDA2MDANCiBhbmQg
aGlnaGxpZ2h0IHRoZSBlcnJvci4gPC9zcGFuPjwvcD4NCjwvZGl2Pg0KX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnIgY2xhc3M9IiI+DQpTTElNIG1haWxp
bmcgbGlzdDxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Im1haWx0bzpTTElNQGlldGYub3JnIiBjbGFz
cz0iIj5TTElNQGlldGYub3JnPC9hPjxiciBjbGFzcz0iIj4NCmh0dHBzOi8vd3d3LmlldGYub3Jn
L21haWxtYW4vbGlzdGluZm8vc2xpbTxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl
Pg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8cCBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLHNh
bnMtc2VyaWY7Zm9udC1zaXplOjExcHg7Y29sb3I6Izk5OTk5OTsiPjxzcGFuIGxhbmc9IkVOLVVT
IiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLHNhbnMtc2VyaWY7Y29sb3I6Izk5OTk5OTsgbXNv
LWZhcmVhc3QtZm9udC1mYW1pbHk6IEFyaWFsOyBtc28tZmFyZWFzdC10aGVtZS1mb250OiBtaW5v
ci1sYXRpbjsgbXNvLWJpZGktZm9udC1mYW1pbHk6ICZxdW90O0FyaWFsJnF1b3Q7OyBtc28tYW5z
aS1sYW5ndWFnZTogRU4tVVM7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBFTi1HQjsgbXNvLWJpZGkt
bGFuZ3VhZ2U6IEFSLVNBIj5UaGlzDQogZW1haWwgYW5kIGl0cyBhdHRhY2htZW50cyBhcmUgaW50
ZW5kZWQgZm9yIHRoZSBhYm92ZSBuYW1lZCBvbmx5IGFuZCBtYXkgYmUgY29uZmlkZW50aWFsLiBJ
ZiB0aGV5IGhhdmUgY29tZSB0byB5b3UgaW4gZXJyb3IgeW91IG11c3QgdGFrZSBubyBhY3Rpb24g
YmFzZWQgb24gdGhlbSwgbm9yIG11c3QgeW91IGNvcHkgb3Igc2hvdyB0aGVtIHRvIGFueW9uZTsg
cGxlYXNlIHJlcGx5IHRvIHRoaXMgZW1haWwgb3IgY2FsbCAmIzQzOzQ0IDIwNyAzNTYgMDYwMA0K
IGFuZCBoaWdobGlnaHQgdGhlIGVycm9yLiA8L3NwYW4+PC9wPg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_42239F35E30840DABDA4F5464F5D4C7Egsmacom_--


From nobody Tue Mar 22 08:03:27 2016
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CC4A12D5A2 for ; Tue, 22 Mar 2016 08:03:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level: 
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gsmasso.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TBZTNRissgiQ for ; Tue, 22 Mar 2016 08:03:23 -0700 (PDT)
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0050.outbound.protection.outlook.com [104.47.1.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63A8112D8B6 for ; Tue, 22 Mar 2016 07:56:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=GSMASSO.onmicrosoft.com; s=selector1-gsma-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=3vO4nH0m+KMptMESl5idqPZInZvW4+oSWl9HSgFPi94=; b=HGFOeKgSaUsoBZo7zK7vpOgSOhKjIRVp6dA0FF5V/t4q77i9eCf1sa6ciZjvxf0ioPbtj9eOwvzyt5YzPu2qU7ruIPPQHRPFWdz+QVssV5u1F9YPFOmilADtq5NxTb7zl7QiAt2mxSabWUqT3D/fWPqv6G1JV7eg9md6KLEl2bw=
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.443.12; Tue, 22 Mar 2016 14:56:26 +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.0443.014; Tue, 22 Mar 2016 14:56:26 +0000
From: Natasha Rooney 
To: "slim@ietf.org" 
Thread-Topic: New drafts
Thread-Index: AQHRhEsCMEWdG75hq0++ARz9F8Vwaw==
Date: Tue, 22 Mar 2016 14:56:26 +0000
Message-ID: <53196C9D-DEDF-4D80-AA30-377D87FA093A@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.3112)
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=gsma.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [18.111.17.192]
x-ms-office365-filtering-correlation-id: 964db06a-f2ab-421d-444a-08d3526224e2
x-microsoft-exchange-diagnostics: 1; HE1PR04MB1035; 5:xXot5cQTBb9hx7aqJKs+MuAipBERc5kLDwyVmDTaRy8OGMalyIv3MF/uSpE9W+eGLwuusqGfmUS8Ftz2e1DYTxDflSEVgcS3+DMW2PHyqz06MUqUM7uYX6WrmhRGjKH8OrnBhwei8ou2wSEscq6ALQ==; 24:uBnt3RGjClojYD/BSW8lsJtKHb8cFEY61qIA8TNaqNxiJTzlq0voYWGSVKjN3LOXkOwHWM9hJfxnOqUd/H2trizfzEhLuN4IbXfepULABW8=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR04MB1035;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:HE1PR04MB1035; BCL:0; PCL:0; RULEID:; SRVR:HE1PR04MB1035; 
x-forefront-prvs: 08897B549D
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(53754006)(3480700003)(586003)(3846002)(102836003)(6116002)(81166005)(5640700001)(106116001)(229853001)(16236675004)(77096005)(189998001)(5008740100001)(450100001)(122556002)(2351001)(107886002)(5890100001)(86362001)(2501003)(110136002)(11100500001)(2906002)(3660700001)(1220700001)(1730700002)(1096002)(3280700002)(66066001)(221733001)(19580405001)(50226001)(19580395003)(10400500002)(5004730100002)(83716003)(57306001)(82746002)(92566002)(87936001)(50986999)(33656002)(5002640100001)(36756003)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR04MB1035; H:HE1PR04MB1033.eurprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_53196C9DDEDF4D80AA30377D87FA093Agsmacom_"
MIME-Version: 1.0
X-OriginatorOrg: gsma.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2016 14:56:26.7671 (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: 18.111.17.192
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] New drafts
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
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, 22 Mar 2016 15:03:24 -0000

--_000_53196C9DDEDF4D80AA30377D87FA093Agsmacom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgYWxsLA0KDQpXZSBoYXZlIHR3byBuZXcgZHJhZnQgdXBsb2FkcyB0byBvdXIgZG9jdW1lbnRz
IGxpc3Q6DQoNCmRyYWZ0LWlldGYtc2xpbS1uZWdvdGlhdGluZy1odW1hbi1sYW5ndWFnZS0wMQ0K
TmVnb3RpYXRpbmcgSHVtYW4gTGFuZ3VhZ2UgaW4gUmVhbC1UaW1lIENvbW11bmljYXRpb25zDQpO
aWsgYW5kIE5hdGhhbmllbCBoYXZlIHdvcmtlZCBvbiBhIG5ldyB2ZXJzaW9uIG9mIHRoZSBkb2N1
bWVudCwgcGxlYXNlIHJldmlldyB3aGVuIHlvdSBjYW4gKHByaW9yIHRvIElFVEY5NSBpZiBwb3Nz
aWJsZSEpDQoNCmRyYWZ0LWlldGYtc2xpbS11c2UtY2FzZXMtMDANClNMSU0gVXNlIENhc2VzDQpJ
IGhhdmUgYWRkZWQgc29tZSB0ZXh0IHRvIHRoZSB1c2UgY2FzZXMgZG9jdW1lbnQgdG8gbWFrZSBp
dCBhIGxpdHRsZSBtb3JlIHJlYWRlciBmcmllbmRseS4gSSBoYXZlIG5vdGljZWQgc29tZSB0eXBl
cyBhbHJlYWR5LCBJ4oCZbGwgZ2V0IHdvcmtpbmcgb24gdGhvc2Ugc28gdGhlIGRvYyBpcyBwZXJm
ZWN0IGZvciA5NS4NCg0KVGhhbmtzIGFsbCENCg0KTmF0YXNoYQ0KDQoNCk5hdGFzaGEgUm9vbmV5
IHwgVGVjaG5vbG9naXN0LCBXZWIgYW5kIEludGVybmV0LCBXM0MgJiBJRVRGIHwgR1NNQSB8IG5y
b29uZXlAZ3NtYS5jb208bWFpbHRvOm5yb29uZXlAZ3NtYS5jb20+IHwgKzQ0ICgwKSA3NzMwIDIx
OSA3NjUgfCBAdGhpc05hdGFzaGEgfCBTa3lwZTogbnJvb25leUBnc20ub3JnPG1haWx0bzpucm9v
bmV5QGdzbS5vcmc+DQoNCg0KDQpUaGlzIGVtYWlsIGFuZCBpdHMgYXR0YWNobWVudHMgYXJlIGlu
dGVuZGVkIGZvciB0aGUgYWJvdmUgbmFtZWQgb25seSBhbmQgbWF5IGJlIGNvbmZpZGVudGlhbC4g
SWYgdGhleSBoYXZlIGNvbWUgdG8geW91IGluIGVycm9yIHlvdSBtdXN0IHRha2Ugbm8gYWN0aW9u
IGJhc2VkIG9uIHRoZW0sIG5vciBtdXN0IHlvdSBjb3B5IG9yIHNob3cgdGhlbSB0byBhbnlvbmU7
IHBsZWFzZSByZXBseSB0byB0aGlzIGVtYWlsIG9yIGNhbGwgKzQ0IDIwNyAzNTYgMDYwMCBhbmQg
aGlnaGxpZ2h0IHRoZSBlcnJvci4NCg==

--_000_53196C9DDEDF4D80AA30377D87FA093Agsmacom_
Content-Type: text/html; charset="utf-8"
Content-ID: <0AE1DE3139579342ACB15E808D123F13@eurprd04.prod.outlook.com>
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy
ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiIGRpcj0iYXV0byI+DQpIaSBhbGwsDQo8
ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5XZSBoYXZl
IHR3byBuZXcgZHJhZnQgdXBsb2FkcyB0byBvdXIgZG9jdW1lbnRzIGxpc3Q6PC9kaXY+DQo8ZGl2
IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YiBjbGFzcz0i
Ij5kcmFmdC1pZXRmLXNsaW0tbmVnb3RpYXRpbmctaHVtYW4tbGFuZ3VhZ2UtMDEmbmJzcDs8YnIg
Y2xhc3M9IiI+DQpOZWdvdGlhdGluZyBIdW1hbiBMYW5ndWFnZSBpbiBSZWFsLVRpbWUgQ29tbXVu
aWNhdGlvbnM8L2I+PGJyIGNsYXNzPSIiPg0KTmlrIGFuZCBOYXRoYW5pZWwgaGF2ZSB3b3JrZWQg
b24gYSBuZXcgdmVyc2lvbiBvZiB0aGUgZG9jdW1lbnQsIHBsZWFzZSByZXZpZXcgd2hlbiB5b3Ug
Y2FuIChwcmlvciB0byBJRVRGOTUgaWYgcG9zc2libGUhKTwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48
YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGIgY2xhc3M9IiI+ZHJhZnQtaWV0
Zi1zbGltLXVzZS1jYXNlcy0wMCZuYnNwOzxiciBjbGFzcz0iIj4NClNMSU0gVXNlIENhc2VzPC9i
PjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAs
IDAsIDApOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWdu
OiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNw
YWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4
dC1zdHJva2Utd2lkdGg6IDBweDsgd29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3At
bW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFz
cz0iIj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGxldHRlci1zcGFjaW5nOiBu
b3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4
OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRv
OyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB3b3Jk
LXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5l
LWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSSBoYXZlIGFkZGVkIHNvbWUg
dGV4dCB0byB0aGUgdXNlIGNhc2VzIGRvY3VtZW50IHRvIG1ha2UgaXQgYSBsaXR0bGUgbW9yZSBy
ZWFkZXIgZnJpZW5kbHkuIEkgaGF2ZSBub3RpY2VkIHNvbWUgdHlwZXMgYWxyZWFkeSwgSeKAmWxs
IGdldCB3b3JraW5nIG9uIHRob3NlIHNvIHRoZSBkb2MgaXMgcGVyZmVjdCBmb3IgOTUuPGJyIGNs
YXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KVGhhbmtzIGFsbCE8YnIgY2xhc3M9IiI+DQo8YnIgY2xh
c3M9IiI+DQpOYXRhc2hhPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIi
Pg0KTmF0YXNoYSBSb29uZXkgfCBUZWNobm9sb2dpc3QsIFdlYiBhbmQgSW50ZXJuZXQsIFczQyAm
YW1wOyBJRVRGIHwmbmJzcDtHU01BIHwgPGEgaHJlZj0ibWFpbHRvOm5yb29uZXlAZ3NtYS5jb20i
IGNsYXNzPSIiPg0KbnJvb25leUBnc21hLmNvbTwvYT4gfCAmIzQzOzQ0ICgwKSZuYnNwOzc3MzAg
MjE5IDc2NSB8IEB0aGlzTmF0YXNoYSB8IFNreXBlOiZuYnNwOzxhIGhyZWY9Im1haWx0bzpucm9v
bmV5QGdzbS5vcmciIGNsYXNzPSIiPm5yb29uZXlAZ3NtLm9yZzwvYT4mbmJzcDs8YnIgY2xhc3M9
IiI+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+
DQo8L2Rpdj4NCjxwIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsc2Fucy1zZXJpZjtmb250LXNp
emU6MTFweDtjb2xvcjojOTk5OTk5OyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZh
bWlseTogQXJpYWwsc2Fucy1zZXJpZjtjb2xvcjojOTk5OTk5OyBtc28tZmFyZWFzdC1mb250LWZh
bWlseTogQXJpYWw7IG1zby1mYXJlYXN0LXRoZW1lLWZvbnQ6IG1pbm9yLWxhdGluOyBtc28tYmlk
aS1mb250LWZhbWlseTogJnF1b3Q7QXJpYWwmcXVvdDs7IG1zby1hbnNpLWxhbmd1YWdlOiBFTi1V
UzsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEVOLUdCOyBtc28tYmlkaS1sYW5ndWFnZTogQVItU0Ei
PlRoaXMNCiBlbWFpbCBhbmQgaXRzIGF0dGFjaG1lbnRzIGFyZSBpbnRlbmRlZCBmb3IgdGhlIGFi
b3ZlIG5hbWVkIG9ubHkgYW5kIG1heSBiZSBjb25maWRlbnRpYWwuIElmIHRoZXkgaGF2ZSBjb21l
IHRvIHlvdSBpbiBlcnJvciB5b3UgbXVzdCB0YWtlIG5vIGFjdGlvbiBiYXNlZCBvbiB0aGVtLCBu
b3IgbXVzdCB5b3UgY29weSBvciBzaG93IHRoZW0gdG8gYW55b25lOyBwbGVhc2UgcmVwbHkgdG8g
dGhpcyBlbWFpbCBvciBjYWxsICYjNDM7NDQgMjA3IDM1NiAwNjAwDQogYW5kIGhpZ2hsaWdodCB0
aGUgZXJyb3IuIDwvc3Bhbj48L3A+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_53196C9DDEDF4D80AA30377D87FA093Agsmacom_--


From nobody Thu Mar 31 09:29:45 2016
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57AEB12D667 for ; Thu, 31 Mar 2016 09:29:43 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gsmasso.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lmw2PJZMszXc for ; Thu, 31 Mar 2016 09:29:40 -0700 (PDT)
Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0678.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::678]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39A1B12D621 for ; Thu, 31 Mar 2016 09:29:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=GSMASSO.onmicrosoft.com; s=selector1-gsma-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ATSO8cisGxPkfwvPQw2gJIE3p7xU84GQeZ5J3JEc9kY=; b=GCKVlm0ZSVTtODHVB8HDWKE/XYo1o79W56tGR9EE08vKBBheiRT4h0IKSFJg6w/3vdwMwkxg5+Ajfzao2ypTpihCScXdOCs5OwzxsBuSFrOB5y4gDAbzT6tQTV8CSLWAy4TairxdZguM/QTbFEj3pLsdGBTd6UfuCWlHy/OZCuU=
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.447.15; Thu, 31 Mar 2016 16:29:23 +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.0447.024; Thu, 31 Mar 2016 16:29:22 +0000
From: Natasha Rooney 
To: "slim@ietf.org" 
Thread-Topic: Documents
Thread-Index: AQHRi2p7ynf0DeMCWEee/KwfQr++HQ==
Date: Thu, 31 Mar 2016 16:29:22 +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.3112)
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=gsma.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [62.189.0.100]
x-ms-office365-filtering-correlation-id: 95af596c-e660-4f53-93f5-08d359819e32
x-microsoft-exchange-diagnostics: 1; HE1PR04MB1034; 5:qBbJ3jmwBbFDjQFcfgjcnDprMZMaZ2RJYidpAI3TBOLyP5gYYjMQqw3yyASeT/8dVoqV93G/+z/CmRIsVGcoPkemo19SQFTMKdNlQ72KyoeMIYAYq1dLTNdaZbshLAuJ9/hDUiIMhNn7qwDCLPHZUQ==; 24:mcwqbtPRZ4sdAOm9XUSvjxlF2ORelJ9PzHO8WwZv33IpfsQaLPjgDNac7UIplxwI5BGsHHc0vZBO4mSGQCt1WuTbRRhwdmJvabMZNTpn4Ns=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR04MB1034;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:HE1PR04MB1034; BCL:0; PCL:0; RULEID:; SRVR:HE1PR04MB1034; 
x-forefront-prvs: 0898A6E028
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(66654002)(53754006)(92566002)(5004730100002)(1220700001)(122556002)(3846002)(87936001)(106116001)(2900100001)(86362001)(66066001)(50226001)(5008740100001)(10400500002)(6116002)(102836003)(1096002)(221733001)(229853001)(2351001)(586003)(36756003)(19617315012)(450100001)(33656002)(107886002)(15975445007)(3480700003)(110136002)(2501003)(189998001)(16236675004)(5640700001)(81166005)(50986999)(2906002)(3280700002)(19580395003)(5002640100001)(77096005)(83716003)(5890100001)(1730700002)(19580405001)(82746002)(3660700001)(104396002)(7090700003); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR04MB1034; H:HE1PR04MB1033.eurprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_DB13A9EDCC1644268E04A1B7A02B92F7gsmacom_"
MIME-Version: 1.0
X-OriginatorOrg: gsma.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Mar 2016 16:29:22.8202 (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: 62.189.0.100
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] Documents
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
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, 31 Mar 2016 16:29:43 -0000

--_000_DB13A9EDCC1644268E04A1B7A02B92F7gsmacom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgYWxsIQ0KDQpIaSBhbGwhDQoNCldlIGhhdmUgc29tZSB1cGRhdGVzIHRvIHNvbWUgZG9jdW1l
bnRzOg0KDQpTTElNIFVzZSBDYXNlcw0KT2ZmaWNpYWw6IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0
Zi5vcmcvZG9jL2RyYWZ0LWlldGYtc2xpbS11c2UtY2FzZXMvDQpBbiB1cGRhdGVkIHZlcnNpb24g
KGNsZWFudXApIGhhcyBiZWVuIHVwbG9hZGVkIHRvIHRoZSBTTElNIEdpdGh1YiBSZXBvIChodHRw
czovL2dpdGh1Yi5jb20vaWV0Zi1zbGltLXdnL3NsaW0tdXNlLWNhc2VzKQ0KQUNUSU9OIFRPIEFM
TDogUGxlYXNlIFJldmlldw0KDQpOZWdvdGlhdGluZyBIdW1hbiBMYW5ndWFnZSBpbiBSZWFsLVRp
bWUgQ29tbXVuaWNhdGlvbnMNCk9mZmljaWFsOiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn
L2RvYy9kcmFmdC1pZXRmLXNsaW0tbmVnb3RpYXRpbmctaHVtYW4tbGFuZ3VhZ2UvDQpUaGlzIGlz
IFJhbmRhbGzigJlzIGRyYWZ0IHdoaWNoIEkgaW5jb3JyZWN0bHkgbm90ZWQgaW4gdGhlIGxhc3Qg
bWFpbHMgLSBhcG9sb2dpZXMgZm9yIHRoaXMuDQpBQ1RJT04gVE8gQUxMOiBQbGVhc2UgUmV2aWV3
DQoNCk11bHRpcGxlIExhbmd1YWdlIENvbnRlbnQgVHlwZQ0KT2ZmaWNpYWw6IGh0dHBzOi8vZGF0
YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtc2xpbS1tdWx0aWxhbmdjb250ZW50Lw0K
VGhpcyBkcmFmdCBoYXMgbm90IGhhZCBhbiB1cGRhdGUgYnV0IGV4cGVjdGVkIHVwZGF0ZXMgdG8g
dGhlIGRvY3VtZW50IHdpbGwgYmUgZ2l2ZW4gYnkgTmlrIG9yIGJ5IG1lIGluIHRoZSBtZWV0aW5n
IG5leHQgd2Vlay4NCg0KTWFueSB0aGFua3MhDQoNCk5hdGFzaGENCg0KDQpOYXRhc2hhIFJvb25l
eSB8IFRlY2hub2xvZ2lzdCwgV2ViIGFuZCBJbnRlcm5ldCwgVzNDICYgSUVURiB8IEdTTUEgfCBu
cm9vbmV5QGdzbWEuY29tPG1haWx0bzpucm9vbmV5QGdzbWEuY29tPiB8ICs0NCAoMCkgNzczMCAy
MTkgNzY1IHwgQHRoaXNOYXRhc2hhIHwgU2t5cGU6IG5yb29uZXlAZ3NtLm9yZzxtYWlsdG86bnJv
b25leUBnc20ub3JnPg0KDQoNCg0KVGhpcyBlbWFpbCBhbmQgaXRzIGF0dGFjaG1lbnRzIGFyZSBp
bnRlbmRlZCBmb3IgdGhlIGFib3ZlIG5hbWVkIG9ubHkgYW5kIG1heSBiZSBjb25maWRlbnRpYWwu
IElmIHRoZXkgaGF2ZSBjb21lIHRvIHlvdSBpbiBlcnJvciB5b3UgbXVzdCB0YWtlIG5vIGFjdGlv
biBiYXNlZCBvbiB0aGVtLCBub3IgbXVzdCB5b3UgY29weSBvciBzaG93IHRoZW0gdG8gYW55b25l
OyBwbGVhc2UgcmVwbHkgdG8gdGhpcyBlbWFpbCBvciBjYWxsICs0NCAyMDcgMzU2IDA2MDAgYW5k
IGhpZ2hsaWdodCB0aGUgZXJyb3IuDQo=

--_000_DB13A9EDCC1644268E04A1B7A02B92F7gsmacom_
Content-Type: text/html; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy
ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGkgYWxsIQ0KPGRpdiBjbGFzcz0i
Ij48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SGkgYWxsITxiciBjbGFzcz0i
Ij4NCjxiciBjbGFzcz0iIj4NCldlIGhhdmUgc29tZSB1cGRhdGVzIHRvIHNvbWUgZG9jdW1lbnRz
OjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPlNMSU0gVXNlIENhc2Vz
PC9iPjxiciBjbGFzcz0iIj4NCk9mZmljaWFsOiZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vZGF0YXRy
YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtc2xpbS11c2UtY2FzZXMvIiBjbGFzcz0iIj5o
dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXNsaW0tdXNlLWNhc2Vz
LzwvYT4mbmJzcDsmbmJzcDs8YnIgY2xhc3M9IiI+DQpBbiB1cGRhdGVkIHZlcnNpb24gKGNsZWFu
dXApIGhhcyBiZWVuIHVwbG9hZGVkIHRvIHRoZSBTTElNIEdpdGh1YiBSZXBvICg8YSBocmVmPSJo
dHRwczovL2dpdGh1Yi5jb20vaWV0Zi1zbGltLXdnL3NsaW0tdXNlLWNhc2VzIiBjbGFzcz0iIj5o
dHRwczovL2dpdGh1Yi5jb20vaWV0Zi1zbGltLXdnL3NsaW0tdXNlLWNhc2VzPC9hPik8L2Rpdj4N
CjxkaXYgY2xhc3M9IiI+QUNUSU9OIFRPIEFMTDogUGxlYXNlIFJldmlldzxiciBjbGFzcz0iIj4N
CjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRp
diBzdHlsZT0ib3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAw
cHg7IHdpZG93czogYXV0bzsgd29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9k
ZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0i
Ij4NCjxkaXYgc3R5bGU9Im9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWlu
ZGVudDogMHB4OyB3aWRvd3M6IGF1dG87IHdvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1u
YnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIg
Y2xhc3M9IiI+DQo8YiBjbGFzcz0iIj5OZWdvdGlhdGluZyBIdW1hbiBMYW5ndWFnZSBpbiBSZWFs
LVRpbWUgQ29tbXVuaWNhdGlvbnM8L2I+PGJyIGNsYXNzPSIiPg0KT2ZmaWNpYWw6Jm5ic3A7PGEg
aHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1zbGltLW5l
Z290aWF0aW5nLWh1bWFuLWxhbmd1YWdlLyIgY2xhc3M9IiI+aHR0cHM6Ly9kYXRhdHJhY2tlci5p
ZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1zbGltLW5lZ290aWF0aW5nLWh1bWFuLWxhbmd1YWdlLzwv
YT48L2Rpdj4NCjxkaXYgc3R5bGU9Im9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0
ZXh0LWluZGVudDogMHB4OyB3aWRvd3M6IGF1dG87IHdvcmQtd3JhcDogYnJlYWstd29yZDsgLXdl
YmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNw
YWNlOyIgY2xhc3M9IiI+DQpUaGlzIGlzIFJhbmRhbGzigJlzIGRyYWZ0IHdoaWNoIEkgaW5jb3Jy
ZWN0bHkgbm90ZWQgaW4gdGhlIGxhc3QgbWFpbHMgLSBhcG9sb2dpZXMgZm9yIHRoaXMuPC9kaXY+
DQo8ZGl2IHN0eWxlPSJvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRl
bnQ6IDBweDsgd2lkb3dzOiBhdXRvOyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJz
cC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNs
YXNzPSIiPg0KQUNUSU9OIFRPIEFMTDogUGxlYXNlIFJldmlldzwvZGl2Pg0KPGRpdiBzdHlsZT0i
b3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHdpZG93
czogYXV0bzsgd29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7
IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxiciBj
bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ib3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjog
c3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHdpZG93czogYXV0bzsgd29yZC13cmFwOiBicmVhay13
b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXIt
d2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPk11bHRpcGxlIExhbmd1YWdlIENv
bnRlbnQgVHlwZTwvYj48L2Rpdj4NCjxkaXYgc3R5bGU9Im9ycGhhbnM6IGF1dG87IHRleHQtYWxp
Z246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB3aWRvd3M6IGF1dG87IHdvcmQtd3JhcDogYnJl
YWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFm
dGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQpPZmZpY2lhbDombmJzcDs8YSBocmVmPSJodHRw
czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXNsaW0tbXVsdGlsYW5nY29u
dGVudC8iIGNsYXNzPSIiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWll
dGYtc2xpbS1tdWx0aWxhbmdjb250ZW50LzwvYT48L2Rpdj4NCjxkaXYgc3R5bGU9Im9ycGhhbnM6
IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB3aWRvd3M6IGF1dG87
IHdvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0
LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQpUaGlzIGRyYWZ0IGhh
cyBub3QgaGFkIGFuIHVwZGF0ZSBidXQgZXhwZWN0ZWQgdXBkYXRlcyB0byB0aGUgZG9jdW1lbnQg
d2lsbCBiZSBnaXZlbiBieSBOaWsgb3IgYnkgbWUgaW4gdGhlIG1lZXRpbmcgbmV4dCB3ZWVrLjwv
ZGl2Pg0KPGRpdiBzdHlsZT0ib3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQt
aW5kZW50OiAwcHg7IHdpZG93czogYXV0bzsgd29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0
LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7
IiBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ib3JwaGFuczog
YXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHdpZG93czogYXV0bzsg
d29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQt
bGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCk1hbnkgdGhhbmtzITwv
ZGl2Pg0KPGRpdiBzdHlsZT0ib3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQt
aW5kZW50OiAwcHg7IHdpZG93czogYXV0bzsgd29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0
LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7
IiBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCk5hdGFzaGE8YnIgY2xhc3M9IiI+DQo8YnIgY2xh
c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpOYXRhc2hhIFJvb25leSB8IFRlY2hub2xvZ2lzdCwgV2Vi
IGFuZCBJbnRlcm5ldCwgVzNDICZhbXA7IElFVEYgfCZuYnNwO0dTTUEgfCA8YSBocmVmPSJtYWls
dG86bnJvb25leUBnc21hLmNvbSIgY2xhc3M9IiI+DQpucm9vbmV5QGdzbWEuY29tPC9hPiB8ICYj
NDM7NDQgKDApJm5ic3A7NzczMCAyMTkgNzY1IHwgQHRoaXNOYXRhc2hhIHwgU2t5cGU6Jm5ic3A7
PGEgaHJlZj0ibWFpbHRvOm5yb29uZXlAZ3NtLm9yZyIgY2xhc3M9IiI+bnJvb25leUBnc20ub3Jn
PC9hPiZuYnNwOzxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPHAgc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlh
bCxzYW5zLXNlcmlmO2ZvbnQtc2l6ZToxMXB4O2NvbG9yOiM5OTk5OTk7Ij48c3BhbiBsYW5nPSJF
Ti1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCxzYW5zLXNlcmlmO2NvbG9yOiM5OTk5OTk7
IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiBBcmlhbDsgbXNvLWZhcmVhc3QtdGhlbWUtZm9udDog
bWlub3ItbGF0aW47IG1zby1iaWRpLWZvbnQtZmFtaWx5OiAmcXVvdDtBcmlhbCZxdW90OzsgbXNv
LWFuc2ktbGFuZ3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogRU4tR0I7IG1zby1i
aWRpLWxhbmd1YWdlOiBBUi1TQSI+VGhpcw0KIGVtYWlsIGFuZCBpdHMgYXR0YWNobWVudHMgYXJl
IGludGVuZGVkIGZvciB0aGUgYWJvdmUgbmFtZWQgb25seSBhbmQgbWF5IGJlIGNvbmZpZGVudGlh
bC4gSWYgdGhleSBoYXZlIGNvbWUgdG8geW91IGluIGVycm9yIHlvdSBtdXN0IHRha2Ugbm8gYWN0
aW9uIGJhc2VkIG9uIHRoZW0sIG5vciBtdXN0IHlvdSBjb3B5IG9yIHNob3cgdGhlbSB0byBhbnlv
bmU7IHBsZWFzZSByZXBseSB0byB0aGlzIGVtYWlsIG9yIGNhbGwgJiM0Mzs0NCAyMDcgMzU2IDA2
MDANCiBhbmQgaGlnaGxpZ2h0IHRoZSBlcnJvci4gPC9zcGFuPjwvcD4NCjwvYm9keT4NCjwvaHRt
bD4NCg==

--_000_DB13A9EDCC1644268E04A1B7A02B92F7gsmacom_--


From nobody Thu Mar 31 09:40:24 2016
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C380712D621 for ; Thu, 31 Mar 2016 09:40:21 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gsmasso.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WwnjRim1vR_L for ; Thu, 31 Mar 2016 09:40:18 -0700 (PDT)
Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0664.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::664]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C7B212D543 for ; Thu, 31 Mar 2016 09:40:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=GSMASSO.onmicrosoft.com; s=selector1-gsma-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=8V7iotpcBzZNlJ52Dvekev/dZlJkQOblVPJqckfOuNo=; b=ZOut/1yOF2XrPbHKBRIcHOcqDdK+5YHb3KlUiOKofyYJZuAZkoLFkrBnoMAJiAblLdmRFwo4sV1QcDvrCPwTg+IsPO8QTeK0sjxrBjTA/Suw3jHC55jGqHpLbAHxvTTqtfara9pgypqVea7fgu9qnRckKPSor1udCvaOHAS2Ilk=
Received: from HE1PR04MB1033.eurprd04.prod.outlook.com (10.162.26.142) by HE1PR04MB1033.eurprd04.prod.outlook.com (10.162.26.142) with Microsoft SMTP Server (TLS) id 15.1.447.15; Thu, 31 Mar 2016 16:39:56 +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.0447.024; Thu, 31 Mar 2016 16:39:56 +0000
From: Natasha Rooney 
To: "slim@ietf.org" 
Thread-Topic: IETF95, was: Re: [Slim] Change proposals for draft-ietf-slim-negotiating-human-language-00.txt
Thread-Index: AQHRgwmJVWwsWBtwGEO8RbSqbCDo8p9jbTOAgACxNICAAEFmgIAPcgiA
Date: Thu, 31 Mar 2016 16:39:56 +0000
Message-ID: 
References: <20151102160934.3160.2433.idtracker@ietfa.amsl.com> <56E8FEF0.10503@omnitor.se>  <56EF9277.7040306@omnitor.se>  <56F05DF9.2080802@omnitor.se>
In-Reply-To: <56F05DF9.2080802@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.3112)
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=gsma.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [62.189.0.100]
x-ms-office365-filtering-correlation-id: c508eeaf-0824-4401-0df5-08d3598317ec
x-microsoft-exchange-diagnostics: 1; HE1PR04MB1033; 5:KFGu1shwU6JDLkolOn20uLLl0Cr5I+rwmP2Uh4DjZZQOTr5/OkJZwwFpB88VdVaBqYYuKw+bO3THx9T2enWDDddZeM1Ft4gXr+R65Jenhpjp2xlQtLXZXT4h/rt3m1qoovSXg6p4qLov6nDLoAdyxQ==; 24:qInyXwk0UYVXj6DY2bWJ7M312OTGjN4xwcz8fRZLYnzbi3OyS68g0b44qVbbFOZYd5x38erx/sv5uGw4jVOkC9+EIoact2ENbN+Gm56KoAU=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR04MB1033;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:HE1PR04MB1033; BCL:0; PCL:0; RULEID:; SRVR:HE1PR04MB1033; 
x-forefront-prvs: 0898A6E028
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(24454002)(377454003)(53754006)(377424004)(158454003)(2501003)(16236675004)(19580395003)(19580405001)(82746002)(92566002)(102836003)(5890100001)(66066001)(77096005)(11100500001)(2351001)(1220700001)(106116001)(2950100001)(6116002)(1730700002)(3846002)(229853001)(2900100001)(586003)(15975445007)(50226001)(81166005)(3280700002)(5002640100001)(86362001)(5004730100002)(450100001)(3660700001)(5640700001)(1096002)(122556002)(10400500002)(2906002)(189998001)(76176999)(50986999)(87936001)(5008740100001)(19617315012)(83716003)(107886002)(36756003)(93886004)(110136002)(33656002)(230783001)(104396002)(7090700003); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR04MB1033; H:HE1PR04MB1033.eurprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_C208B73D6FC243E4A2B81791B25D5397gsmacom_"
MIME-Version: 1.0
X-OriginatorOrg: gsma.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Mar 2016 16:39:56.4274 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72a4ff82-fec3-469d-aafb-ac8276216699
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR04MB1033
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: 62.189.0.100
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: HE1PR04MB1033.eurprd04.prod.outlook.com
Archived-At: 
Subject: [Slim] IETF95, was: Re: Change proposals for draft-ietf-slim-negotiating-human-language-00.txt
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
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, 31 Mar 2016 16:40:22 -0000

--_000_C208B73D6FC243E4A2B81791B25D5397gsmacom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi all,

It=92s about time (or, perhaps late by two weeks!) that we decide on our ag=
enda for next week=92s meeting. We have an hour between 16:20-17:20 on Thur=
sday and we will have both remote and present attendees.

In this meeting we will be discussing the below open issue and updates that=
 have been made / will be made to the existing documents. The meeting shoul=
d be less than an hour. A guidelines agenda is:

Welcome
Update on SLIM new and existing docs
draft-ietf-slim-multilangcontent-00
draft-ietf-slim-negotiating-human-language-01
draft-ietf-slim-use-cases-00
Open Issue(s)

If you have something else to add please do let me know as soon as you can =
so I can add this to the agenda. I will publish this tomorrow.

Also, please let me know if you are attending in person or not if you haven=
=92t already!

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


On Mar 21, 2016, at 8:47 PM, Gunnar Hellstr=F6m > wrote:

Hi Randall,
Den 2016-03-21 kl. 17:53, skrev Randall Gellens:
Hi Gunnar,

I do not believe we are forcing an interpretation on RFC 4566, rather, the =
drafts says, in an explanatory aside in parentheses, how the authors interp=
ret it.  This is quite far from a normative statement.
It will be documented anyway, and just as you looked at the discussion arou=
nd the STOX - example and got influenced by it, there is a risk that we spr=
ead more uncertainty in the topic or lead others to make unlogical conclusi=
ons.
Let it be sufficient to say that 'lang' does not have the detailing we need=
.


I have re-read the text on language directionality within a media stream, a=
nd I do not see that we have an interoperability problem. It's possible tha=
t multiple streams with a language in the same direction are established, a=
nd it's possible that not all of them are actually used (e.g., if higher pr=
iority streams are established, perhaps the lower priority ones are not use=
d).  I don't see that as causing an interoperability problem.
See use cases 2.3, 2.4, 2.5 and 2.6 in the use-case document just published=
 by Natasha. Thanks!
Only 2.3 is solved by the current specification. The other needs cross-medi=
a preferences.
They could need media and language grouping as well, but I prefer that we t=
ry to solve that with a rule saying that languages in different media speci=
fied on the same preference level shall be seen as a group that is required=
 together, while languages in different media specified with different pref=
erence levels specify single languages provided for selection.


Note also that the primary function of these attributes are not to guide wh=
ich media streams shall be accepted and activated, it is usually good with =
media streams even if they are not used for language.
The function I see as the main purpose is to make sure that the caller gets=
 in contact with a person with the right language competence and if needed =
a suitable relay service is invoked in the call in order to cover any gaps =
in language coverage.
Of course a media stream must not be excluded that is needed for the select=
ed language combination.  But the opposite should not happen - that a media=
 stream is ignored because it is not needed for language communication.



I could add a statement that both 'lang' and 'humintlang-' attributes shoul=
d not be used in the same stream, due to potential confusion.
Yes, if we cannot agree on how to interpret 'lang', it would be a solution.
But the problem is also between media. 'lang' in one medium and 'humintlang=
' in another is also undefined if it represents an offered selection, or a =
required combination and if selection, what preference levels do they repre=
sent?
We must then also think about the conflict between 'lang' on session level =
and 'humintlang' on media level.


/Gunnar

At 7:19 AM +0100 3/21/16, Gunnar Hellstr=F6m wrote:

Randall,

I think it is unfair to RFC 4566 and RFC 3264 that we force an interpretati=
on of the use of the 'lang' attribute on them that we do not agree on.

If we do not come to an agreement, we could instead just refrain from docum=
enting an interpretation of how the 'lang' attribute works and  conclude wi=
th

"Unfortunately, there are cases, where the users need to use different
   modalities in different directions, and when it is important to combine
   languages in different modalities. The 'lang' attribute does not have
   the details needed to cover these cases."

We must also make sure that we do not make the same kind of unders-pecifica=
tion as apparently has been done in RFC 4566.
We need to describe what it means if we have language indications for the s=
ame direction in two (or more) media.
Shall it be understood as an indication that
    1) I am prepared to use both in the session or that
    2) I require both to be used or that
    3) I am not prepared to use both but offer them for selection.
If the normal interpretation is that it is for selection of one, how is the=
 preference for one or the other indicated?
And if the normal interpretation is for a selection, how do we then indicat=
e the case when we really strongly prefer to get both. ( e.g. voice plus ca=
ptions ).

We also need to describe how use of both 'lang' and 'humintlang-' attribute=
s in the same sdp shall be interpreted.

Regards

Gunnar


Den 2016-03-21 kl. 01:32, skrev Randall Gellens:
Hi Gunnar,

Thanks very much for your comments.  Please see in-line:

At 7:36 AM +0100 3/16/16, Gunnar Hellstr=F6m wrote:

 In addition to the changes proposed in draft-ietf-slim-negotiating-human-l=
anguage-00 for the preference regardless of media recently submitted, I hav=
e the following proposals for changes:

 1. Change the first paragraph of section 5 from:


---------------------------------------------------------------------------=
-----------------------
  RFC 4566 specifies an attribute 'lan=
g' which sounds similar to what
    is needed here, the difference being that it specifies that 'a=3Dlang'
    is declarative with the semantics of multiple 'lang' attributes being
    that all of them are used, while we want a means to negotiate which
    one is used in each stream.  This difference means that the existing
    'lang' attribute can't be used and we need to define a new attribute.

---------------------------------------------------------------------------=
----

 to


---------------------------------------------------------------------------=
------------
  RFC 4566 specifies an attribute 'lan=
g' which sounds similar to what
    is needed here. It specifies that 'a=3Dlang'
    is declarative with the semantics of multiple 'lang' attributes being
    possible, indicating a number of possible languages in the session in
    an order of preference. Each party declares their capabilities and the
    language(s) used in the session can then be selected from the common se=
t.
    We have however a need to specify direction of use of each language,
    and an order of preference between languages in different modalities.
    This difference means that the existing 'lang' attribute is not suffici=
ent
    for our use and we need to complement it with definition of a new attri=
bute.


---------------------------------------------------------------------------=
-----------------------

I disagree.  I've reread the text in the draft and in RFC 4566 multiple tim=
es.  However, I added clarifying wording to the draft.


 2. change the last two paragraphs of section 5 from:


---------------------------------------------------------------------------=
-----------------------------
  A recent search of RFCs and Internet Drafts turned up only one use of
    the 'lang' attribute (in a now-expired draft), and that sole use was
    coincidentally in exactly the way we need (erroniously assuming that
    the attribute was used for negotiation).  The sole use was in an
    example in a draft not directly related to language, where the
    initial invitation contains two 'a=3Dlang' entries for a media stream
    (for English and Italian) and the OK accepts one of them (Italian).

    The example serves as evidence of the need for an SDP attribute with
    the semantics as described in this document; unfortunately, the
    existing 'lang' attribute is not it.
----------------------------------------------------------------------
 to

---------------------------------------------------------------------------=
--
  A recent search of RFCs and Internet Drafts turned up only one use of
    the 'lang' attribute (in a now-expired draft), and that sole use was
    coincidentally in exactly the way we need.  The sole use was in an
    example in a draft not directly related to language, where the
    initial invitation contains two 'a=3Dlang' entries for a media stream
    (for English and Italian) and the OK accepts one of them (Italian).

    This use was questioned in a discussion of that draft because of this
    sentence in RFC 4566: "Multiple lang attributes can be
       provided either at session or media level if the session
       description or media use multiple languages."
    An interpretation was that all declared languages must be used in
    the session, while the example showed use of a selection of the
    originally indicated languages. The uncertainty caused withdrawal
    of the example because it was not essential for the draft.

   However, studying the wording in RFC 4566 further, it is evident
   that a negotiation of languages was intended for the real-time case.
   When sdp is used to declare contents of a recorded session, then it
   makes sense to list the provided languages, while for a real-time
   session, it is obvious that the capabilities of the parties and the
   development of the session influence the selection of language for
   the session.
   The continuation in RFC 4566 "the order of the attributes indicates
   the order of importance of the various languages" makes it very clear
   that the list shall be seen as a list for selection and negotiation.
   The "order of importance" has no meaning if all languages must be provid=
ed.

   The conclusion is that the 'lang' attribute can be used for negotiation
   of one or more common languages to select from for use in a real-time se=
ssion.
   A clarification is prepared for a possible future revision of RFC 4566.

   Thus, the 'lang' attribute satisfies our needs in many cases.

   Unfortunately, there are cases, where the users need to use different
   modalities in different directions, and when it is important to combine
   languages in different modalities. The 'lang' attribute does not have
   the details needed to cover these cases."


---------------------------------------------------------------------------=
----------------------

While I disagree with your interpretation, I don't think it's needed to go =
into this level of detail at this point in the draft, so I left it unchange=
d.


 3. Change section 6 from:
 -------------------------------------------------------
 6 Proposed Solution
    An SDP attribute seems the natural choice to negotiate human
    (natural) language of an interactive media stream.  The attribute
    value should be a language tag per RFC 5646 [RFC5646] "
------------------------------------------------------------------
 to
-----------------------------------------------------------------------
 6 Proposed Solution
    An SDP attribute seems the natural choice to negotiate human
    (natural) language of an interactive media stream.  The attribute
    value should be a language tag per RFC 5646 [RFC5646]
    The new attribute can appear together with the existing 'lang'
    attribute to compose the preferred language/modality combinations
    offered or negotiated.
----------------------------------------------------------------------

I don't think we have consensus on doing this, so I left it unchanged.


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



--
-----------------------------------------
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_C208B73D6FC243E4A2B81791B25D5397gsmacom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <9CCD7C041AFA1D4B80B36EDE3CF732CF@eurprd04.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable






Hi all,












It=92s about time (or, perhaps late by two weeks!) that we decide on our ag=
enda for next week=92s meeting. We have an hour between 16:20-17:20 on Thur=
sday and we will have both remote and present attendees.









In this meeting we will be discussing the below open issue and updates that=
 have been made / will be made to the existing documents. The meeting shoul=
d be less than an hour. A guidelines agenda is:









Welcome



Update on SLIM new and existing docs



draft-ietf-=
slim-multilangcontent-00 

draft-ietf-=
slim-negotiating-human-language-01 

draft-ietf-=
slim-use-cases-00 

Open Issue(s)









If you have something else to add please do let me know as soon as you can =
so I can add this to the agenda. I will publish this tomorrow.









Also, please let me know if you are attending in person or not if you haven=
=92t already!









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;
















On Mar 21, 2016, at 8:47 PM, Gunnar Hellstr=F6m <gunnar.hellstrom@omnitor=
.se> wrote:






Hi Randall,

Den 2016-03-21 kl. 17:53, skrev Randall Gellens:


Hi Gunnar,



I do not believe we are forcing an interpretation on RFC 4566, rather, the =
drafts says, in an explanatory aside in parentheses, how the authors interp=
ret it.  This is quite far from a normative statement.



It will be documented anyway, and just as you looked at the discussion arou=
nd the STOX - example and got influenced by it, there is a risk that we spr=
ead more uncertainty in the topic or lead others to make unlogical conclusi=
ons.

Let it be sufficient to say that 'lang' does not have the detailing we need=
.






I have re-read the text on language directionality within a media stream, a=
nd I do not see that we have an interoperability problem. It's possible tha=
t multiple streams with a language in the same direction are established, a=
nd it's possible that not all of
 them are actually used (e.g., if higher priority streams are established, =
perhaps the lower priority ones are not used).  I don't see that as ca=
using an interoperability problem.



See use cases 2.3, 2.4, 2.5 and 2.6 in the use-case document just published=
 by Natasha. Thanks!

Only 2.3 is solved by the current specification. The other needs cross-medi=
a preferences.

They could need media and language grouping as well, but I prefer that we t=
ry to solve that with a rule saying that languages in different media speci=
fied on the same preference level shall be seen as a group that is required=
 together, while languages in different
 media specified with different preference levels specify single languages =
provided for selection.





Note also that the primary function of these attributes are not to guide wh=
ich media streams shall be accepted and activated, it is usually good with =
media streams even if they are not used for language.

The function I see as the main purpose is to make sure that the caller gets=
 in contact with a person with the right language competence and if needed =
a suitable relay service is invoked in the call in order to cover any gaps =
in language coverage.

Of course a media stream must not be excluded that is needed for the select=
ed language combination.  But the opposite should not happen - that a =
media stream is ignored because it is not needed for language communication=
.








I could add a statement that both 'lang' and 'humintlang-' attributes shoul=
d not be used in the same stream, due to potential confusion.



Yes, if we cannot agree on how to interpret 'lang', it would be a solution.=


But the problem is also between media. 'lang' in one medium and 'humintlang=
' in another is also undefined if it represents an offered selection, or a =
required combination and if selection, what preference levels do they repre=
sent?

We must then also think about the conflict between 'lang' on session level =
and 'humintlang' on media level.





/Gunnar




At 7:19 AM +0100 3/21/16, Gunnar Hellstr=F6m wrote:




Randall,



I think it is unfair to RFC 4566 and RFC 3264 that we force an interpretati=
on of the use of the 'lang' attribute on them that we do not agree on.



If we do not come to an agreement, we could instead just refrain from docum=
enting an interpretation of how the 'lang' attribute works and  conclu=
de with



"Unfortunately, there are cases, where the users need to use different=


   modalities in different directions, and when it is import=
ant to combine

   languages in different modalities. The 'lang' attribute d=
oes not have

   the details needed to cover these cases."



We must also make sure that we do not make the same kind of unders-pecifica=
tion as apparently has been done in RFC 4566.

We need to describe what it means if we have language indications for the s=
ame direction in two (or more) media.

Shall it be understood as an indication that

    1) I am prepared to use both in the session or that=


    2) I require both to be used or that

    3) I am not prepared to use both but offer them for=
 selection.

If the normal interpretation is that it is for selection of one, how is the=
 preference for one or the other indicated?

And if the normal interpretation is for a selection, how do we then indicat=
e the case when we really strongly prefer to get both. ( e.g. voice plus ca=
ptions ).



We also need to describe how use of both 'lang' and 'humintlang-' attribute=
s in the same sdp shall be interpreted.



Regards



Gunnar





Den 2016-03-21 kl. 01:32, skrev Randall Gellens:


Hi Gunnar,



Thanks very much for your comments.  Please see in-line:



At 7:36 AM +0100 3/16/16, Gunnar Hellstr=F6m wrote:




 In addition to the changes propo=
sed in draft-ietf-slim-negotiating-human-language-00 for the preference reg=
ardless of media recently submitted, I have the following proposals for cha=
nges:



 1. Change the first paragraph of section 5 from:





---------------------------------------------------------------------------=
-----------------------


  <=
https://tools.ietf.org/html/rfc4566>RFC 4566 specifies an attribute =
'lang' which sounds similar to what

    is needed here, the difference being that it specif=
ies that 'a=3Dlang'

    is declarative with the semantics of multiple 'lang=
' attributes being

    that all of them are used, while we want a means to=
 negotiate which

    one is used in each stream.  This difference m=
eans that the existing

    'lang' attribute can't be used and we need to defin=
e a new attribute.



---------------------------------------------------------------------------=
---- 



 to





---------------------------------------------------------------------------=
------------


  <=
https://tools.ietf.org/html/rfc4566>RFC 4566 specifies an attribute =
'lang' which sounds similar to what

    is needed here. It specifies that 'a=3Dlang'

    is declarative with the semantics of multiple 'lang=
' attributes being

    possible, indicating a number of possible languages=
 in the session in

    an order of preference. Each party declares their c=
apabilities and the

    language(s) used in the session can then be selecte=
d from the common set.

    We have however a need to specify direction of use =
of each language,

    and an order of preference between languages in dif=
ferent modalities.

    This difference means that the existing 'lang' attr=
ibute is not sufficient

    for our use and we need to complement it with defin=
ition of a new attribute.





---------------------------------------------------------------------------=
-----------------------






I disagree.  I've reread the text in the draft and in RFC 4566 multipl=
e times.  However, I added clarifying wording to the draft.






 2. change the last two paragraphs of section 5 from:





---------------------------------------------------------------------------=
-----------------------------


  A recent search of RFCs and Internet Drafts turned up only one =
use of

    the 'lang' attribute (in a now-expired draft), and =
that sole use was

    coincidentally in exactly the way we need (erroniou=
sly assuming that

    the attribute was used for negotiation).  The =
sole use was in an

    example in a draft not directly related to language=
, where the

    initial invitation contains two 'a=3Dlang' entries =
for a media stream

    (for English and Italian) and the OK accepts one of=
 them (Italian).



    The example serves as evidence of the need for an S=
DP attribute with

    the semantics as described in this document; unfort=
unately, the

    existing 'lang' attribute is not it.

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

 to



---------------------------------------------------------------------------=
-- 

  A recent search of RFCs and Internet Drafts turned up only one =
use of

    the 'lang' attribute (in a now-expired draft), and =
that sole use was

    coincidentally in exactly the way we need.  Th=
e sole use was in an

    example in a draft not directly related to language=
, where the

    initial invitation contains two 'a=3Dlang' entries =
for a media stream

    (for English and Italian) and the OK accepts one of=
 them (Italian).



    This use was questioned in a discussion of that dra=
ft because of this

    sentence in RFC 4566: "Multiple lang attribute=
s can be

       provided either at session or med=
ia level if the session

       description or media use multiple=
 languages."

    An interpretation was that all declared languages m=
ust be used in

    the session, while the example showed use of a sele=
ction of the

    originally indicated languages. The uncertainty cau=
sed withdrawal

    of the example because it was not essential for the=
 draft.



   However, studying the wording in RFC 4566 further, it is =
evident

   that a negotiation of languages was intended for the real=
-time case.

   When sdp is used to declare contents of a recorded sessio=
n, then it

   makes sense to list the provided languages, while for a r=
eal-time

   session, it is obvious that the capabilities of the parti=
es and the

   development of the session influence the selection of lan=
guage for

   the session.

   The continuation in RFC 4566 "the order of the attri=
butes indicates

   the order of importance of the various languages" ma=
kes it very clear

   that the list shall be seen as a list for selection and n=
egotiation.

   The "order of importance" has no meaning if all=
 languages must be provided.



   The conclusion is that the 'lang' attribute can be used f=
or negotiation

   of one or more common languages to select from for use in=
 a real-time session.

   A clarification is prepared for a possible future revisio=
n of RFC 4566.



   Thus, the 'lang' attribute satisfies our needs in many ca=
ses.



   Unfortunately, there are cases, where the users need to u=
se different

   modalities in different directions, and when it is import=
ant to combine

   languages in different modalities. The 'lang' attribute d=
oes not have

   the details needed to cover these cases."





---------------------------------------------------------------------------=
----------------------






While I disagree with your interpretation, I don't think it's needed to go =
into this level of detail at this point in the draft, so I left it unchange=
d.






 3. Change section 6 from:

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

 6 Proposed Solution

    An SDP attribute seems the natural choice to negoti=
ate human

    (natural) language of an interactive media stream. =
 The attribute

    value should be a language tag per <https://tools.ietf.org/html/=
rfc5646>RFC 5646 [<https://tools.ietf.org/html/rfc5646>RFC5646] "

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

 to

----------------------------------------------------------------------- 
 6 Proposed Solution

    An SDP attribute seems the natural choice to negoti=
ate human

    (natural) language of an interactive media stream. =
 The attribute

    value should be a language tag per <https://tools.ietf.org/html/=
rfc5646>RFC 5646 [<https://tools.ietf.org/html/rfc5646>RFC5646]

    The new attribute can appear together with the exis=
ting 'lang'

    attribute to compose the preferred language/modalit=
y combinations

    offered or negotiated.

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





I don't think we have consensus on doing this, so I left it unchanged.







--

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

Gunnar Hellstr=F6m

Omnitor

gunnar.hellstrom@=
omnitor.se

+46 708 204 288



_______________________________________________

SLIM mailing list

SLIM@ietf.org

https://w=
ww.ietf.org/mailman/listinfo/slim











-- 

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

Gunnar Hellstr=F6m

Omnitor

gunnar.hellstrom@=
omnitor.se

+46 708 204 288



_______________________________________________

SLIM mailing list

SLIM@ietf.org

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












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