From nobody Fri May 13 10:45: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 E457712D62C for ; Fri, 13 May 2016 10:45:24 -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 f8v7gsctp2r1 for ; Fri, 13 May 2016 10:45:22 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0636.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::636]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C721912D517 for ; Fri, 13 May 2016 10:45:20 -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=SVAvzbukjOfuFGA1spJn5qH4bh1zwraXA0RvVig8AyY=; b=Jy4rJ0BKmxgfqfWkJSqyQhtpbt+Oi5oX3wuSCv70bmjezw32ayJPdwV0fP6HUFSoe+UoruAOwYB2sVXWUAzeF4AVY4j+s7tzWzIdxLQxfOHGx9K8ipOSBO+VITqckITplCsh9/1yBkDUoJfxjWyXVMQCFWX2bj/huyhOSs4IMUk= Received: from VI1PR0401MB2064.eurprd04.prod.outlook.com (10.166.141.138) by VI1PR0401MB2062.eurprd04.prod.outlook.com (10.166.141.136) with Microsoft SMTP Server (TLS) id 15.1.497.12; Fri, 13 May 2016 17:45:00 +0000 Received: from VI1PR0401MB2064.eurprd04.prod.outlook.com ([10.166.141.138]) by VI1PR0401MB2064.eurprd04.prod.outlook.com ([10.166.141.138]) with mapi id 15.01.0492.019; Fri, 13 May 2016 17:44:59 +0000 From: Natasha Rooney To: "slim@ietf.org" Thread-Topic: Seeking rough consensus for draft-ietf-slim-negotiating-human-language Thread-Index: AQHRrT8raBk1U+yGL0aAn5CHO36syg== Date: Fri, 13 May 2016 17:44:59 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.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.85.58] x-ms-office365-filtering-correlation-id: 4e6a6b73-994a-4308-6be1-08d37b564e25 x-microsoft-exchange-diagnostics: 1; VI1PR0401MB2062; 5:02pU3YzyVsNZQZxHnx05290MLF31y/DWLV3gSEKlA2xO3jVcsjqZEZha/e3Oj+i6HC3ntGaK4PIo5WrTn/RYvLiMVJQTeY2/gmD1ARfwzONjJ6cMdAsU7FMoItRiFUYfDXgh5xu6FJcGBz/nGoM4og==; 24:+YrFOmFHz2YqWRzKMOoQSF+eXOu368NLeocs6FcktCAZwcDQgDBLVkoPGVX2UpFwHwwE1Lw6pn55t3UbJZVJAGR6zrVaHHpSZD/H+QRmEZ8=; 7:y8PhsZWR3wlR3IsbMmVPs76yWQc0p38/rJWoOlZTN4za77Q00JZG3oWCxg8hHa6UjXVKVOU82yg+Z9b22tpjwwJB8+SNvFVZoHmI2/0jZ2tl58XwgT+cnNy2/yk+fQfqfNKRPggiMkZI9WcU2+XDOQX8W3q2M1YFe3nqxZMnzWFEsGYiQo8Ic4THARO3Td4J x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR0401MB2062; 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:VI1PR0401MB2062; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0401MB2062; x-forefront-prvs: 0941B96580 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(53754006)(83716003)(50226002)(82746002)(5004730100002)(86362001)(106116001)(8936002)(19580405001)(19580395003)(5008740100001)(77096005)(110136002)(107886002)(5002640100001)(1220700001)(6116002)(3846002)(189998001)(33656002)(230783001)(87936001)(102836003)(50986999)(16236675004)(586003)(2906002)(5640700001)(2900100001)(2351001)(1730700003)(57306001)(122556002)(5890100001)(81166006)(8676002)(3280700002)(92566002)(450100001)(229853001)(66066001)(3660700001)(36756003)(2501003)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0401MB2062; H:VI1PR0401MB2064.eurprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_B00873AF93BC4256ABA3D9E3EB7E5325gsmacom_" MIME-Version: 1.0 X-OriginatorOrg: gsma.com X-MS-Exchange-CrossTenant-originalarrivaltime: 13 May 2016 17:44:59.7069 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72a4ff82-fec3-469d-aafb-ac8276216699 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0401MB2062 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: VI1PR0401MB2064.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.85.58 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: VI1PR0401MB2062.eurprd04.prod.outlook.com Archived-At: Subject: [Slim] Seeking rough consensus for draft-ietf-slim-negotiating-human-language 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, 13 May 2016 17:45:25 -0000 --_000_B00873AF93BC4256ABA3D9E3EB7E5325gsmacom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all! I hope everyone is well and enjoying some short vacations throughout May. I= n this email we would like to discuss a route towards getting rough consens= us for draft-ietf-slim-negotiating-human-language. In Buenos Aires, we discussed the completeness of draft-ietf-slim-negotiati= ng-human-language. In particular, we discussed advancing the draft as it i= s versus adding mechanisms for grouping and absolute priority. Most partic= ipants (with one objection) at the meeting believed the draft to be suffici= ent for deployment now, that it is better to start with a simple mechanism = that will be easier to implement and see earlier use, and that additional c= omplexity can be added later (in an extension or -bis document) if we find = we need grouping, absolute priority, or other advanced features. Therefore, the chairs would like to ask SLIM members on the list to respond= to this suggestion: please let us know if you are happy with this to proce= ed or not and if not, why. 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 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_B00873AF93BC4256ABA3D9E3EB7E5325gsmacom_ Content-Type: text/html; charset="us-ascii" Content-ID: <0C60EF0B4708CE4C982217F83F92D0E3@eurprd04.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Hi all!

I hope everyone is well and enjoying some short vacations t= hroughout May. In this email we would like to discuss a route towards getti= ng rough consensus for draft-ietf-slim-negotiating-human-language. 

In Buenos Aires, we discussed the completeness of draft-ietf-slim-negotiati= ng-human-language.  In particular, we discussed advancing the draft as= it is versus adding mechanisms for grouping and absolute priority.  M= ost participants (with one objection) at the meeting believed the draft to be sufficient for deployment now, that it is= better to start with a simple mechanism that will be easier to implement a= nd see earlier use, and that additional complexity can be added later (in a= n extension or -bis document) if we find we need grouping, absolute priority, or other advanced features. &= nbsp;

Therefore, the chairs would like to ask SLIM members on the= list to respond to this suggestion: please let us know if you are happy wi= th this to proceed or not and if not, why.

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


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_B00873AF93BC4256ABA3D9E3EB7E5325gsmacom_-- From nobody Fri May 13 11:27:55 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 198CB12D688 for ; Fri, 13 May 2016 11:27:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 2SSh1LP0fllE for ; Fri, 13 May 2016 11:27:52 -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 79C2E12D681 for ; Fri, 13 May 2016 11:27:51 -0700 (PDT) X-Halon-ID: 5e9aac91-1938-11e6-8615-005056917f90 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.2] (unknown [87.96.161.49]) by bin-vsp-out-02.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Fri, 13 May 2016 20:27:37 +0200 (CEST) To: slim@ietf.org References: From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <64a760fc-1100-5755-bc9d-ca0e26f0e102@omnitor.se> Date: Fri, 13 May 2016 20:27:41 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------E3A9456C1D96A2305AE8F5FB" Archived-At: Subject: Re: [Slim] Seeking rough consensus for draft-ietf-slim-negotiating-human-language 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, 13 May 2016 18:27:55 -0000 This is a multi-part message in MIME format. --------------E3A9456C1D96A2305AE8F5FB Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit We also discussed another issue that we need to decide on before moving on. I think the conclusion on how the current lang attribute in sdp can be used, that is currently documented in the draft, is not what was intended with the attribute. We collected history about the attribute with the intention to sort out the issue. I suggest that that action is followed up with a discussion in mmusic before we move on. The work with 4566bis has accepted an improved description of the attribute, but it would be good to have a common view already about the use according to RFC 4566. Regards Gunnar Den 2016-05-13 kl. 19:44, skrev Natasha Rooney: > Hi all! > > I hope everyone is well and enjoying some short vacations throughout > May. In this email we would like to discuss a route towards getting > rough consensus for draft-ietf-slim-negotiating-human-language. > > In Buenos Aires, we discussed the completeness of > draft-ietf-slim-negotiating-human-language. In particular, we > discussed advancing the draft as it is versus adding mechanisms for > grouping and absolute priority. Most participants (with one > objection) at the meeting believed the draft to be sufficient for > deployment now, that it is better to start with a simple mechanism > that will be easier to implement and see earlier use, and that > additional complexity can be added later (in an extension or -bis > document) if we find we need grouping, absolute priority, or other > advanced features. > > Therefore, the chairs would like to ask SLIM members on the list to > respond to this suggestion: please let us know if you are happy with > this to proceed or not and if not, why. > > 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 > > > 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 --------------E3A9456C1D96A2305AE8F5FB Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

We also discussed another issue that we need to decide on before moving on.

I think the conclusion on how the current lang attribute in sdp can be used, that is currently documented in the draft, is not what was intended with the attribute.

We collected history about the attribute with the intention to sort out the issue.

I suggest that that action is followed up with a discussion in mmusic before we move on.

The work with 4566bis has accepted an improved description of the attribute, but it would be good to have a common view already about the use according to RFC 4566.

Regards

Gunnar

Den 2016-05-13 kl. 19:44, skrev Natasha Rooney:
Hi all!

I hope everyone is well and enjoying some short vacations throughout May. In this email we would like to discuss a route towards getting rough consensus for draft-ietf-slim-negotiating-human-language. 

In Buenos Aires, we discussed the completeness of draft-ietf-slim-negotiating-human-language.  In particular, we discussed advancing the draft as it is versus adding mechanisms for grouping and absolute priority.  Most participants (with one objection) at the meeting believed the draft to be sufficient for deployment now, that it is better to start with a simple mechanism that will be easier to implement and see earlier use, and that additional complexity can be added later (in an extension or -bis document) if we find we need grouping, absolute priority, or other advanced features.  

Therefore, the chairs would like to ask SLIM members on the list to respond to this suggestion: please let us know if you are happy with this to proceed or not and if not, why.

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


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
--------------E3A9456C1D96A2305AE8F5FB-- From nobody Fri May 13 13:11:37 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 83E3A12B065 for ; Fri, 13 May 2016 13:11: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 pe-0D0deGowE for ; Fri, 13 May 2016 13:11:31 -0700 (PDT) Received: from bin-vsp-out-05.atm.binero.net (vsp-unauthed02.binero.net [195.74.38.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFF4E12B039 for ; Fri, 13 May 2016 13:11:30 -0700 (PDT) X-Halon-ID: e10954d7-1946-11e6-9ca0-005056913f0f Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.2] (unknown [87.96.161.49]) by bin-vsp-out-05.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Fri, 13 May 2016 22:11:29 +0200 (CEST) To: slim@ietf.org References: From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <179bc991-af2d-a726-d8ba-71a8c2f5322d@omnitor.se> Date: Fri, 13 May 2016 22:11:19 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------3D0C03E7ADBE734AB38FB722" Archived-At: Subject: Re: [Slim] Seeking rough consensus for draft-ietf-slim-negotiating-human-language 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, 13 May 2016 20:11:35 -0000 This is a multi-part message in MIME format. --------------3D0C03E7ADBE734AB38FB722 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Thanks Natasha for pushing us to action, I am not happy to move on before we have a solution to the use cases. I do not understand why we mention that the languages are listed in preference order within a media description, but do not mention what relation there is in preference between languages in different media descriptions. The need for preference ordering can appear between media as well as within a medium. And we need to have a way to indicate the difference between requiring to use two or more lanuage/modalities together versus providing them as selectable options. If we do not sort this out, we cause the same confusion as we have around the current lang attribute. We were discussing solutions to part of this on April 10 in the list, but had no final conclusion on suitable wording that would cause less confusion than current RFC 4566. That discussion needs to be concluded. Can we start with getting to see the current wording of the sections under discussion on April 10? Thanks, Gunnar Den 2016-05-13 kl. 19:44, skrev Natasha Rooney: > Hi all! > > I hope everyone is well and enjoying some short vacations throughout > May. In this email we would like to discuss a route towards getting > rough consensus for draft-ietf-slim-negotiating-human-language. > > In Buenos Aires, we discussed the completeness of > draft-ietf-slim-negotiating-human-language. In particular, we > discussed advancing the draft as it is versus adding mechanisms for > grouping and absolute priority. Most participants (with one > objection) at the meeting believed the draft to be sufficient for > deployment now, that it is better to start with a simple mechanism > that will be easier to implement and see earlier use, and that > additional complexity can be added later (in an extension or -bis > document) if we find we need grouping, absolute priority, or other > advanced features. > > Therefore, the chairs would like to ask SLIM members on the list to > respond to this suggestion: please let us know if you are happy with > this to proceed or not and if not, why. > > 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 > > > 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 --------------3D0C03E7ADBE734AB38FB722 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Thanks Natasha for pushing us to action,

I am not happy to move on before we have a solution to the use cases.

I do not understand why we mention that the languages are listed in preference order within a media description, but do not mention what relation there is in preference between languages in different media descriptions. The need for preference ordering can appear between media as well as within a medium.

And we need to have a way to indicate the difference between requiring to use two or more lanuage/modalities together versus providing them as selectable options. If we do not sort this out, we cause the same confusion as we have around the current lang attribute.  We were discussing solutions to part of this on April 10 in the list, but had no final conclusion on suitable wording that would cause less confusion than current RFC 4566. That discussion needs to be concluded.

Can we start with getting to see the current wording of the sections under discussion on April 10?

Thanks,

Gunnar





Den 2016-05-13 kl. 19:44, skrev Natasha Rooney:
Hi all!

I hope everyone is well and enjoying some short vacations throughout May. In this email we would like to discuss a route towards getting rough consensus for draft-ietf-slim-negotiating-human-language. 

In Buenos Aires, we discussed the completeness of draft-ietf-slim-negotiating-human-language.  In particular, we discussed advancing the draft as it is versus adding mechanisms for grouping and absolute priority.  Most participants (with one objection) at the meeting believed the draft to be sufficient for deployment now, that it is better to start with a simple mechanism that will be easier to implement and see earlier use, and that additional complexity can be added later (in an extension or -bis document) if we find we need grouping, absolute priority, or other advanced features.  

Therefore, the chairs would like to ask SLIM members on the list to respond to this suggestion: please let us know if you are happy with this to proceed or not and if not, why.

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


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
--------------3D0C03E7ADBE734AB38FB722-- From nobody Sat May 14 16:06:28 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 C82D912B034 for ; Sat, 14 May 2016 16:06:26 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 HFNTnmk0iiVg for ; Sat, 14 May 2016 16:06:25 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 33CB112B01F for ; Sat, 14 May 2016 16:06:25 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Sat, 14 May 2016 16:06:24 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Mailer: Eudora for Mac OS X Date: Sat, 14 May 2016 16:06:21 -0700 To: Natasha Rooney , "slim@ietf.org" From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 Archived-At: Subject: Re: [Slim] Seeking rough consensus for draft-ietf-slim-negotiating-human-language 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, 14 May 2016 23:06:27 -0000 I believe the draft can proceed as is. At 5:44 PM +0000 5/13/16, Natasha Rooney wrote: > Hi all! > > I hope everyone is well and enjoying some short vacations > throughout May. In this email we would like to discuss a route > towards getting rough consensus for > draft-ietf-slim-negotiating-human-language. > > In Buenos Aires, we discussed the completeness of > draft-ietf-slim-negotiating-human-language. In particular, we > discussed advancing the draft as it is versus adding mechanisms for > grouping and absolute priority. Most participants (with one > objection) at the meeting believed the draft to be sufficient for > deployment now, that it is better to start with a simple mechanism > that will be easier to implement and see earlier use, and that > additional complexity can be added later (in an extension or -bis > document) if we find we need grouping, absolute priority, or other > advanced features. > > Therefore, the chairs would like to ask SLIM members on the list to > respond to this suggestion: please let us know if you are happy > with this to proceed or not and if not, why. > > > 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 > > > 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 -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Algorhyme I think that I shall never see a graph more lovely than a tree. A tree whose crucial property is loop-free connectivity. A tree that must be sure to span so packet can reach every LAN. First, the root must be selected. By ID, it is elected. Least-cost paths from root are traced. In the tree, these paths are placed. A mesh is made by folks like me, then bridges find a spanning tree. --Radia Perlman From nobody Sat May 14 16:08:01 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 EEF5912B034 for ; Sat, 14 May 2016 16:07:59 -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: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 NZAl3luCvPK5 for ; Sat, 14 May 2016 16:07:58 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 7A02F12B01F for ; Sat, 14 May 2016 16:07:58 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Sat, 14 May 2016 16:07:58 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <64a760fc-1100-5755-bc9d-ca0e26f0e102@omnitor.se> References: <64a760fc-1100-5755-bc9d-ca0e26f0e102@omnitor.se> X-Mailer: Eudora for Mac OS X Date: Sat, 14 May 2016 16:07:54 -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] Seeking rough consensus for draft-ietf-slim-negotiating-human-language 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, 14 May 2016 23:08:00 -0000 I believe that, at this point, this is a=20 distraction and not important. We are defining=20 new SDP attributes. At 8:27 PM +0200 5/13/16, Gunnar Hellstr=F6m wrote: > We also discussed another issue that we need to decide on before moving o= n. > > I think the conclusion on how the current lang=20 > attribute in sdp can be used, that is currently=20 > documented in the draft, is not what was=20 > intended with the attribute. > > We collected history about the attribute with=20 > the intention to sort out the issue. > > I suggest that that action is followed up with=20 > a discussion in mmusic before we move on. > > The work with 4566bis has accepted an improved=20 > description of the attribute, but it would be=20 > good to have a common view already about the=20 > use according to RFC 4566. > > Regards > > Gunnar > > Den 2016-05-13 kl. 19:44, skrev Natasha Rooney: > >> Hi all! >> >> I hope everyone is well and enjoying some=20 >> short vacations throughout May. In this email=20 >> we would like to discuss a route towards=20 >> getting rough consensus for=20 >> draft-ietf-slim-negotiating-human-language. >> >> In Buenos Aires, we discussed the completeness=20 >> of draft-ietf-slim-negotiating-human-language.=20 >> In particular, we discussed advancing the=20 >> draft as it is versus adding mechanisms for=20 >> grouping and absolute priority. Most=20 >> participants (with one objection) at the=20 >> meeting believed the draft to be sufficient=20 >> for deployment now, that it is better to start=20 >> with a simple mechanism that will be easier to=20 >> implement and see earlier use, and that=20 >> additional complexity can be added later (in=20 >> an extension or -bis document) if we find we=20 >> need grouping, absolute priority, or other=20 >> advanced features. >> >> Therefore, the chairs would like to ask SLIM=20 >> members on the list to respond to this=20 >> suggestion: please let us know if you are=20 >> happy with this to proceed or not and if not,=20 >> why. >> >> >> 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 >> >> >> This email and its attachments are intended=20 >> for the above named only and may be=20 >> confidential. If they have come to you in=20 >> error you must take no action based on them,=20 >> nor must you copy or show them to anyone;=20 >> please reply to this email or call +44 207 356=20 >> 0600 and highlight the error. >> >> >> >> _______________________________________________ >> SLIM mailing list >> SLIM@ietf.org >>=20 >> https://www.ietf.org/mailman/= listinfo/slim >> > > -- > ----------------------------------------- > Gunnar Hellstr=F6m > Omnitor > gunnar.hellstrom@omnitor.se > +46 708 204 288 > > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- The way to make a small fortune in the commodities market is to start with a large fortune. From nobody Sat May 14 16:10: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 2C44112B034 for ; Sat, 14 May 2016 16:10: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: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 LdU_6aYx-4JI for ; Sat, 14 May 2016 16:10:54 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id C403812B01F for ; Sat, 14 May 2016 16:10:53 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Sat, 14 May 2016 16:10:53 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <179bc991-af2d-a726-d8ba-71a8c2f5322d@omnitor.se> References: <179bc991-af2d-a726-d8ba-71a8c2f5322d@omnitor.se> X-Mailer: Eudora for Mac OS X Date: Sat, 14 May 2016 16:10: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] Seeking rough consensus for draft-ietf-slim-negotiating-human-language 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, 14 May 2016 23:10:55 -0000 I think the draft is sufficient for us to move=20 forward. If we later find we need to describe=20 "preference between languages in different media=20 descriptions" or "requiring to use two or more=20 language/modalities together" then we can define=20 mechanisms to do so, either as an extension or in=20 a -bis document. t 10:11 PM +0200 5/13/16, Gunnar Hellstr=F6m wrote: > Thanks Natasha for pushing us to action, > > I am not happy to move on before we have a solution to the use cases. > > I do not understand why we mention that the=20 > languages are listed in preference order within=20 > a media description, but do not mention what=20 > relation there is in preference between=20 > languages in different media descriptions. The=20 > need for preference ordering can appear between=20 > media as well as within a medium. > > And we need to have a way to indicate the=20 > difference between requiring to use two or more=20 > lanuage/modalities together versus providing=20 > them as selectable options. If we do not sort=20 > this out, we cause the same confusion as we=20 > have around the current lang attribute. We were=20 > discussing solutions to part of this on April=20 > 10 in the list, but had no final conclusion on=20 > suitable wording that would cause less=20 > confusion than current RFC 4566. That=20 > discussion needs to be concluded. > > Can we start with getting to see the current=20 > wording of the sections under discussion on=20 > April 10? > > Thanks, > > Gunnar > > > > > Den 2016-05-13 kl. 19:44, skrev Natasha Rooney: > >> Hi all! >> >> I hope everyone is well and enjoying some=20 >> short vacations throughout May. In this email=20 >> we would like to discuss a route towards=20 >> getting rough consensus for=20 >> draft-ietf-slim-negotiating-human-language. >> >> In Buenos Aires, we discussed the completeness=20 >> of draft-ietf-slim-negotiating-human-language.=20 >> In particular, we discussed advancing the=20 >> draft as it is versus adding mechanisms for=20 >> grouping and absolute priority. Most=20 >> participants (with one objection) at the=20 >> meeting believed the draft to be sufficient=20 >> for deployment now, that it is better to start=20 >> with a simple mechanism that will be easier to=20 >> implement and see earlier use, and that=20 >> additional complexity can be added later (in=20 >> an extension or -bis document) if we find we=20 >> need grouping, absolute priority, or other=20 >> advanced features. >> >> Therefore, the chairs would like to ask SLIM=20 >> members on the list to respond to this=20 >> suggestion: please let us know if you are=20 >> happy with this to proceed or not and if not,=20 >> why. >> >> >> 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 >> >> >> This email and its attachments are intended=20 >> for the above named only and may be=20 >> confidential. If they have come to you in=20 >> error you must take no action based on them,=20 >> nor must you copy or show them to anyone;=20 >> please reply to this email or call +44 207 356=20 >> 0600 and highlight the error. >> >> >> >> _______________________________________________ >> SLIM mailing list >> SLIM@ietf.org >>=20 >> https://www.ietf.org/mailman/= listinfo/slim >> > > -- > ----------------------------------------- > Gunnar Hellstr=F6m > Omnitor > gunnar.hellstrom@omnitor.se > +46 708 204 288 > > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Trying to be happy is like trying to build a machine for which the only specification is that it should run noiselessly. From nobody Sun May 15 11: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 788CE12D1BB for ; Sun, 15 May 2016 11:40:23 -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 3by_svJr2lhx for ; Sun, 15 May 2016 11:40:22 -0700 (PDT) Received: from resqmta-ch2-06v.sys.comcast.net (resqmta-ch2-06v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F002612D1B4 for ; Sun, 15 May 2016 11:40:20 -0700 (PDT) Received: from resomta-ch2-18v.sys.comcast.net ([69.252.207.114]) by comcast with SMTP id 20wYbtkZk2R4w20xfbkFqY; Sun, 15 May 2016 18:40:19 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1463337619; bh=HD/Iu3FPt8v5UCep6OAIF8EuKNh1MOzY1KA0ZAcC6S8=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=YsduqtyFC0AP6F17RNCCNGA1ffcOaoqUSmkDrMmFR/V75v+PpS4dOyHnGx1W6aW2O stWonlzlSI4/844V07zmj2z2hYa+vBMleuumFg8iH8cmI6ogM1964XMSf0rmEBL2ks RdVlQ0cHEGgEYLQMKCRAanC8g++uryQJAof5hup6OoKav2FMLxEK2I/K0S2uW4yNRf zt7zQroZwRdOs6G6Lm6itYhxXVpv8UMJvB4QSJGOC7J/xT+aqL66XubNpVGmugIchZ xH9zMl2/KuTv/3xr5x+nfVmL9m3uTAhWJ6Zf/Sdnv++rnxfWDRxKeHU/XpxDx30Rz5 ly7rYN/+CnPvQ== Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-18v.sys.comcast.net with comcast id uigK1s0043KdFy101igKD0; Sun, 15 May 2016 18:40:19 +0000 To: slim@ietf.org References: <179bc991-af2d-a726-d8ba-71a8c2f5322d@omnitor.se> From: Paul Kyzivat Message-ID: Date: Sun, 15 May 2016 14:40:17 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.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] Seeking rough consensus for draft-ietf-slim-negotiating-human-language 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, 15 May 2016 18:40:23 -0000 On 5/14/16 7:10 PM, Randall Gellens wrote: > I think the draft is sufficient for us to move forward. If we later > find we need to describe "preference between languages in different > media descriptions" or "requiring to use two or more language/modalities > together" then we can define mechanisms to do so, either as an extension > or in a -bis document. I am ok with this approach *if* we agree that there is no implicit assumption about preference. Absent anything else, I think we must assume that the offerer wants *all* m-lines in the offer to be accepted, and intends to use them all. My fear is that implementers will make some assumption, but they won't all make the same assumption. Then there are surprises when something unexpected happens. Alternately, we could make a particular assumption and state it clearly. Thanks, Paul > t 10:11 PM +0200 5/13/16, Gunnar Hellström wrote: > >> Thanks Natasha for pushing us to action, >> >> I am not happy to move on before we have a solution to the use cases. >> >> I do not understand why we mention that the languages are listed in >> preference order within a media description, but do not mention what >> relation there is in preference between languages in different media >> descriptions. The need for preference ordering can appear between >> media as well as within a medium. >> >> And we need to have a way to indicate the difference between >> requiring to use two or more lanuage/modalities together versus >> providing them as selectable options. If we do not sort this out, we >> cause the same confusion as we have around the current lang attribute. >> We were discussing solutions to part of this on April 10 in the list, >> but had no final conclusion on suitable wording that would cause less >> confusion than current RFC 4566. That discussion needs to be concluded. >> >> Can we start with getting to see the current wording of the sections >> under discussion on April 10? >> >> Thanks, >> >> Gunnar >> >> >> >> >> Den 2016-05-13 kl. 19:44, skrev Natasha Rooney: >> >>> Hi all! >>> >>> I hope everyone is well and enjoying some short vacations throughout >>> May. In this email we would like to discuss a route towards getting >>> rough consensus for draft-ietf-slim-negotiating-human-language. >>> >>> In Buenos Aires, we discussed the completeness of >>> draft-ietf-slim-negotiating-human-language. In particular, we >>> discussed advancing the draft as it is versus adding mechanisms for >>> grouping and absolute priority. Most participants (with one >>> objection) at the meeting believed the draft to be sufficient for >>> deployment now, that it is better to start with a simple mechanism >>> that will be easier to implement and see earlier use, and that >>> additional complexity can be added later (in an extension or -bis >>> document) if we find we need grouping, absolute priority, or other >>> advanced features. >>> >>> Therefore, the chairs would like to ask SLIM members on the list to >>> respond to this suggestion: please let us know if you are happy with >>> this to proceed or not and if not, why. >>> >>> >>> 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 >>> >>> >>> This email and its attachments are intended for the above named only >>> and may be confidential. If they have come to you in error you must >>> take no action based on them, nor must you copy or show them to >>> anyone; please reply to this email or call +44 207 356 0600 and >>> highlight the error. >>> >>> >>> >>> _______________________________________________ >>> SLIM mailing list >>> SLIM@ietf.org >>> >>> https://www.ietf.org/mailman/listinfo/slim >>> >>> >> >> -- >> ----------------------------------------- >> Gunnar Hellström >> Omnitor >> gunnar.hellstrom@omnitor.se >> +46 708 204 288 >> >> _______________________________________________ >> SLIM mailing list >> SLIM@ietf.org >> https://www.ietf.org/mailman/listinfo/slim > > From nobody Sun May 15 15:36:00 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 F064B12D1C7 for ; Sun, 15 May 2016 15:35:58 -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 0OUfjilI2GRO for ; Sun, 15 May 2016 15:35:55 -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 ADE5012B039 for ; Sun, 15 May 2016 15:35:54 -0700 (PDT) X-Halon-ID: 5f2ae0be-1aed-11e6-928d-005056917a89 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.15] (unknown [87.96.161.49]) by bin-vsp-out-01.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Mon, 16 May 2016 00:35:48 +0200 (CEST) To: slim@ietf.org References: <179bc991-af2d-a726-d8ba-71a8c2f5322d@omnitor.se> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <4b15d4e1-40d9-1fbf-8fcb-3301108ee686@omnitor.se> Date: Mon, 16 May 2016 00:35:40 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------06F061C1D4CDD03442E2B62F" Archived-At: Subject: Re: [Slim] Seeking rough consensus for draft-ietf-slim-negotiating-human-language 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, 15 May 2016 22:35:59 -0000 This is a multi-part message in MIME format. --------------06F061C1D4CDD03442E2B62F Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Den 2016-05-15 kl. 20:40, skrev Paul Kyzivat: > On 5/14/16 7:10 PM, Randall Gellens wrote: >> I think the draft is sufficient for us to move forward. If we later >> find we need to describe "preference between languages in different >> media descriptions" or "requiring to use two or more language/modalities >> together" then we can define mechanisms to do so, either as an extension >> or in a -bis document. The need is described in the use cases. Lacking any other mechanism for describing the preference between media, I proposed introducing the q-value similar to how that is used for SIP media tags. I and others were concerned about the introduced complexity by that mechanism. Here is another proposal: Let the humintlang attribute position in each media specification represent a relative preference, lower the later it appears within the media specification. Let the first position in each media specification represent the same preference. Insert language subtag zxx "No Linguistic content" before humintlang attributes for languages of lower preference than the ones in earlier positions in other media specifications. Example m=video ... a=humintlang-send:ase a=humintlang-recv:ase m=text ... a=humintlang-send:zxx a=humintlang-send:en a=humintlang-recv:zxx a=humintlang-recv:en Would mean that the user prefers to use American sign language but can with lower preference accept to type and read English. Even if this is accepted for the preference notation between media, we still need a notation for differentiating between using two languages in different media versus providing a selection between two language/modality combinations in different media. Requiring to use more than one medium in the same direction is an unusual case, so that should not be the default. We could have the notation that if two languages are specified at the same preference level but in different media, then they are both required. That would mean that a selection always must be specified with a difference in preference. > > I am ok with this approach *if* we agree that there is no implicit > assumption about preference. Absent anything else, I think we must > assume that the offerer wants *all* m-lines in the offer to be > accepted, and intends to use them all. Yes, the medium is uíndicated as wanted by including its m-line. The humintlang attribute just specifies how the users prefer to use the media. > > My fear is that implementers will make some assumption, but they won't > all make the same assumption. Then there are surprises when something > unexpected happens. > > Alternately, we could make a particular assumption and state it clearly. Yes, we are aware of the problem now, so we should be able to formulate clear rules. Randall and I discussed in the list some of the wording for getting the intentions more clearly specified. I would like to see the resulting wording. > > > Thanks, > Paul Thanks Gunnar > >> t 10:11 PM +0200 5/13/16, Gunnar Hellström wrote: >> >>> Thanks Natasha for pushing us to action, >>> >>> I am not happy to move on before we have a solution to the use cases. >>> >>> I do not understand why we mention that the languages are listed in >>> preference order within a media description, but do not mention what >>> relation there is in preference between languages in different media >>> descriptions. The need for preference ordering can appear between >>> media as well as within a medium. >>> >>> And we need to have a way to indicate the difference between >>> requiring to use two or more lanuage/modalities together versus >>> providing them as selectable options. If we do not sort this out, we >>> cause the same confusion as we have around the current lang attribute. >>> We were discussing solutions to part of this on April 10 in the list, >>> but had no final conclusion on suitable wording that would cause less >>> confusion than current RFC 4566. That discussion needs to be concluded. >>> >>> Can we start with getting to see the current wording of the sections >>> under discussion on April 10? >>> >>> Thanks, >>> >>> Gunnar >>> >>> >>> >>> >>> Den 2016-05-13 kl. 19:44, skrev Natasha Rooney: >>> >>>> Hi all! >>>> >>>> I hope everyone is well and enjoying some short vacations throughout >>>> May. In this email we would like to discuss a route towards getting >>>> rough consensus for draft-ietf-slim-negotiating-human-language. >>>> >>>> In Buenos Aires, we discussed the completeness of >>>> draft-ietf-slim-negotiating-human-language. In particular, we >>>> discussed advancing the draft as it is versus adding mechanisms for >>>> grouping and absolute priority. Most participants (with one >>>> objection) at the meeting believed the draft to be sufficient for >>>> deployment now, that it is better to start with a simple mechanism >>>> that will be easier to implement and see earlier use, and that >>>> additional complexity can be added later (in an extension or -bis >>>> document) if we find we need grouping, absolute priority, or other >>>> advanced features. >>>> >>>> Therefore, the chairs would like to ask SLIM members on the list to >>>> respond to this suggestion: please let us know if you are happy with >>>> this to proceed or not and if not, why. >>>> >>>> >>>> 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 >>>> >>>> >>>> This email and its attachments are intended for the above named only >>>> and may be confidential. If they have come to you in error you must >>>> take no action based on them, nor must you copy or show them to >>>> anyone; please reply to this email or call +44 207 356 0600 and >>>> highlight the error. >>>> >>>> >>>> >>>> _______________________________________________ >>>> SLIM mailing list >>>> SLIM@ietf.org >>>> >>>> https://www.ietf.org/mailman/listinfo/slim >>>> >>>> >>>> >>> >>> -- >>> ----------------------------------------- >>> Gunnar Hellström >>> Omnitor >>> gunnar.hellstrom@omnitor.se >>> +46 708 204 288 >>> >>> _______________________________________________ >>> SLIM mailing list >>> SLIM@ietf.org >>> https://www.ietf.org/mailman/listinfo/slim >> >> > > _______________________________________________ > 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 --------------06F061C1D4CDD03442E2B62F Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit



Den 2016-05-15 kl. 20:40, skrev Paul Kyzivat:
On 5/14/16 7:10 PM, Randall Gellens wrote:
I think the draft is sufficient for us to move forward.  If we later
find we need to describe "preference between languages in different
media descriptions" or "requiring to use two or more language/modalities
together" then we can define mechanisms to do so, either as an extension
or in a -bis document.
The need is described in the use cases.

Lacking any other mechanism for describing the preference between media, I proposed introducing the q-value similar to how that is used for SIP media tags.

I and others were concerned about the introduced complexity by that mechanism.

Here is another proposal:
Let the humintlang attribute position in each media specification represent a relative preference, lower the later it appears within the media specification.
Let the first position in each media specification represent the same preference.
Insert language subtag zxx "No Linguistic content" before humintlang attributes for languages of lower preference than the ones in earlier positions in other media specifications.

Example

m=video ...
a=humintlang-send:ase
a=humintlang-recv:ase

m=text ...
a=humintlang-send:zxx
a=humintlang-send:en
a=humintlang-recv:zxx
a=humintlang-recv:en

Would mean that the user prefers to use American sign language but can with lower preference accept to type and read English.

Even if this is accepted for the preference notation between media, we still need a notation for differentiating between using two languages in different media  versus providing a selection between two language/modality combinations in different media.

Requiring to use more than one medium in the same direction is an unusual case, so that should not be the default.

We could have the notation that if two languages are specified at the same preference level but in different media, then they are both required. That would mean that a selection always must be specified with a difference in preference.







I am ok with this approach *if* we agree that there is no implicit assumption about preference. Absent anything else, I think we must assume that the offerer wants *all* m-lines in the offer to be accepted, and intends to use them all.
Yes, the medium is uíndicated as wanted by including its m-line.   The humintlang attribute just specifies how the users prefer to use the media. 

My fear is that implementers will make some assumption, but they won't all make the same assumption. Then there are surprises when something unexpected happens.

Alternately, we could make a particular assumption and state it clearly.
Yes, we are aware of the problem now, so we should be able to formulate clear rules.
Randall and I discussed in the list some of the wording for getting the intentions more clearly specified. I would like to see the resulting wording.


    Thanks,
    Paul
Thanks
Gunnar

t 10:11 PM +0200 5/13/16, Gunnar Hellström wrote:

 Thanks Natasha for pushing us to action,

 I am not happy to move on before we have a solution to the use cases.

 I do not understand why we mention that the languages are listed in
preference order within a media description, but do not mention what
relation there is in preference between languages in different media
descriptions. The need for preference ordering can appear between
media as well as within a medium.

 And we need to have a way to indicate the difference between
requiring to use two or more lanuage/modalities together versus
providing them as selectable options. If we do not sort this out, we
cause the same confusion as we have around the current lang attribute.
We were discussing solutions to part of this on April 10 in the list,
but had no final conclusion on suitable wording that would cause less
confusion than current RFC 4566. That discussion needs to be concluded.

 Can we start with getting to see the current wording of the sections
under discussion on April 10?

 Thanks,

 Gunnar




 Den 2016-05-13 kl. 19:44, skrev Natasha Rooney:

 Hi all!

 I hope everyone is well and enjoying some short vacations throughout
May. In this email we would like to discuss a route towards getting
rough consensus for draft-ietf-slim-negotiating-human-language.

 In Buenos Aires, we discussed the completeness of
draft-ietf-slim-negotiating-human-language. In particular, we
discussed advancing the draft as it is versus adding mechanisms for
grouping and absolute priority. Most participants (with one
objection) at the meeting believed the draft to be sufficient for
deployment now, that it is better to start with a simple mechanism
that will be easier to implement and see earlier use, and that
additional complexity can be added later (in an extension or -bis
document) if we find we need grouping, absolute priority, or other
advanced features.

 Therefore, the chairs would like to ask SLIM members on the list to
respond to this suggestion: please let us know if you are happy with
this to proceed or not and if not, why.


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



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

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



_______________________________________________
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
--------------06F061C1D4CDD03442E2B62F-- From nobody Sun May 15 15:49: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 3A81C12D0BA for ; Sun, 15 May 2016 15:49:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.481 X-Spam-Level: X-Spam-Status: No, score=-1.481 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, STOX_REPLY_TYPE=0.439] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XalHg7BU-rZZ for ; Sun, 15 May 2016 15:49:08 -0700 (PDT) Received: from p3plsmtpa12-03.prod.phx3.secureserver.net (p3plsmtpa12-03.prod.phx3.secureserver.net [68.178.252.232]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A25612B039 for ; Sun, 15 May 2016 15:49:08 -0700 (PDT) Received: from DougEwell ([184.96.255.129]) by p3plsmtpa12-03.prod.phx3.secureserver.net with id ump71s0072oHCb401mp72e; Sun, 15 May 2016 15:49:08 -0700 Message-ID: <83BCCAEC07554E7D91C0A416F51A6722@DougEwell> From: "Doug Ewell" To: , =?utf-8?Q?Gunnar_Hellstr=C3=B6m?= References: <179bc991-af2d-a726-d8ba-71a8c2f5322d@omnitor.se> <4b15d4e1-40d9-1fbf-8fcb-3301108ee686@omnitor.se> In-Reply-To: <4b15d4e1-40d9-1fbf-8fcb-3301108ee686@omnitor.se> Date: Sun, 15 May 2016 16:49:17 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3555.308 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3555.308 Archived-At: Subject: Re: [Slim] Seeking rough consensus for draft-ietf-slim-negotiating-human-language 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, 15 May 2016 22:49:09 -0000 Gunnar Hellström wrote: > Insert language subtag zxx "No Linguistic content" before humintlang > attributes for languages of lower preference than the ones in earlier > positions in other media specifications. > > Example > > m=video ... > a=humintlang-send:ase > a=humintlang-recv:ase > > m=text ... > a=humintlang-send:zxx > a=humintlang-send:en > a=humintlang-recv:zxx > a=humintlang-recv:en > > Would mean that the user prefers to use American sign language but can > with lower preference accept to type and read English. What does this have to do with the meaning of 'zxx' as "No linguistic content", or for that matter "Not applicable" (the other Description field currently associated with 'zxx')? BCP 47 subtags are not to be redefined as application-specific sentinel values. If you need a mechanism to rank humintlang attributes by priority or preference, create a mechanism to do that; don't make up your own meanings for subtags. The main reason I monitor this group is to help ensure that SLIM becomes a proper application of BCP 47, and doesn't try to bastardize it in some way. This would be an example of the latter. -- Doug Ewell | http://ewellic.org | Thornton, CO 🇺🇸 From nobody Sun May 15 16:59: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 017B312D560 for ; Sun, 15 May 2016 16:59:13 -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: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 S7HZY8GH4v-K for ; Sun, 15 May 2016 16:59:11 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 2A4E812D559 for ; Sun, 15 May 2016 16:59:11 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Sun, 15 May 2016 16:59:10 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <179bc991-af2d-a726-d8ba-71a8c2f5322d@omnitor.se> X-Mailer: Eudora for Mac OS X Date: Sun, 15 May 2016 16:59:08 -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] Seeking rough consensus for draft-ietf-slim-negotiating-human-language 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, 15 May 2016 23:59:13 -0000 At 2:40 PM -0400 5/15/16, Paul Kyzivat wrote: > On 5/14/16 7:10 PM, Randall Gellens wrote: >> I think the draft is sufficient for us to move forward. If we later >> find we need to describe "preference between languages in different >> media descriptions" or "requiring to use two or more language/modalities >> together" then we can define mechanisms to do so, either as an extension >> or in a -bis document. > > I am ok with this approach *if* we agree that=20 > there is no implicit assumption about=20 > preference. Absent anything else, I think we=20 > must assume that the offerer wants *all*=20 > m-lines in the offer to be accepted, and=20 > intends to use them all. I don't think we can assume the offerer intends=20 to use them all, but that's OK. Possibly some=20 media streams get established that are not used=20 (because more preferred streams were also set up). > > My fear is that implementers will make some=20 > assumption, but they won't all make the same=20 > assumption. Then there are surprises when=20 > something unexpected happens. As long as we keep it simple, we'll be OK. If=20 the answer contains all media and languages from=20 the offer that the answerer supports, the user=20 gets to use whichever he or she wants. > > Alternately, we could make a particular assumption and state it clearly. > > Thanks, > Paul > >> t 10:11 PM +0200 5/13/16, Gunnar Hellstr=F6m wrote: >> >>> Thanks Natasha for pushing us to action, >>> >>> I am not happy to move on before we have a solution to the use cases. >>> >>> I do not understand why we mention that the languages are listed in >>> preference order within a media description, but do not mention what >>> relation there is in preference between languages in different media >>> descriptions. The need for preference ordering can appear between >>> media as well as within a medium. >>> >>> And we need to have a way to indicate the difference between >>> requiring to use two or more lanuage/modalities together versus >>> providing them as selectable options. If we do not sort this out, we >>> cause the same confusion as we have around the current lang attribute. >>> We were discussing solutions to part of this on April 10 in the list, >>> but had no final conclusion on suitable wording that would cause less >>> confusion than current RFC 4566. That discussion needs to be concluded. >>> >>> Can we start with getting to see the current wording of the sections >>> under discussion on April 10? >>> >>> Thanks, >>> >>> Gunnar >>> >>> >>> >>> >>> Den 2016-05-13 kl. 19:44, skrev Natasha Rooney: >>> >>>> Hi all! >>>> >>>> I hope everyone is well and enjoying some short vacations throughout >>>> May. In this email we would like to discuss a route towards getting >>>> rough consensus for draft-ietf-slim-negotiating-human-language. >>>> >>>> In Buenos Aires, we discussed the completeness of >>>> draft-ietf-slim-negotiating-human-language. In particular, we >>>> discussed advancing the draft as it is versus adding mechanisms for >>>> grouping and absolute priority. Most participants (with one >>>> objection) at the meeting believed the draft to be sufficient for >>>> deployment now, that it is better to start with a simple mechanism >>>> that will be easier to implement and see earlier use, and that >>>> additional complexity can be added later (in an extension or -bis >>>> document) if we find we need grouping, absolute priority, or other >>>> advanced features. >>>> >>>> Therefore, the chairs would like to ask SLIM members on the list to >>>> respond to this suggestion: please let us know if you are happy with >>>> this to proceed or not and if not, why. >>>> >>>> >>>> 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 >>>> >>>> >>>> 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 >>>> >>>>=20 >>>> https://www.ietf.org/mailma= n/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 >> >> > > _______________________________________________ > 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: --------------- Q: Why do mountain climbers rope themselves together? A: To prevent the sensible ones from going home. From nobody Sun May 15 17:01: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 2EDD612D54E for ; Sun, 15 May 2016 17:01:16 -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: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 oPuWnCb0N6qf for ; Sun, 15 May 2016 17:01:14 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 60C6612B034 for ; Sun, 15 May 2016 17:01:14 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Sun, 15 May 2016 17:01:13 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <4b15d4e1-40d9-1fbf-8fcb-3301108ee686@omnitor.se> References: <179bc991-af2d-a726-d8ba-71a8c2f5322d@omnitor.se> <4b15d4e1-40d9-1fbf-8fcb-3301108ee686@omnitor.se> X-Mailer: Eudora for Mac OS X Date: Sun, 15 May 2016 17:01:09 -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] Seeking rough consensus for draft-ietf-slim-negotiating-human-language 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, 16 May 2016 00:01:16 -0000 I do not think we need the complexity of=20 preference between media. Let's start out with=20 the simplest approach. We can add complexity=20 later if we find we need it. At 12:35 AM +0200 5/16/16, Gunnar Hellstr=F6m wrote: > Den 2016-05-15 kl. 20:40, skrev Paul Kyzivat: > >> On 5/14/16 7:10 PM, Randall Gellens wrote: >> >>> I think the draft is sufficient for us to move forward. If we later >>> find we need to describe "preference between languages in different >>> media descriptions" or "requiring to use two or more language/modalitie= s >>> together" then we can define mechanisms to do so, either as an extensio= n >>> or in a -bis document. >>> > The need is described in the use cases. > > Lacking any other mechanism for describing the=20 > preference between media, I proposed=20 > introducing the q-value similar to how that is=20 > used for SIP media tags. > > I and others were concerned about the=20 > introduced complexity by that mechanism. > > Here is another proposal: > Let the humintlang attribute position in each=20 > media specification represent a relative=20 > preference, lower the later it appears within=20 > the media specification. > Let the first position in each media=20 > specification represent the same preference. > Insert language subtag zxx "No Linguistic=20 > content" before humintlang attributes for=20 > languages of lower preference than the ones in=20 > earlier positions in other media specifications. > > Example > > m=3Dvideo ... > a=3Dhumintlang-send:ase > a=3Dhumintlang-recv:ase > > m=3Dtext ... > a=3Dhumintlang-send:zxx > a=3Dhumintlang-send:en > a=3Dhumintlang-recv:zxx > a=3Dhumintlang-recv:en > > Would mean that the user prefers to use=20 > American sign language but can with lower=20 > preference accept to type and read English. > > Even if this is accepted for the preference=20 > notation between media, we still need a=20 > notation for differentiating between using two=20 > languages in different media versus providing a=20 > selection between two language/modality=20 > combinations in different media. > > Requiring to use more than one medium in the=20 > same direction is an unusual case, so that=20 > should not be the default. > > We could have the notation that if two=20 > languages are specified at the same preference=20 > level but in different media, then they are=20 > both required. That would mean that a selection=20 > always must be specified with a difference in=20 > preference. > > > > > >> >> I am ok with this approach *if* we agree that=20 >> there is no implicit assumption about=20 >> preference. Absent anything else, I think we=20 >> must assume that the offerer wants *all*=20 >> m-lines in the offer to be accepted, and=20 >> intends to use them all. >> > Yes, the medium is u=EDndicated as wanted by=20 > including its m-line. The humintlang attribute=20 > just specifies how the users prefer to use the=20 > media. > >> >> My fear is that implementers will make some=20 >> assumption, but they won't all make the same=20 >> assumption. Then there are surprises when=20 >> something unexpected happens. >> >> >> Alternately, we could make a particular assumption and state it clearly. >> > Yes, we are aware of the problem now, so we=20 > should be able to formulate clear rules. > Randall and I discussed in the list some of the=20 > wording for getting the intentions more clearly=20 > specified. I would like to see the resulting=20 > wording. > >> >> >> Thanks, >> Paul >> > Thanks > Gunnar > >> >>> t 10:11 PM +0200 5/13/16, Gunnar Hellstr=F6m wrote: >>> >>>> Thanks Natasha for pushing us to action, >>>> >>>> I am not happy to move on before we have a solution to the use cases. >>>> >>>> I do not understand why we mention that the languages are listed in >>>> preference order within a media description, but do not mention what >>>> relation there is in preference between languages in different media >>>> descriptions. The need for preference ordering can appear between >>>> media as well as within a medium. >>>> >>>> And we need to have a way to indicate the difference between >>>> requiring to use two or more lanuage/modalities together versus >>>> providing them as selectable options. If we do not sort this out, we >>>> cause the same confusion as we have around the current lang attribute. >>>> We were discussing solutions to part of this on April 10 in the list, >>>> but had no final conclusion on suitable wording that would cause less >>>> confusion than current RFC 4566. That discussion needs to be concluded= =2E >>>> >>>> Can we start with getting to see the current wording of the sections >>>> under discussion on April 10? >>>> >>>> Thanks, >>>> >>>> Gunnar >>>> >>>> >>>> >>>> >>>> Den 2016-05-13 kl. 19:44, skrev Natasha Rooney: >>>> >>>>> Hi all! >>>>> >>>>> I hope everyone is well and enjoying some short vacations throughout >>>>> May. In this email we would like to discuss a route towards getting >>>>> rough consensus for draft-ietf-slim-negotiating-human-language. >>>>> >>>>> In Buenos Aires, we discussed the completeness of >>>>> draft-ietf-slim-negotiating-human-language. In particular, we >>>>> discussed advancing the draft as it is versus adding mechanisms for >>>>> grouping and absolute priority. Most participants (with one >>>>> objection) at the meeting believed the draft to be sufficient for >>>>> deployment now, that it is better to start with a simple mechanism >>>>> that will be easier to implement and see earlier use, and that >>>>> additional complexity can be added later (in an extension or -bis >>>>> document) if we find we need grouping, absolute priority, or other >>>>> advanced features. >>>>> >>>>> Therefore, the chairs would like to ask SLIM members on the list to >>>>> respond to this suggestion: please let us know if you are happy with >>>>> this to proceed or not and if not, why. >>>>> >>>>> >>>>> Thanks everyone! >>>>> >>>>> Natasha >>>>> >>>>> >>>>> Natasha Rooney | Technologist, Web and Internet, W3C & IETF | GSMA | >>>>>=20 >>>>> nrooney@gsma.com=20 >>>>> | +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 >>>>>=20 >>>>> SLIM= @ietf.org >>>>> >>>>>=20 >>>>> https://www.ie= tf.org/mailman/listinfo/slim >>>>> >>>> >>>> -- >>>> ----------------------------------------- >>>> Gunnar Hellstr=F6m >>>> Omnitor >>>>=20 >>>> gunnar.hellstrom@omnitor.se >>>> +46 708 204 288 >>>> >>>> _______________________________________________ >>>> SLIM mailing list >>>> SLIM@ietf.org >>>>=20 >>>> https://www.ietf.org/mailma= n/listinfo/slim >>>> >>> >>> >> >> _______________________________________________ >> 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: --------------- An economist is an expert who will know tomorrow why the things he predicted yesterday didn't happen today. --Laurence J. Peter From nobody Sun May 15 22:45:16 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 3560812D5AB for ; Sun, 15 May 2016 22:45:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 es-VyhnXr458 for ; Sun, 15 May 2016 22:45:12 -0700 (PDT) Received: from bin-vsp-out-04.atm.binero.net (bin-mail-out-06.binero.net [195.74.38.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D42A412D5A9 for ; Sun, 15 May 2016 22:45:11 -0700 (PDT) X-Halon-ID: 588d178a-1b29-11e6-8988-005056917c0c Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.7] (unknown [87.96.161.49]) by bin-vsp-out-04.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Mon, 16 May 2016 07:45:07 +0200 (CEST) To: Doug Ewell , slim@ietf.org References: <179bc991-af2d-a726-d8ba-71a8c2f5322d@omnitor.se> <4b15d4e1-40d9-1fbf-8fcb-3301108ee686@omnitor.se> <83BCCAEC07554E7D91C0A416F51A6722@DougEwell> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <9ae1d006-73ce-bdfe-6ec7-868414e49279@omnitor.se> Date: Mon, 16 May 2016 07:44:59 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <83BCCAEC07554E7D91C0A416F51A6722@DougEwell> Content-Type: multipart/alternative; boundary="------------589ABDDAD7D5D8ED1E5E7EED" Archived-At: Subject: Re: [Slim] Seeking rough consensus for draft-ietf-slim-negotiating-human-language 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, 16 May 2016 05:45:15 -0000 This is a multi-part message in MIME format. --------------589ABDDAD7D5D8ED1E5E7EED Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Den 2016-05-16 kl. 00:49, skrev Doug Ewell: > Gunnar Hellström wrote: > >> Insert language subtag zxx "No Linguistic content" before humintlang >> attributes for languages of lower preference than the ones in earlier >> positions in other media specifications. >> >> Example >> >> m=video ... >> a=humintlang-send:ase >> a=humintlang-recv:ase >> >> m=text ... >> a=humintlang-send:zxx >> a=humintlang-send:en >> a=humintlang-recv:zxx >> a=humintlang-recv:en >> >> Would mean that the user prefers to use American sign language but can >> with lower preference accept to type and read English. > > What does this have to do with the meaning of 'zxx' as "No linguistic > content", or for that matter "Not applicable" (the other Description > field currently associated with 'zxx')? The thought was that the tags are ordered in preference order and since there was no preference on the highest level in the example to use language contents in text, therefore that preference level is marked with "No linguistic content". Not until coming to specifying lower preferences, there is a desire to use text for linguistic content. > > BCP 47 subtags are not to be redefined as application-specific > sentinel values. If you need a mechanism to rank humintlang attributes > by priority or preference, create a mechanism to do that; don't make > up your own meanings for subtags. I do not realize why this use of 'zxx' is not in line with the definition of the use of BCP 47 subtags. Is the intention with 'zxx' specified somewhere? The name looked useful for me. There are certainly other possible ways to indicate how a language in one media relates in priority to a language in another media. I have tried earlier with some hi, med and lo marks, and the q-values. All possible, but none elegant. We could put a number for where the preferences for language in one medium starts relative to the others. That is however so close to the q-number notation that it probably saves more implementation effort to use the q-number notation. The example would then be: m=video ... a=humintlang-send:1;ase a=humintlang-recv:1;ase m=text ... a=humintlang-send:3;en a=humintlang-recv:3;en I put here 3 instead of 2 to indicate a clearly lower preference for written Ennglish as an alternative. > > The main reason I monitor this group is to help ensure that SLIM > becomes a proper application of BCP 47, and doesn't try to bastardize > it in some way. This would be an example of the latter. Thanks for watching. Can you explein in some more words why it would not be proper to use 'zxx' in a place where the syntax requires a language subtag, but we do not have any language content? > > -- > Doug Ewell | http://ewellic.org | Thornton, CO 🇺🇸 -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 --------------589ABDDAD7D5D8ED1E5E7EED Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Den 2016-05-16 kl. 00:49, skrev Doug Ewell:

Gunnar Hellström wrote:

Insert language subtag zxx "No Linguistic content" before humintlang
attributes for languages of lower preference than the ones in earlier
positions in other media specifications.

Example

m=video ...
a=humintlang-send:ase
a=humintlang-recv:ase

m=text ...
a=humintlang-send:zxx
a=humintlang-send:en
a=humintlang-recv:zxx
a=humintlang-recv:en

Would mean that the user prefers to use American sign language but can
with lower preference accept to type and read English.

What does this have to do with the meaning of 'zxx' as "No linguistic content", or for that matter "Not applicable" (the other Description field currently associated with 'zxx')?
The thought was that the tags are ordered in preference order and since there was no preference on the highest level in the example to use language contents in text, therefore that preference level is marked with "No linguistic content". Not until coming to specifying lower preferences, there is a desire to use text for linguistic content. 

BCP 47 subtags are not to be redefined as application-specific sentinel values. If you need a mechanism to rank humintlang attributes by priority or preference, create a mechanism to do that; don't make up your own meanings for subtags.
I do not realize why this use of 'zxx' is not in line with the definition of the use of BCP 47 subtags. Is the intention with 'zxx' specified somewhere? The name looked useful for me.

There are certainly other possible ways to indicate how a language in one media relates in priority to a language in another media. I have tried earlier with some hi, med and lo marks, and the q-values. All possible, but none elegant.

We could put a number for where the preferences for language in one medium starts relative to the others. That is however so close to the q-number notation that it probably saves more implementation effort to use the q-number notation.

The example would then be:

m=video ...
a=humintlang-send:1;ase
a=humintlang-recv:1;ase

m=text ...
a=humintlang-send:3;en 
a=humintlang-recv:3;en

I put here 3 instead of 2 to indicate a clearly lower preference for written Ennglish as an alternative.



The main reason I monitor this group is to help ensure that SLIM becomes a proper application of BCP 47, and doesn't try to bastardize it in some way. This would be an example of the latter.
Thanks for watching. Can you explein in some more words why it would not be proper to use 'zxx' in a place where the syntax requires a language subtag, but we do not have any language content?

--
Doug Ewell | http://ewellic.org | Thornton, CO 🇺🇸 

-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288
--------------589ABDDAD7D5D8ED1E5E7EED-- From nobody Sun May 15 22:59: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 5F6FE12B02F for ; Sun, 15 May 2016 22:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 D7JlZxkp_yZp for ; Sun, 15 May 2016 22:59:21 -0700 (PDT) Received: from bin-vsp-out-05.atm.binero.net (vsp-unauthed02.binero.net [195.74.38.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 921A312B02B for ; Sun, 15 May 2016 22:59:20 -0700 (PDT) X-Halon-ID: 54fcfdcd-1b2b-11e6-9ca0-005056913f0f Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.7] (unknown [87.96.161.49]) by bin-vsp-out-05.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Mon, 16 May 2016 07:59:20 +0200 (CEST) To: slim@ietf.org References: <179bc991-af2d-a726-d8ba-71a8c2f5322d@omnitor.se> <4b15d4e1-40d9-1fbf-8fcb-3301108ee686@omnitor.se> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <8f45d12c-4f14-c06a-2583-2139032542ac@omnitor.se> Date: Mon, 16 May 2016 07:59:09 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------D18EC5F19A5E1EBFE0D8BAF2" Archived-At: Subject: Re: [Slim] Seeking rough consensus for draft-ietf-slim-negotiating-human-language 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, 16 May 2016 05:59:24 -0000 This is a multi-part message in MIME format. --------------D18EC5F19A5E1EBFE0D8BAF2 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Den 2016-05-16 kl. 02:01, skrev Randall Gellens: > I do not think we need the complexity of preference between media. > Let's start out with the simplest approach. We can add complexity > later if we find we need it. I see the clear need especially for marking a possible but much less preferred alternative in another media as a contrast against 'select whichever you want among the alternatives in different media'. That would signal to the callee to make efforts to satisfy the preferred case but a good guidance on what to do if that seems impossible to achieve. I don't want to wait when we already now see the need. I wonder if the problem to get to an agreement is that I see the language indication as guidance to the answering part on what they shall use media for rather than a base for just acceptance to connect media. Can you accept the view that the language/modality indication can be used for routing to the proper person with the right language competence and as a guide to that person for what modality and language to answer the call? /Gunnar > > At 12:35 AM +0200 5/16/16, Gunnar Hellström wrote: > >> Den 2016-05-15 kl. 20:40, skrev Paul Kyzivat: >> >>> On 5/14/16 7:10 PM, Randall Gellens wrote: >>> >>>> I think the draft is sufficient for us to move forward. If we later >>>> find we need to describe "preference between languages in different >>>> media descriptions" or "requiring to use two or more >>>> language/modalities >>>> together" then we can define mechanisms to do so, either as an >>>> extension >>>> or in a -bis document. >>>> >> The need is described in the use cases. >> >> Lacking any other mechanism for describing the preference between >> media, I proposed introducing the q-value similar to how that is used >> for SIP media tags. >> >> I and others were concerned about the introduced complexity by that >> mechanism. >> >> Here is another proposal: >> Let the humintlang attribute position in each media specification >> represent a relative preference, lower the later it appears within >> the media specification. >> Let the first position in each media specification represent the >> same preference. >> Insert language subtag zxx "No Linguistic content" before humintlang >> attributes for languages of lower preference than the ones in earlier >> positions in other media specifications. >> >> Example >> >> m=video ... >> a=humintlang-send:ase >> a=humintlang-recv:ase >> >> m=text ... >> a=humintlang-send:zxx >> a=humintlang-send:en >> a=humintlang-recv:zxx >> a=humintlang-recv:en >> >> Would mean that the user prefers to use American sign language but >> can with lower preference accept to type and read English. >> >> Even if this is accepted for the preference notation between media, >> we still need a notation for differentiating between using two >> languages in different media versus providing a selection between two >> language/modality combinations in different media. >> >> Requiring to use more than one medium in the same direction is an >> unusual case, so that should not be the default. >> >> We could have the notation that if two languages are specified at >> the same preference level but in different media, then they are both >> required. That would mean that a selection always must be specified >> with a difference in preference. >> >> >> >> >> >>> >>> I am ok with this approach *if* we agree that there is no implicit >>> assumption about preference. Absent anything else, I think we must >>> assume that the offerer wants *all* m-lines in the offer to be >>> accepted, and intends to use them all. >>> >> Yes, the medium is uíndicated as wanted by including its m-line. The >> humintlang attribute just specifies how the users prefer to use the >> media. >> >>> >>> My fear is that implementers will make some assumption, but they >>> won't all make the same assumption. Then there are surprises when >>> something unexpected happens. >>> >>> >>> Alternately, we could make a particular assumption and state it >>> clearly. >>> >> Yes, we are aware of the problem now, so we should be able to >> formulate clear rules. >> Randall and I discussed in the list some of the wording for getting >> the intentions more clearly specified. I would like to see the >> resulting wording. >> >>> >>> >>> Thanks, >>> Paul >>> >> Thanks >> Gunnar >> >>> >>>> t 10:11 PM +0200 5/13/16, Gunnar Hellström wrote: >>>> >>>>> Thanks Natasha for pushing us to action, >>>>> >>>>> I am not happy to move on before we have a solution to the use >>>>> cases. >>>>> >>>>> I do not understand why we mention that the languages are listed in >>>>> preference order within a media description, but do not mention what >>>>> relation there is in preference between languages in different media >>>>> descriptions. The need for preference ordering can appear between >>>>> media as well as within a medium. >>>>> >>>>> And we need to have a way to indicate the difference between >>>>> requiring to use two or more lanuage/modalities together versus >>>>> providing them as selectable options. If we do not sort this out, we >>>>> cause the same confusion as we have around the current lang >>>>> attribute. >>>>> We were discussing solutions to part of this on April 10 in the >>>>> list, >>>>> but had no final conclusion on suitable wording that would cause >>>>> less >>>>> confusion than current RFC 4566. That discussion needs to be >>>>> concluded. >>>>> >>>>> Can we start with getting to see the current wording of the sections >>>>> under discussion on April 10? >>>>> >>>>> Thanks, >>>>> >>>>> Gunnar >>>>> >>>>> >>>>> >>>>> >>>>> Den 2016-05-13 kl. 19:44, skrev Natasha Rooney: >>>>> >>>>>> Hi all! >>>>>> >>>>>> I hope everyone is well and enjoying some short vacations >>>>>> throughout >>>>>> May. In this email we would like to discuss a route towards getting >>>>>> rough consensus for draft-ietf-slim-negotiating-human-language. >>>>>> >>>>>> In Buenos Aires, we discussed the completeness of >>>>>> draft-ietf-slim-negotiating-human-language. In particular, we >>>>>> discussed advancing the draft as it is versus adding mechanisms for >>>>>> grouping and absolute priority. Most participants (with one >>>>>> objection) at the meeting believed the draft to be sufficient for >>>>>> deployment now, that it is better to start with a simple mechanism >>>>>> that will be easier to implement and see earlier use, and that >>>>>> additional complexity can be added later (in an extension or -bis >>>>>> document) if we find we need grouping, absolute priority, or other >>>>>> advanced features. >>>>>> >>>>>> Therefore, the chairs would like to ask SLIM members on the list to >>>>>> respond to this suggestion: please let us know if you are happy >>>>>> with >>>>>> this to proceed or not and if not, why. >>>>>> >>>>>> >>>>>> 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 >>>>>> >>>>>> >>>>>> This email and its attachments are intended for the above named >>>>>> only >>>>>> and may be confidential. If they have come to you in error you must >>>>>> take no action based on them, nor must you copy or show them to >>>>>> anyone; please reply to this email or call +44 207 356 0600 and >>>>>> highlight the error. >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> SLIM mailing list >>>>>> >>>>>> SLIM@ietf.org >>>>>> >>>>>> >>>>>> >>>>>> https://www.ietf.org/mailman/listinfo/slim >>>>>> >>>>>> >>>>> >>>>> -- >>>>> ----------------------------------------- >>>>> Gunnar Hellström >>>>> Omnitor >>>>> >>>>> gunnar.hellstrom@omnitor.se >>>>> >>>>> +46 708 204 288 >>>>> >>>>> _______________________________________________ >>>>> SLIM mailing list >>>>> SLIM@ietf.org >>>>> >>>>> https://www.ietf.org/mailman/listinfo/slim >>>>> >>>>> >>>> >>>> >>> >>> _______________________________________________ >>> 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 --------------D18EC5F19A5E1EBFE0D8BAF2 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Den 2016-05-16 kl. 02:01, skrev Randall Gellens:

I do not think we need the complexity of preference between media.  Let's start out with the simplest approach.  We can add complexity later if we find we need it.
I see the clear need especially for marking a possible but much less preferred alternative in another media as a contrast against 'select whichever you want among the alternatives in different media'.
That would signal to the callee to make efforts to satisfy the preferred case but a good guidance on what to do if that seems impossible to achieve. I don't want to wait when we already now see the need.

I wonder if the problem to get to an agreement is that I see the language indication as guidance to the answering part on what they shall use media for rather than a base for just acceptance to connect media.

Can you accept the view that the language/modality indication can be used for routing to the proper person with the right language competence and as a guide to that person for what modality and language to answer the call?

/Gunnar


At 12:35 AM +0200 5/16/16, Gunnar Hellström wrote:

 Den 2016-05-15 kl. 20:40, skrev Paul Kyzivat:

 On 5/14/16 7:10 PM, Randall Gellens wrote:

 I think the draft is sufficient for us to move forward. If we later
 find we need to describe "preference between languages in different
 media descriptions" or "requiring to use two or more language/modalities
 together" then we can define mechanisms to do so, either as an extension
 or in a -bis document.

 The need is described in the use cases.

 Lacking any other mechanism for describing the preference between media, I proposed introducing the q-value similar to how that is used for SIP media tags.

 I and others were concerned about the introduced complexity by that mechanism.

 Here is another proposal:
 Let the humintlang attribute position in each media specification represent a relative preference, lower the later it appears within the media specification.
 Let the first position in each media specification represent the same preference.
 Insert language subtag zxx "No Linguistic content" before humintlang attributes for languages of lower preference than the ones in earlier positions in other media specifications.

 Example

 m=video ...
 a=humintlang-send:ase
 a=humintlang-recv:ase

 m=text ...
 a=humintlang-send:zxx
 a=humintlang-send:en
 a=humintlang-recv:zxx
 a=humintlang-recv:en

 Would mean that the user prefers to use American sign language but can with lower preference accept to type and read English.

 Even if this is accepted for the preference notation between media, we still need a notation for differentiating between using two languages in different media versus providing a selection between two language/modality combinations in different media.

 Requiring to use more than one medium in the same direction is an unusual case, so that should not be the default.

 We could have the notation that if two languages are specified at the same preference level but in different media, then they are both required. That would mean that a selection always must be specified with a difference in preference.






 I am ok with this approach *if* we agree that there is no implicit assumption about preference. Absent anything else, I think we must assume that the offerer wants *all* m-lines in the offer to be accepted, and intends to use them all.

 Yes, the medium is uíndicated as wanted by including its m-line. The humintlang attribute just specifies how the users prefer to use the media.


 My fear is that implementers will make some assumption, but they won't all make the same assumption. Then there are surprises when something unexpected happens.


 Alternately, we could make a particular assumption and state it clearly.

 Yes, we are aware of the problem now, so we should be able to formulate clear rules.
 Randall and I discussed in the list some of the wording for getting the intentions more clearly specified. I would like to see the resulting wording.



 Thanks,
 Paul

 Thanks
 Gunnar


 t 10:11 PM +0200 5/13/16, Gunnar Hellström wrote:

 Thanks Natasha for pushing us to action,

 I am not happy to move on before we have a solution to the use cases.

 I do not understand why we mention that the languages are listed in
 preference order within a media description, but do not mention what
 relation there is in preference between languages in different media
 descriptions. The need for preference ordering can appear between
 media as well as within a medium.

 And we need to have a way to indicate the difference between
 requiring to use two or more lanuage/modalities together versus
 providing them as selectable options. If we do not sort this out, we
 cause the same confusion as we have around the current lang attribute.
 We were discussing solutions to part of this on April 10 in the list,
 but had no final conclusion on suitable wording that would cause less
 confusion than current RFC 4566. That discussion needs to be concluded.

 Can we start with getting to see the current wording of the sections
 under discussion on April 10?

 Thanks,

 Gunnar




 Den 2016-05-13 kl. 19:44, skrev Natasha Rooney:

 Hi all!

 I hope everyone is well and enjoying some short vacations throughout
 May. In this email we would like to discuss a route towards getting
 rough consensus for draft-ietf-slim-negotiating-human-language.

 In Buenos Aires, we discussed the completeness of
 draft-ietf-slim-negotiating-human-language. In particular, we
 discussed advancing the draft as it is versus adding mechanisms for
 grouping and absolute priority. Most participants (with one
 objection) at the meeting believed the draft to be sufficient for
 deployment now, that it is better to start with a simple mechanism
 that will be easier to implement and see earlier use, and that
 additional complexity can be added later (in an extension or -bis
 document) if we find we need grouping, absolute priority, or other
 advanced features.

 Therefore, the chairs would like to ask SLIM members on the list to
 respond to this suggestion: please let us know if you are happy with
 this to proceed or not and if not, why.


 Thanks everyone!

 Natasha


 Natasha Rooney | Technologist, Web and Internet, W3C & IETF | GSMA |

<mailto:nrooney@gsma.com><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><mailto:SLIM@ietf.org><mailto:SLIM@ietf.org>SLIM@ietf.org


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


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

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

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

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




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

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


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

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



-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288
--------------D18EC5F19A5E1EBFE0D8BAF2-- From nobody Mon May 16 07:39: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 0970D12B042 for ; Mon, 16 May 2016 07:39:14 -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 nm3Bt4NcTtA1 for ; Mon, 16 May 2016 07:39:12 -0700 (PDT) Received: from p3plwbeout03-03.prod.phx3.secureserver.net (p3plsmtp03-03-2.prod.phx3.secureserver.net [72.167.218.215]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DEF612D161 for ; Mon, 16 May 2016 07:39:12 -0700 (PDT) Received: from localhost ([72.167.218.135]) by p3plwbeout03-03.prod.phx3.secureserver.net with bizsmtp id v2fB1s0012vs63s012fBGY; Mon, 16 May 2016 07:39:11 -0700 X-SID: v2fB1s0012vs63s01 Received: (qmail 4882 invoked by uid 99); 16 May 2016 14:39:11 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 208.51.143.189 User-Agent: Workspace Webmail 6.2.9 Message-Id: <20160516073909.665a7a7059d7ee80bb4d670165c8327d.fae8a9ae5a.wbe@email03.godaddy.com> From: "Doug Ewell" To: "=?UTF-8?Q?Gunnar=5FHellstr=C3=B6m?=" , slim@ietf.org Date: Mon, 16 May 2016 07:39:09 -0700 Mime-Version: 1.0 Archived-At: Subject: Re: [Slim] Seeking rough consensus for draft-ietf-slim-negotiating-human-language 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, 16 May 2016 14:39:14 -0000 Gunnar Hellstr=C3=B6m wrote:=0A=0A>> What does this have to do with the mea= ning of 'zxx' as "No linguistic=0A>> content", or for that matter "Not appl= icable" (the other Description=0A>> field currently associated with 'zxx')?= =0A>=0A> The thought was that the tags are ordered in preference order and= =0A> since there was no preference on the highest level in the example to= =0A> use language contents in text, therefore that preference level is=0A> = marked with "No linguistic content". Not until coming to specifying=0A> low= er preferences, there is a desire to use text for linguistic=0A> content.= =0A=0ALanguage tags indicate the language, and variant(s) thereof, of the= =0Acontent thus tagged. A tag of "zxx" indicates content that is not=0Aling= uistic in nature, such as instrumental music or the sound of fingers=0Asnap= ping, or an origami bird, or the Mona Lisa.=0A=0AWhat you are trying to imp= lement is a sentinel that means "Here is a=0Aboundary between items of high= er preference or priority, and items of=0Alower preference or priority." It= is a special flag value. It doesn't=0Amean "no linguistic content."=0A=0A>= I do not realize why this use of 'zxx' is not in line with the=0A> definit= ion of the use of BCP 47 subtags. Is the intention with 'zxx'=0A> specified= somewhere? The name looked useful for me.=0A=0AThis is from RFC 5646, Sect= ion 4.1 ("Choice of Language Tag"), item 5,=0Abullet point 3:=0A=0A"The 'zx= x' (Non-Linguistic, Not Applicable) primary language subtag=0Aidentifies co= ntent for which a language classification is inappropriate=0Aor does not ap= ply. Some examples might include instrumental or=0Aelectronic music; sound= recordings consisting of nonverbal sounds;=0Aaudiovisual materials with no= narration, dialog, printed titles, or=0Asubtitles; machine-readable data f= iles consisting of machine languages=0Aor character codes; or programming s= ource code."=0A=0ANotice the key term here: "content." The line "a=3Dhumint= lang-send:zxx" in=0Ayour example would mean "I prefer to send CONTENT that = is non-linguistic=0Ain nature." Perhaps it means that the user prefers to c= ommunicate by=0Awhistling or making facial gestures.=0A=0A> We could put a = number for where the preferences for language in one=0A> medium starts rela= tive to the others. That is however so close to the=0A> q-number notation t= hat it probably saves more implementation effort to=0A> use the q-number no= tation.=0A>=0A> The example would then be:=0A>=0A> m=3Dvideo ...=0A> a=3Dhu= mintlang-send:1;ase=0A> a=3Dhumintlang-recv:1;ase=0A>=0A> m=3Dtext ...=0A> = a=3Dhumintlang-send:3;en=0A> a=3Dhumintlang-recv:3;en=0A>=0A> I put here 3 = instead of 2 to indicate a clearly lower preference for=0A> written Ennglis= h as an alternative.=0A=0AThat is exactly what I meant by "create a mechani= sm to do that." The=0Anumbers 1 and 3 are clearly defined as an indication = of preference. As=0Ayou observed, q-numbers would be similar, and might be = better because=0Athey are already used and understood in other contexts.=0A= =0AI'm not stating an opinion for or against the additional complexity=0Ahe= re. I do think some of the use cases that have been used to justify=0Aprefe= rence mechanisms are excessively elaborate and far-fetched, and=0Amight eve= n dilute the more realistic arguments. My point here is just=0Athat, if SLI= M does need a preference mechanism, an imaginative=0Ainterpretation of "no = linguistic content" isn't it.=0A=0A> Thanks for watching. Can you explein i= n some more words why it would=0A> not be proper to use 'zxx' in a place wh= ere the syntax requires a=0A> language subtag, but we do not have any langu= age content?=0A=0ASee the quote from RFC 5646 above. What you're trying to = define is a=0Aboundary between preferences, not an indication of non-langua= ge content.=0A=0A--=0ADoug Ewell | http://ewellic.org | Thornton, CO =F0=9F= =87=BA=F0=9F=87=B8=0A From nobody Mon May 16 08:40: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 59FA312D6CD for ; Mon, 16 May 2016 08:40:02 -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 T6waRliBp35L for ; Mon, 16 May 2016 08:40:01 -0700 (PDT) Received: from p3plwbeout03-03.prod.phx3.secureserver.net (p3plsmtp03-03-2.prod.phx3.secureserver.net [72.167.218.215]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2C7212D10D for ; Mon, 16 May 2016 08:40:00 -0700 (PDT) Received: from localhost ([72.167.218.132]) by p3plwbeout03-03.prod.phx3.secureserver.net with bizsmtp id v3g01s0082rz534013g0Rj; Mon, 16 May 2016 08:40:00 -0700 X-SID: v3g01s0082rz53401 Received: (qmail 6349 invoked by uid 99); 16 May 2016 15:40:00 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 208.51.143.189 User-Agent: Workspace Webmail 6.2.9 Message-Id: <20160516083958.665a7a7059d7ee80bb4d670165c8327d.5e281af085.wbe@email03.godaddy.com> From: "Doug Ewell" To: "=?UTF-8?Q?Gunnar=5FHellstr=C3=B6m?=" , slim@ietf.org Date: Mon, 16 May 2016 08:39:58 -0700 Mime-Version: 1.0 Archived-At: Subject: Re: [Slim] Seeking rough consensus for draft-ietf-slim-negotiating-human-language 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, 16 May 2016 15:40:02 -0000 Gunnar Hellstr=C3=B6m wrote:=0A=0A>>> m=3Dvideo ...=0A>>> a=3Dhumintlang-se= nd:ase=0A>>> a=3Dhumintlang-recv:ase=0A>>>=0A>>> m=3Dtext ...=0A>>> a=3Dhum= intlang-send:zxx=0A>>> a=3Dhumintlang-send:en=0A>>> a=3Dhumintlang-recv:zxx= =0A>>> a=3Dhumintlang-recv:en=0A>>>=0A>>> Would mean that the user prefers = to use American sign language but=0A>>> can with lower preference accept to= type and read English.=0A>=0A> [ ... ]=0A>=0A> The thought was that the ta= gs are ordered in preference order and=0A> since there was no preference on= the highest level in the example to=0A> use language contents in text, the= refore that preference level is=0A> marked with "No linguistic content". No= t until coming to specifying=0A> lower preferences, there is a desire to us= e text for linguistic=0A> content.=0A=0AI read this again, more slowly, and= it sounds like what you are really=0Atrying to do is implement a 2-dimensi= onal matrix, with 'zxx' used as a=0Aplaceholder:=0A=0ADirection Priority = Video Text=0A--------- -------- ----- ----=0A Send 1 = ase zxx=0A Send 2 --- en=0A Receive 1 = ase zxx=0A Receive 2 --- en=0A=0AThat still uses 'zx= x' to mean something other than what it means. You're=0Anot saying "text co= ntent that is not linguistic," you're saying "no text=0Acontent at all."=0A= =0AWhat you are trying to achieve is this:=0A=0ADirection Priority Medi= um Language=0A--------- -------- ------ --------=0A Send 1= Video ase=0A Send 2 Text en=0A Receive = 1 Video ase=0A Receive 2 Text en=0A=0AAnd= that makes more sense (again, not weighing in on whether we actually=0Anee= d this), because the data directly models the intended meaning.=0A=0AIf we = are the ones inventing the syntax, and we need to represent=0Asomething tha= t the syntax doesn't cover, the solution is to augment the=0Asyntax so it d= oes.=0A=0A--=0ADoug Ewell | http://ewellic.org | Thornton, CO =F0=9F=87=BA= =F0=9F=87=B8=0A From nobody Mon May 16 13:25: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 5F11612D9F8 for ; Mon, 16 May 2016 13:25:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 T7QMZ9EpP-Zz for ; Mon, 16 May 2016 13:25:34 -0700 (PDT) Received: from bin-vsp-out-04.atm.binero.net (bin-mail-out-06.binero.net [195.74.38.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D656C12D1DF for ; Mon, 16 May 2016 13:25:33 -0700 (PDT) X-Halon-ID: 554e9b8b-1ba4-11e6-8988-005056917c0c Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.5] (unknown [87.96.161.49]) by bin-vsp-out-04.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Mon, 16 May 2016 22:25:30 +0200 (CEST) To: Doug Ewell , slim@ietf.org References: <20160516083958.665a7a7059d7ee80bb4d670165c8327d.5e281af085.wbe@email03.godaddy.com> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: Date: Mon, 16 May 2016 22:25:21 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <20160516083958.665a7a7059d7ee80bb4d670165c8327d.5e281af085.wbe@email03.godaddy.com> Content-Type: multipart/alternative; boundary="------------ED936C8F99FC4512577C4F83" Archived-At: Subject: Re: [Slim] Seeking rough consensus for draft-ietf-slim-negotiating-human-language 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, 16 May 2016 20:25:37 -0000 This is a multi-part message in MIME format. --------------ED936C8F99FC4512577C4F83 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Den 2016-05-16 kl. 17:39, skrev Doug Ewell: > Gunnar Hellström wrote: > >>>> m=video ... >>>> a=humintlang-send:ase >>>> a=humintlang-recv:ase >>>> >>>> m=text ... >>>> a=humintlang-send:zxx >>>> a=humintlang-send:en >>>> a=humintlang-recv:zxx >>>> a=humintlang-recv:en >>>> >>>> Would mean that the user prefers to use American sign language but >>>> can with lower preference accept to type and read English. >> [ ... ] >> >> The thought was that the tags are ordered in preference order and >> since there was no preference on the highest level in the example to >> use language contents in text, therefore that preference level is >> marked with "No linguistic content". Not until coming to specifying >> lower preferences, there is a desire to use text for linguistic >> content. > I read this again, more slowly, and it sounds like what you are really > trying to do is implement a 2-dimensional matrix, with 'zxx' used as a > placeholder: > > Direction Priority Video Text > --------- -------- ----- ---- > Send 1 ase zxx > Send 2 --- en > Receive 1 ase zxx > Receive 2 --- en > > That still uses 'zxx' to mean something other than what it means. You're > not saying "text content that is not linguistic," you're saying "no text > content at all." No, not really. With humintlang we only negotiate the initial modality/language combination(s) to start using for the main dialogue. Conditions during the call may cause use of other media for occasional non linguistic content or other modalities/languages for shorter or longer periods of linguistic content. But you are right anyway. We do not want to control in detail what the other media than the one(s) used for the main dialogue are used for. So the proposal example just uses zxx as a placeholder to move english text to a lower preference than American Sign Language. It should be possible to specify and agree on a notation for preference that meet our needs. > > What you are trying to achieve is this: > > Direction Priority Medium Language > --------- -------- ------ -------- > Send 1 Video ase > Send 2 Text en > Receive 1 Video ase > Receive 2 Text en > > And that makes more sense (again, not weighing in on whether we actually > need this), because the data directly models the intended meaning. > > If we are the ones inventing the syntax, and we need to represent > something that the syntax doesn't cover, the solution is to augment the > syntax so it does. > > -- > Doug Ewell | http://ewellic.org | Thornton, CO 🇺🇸 > /Gunnar -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 --------------ED936C8F99FC4512577C4F83 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Den 2016-05-16 kl. 17:39, skrev Doug Ewell:
Gunnar Hellström wrote:


m=video ...
a=humintlang-send:ase
a=humintlang-recv:ase

m=text ...
a=humintlang-send:zxx
a=humintlang-send:en
a=humintlang-recv:zxx
a=humintlang-recv:en

Would mean that the user prefers to use American sign language but
can with lower preference accept to type and read English.

[ ... ]

The thought was that the tags are ordered in preference order and
since there was no preference on the highest level in the example to
use language contents in text, therefore that preference level is
marked with "No linguistic content". Not until coming to specifying
lower preferences, there is a desire to use text for linguistic
content.

I read this again, more slowly, and it sounds like what you are really
trying to do is implement a 2-dimensional matrix, with 'zxx' used as a
placeholder:

Direction   Priority   Video   Text
---------   --------   -----   ----
  Send         1        ase    zxx
  Send         2        ---     en
 Receive       1        ase    zxx
 Receive       2        ---     en

That still uses 'zxx' to mean something other than what it means. You're
not saying "text content that is not linguistic," you're saying "no text
content at all."
No, not really.  With humintlang we only negotiate the initial modality/language combination(s) to start using for the main dialogue. Conditions during the call may cause use of other media for occasional non linguistic content or other modalities/languages for shorter or longer periods of linguistic content.

But you are right anyway. We do not want to control in detail what the other media than the one(s) used for the main dialogue are used for.  So the proposal example just uses zxx as a placeholder to move english text to a lower preference than American Sign Language.

It should be possible to specify and agree on a notation for preference that meet our needs.
 

What you are trying to achieve is this:

Direction   Priority   Medium   Language
---------   --------   ------   --------
  Send         1       Video      ase
  Send         2        Text       en
 Receive       1       Video      ase
 Receive       2        Text       en

And that makes more sense (again, not weighing in on whether we actually
need this), because the data directly models the intended meaning.

If we are the ones inventing the syntax, and we need to represent
something that the syntax doesn't cover, the solution is to augment the
syntax so it does.

--
Doug Ewell | http://ewellic.org | Thornton, CO 🇺🇸
/Gunnar
-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288
--------------ED936C8F99FC4512577C4F83-- From nobody Mon May 16 19:28:22 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 4A24812D79F for ; Mon, 16 May 2016 19:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.462 X-Spam-Level: X-Spam-Status: No, score=-1.462 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, STOX_REPLY_TYPE=0.439] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ax087rJ3yhBV for ; Mon, 16 May 2016 19:28:20 -0700 (PDT) Received: from p3plsmtpa11-02.prod.phx3.secureserver.net (p3plsmtpa11-02.prod.phx3.secureserver.net [68.178.252.103]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3ACD912B018 for ; Mon, 16 May 2016 19:28:20 -0700 (PDT) Received: from DougEwell ([97.124.243.15]) by p3plsmtpa11-02.prod.phx3.secureserver.net with id vEUJ1s00B0LexbV01EUKRs; Mon, 16 May 2016 19:28:19 -0700 Message-ID: <7C5A334F88FD45E0A7770AFA6CB33C82@DougEwell> From: "Doug Ewell" To: , =?utf-8?Q?Gunnar_Hellstr=C3=B6m?= References: <20160516083958.665a7a7059d7ee80bb4d670165c8327d.5e281af085.wbe@email03.godaddy.com> In-Reply-To: Date: Mon, 16 May 2016 20:28:29 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3555.308 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3555.308 Archived-At: Subject: Re: [Slim] Seeking rough consensus for draft-ietf-slim-negotiating-human-language 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, 17 May 2016 02:28:21 -0000 Gunnar Hellström wrote: > But you are right anyway. We do not want to control in detail what the > other media than the one(s) used for the main dialogue are used for. > So the proposal example just uses zxx as a placeholder to move english > text to a lower preference than American Sign Language. Which is not correct, you see. The protocol should not use a "no linguistic content" tag for text when there is no text content at all in the initial modality/language combination. Direction Priority Video Text --------- -------- ----- ---- Send 1 ase zxx means "the user prefers to sign in American Sign Language while simultaneously typing non-linguistic text, such as gibberish." I don't think that is what is intended. > It should be possible to specify and agree on a notation for > preference that meet our needs. Except that there is still disagreement on whether the mechanism is needed for SLIM 1.0. -- Doug Ewell | http://ewellic.org | Thornton, CO 🇺🇸 From nobody Mon May 16 20:25: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 8A67012D512 for ; Mon, 16 May 2016 20:25:56 -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: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 yAphDZX5j_MA for ; Mon, 16 May 2016 20:25:55 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 8D06912D0A0 for ; Mon, 16 May 2016 20:25:55 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Mon, 16 May 2016 20:25:54 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <7C5A334F88FD45E0A7770AFA6CB33C82@DougEwell> References: <20160516083958.665a7a7059d7ee80bb4d670165c8327d.5e281af085.wbe@email0 3.godaddy.com> <7C5A334F88FD45E0A7770AFA6CB33C82@DougEwell> X-Mailer: Eudora for Mac OS X Date: Mon, 16 May 2016 20:25:53 -0700 To: "Doug Ewell" , , Gunnar =?iso-8859-1?Q?Hellstr=F6m?= From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 Archived-At: Subject: Re: [Slim] Seeking rough consensus for draft-ietf-slim-negotiating-human-language 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, 17 May 2016 03:25:56 -0000 At 8:28 PM -0600 5/16/16, Doug Ewell wrote: > Except that there is still disagreement on whether the mechanism is > needed for SLIM 1.0. And we have a call for consensus by the chairs. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- By further reducing the number of legacy airlines and aligning the economic incentives of those that remain, the merger of US Airways and American would make it easier for the remaining airlines to cooperate rather than compete on price on service. --US Justice Department, part of a lawsuit filed to stop the AA/US Air airline merger, 13 August 2013. From nobody Mon May 16 23:01: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 7022312D0CD for ; Mon, 16 May 2016 23:01:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 RuMD-cKd4xl5 for ; Mon, 16 May 2016 23:01:16 -0700 (PDT) Received: from bin-vsp-out-04.atm.binero.net (bin-mail-out-06.binero.net [195.74.38.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81C2612D505 for ; Mon, 16 May 2016 23:01:15 -0700 (PDT) X-Halon-ID: c1d90316-1bf4-11e6-8988-005056917c0c Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.7] (unknown [87.96.161.49]) by bin-vsp-out-04.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Tue, 17 May 2016 08:01:11 +0200 (CEST) To: Randall Gellens , slim@ietf.org References: <20160516083958.665a7a7059d7ee80bb4d670165c8327d.5e281af085.wbe@email0 3.godaddy.com> <7C5A334F88FD45E0A7770AFA6CB33C82@DougEwell> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <57289c9f-a63a-0466-eeb7-845f1f1421ae@omnitor.se> Date: Tue, 17 May 2016 08:01:03 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------7D1D960FB6BDEC5DA6A96907" Archived-At: Subject: Re: [Slim] Seeking rough consensus for draft-ietf-slim-negotiating-human-language 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, 17 May 2016 06:01:18 -0000 This is a multi-part message in MIME format. --------------7D1D960FB6BDEC5DA6A96907 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Randall, Can you accept that our goal is to select the most appropriate language(s) for the call? This includes providing guidance to the answering part so that the answer can be made in the most appropriate language(s). That is stated in the charter: "While the two use cases are in different contexts (real time and non-real-time), the fundamental goal is the same: to enable selection of the best-fit language(s) for a specific situation." It is not sufficient to use the indications to select which media shall be enabled, and then let the users sort out which language to use. The user needs guidance if it is most appropriate to start the conversation in voice, sign language or text or a combination of these modalities. If not, the call will start with confusion about what is the most efficient means for them to communicate. That is why the preference indication needs to have: a) a common scope over all media, and b) an indication if two modalities simultaneously are desired for reception. Can we agree on that and move on to find a simple way of expressing these needs? /Gunnar Den 2016-05-17 kl. 05:25, skrev Randall Gellens: > At 8:28 PM -0600 5/16/16, Doug Ewell wrote: > >> Except that there is still disagreement on whether the mechanism is >> needed for SLIM 1.0. > > And we have a call for consensus by the chairs. > -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 --------------7D1D960FB6BDEC5DA6A96907 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Randall,

Can you accept that our goal is to select the most appropriate language(s) for the call?

This includes providing guidance to the answering part so that the answer can be made in the most appropriate language(s).

That is stated in the charter:

"While the two use cases are in different contexts (real time and
non-real-time), the fundamental goal is the same: to enable selection of
the best-fit language(s) for a specific situation. "

It is not sufficient to use the indications to select which media shall be enabled, and then let the users sort out which language to use.

The user needs guidance if it is most appropriate to start the conversation in voice, sign language or text or a combination of these modalities. If not, the call will start with confusion about what is the most efficient means for them to communicate.

That is why the preference indication needs to have:

a) a common scope over all media, and

b) an indication if two modalities simultaneously are desired for reception.

Can we agree on that and move on to find a simple way of expressing these needs?

/Gunnar




Den 2016-05-17 kl. 05:25, skrev Randall Gellens:
At 8:28 PM -0600 5/16/16, Doug Ewell wrote:

 Except that there is still disagreement on whether the mechanism is needed for SLIM 1.0.

And we have a call for consensus by the chairs. 


-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288
--------------7D1D960FB6BDEC5DA6A96907-- From nobody Mon May 16 23:15:57 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 920E112B02B for ; Mon, 16 May 2016 23:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 ecrMh7w7i3ex for ; Mon, 16 May 2016 23:15:53 -0700 (PDT) Received: from bin-vsp-out-04.atm.binero.net (bin-mail-out-06.binero.net [195.74.38.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E369412D51E for ; Mon, 16 May 2016 23:15:52 -0700 (PDT) X-Halon-ID: cd71dccb-1bf6-11e6-8988-005056917c0c Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.7] (unknown [87.96.161.49]) by bin-vsp-out-04.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Tue, 17 May 2016 08:15:50 +0200 (CEST) To: Doug Ewell , slim@ietf.org References: <20160516083958.665a7a7059d7ee80bb4d670165c8327d.5e281af085.wbe@email03.godaddy.com> <7C5A334F88FD45E0A7770AFA6CB33C82@DougEwell> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <2b42d3d1-4648-7a69-a6b5-f4ca3ab61501@omnitor.se> Date: Tue, 17 May 2016 08:15:42 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <7C5A334F88FD45E0A7770AFA6CB33C82@DougEwell> Content-Type: multipart/alternative; boundary="------------6A61970ACD98E3A452A45F53" Archived-At: Subject: Re: [Slim] Seeking rough consensus for draft-ietf-slim-negotiating-human-language 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, 17 May 2016 06:15:55 -0000 This is a multi-part message in MIME format. --------------6A61970ACD98E3A452A45F53 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Den 2016-05-17 kl. 04:28, skrev Doug Ewell: > Gunnar Hellström wrote: > >> But you are right anyway. We do not want to control in detail what the >> other media than the one(s) used for the main dialogue are used for. >> So the proposal example just uses zxx as a placeholder to move english >> text to a lower preference than American Sign Language. > > Which is not correct, you see. The protocol should not use a "no > linguistic content" tag for text when there is no text content at all > in the initial modality/language combination. > > Direction Priority Video Text > --------- -------- ----- ---- > Send 1 ase zxx > > means "the user prefers to sign in American Sign Language while > simultaneously typing non-linguistic text, such as gibberish." I don't > think that is what is intended. No, it means my highest preference is to use video with american sign language and have text available for items such as phone numbers, dates, web urls, email-addresses etc that is more rapid and reliable to type than to sign ( or say ). However, that difference is not essential for our discussion. The mere existence of the text media description in sdp is sufficient to express that I want to establish text media. > >> It should be possible to specify and agree on a notation for >> preference that meet our needs. > > Except that there is still disagreement on whether the mechanism is > needed for SLIM 1.0. > > -- > Doug Ewell | http://ewellic.org | Thornton, CO 🇺🇸 > /Gunnar -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 --------------6A61970ACD98E3A452A45F53 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Den 2016-05-17 kl. 04:28, skrev Doug Ewell:
Gunnar Hellström wrote:

But you are right anyway. We do not want to control in detail what the
other media than the one(s) used for the main dialogue are used for.
So the proposal example just uses zxx as a placeholder to move english
text to a lower preference than American Sign Language.

Which is not correct, you see. The protocol should not use a "no linguistic content" tag for text when there is no text content at all in the initial modality/language combination.

Direction   Priority   Video   Text
---------   --------   -----   ----
 Send         1        ase    zxx

means "the user prefers to sign in American Sign Language while simultaneously typing non-linguistic text, such as gibberish." I don't think that is what is intended.
No, it means my highest preference is to use video with american sign language and have text available for items such as phone numbers, dates, web urls, email-addresses etc that is more rapid and reliable to type than to sign ( or say ).

However, that difference is not essential for our discussion. The mere existence of the text media description in sdp is sufficient to express that I want to establish text media. 

It should be possible to specify and agree on a notation for
preference that meet our needs.

Except that there is still disagreement on whether the mechanism is needed for SLIM 1.0.

--
Doug Ewell | http://ewellic.org | Thornton, CO 🇺🇸

/Gunnar
-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288
--------------6A61970ACD98E3A452A45F53-- From nobody Tue May 17 07:56:29 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 B0C1312D6D9 for ; Tue, 17 May 2016 07:56:27 -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 1w8HrWljaast for ; Tue, 17 May 2016 07:56:23 -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 3083812D6DA for ; Tue, 17 May 2016 07:56:23 -0700 (PDT) Received: from localhost ([72.167.218.130]) by p3plwbeout03-05.prod.phx3.secureserver.net with bizsmtp id vSwN1s0032pPkNY01SwNK2; Tue, 17 May 2016 07:56:22 -0700 X-SID: vSwN1s0032pPkNY01 Received: (qmail 17393 invoked by uid 99); 17 May 2016 14:56:22 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 208.51.143.189 User-Agent: Workspace Webmail 6.2.9 Message-Id: <20160517075621.665a7a7059d7ee80bb4d670165c8327d.973fb56d26.wbe@email03.godaddy.com> From: "Doug Ewell" To: "=?UTF-8?Q?Gunnar=5FHellstr=C3=B6m?=" , slim@ietf.org Date: Tue, 17 May 2016 07:56:21 -0700 Mime-Version: 1.0 Archived-At: Subject: Re: [Slim] Seeking rough consensus for draft-ietf-slim-negotiating-human-language 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, 17 May 2016 14:56:28 -0000 Gunnar Hellstr=C3=B6m wrote:=0A=0A>> means "the user prefers to sign in Ame= rican Sign Language while=0A>> simultaneously typing non-linguistic text, s= uch as gibberish." I=0A>> don't think that is what is intended.=0A>=0A> No,= it means my highest preference is to use video with american sign=0A> lang= uage and have text available for items such as phone numbers,=0A> dates, we= b urls, email-addresses etc that is more rapid and reliable=0A> to type tha= n to sign ( or say ).=0A=0AOh, well, you hadn't said that before. If you re= ally are specifying that=0Ayou want a text channel to send non-linguistic c= ontent, then yes, the=0Aline with "zxx" is appropriate. If you are using it= as a placeholder to=0Ahelp implement a 2-dimensional priorities matrix in = one dimension, then=0Ait is not appropriate.=0A=0A> However, that differenc= e is not essential for our discussion. The mere=0A> existence of the text m= edia description in sdp is sufficient to=0A> express that I want to establi= sh text media. =0A=0AOK, but remember that the use of 'zxx' by itself does= n't change anything=0Aabout the way priorities are expressed. If you had in= stead sent:=0A=0Am=3Dtext ... =0Aa=3Dhumintlang-send:bsk=0A=0Aand then used= the "text in Burushaski" stream to send phone numbers and=0Adates, the res= ult would be exactly the same.=0A=0A--=0ADoug Ewell | http://ewellic.org | = Thornton, CO =F0=9F=87=BA=F0=9F=87=B8=0A From nobody Tue May 17 09:05:53 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 8308E12D1D2 for ; Tue, 17 May 2016 09:05:52 -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 ilzOvK9Yy8Er for ; Tue, 17 May 2016 09:05:50 -0700 (PDT) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 424BB12D1C1 for ; Tue, 17 May 2016 09:05:50 -0700 (PDT) Received: by mail-qg0-x231.google.com with SMTP id f74so10647385qge.2 for ; Tue, 17 May 2016 09:05:50 -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=bOyGyR96POEe9LfFTzYfZW53abrH8coffoHqx+xtkGo=; b=PK/y9/AQlFk1qnyLqso2Ly9XF/sgWYpGq9HiW293Dsm4+Mu0R6UStvPWFCBDtPefTa /d5txovxXv7HVmJ3+w+Q+McFPus1koDFHb2WFn8MBg583o1/51hDz9iqqI0x84aAAqSE 2GhZUbezgLJUMlUmKQTTWA4rgXyhDKtPq7GOCIRB6AaXxSuGlQtOmYIE/ZvThkZfFHfT U1SUYC8DbnZ/Tt85T8d+VNGRJq1bhlNcV6K6IYwy9p8G+yCqcxyeVQ/Fo5NpSoqjkQTD 5eJzBPqc3nKTDic4n6CtyvJ9IfB2MpHWrbtUglbGilVN8PLbP6gBl7VHsoj//mYbPdVW HbjQ== 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=bOyGyR96POEe9LfFTzYfZW53abrH8coffoHqx+xtkGo=; b=QUU08gFWlnTUQOSmc/rmwj6QHJBE5XuktaVV30T7S5JYV5ZJEsjXfhoIHCGg0L1qc/ zuehQUEkoPB0dvL94G6lflwJiesp7nwxQgnpoJWM8UVxOPEFLNLUGv4G4FiqoJLe5nHb nbvzvRxV9j3FuYtYmKIlvIjAQt3VJ+lizSOpm62X5uSvnHahM2XAdXrY73WmK57xSCCO jT80CfKphuq6KKYlNld8Ce1IWvKOZu16JyZUMpsoex4zw2IIMXIQLESzOTry4O86wrye /k7mwSb5U948D/JYl1BgFYvhRFr9/dIY9P27KPxxoExF0kQs2k6hQYVjlto6WaYuW+lB Ukhw== X-Gm-Message-State: AOPr4FWnSlWqGDY0HdHdT79xeem6yBsgFnnam4tdsJ/1kIAmv3bphaB+8ZH88+x7xoSusQ== X-Received: by 10.140.104.146 with SMTP id a18mr2445482qgf.26.1463501149320; Tue, 17 May 2016 09:05:49 -0700 (PDT) Received: from [10.33.192.30] ([156.154.81.54]) by smtp.gmail.com with ESMTPSA id 39sm1647342qgg.8.2016.05.17.09.05.48 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 17 May 2016 09:05:48 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_264984E6-049A-449D-9419-CA34B69CF868" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Brian Rosen In-Reply-To: <57289c9f-a63a-0466-eeb7-845f1f1421ae@omnitor.se> Date: Tue, 17 May 2016 12:05:46 -0400 Message-Id: References: <20160516083958.665a7a7059d7ee80bb4d670165c8327d.5e281af085.wbe@email0 3.godaddy.com> <7C5A334F88FD45E0A7770AFA6CB33C82@DougEwell> <57289c9f-a63a-0466-eeb7-845f1f1421ae@omnitor.se> To: =?utf-8?Q?Gunnar_Hellstr=C3=B6m?= X-Mailer: Apple Mail (2.3124) Archived-At: Cc: slim@ietf.org, Randall Gellens Subject: Re: [Slim] Seeking rough consensus for draft-ietf-slim-negotiating-human-language 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, 17 May 2016 16:05:52 -0000 --Apple-Mail=_264984E6-049A-449D-9419-CA34B69CF868 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Like Randall, I want to stay away from a linkage between what languages = you prefer and what media you are offering. I want to stay with the long standing SDP negotiation that you offer = media you want to use, and and or all of that media can be accepted. I want our work to build on that, not change it, so that we can = indicate, for the media accepted, what language is preferred. =20 I further don=92t want to link a preference of language on one media to = the preference of language on another media. I want them independent: = if audio and text are offered and answered, then language on audio is = specified, and language on text is specified, and those don=92t = interact. I think living with those restrictions will make implementations easier, = and won=92t limit use much.=20 Adding more complexity at this point is, I think, not worth it. Brian > On May 17, 2016, at 2:01 AM, Gunnar Hellstr=F6m = wrote: >=20 > Randall,=20 > Can you accept that our goal is to select the most appropriate = language(s) for the call? >=20 > This includes providing guidance to the answering part so that the = answer can be made in the most appropriate language(s). >=20 > That is stated in the charter: >=20 > "While the two use cases are in different contexts (real time and > non-real-time), the fundamental goal is the same: to enable selection = of > the best-fit language(s) for a specific situation. " >=20 > It is not sufficient to use the indications to select which media = shall be enabled, and then let the users sort out which language to use.=20= >=20 > The user needs guidance if it is most appropriate to start the = conversation in voice, sign language or text or a combination of these = modalities. If not, the call will start with confusion about what is the = most efficient means for them to communicate.=20 >=20 > That is why the preference indication needs to have: >=20 > a) a common scope over all media, and=20 >=20 > b) an indication if two modalities simultaneously are desired for = reception. >=20 > Can we agree on that and move on to find a simple way of expressing = these needs? >=20 > /Gunnar >=20 >=20 >=20 >=20 >=20 >=20 > Den 2016-05-17 kl. 05:25, skrev Randall Gellens: >> At 8:28 PM -0600 5/16/16, Doug Ewell wrote:=20 >>=20 >>> Except that there is still disagreement on whether the mechanism is = needed for SLIM 1.0.=20 >>=20 >> And we have a call for consensus by the chairs.=20 >>=20 >=20 > --=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 --Apple-Mail=_264984E6-049A-449D-9419-CA34B69CF868 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Like Randall, I want to stay away from a linkage between what = languages you prefer and what media you are offering.

I want to stay with the long standing = SDP negotiation that you offer media you want to use, and and or all of = that media can be accepted.

I want our work to build on that, not change it, so that we = can indicate, for the media accepted, what language is preferred. =  

I = further don=92t want to link a preference of language on one media to = the preference of language on another media.   I want them = independent: if audio and text are offered and answered, then language = on audio is specified, and language on text is specified, and those = don=92t interact.

I think living with those restrictions will make = implementations easier, and won=92t limit use much. 

Adding more complexity = at this point is, I think, not worth it.

Brian

On May 17, 2016, at 2:01 AM, Gunnar Hellstr=F6m= <gunnar.hellstrom@omnitor.se> wrote:

=20 =20

Randall,

Can you accept that our goal is to select the most = appropriate language(s) for the call?

This includes providing = guidance to the answering part so that the answer can be made in the most appropriate language(s).

That is stated in the charter:

"While the two use cases are in different contexts (real time and
non-real-time), the fundamental goal is the same: to enable selection = of
the= best-fit language(s) for a specific situation. "

It is not sufficient to = use the indications to select which media shall be enabled, and then let the users sort out which language to use.

The user needs guidance = if it is most appropriate to start the conversation in voice, sign language or text or a combination of these modalities. If not, the call will start with confusion about what is the most efficient means for them to communicate.

That is why the = preference indication needs to have:

a) a common scope over = all media, and

b) an indication if two modalities simultaneously are desired for = reception.

Can we agree on that = and move on to find a simple way of expressing these = needs?

/Gunnar




Den 2016-05-17 kl. 05:25, skrev = Randall Gellens:
At 8:28 PM -0600 5/16/16, Doug Ewell wrote:

 Except that there is = still disagreement on whether the mechanism is needed for SLIM 1.0.

And we have a call for consensus by the chairs. 


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

= --Apple-Mail=_264984E6-049A-449D-9419-CA34B69CF868-- From nobody Tue May 17 14:18: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 0BFB312D979 for ; Tue, 17 May 2016 14:18:00 -0700 (PDT) X-Quarantine-ID: <1PBaEXL4VTbP> 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: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 1PBaEXL4VTbP for ; Tue, 17 May 2016 14:17:58 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 6E90012D188 for ; Tue, 17 May 2016 14:17:58 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Tue, 17 May 2016 14:17:57 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <57289c9f-a63a-0466-eeb7-845f1f1421ae@omnitor.se> References: <20160516083958.665a7a7059d7ee80bb4d670165c8327d.5e281af085.wbe@email0 3.godaddy.com> <7C5A334F88FD45E0A7770AFA6CB33C82@DougEwell> <57289c9f-a63a-0466-eeb7-845f1f1421ae@omnitor.se> X-Mailer: Eudora for Mac OS X Date: Tue, 17 May 2016 14:17:53 -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] Seeking rough consensus for draft-ietf-slim-negotiating-human-language 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, 17 May 2016 21:18:00 -0000 Gunnar, I think we can start with what we have now: the=20 offerer offers all media/languages it wants, and=20 the answerer accepts those it supports. In many=20 cases this will be exactly what's desired, while=20 in some cases there will be extra media that are=20 not used. This gives us something simple that has the best=20 chance of rapid and wide deployment. We can then=20 build on this if need be. At 8:01 AM +0200 5/17/16, Gunnar Hellstr=F6m wrote: > Randall, > > Can you accept that our goal is to select the=20 > most appropriate language(s) for the call? > > This includes providing guidance to the=20 > answering part so that the answer can be made=20 > in the most appropriate language(s). > > That is stated in the charter: > > "While the two use cases are in different contexts (real time and > non-real-time), the fundamental goal is the same: to enable selection of > the best-fit language(s) for a specific situation. " > > It is not sufficient to use the indications to=20 > select which media shall be enabled, and then=20 > let the users sort out which language to use. > > The user needs guidance if it is most=20 > appropriate to start the conversation in voice,=20 > sign language or text or a combination of these=20 > modalities. If not, the call will start with=20 > confusion about what is the most efficient=20 > means for them to communicate. > > That is why the preference indication needs to have: > > a) a common scope over all media, and > > b) an indication if two modalities simultaneously are desired for recepti= on. > > Can we agree on that and move on to find a=20 > simple way of expressing these needs? > > /Gunnar > > > > > Den 2016-05-17 kl. 05:25, skrev Randall Gellens: > >> At 8:28 PM -0600 5/16/16, Doug Ewell wrote: >> >>> Except that there is still disagreement on=20 >>> whether the mechanism is needed for SLIM 1.0. >>> >> >> And we have a call for consensus by the chairs. >> > > -- > ----------------------------------------- > 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 people don't know what you're doing, they don't know what you're doing wrong. --Sir Arnold Robinson, _Yes,_Minister_ From nobody Tue May 17 14:56: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 486E212D643 for ; Tue, 17 May 2016 14:56:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 PCjUAOirxEVe for ; Tue, 17 May 2016 14:56:21 -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 2D8D212DA43 for ; Tue, 17 May 2016 14:56:21 -0700 (PDT) X-Halon-ID: 2a7b79b6-1c7a-11e6-81fe-0050569116f7 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.177] (unknown [87.96.161.49]) by bin-vsp-out-03.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Tue, 17 May 2016 23:56:10 +0200 (CEST) To: Randall Gellens , slim@ietf.org References: <20160516083958.665a7a7059d7ee80bb4d670165c8327d.5e281af085.wbe@email0 3.godaddy.com> <7C5A334F88FD45E0A7770AFA6CB33C82@DougEwell> <57289c9f-a63a-0466-eeb7-845f1f1421ae@omnitor.se> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <363ab6da-abdb-357b-e942-5284b085d451@omnitor.se> Date: Tue, 17 May 2016 23:56:07 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------8BAB0F6EDCAB72D54C33DDB5" Archived-At: Subject: Re: [Slim] Seeking rough consensus for draft-ietf-slim-negotiating-human-language 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, 17 May 2016 21:56:25 -0000 This is a multi-part message in MIME format. --------------8BAB0F6EDCAB72D54C33DDB5 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Den 2016-05-17 kl. 23:17, skrev Randall Gellens: > Gunnar, > > I think we can start with what we have now: the offerer offers all > media/languages it wants, and the answerer accepts those it supports. Yes, but we need a bit more than we have today to express that. Language usage are logically linked. > In many cases this will be exactly what's desired, while in some cases > there will be extra media that are not used. I am not bothered about extra media. Offered media shall not be rejected just because they do not have agreed language contents. > > This gives us something simple that has the best chance of rapid and > wide deployment. We can then build on this if need be. We already have the need. 3GPP cannot use user profiles in emergency registration mode, so we need to be able to express user needs this way to the degree that they can be served well in emergency calls. For that we need to clarify language in some places in the draft so that we do not end up equally fuzzy as RFC 4566, We need to delete our interpretation of RFC 4566, we need to express preference with scope among all media. and we need to express when languages are needed together and when they are to select from. You have accepted some edit proposals that we have discussed and modified others to something that we have not yet seen. I would like to see the draft as it is now so that we can see what more needs to be changed. > > > At 8:01 AM +0200 5/17/16, Gunnar Hellström wrote: > >> Randall, >> >> Can you accept that our goal is to select the most appropriate >> language(s) for the call? >> >> This includes providing guidance to the answering part so that the >> answer can be made in the most appropriate language(s). >> >> That is stated in the charter: >> >> "While the two use cases are in different contexts (real time and >> non-real-time), the fundamental goal is the same: to enable >> selection of >> the best-fit language(s) for a specific situation. " >> >> It is not sufficient to use the indications to select which media >> shall be enabled, and then let the users sort out which language to use. >> >> The user needs guidance if it is most appropriate to start the >> conversation in voice, sign language or text or a combination of >> these modalities. If not, the call will start with confusion about >> what is the most efficient means for them to communicate. >> >> That is why the preference indication needs to have: >> >> a) a common scope over all media, and >> >> b) an indication if two modalities simultaneously are desired for >> reception. >> >> Can we agree on that and move on to find a simple way of expressing >> these needs? >> >> /Gunnar >> >> >> >> >> Den 2016-05-17 kl. 05:25, skrev Randall Gellens: >> >>> At 8:28 PM -0600 5/16/16, Doug Ewell wrote: >>> >>>> Except that there is still disagreement on whether the mechanism >>>> is needed for SLIM 1.0. >>>> >>> >>> And we have a call for consensus by the chairs. >>> >> >> -- >> ----------------------------------------- >> 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 --------------8BAB0F6EDCAB72D54C33DDB5 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Den 2016-05-17 kl. 23:17, skrev Randall Gellens:

Gunnar,

I think we can start with what we have now: the offerer offers all media/languages it wants, and the answerer accepts those it supports.
Yes, but we need a bit more than we have today to express that. Language usage are logically linked.
In many cases this will be exactly what's desired, while in some cases there will be extra media that are not used.
I am not bothered about extra media. Offered media shall not be rejected just because they do not have agreed language contents.

This gives us something simple that has the best chance of rapid and wide deployment.  We can then build on this if need be.
We already have the need. 3GPP cannot use user profiles in emergency registration mode, so we need to be able to express user needs this way to the degree that they can be served well in emergency calls.
For that we need to
clarify language in some places in the draft so that we do not end up equally fuzzy as RFC 4566,
We need to delete our interpretation of RFC 4566,
we need to express preference with scope among all media.
and we need to express when languages are needed together and when they are to select from.

You have accepted some edit proposals that we have discussed and modified others to something that we have not  yet seen. I would like to see the draft as it is now so that we can see what more needs to be changed.  



At 8:01 AM +0200 5/17/16, Gunnar Hellström wrote:

 Randall,

 Can you accept that our goal is to select the most appropriate language(s) for the call?

 This includes providing guidance to the answering part so that the answer can be made in the most appropriate language(s).

 That is stated in the charter:

 "While the two use cases are in different contexts (real time and
 non-real-time), the fundamental goal is the same: to enable selection of
 the best-fit language(s) for a specific situation. "

 It is not sufficient to use the indications to select which media shall be enabled, and then let the users sort out which language to use.

 The user needs guidance if it is most appropriate to start the conversation in voice, sign language or text or a combination of these modalities. If not, the call will start with confusion about what is the most efficient means for them to communicate.

 That is why the preference indication needs to have:

 a) a common scope over all media, and

 b) an indication if two modalities simultaneously are desired for reception.

 Can we agree on that and move on to find a simple way of expressing these needs?

 /Gunnar




 Den 2016-05-17 kl. 05:25, skrev Randall Gellens:

 At 8:28 PM -0600 5/16/16, Doug Ewell wrote:

 Except that there is still disagreement on whether the mechanism is needed for SLIM 1.0.


 And we have a call for consensus by the chairs.


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

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



-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288
--------------8BAB0F6EDCAB72D54C33DDB5-- From nobody Wed May 18 10:08:55 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 CCD4812D5DB for ; Wed, 18 May 2016 10:08:51 -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_MSPIKE_H3=-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 fUkDzN130DFB for ; Wed, 18 May 2016 10:08:48 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-eopbgr20083.outbound.protection.outlook.com [40.107.2.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B568812D567 for ; Wed, 18 May 2016 10:08:46 -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=1BZw9gTvq0M7Gz3wY5LX5b4UOmhNoun3ABtpmI45w88=; b=tSlD0iNu+Rrx4yS569TOC8nfS+kv+5X36UaLqaK1z7w/ddM0PWgAh9IDv85cYPZGzsW/Os8h7VDVRl1rG727REGoL8r4DIahNIti6SjCViQCcbCrtyeqscAclxEr9QuQ/gBmX+8Y/PFNvOLqL5xoQjc7Syctu6ghFh8inbdZXqM= Received: from VI1PR0401MB2064.eurprd04.prod.outlook.com (10.166.141.138) by VI1PR0401MB2064.eurprd04.prod.outlook.com (10.166.141.138) with Microsoft SMTP Server (TLS) id 15.1.497.12; Wed, 18 May 2016 17:08:43 +0000 Received: from VI1PR0401MB2064.eurprd04.prod.outlook.com ([10.166.141.138]) by VI1PR0401MB2064.eurprd04.prod.outlook.com ([10.166.141.138]) with mapi id 15.01.0497.019; Wed, 18 May 2016 17:08:43 +0000 From: Natasha Rooney To: =?Windows-1252?Q?Gunnar_Hellstr=F6m?= , Randall Gellens , "slim@ietf.org" , "bernard.aboba@gmail.com" Thread-Topic: [Slim] Seeking rough consensus for draft-ietf-slim-negotiating-human-language Thread-Index: AQHRr4kz1+epbDnkpUuj97b5MbxoPJ+8AxCAgABldoCAABAJgIAAK1uAgAEAKYCAAAqugIABQgcA Date: Wed, 18 May 2016 17:08:43 +0000 Message-ID: References: <20160516083958.665a7a7059d7ee80bb4d670165c8327d.5e281af085.wbe@email0 3.godaddy.com> <7C5A334F88FD45E0A7770AFA6CB33C82@DougEwell> <57289c9f-a63a-0466-eeb7-845f1f1421ae@omnitor.se> <363ab6da-abdb-357b-e942-5284b085d451@omnitor.se> In-Reply-To: <363ab6da-abdb-357b-e942-5284b085d451@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: 76f7ec37-c614-406c-a306-08d37f3f1125 x-microsoft-exchange-diagnostics: 1; VI1PR0401MB2064; 5:SbmF593xyXGs74hQxEIApGAG/KxtXzZC0ADrXrNBHb+QJe0uHxuwnzrFH62JdU1B7XS3cGPFL4FnBOqzqdA8iUyoBTJG36OqVZnqCjKqC0Nvmj0O1Qd/kGxRO8gw3xRGda5b4MmCJIJRlYGqscwoKQ==; 24:UR3JXw1B5EjhNZfx/EJmuz40QZdZNViRvIYKB6BicIC9Tno7TqDNNvFfU8C7V+GkLdEG2ilqV4THDvKIf2yIcj87Uiifhk8XM2J5lU8I5OE=; 7:lQ/4RpvUUSD4cC2LSiWhVt7NpCgt0zbbsUsGfJyeSl0Ba7qSDbOKZl/sOhQLgrcEBR57UKUPwym5MSP56OtVJ5f1ru7vIZ0PvMog83rSdcb7s8GQK6auN7ZwYGyrJrDS3I3Z7Yi9iMXbvuZOMHApEjGA1TMXLgZtI/SWTIRklQpWhKIsrb/Di9UcHgDSRzuQ x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR0401MB2064; 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)(3002001)(10201501046); SRVR:VI1PR0401MB2064; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0401MB2064; x-forefront-prvs: 0946DC87A1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(377454003)(377424004)(24454002)(57306001)(82746002)(66066001)(83716003)(8936002)(33656002)(106116001)(189998001)(10400500002)(122556002)(8676002)(5008740100001)(3660700001)(5002640100001)(81166006)(5001770100001)(3280700002)(76176999)(50986999)(15975445007)(77096005)(2900100001)(1220700001)(230783001)(11100500001)(2950100001)(87936001)(36756003)(2906002)(4326007)(50226002)(92566002)(2501003)(5890100001)(5004730100002)(19617315012)(586003)(16236675004)(86362001)(6116002)(19580405001)(102836003)(19580395003)(93886004)(7059030)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0401MB2064; H:VI1PR0401MB2064.eurprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_EB30D922E638427EAFCECF3782AC579Fgsmacom_" MIME-Version: 1.0 X-OriginatorOrg: gsma.com X-MS-Exchange-CrossTenant-originalarrivaltime: 18 May 2016 17:08:43.5155 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72a4ff82-fec3-469d-aafb-ac8276216699 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0401MB2064 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: VI1PR0401MB2064.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: VI1PR0401MB2064.eurprd04.prod.outlook.com Archived-At: Cc: Alexey Melnikov Subject: Re: [Slim] Seeking rough consensus for draft-ietf-slim-negotiating-human-language 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, 18 May 2016 17:08:52 -0000 --_000_EB30D922E638427EAFCECF3782AC579Fgsmacom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Randall - the last edit we see of the doc is from March, is this the most r= ecent one? If not can you submit an edit soon? All - In all our discussions I see two things that we want here: [1] we wan= t a simple and easily implementable solution/s and [2] solution/s that cove= r all the use cases. I think we can agree that going ahead with a simple so= lutions which is extensible covers both of these needs. It allows us to get= something out there which can be implemented, and it allows us to answer a= ll the use cases with extensibility which we will work on next (I appreciat= e this isn=92t immediate but it=92s favourable to making a complex solution= now which is too difficult to implement). All advice I have received on th= is has suggested this is the best route forward. Given we=92re well over the time that we should have agreed on this I sugge= st we call rough consensus for this here. I understand there may be some fr= ustration, but really this method solves for both needs and so is sensible. Bernard and Alexey - please check this and input if you see fit! 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 May 17, 2016, at 10:56 PM, Gunnar Hellstr=F6m > wrote: Den 2016-05-17 kl. 23:17, skrev Randall Gellens: Gunnar, I think we can start with what we have now: the offerer offers all media/la= nguages it wants, and the answerer accepts those it supports. Yes, but we need a bit more than we have today to express that. Language us= age are logically linked. In many cases this will be exactly what's desired, while in some cases ther= e will be extra media that are not used. I am not bothered about extra media. Offered media shall not be rejected ju= st because they do not have agreed language contents. This gives us something simple that has the best chance of rapid and wide d= eployment. We can then build on this if need be. We already have the need. 3GPP cannot use user profiles in emergency regist= ration mode, so we need to be able to express user needs this way to the de= gree that they can be served well in emergency calls. For that we need to clarify language in some places in the draft so that we do not end up equal= ly fuzzy as RFC 4566, We need to delete our interpretation of RFC 4566, we need to express preference with scope among all media. and we need to express when languages are needed together and when they are= to select from. You have accepted some edit proposals that we have discussed and modified o= thers to something that we have not yet seen. I would like to see the draf= t as it is now so that we can see what more needs to be changed. At 8:01 AM +0200 5/17/16, Gunnar Hellstr=F6m wrote: Randall, Can you accept that our goal is to select the most appropriate language(s)= for the call? This includes providing guidance to the answering part so that the answer = can be made in the most appropriate language(s). That is stated in the charter: "While the two use cases are in different contexts (real time and non-real-time), the fundamental goal is the same: to enable selection of the best-fit language(s) for a specific situation. " It is not sufficient to use the indications to select which media shall be= enabled, and then let the users sort out which language to use. The user needs guidance if it is most appropriate to start the conversatio= n in voice, sign language or text or a combination of these modalities. If = not, the call will start with confusion about what is the most efficient me= ans for them to communicate. That is why the preference indication needs to have: a) a common scope over all media, and b) an indication if two modalities simultaneously are desired for receptio= n. Can we agree on that and move on to find a simple way of expressing these = needs? /Gunnar Den 2016-05-17 kl. 05:25, skrev Randall Gellens: At 8:28 PM -0600 5/16/16, Doug Ewell wrote: Except that there is still disagreement on whether the mechanism is needed= for SLIM 1.0. And we have a call for consensus by the chairs. -- ----------------------------------------- Gunnar Hellstr=F6m Omnitor gu= nnar.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_EB30D922E638427EAFCECF3782AC579Fgsmacom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <9EC92EAD0D131E40A0F59F6FCDEF86F9@eurprd04.prod.outlook.com> Content-Transfer-Encoding: quoted-printable Randall - the last edit we see of the doc is from March, is this the most r= ecent one? If not can you submit an edit soon?

All - In all our discussions I see two things that we want here: [1] we wan= t a simple and easily implementable solution/s and [2] solution/s that cove= r all the use cases. I think we can agree that going ahead with a simple so= lutions which is extensible covers both of these needs. It allows us to get something out there which can be = implemented, and it allows us to answer all the use cases with extensibilit= y which we will work on next (I appreciate this isn=92t immediate but it=92= s favourable to making a complex solution now which is too difficult to implement). All advice I have received on th= is has suggested this is the best route forward.

Given we=92re well over the time that we should have agreed on this I sugge= st we call rough consensus for this here. I understand there may be some fr= ustration, but really this method solves for both needs and so is sensible.=

Bernard and Alexey - please check this and input if you see fit!

Natasha


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


On May 17, 2016, at 10:56 PM, Gunnar Hellstr=F6m <gunnar.hellstrom@omnito= r.se> wrote:

Den 2016-05-17 kl. 23:17, skrev Randall Gellens:

Gunnar,

I think we can start with what we have now: the offerer offers all media/la= nguages it wants, and the answerer accepts those it supports.
Yes, but we need a bit more than we have today to express that. Language us= age are logically linked.
In many cases this will be exactly what's desired, while in some cases ther= e will be extra media that are not used.
I am not bothered about extra media. Offered media shall not be rejected ju= st because they do not have agreed language contents.

This gives us something simple that has the best chance of rapid and wide d= eployment.  We can then build on this if need be.
We already have the need. 3GPP cannot use user profiles in emergency regist= ration mode, so we need to be able to express user needs this way to the de= gree that they can be served well in emergency calls.
For that we need to
clarify language in some places in the draft so that we do not end up equal= ly fuzzy as RFC 4566,
We need to delete our interpretation of RFC 4566,
we need to express preference with scope among all media.
and we need to express when languages are needed together and when they are= to select from.

You have accepted some edit proposals that we have discussed and modified o= thers to something that we have not  yet seen. I would like to see the= draft as it is now so that we can see what more needs to be changed.  = ;



At 8:01 AM +0200 5/17/16, Gunnar Hellstr=F6m wrote:

 Randall,

 Can you accept that our goal is to select the most appropriate langua= ge(s) for the call?

 This includes providing guidance to the answering part so that the an= swer can be made in the most appropriate language(s).

 That is stated in the charter:

 "While the two use cases are in different contexts (real time an= d
 non-real-time), the fundamental goal is the same: to enable selection= of
 the best-fit language(s) for a specific situation. "

 It is not sufficient to use the indications to select which media sha= ll be enabled, and then let the users sort out which language to use.

 The user needs guidance if it is most appropriate to start the conver= sation in voice, sign language or text or a combination of these modalities= . If not, the call will start with confusion about what is the most efficie= nt means for them to communicate.

 That is why the preference indication needs to have:

 a) a common scope over all media, and

 b) an indication if two modalities simultaneously are desired for rec= eption.

 Can we agree on that and move on to find a simple way of expressing t= hese needs?

 /Gunnar




 Den 2016-05-17 kl. 05:25, skrev Randall Gellens:

 At 8:28 PM -0600 5/16/16, Doug E= well wrote:

 Except that there is still disag= reement on whether the mechanism is needed for SLIM 1.0.


 And we have a call for consensus by the chairs.


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

 _______________________________________________
 SLIM mailing list
 S= LIM@ietf.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_EB30D922E638427EAFCECF3782AC579Fgsmacom_-- From nobody Wed May 18 15:23:49 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 DAB5612D6CA for ; Wed, 18 May 2016 15:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 fJMgObLU_NpO for ; Wed, 18 May 2016 15:23:44 -0700 (PDT) Received: from bin-vsp-out-01.atm.binero.net (bin-mail-out-06.binero.net [195.74.38.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4615A12D119 for ; Wed, 18 May 2016 15:23:43 -0700 (PDT) X-Halon-ID: 2a8f6188-1d47-11e6-9293-005056917a89 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.15] (unknown [87.96.161.49]) by bin-vsp-out-01.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Thu, 19 May 2016 00:23:37 +0200 (CEST) To: Natasha Rooney , Randall Gellens , "slim@ietf.org" , "bernard.aboba@gmail.com" References: <20160516083958.665a7a7059d7ee80bb4d670165c8327d.5e281af085.wbe@email0 3.godaddy.com> <7C5A334F88FD45E0A7770AFA6CB33C82@DougEwell> <57289c9f-a63a-0466-eeb7-845f1f1421ae@omnitor.se> <363ab6da-abdb-357b-e942-5284b085d451@omnitor.se> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <405724e5-61aa-1144-6a2c-7c08fb599c98@omnitor.se> Date: Thu, 19 May 2016 00:23:29 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------617F10DE89B59668A3619BEA" Archived-At: Cc: Alexey Melnikov Subject: Re: [Slim] Seeking rough consensus for draft-ietf-slim-negotiating-human-language 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, 18 May 2016 22:23:48 -0000 This is a multi-part message in MIME format. --------------617F10DE89B59668A3619BEA Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Den 2016-05-18 kl. 19:08, skrev Natasha Rooney: > Randall - the last edit we see of the doc is from March, is this the > most recent one? If not can you submit an edit soon? We had e-mail list discussion around April 8-10 under the subject "[Slim] Wording about selection in draft-ietf-slim-negotiating-human-language-01" that ended with some agreed changes and some in-principle agreed changes but no agreed wording. That is what I refer to when I say I want to see what the latest edits ended up in. That mainly covered the ambition to be more exact than RFC 4566 lang specification. So, when we get that, we can judge: 1. If it is clear when the indications reflect a selection possibility or a combination requirement. There are a couple of other things we need to modify also before progressing to any kind of consensus. 2. In 5. Delete our interpretation of the lang attribute. It is sufficient to say that it is not enough detailed because it does not provide directionality. 3. In 5. insert specification on how lang and humintlang relates. The easiest way is to say that lang should not be used in sdp where humintlang is used. Is that too drastic? 4. Do we really need the * parameter for "do not fail call" introduced in 6.2 and explained in 6.3? It will be most common to want to have that effect, thus requiring to add the * in most media specifications. Can we simplify the syntax by having "do not fail call" as the default and delete the description of the * ? I suggest that we delete it. If not, the description of the syntax of how the * is included needs to be inserted in the syntax description in section 6.2 and an example added. 5. In this part of 6.2: "In cases where the user wishes to use one media for sending and another for receiving (such as a speech-impaired user who wishes to send using text and receive using audio), one of the two MAY be unset. In cases where a media is not primarily intended for language (for example, a video or audio stream intended for background only) both SHOULD be unset. In other cases, both SHOULD have the same values in the same order. The two SHOULD NOT be set to languages which are difficult to match together" Clarify that "two" and "both" refers to the humintlang-send and humintlang-recv attributes for a medium. ( the attribute names are too far back so when searching for what "two" and "both" refers to you end up in confusion). 6. And, yet another proposal to insert a simple indication for preference betweeen media, and one for distinguishing selection versus combination. The needs come from accessibility needs, and fulfilling accessibility needs has strong policy support, so it would be bad to say that that must wait for another version of the document when we already now have specified the need. --------------------------------------------------In 6.2 insert:---------------------------------------------------------------------- A single digit numeric value on a humintlang attribute represents a starting priority for the humintlang attributes of the same medium and direction, with one being the highest priority. If no such value is indicated, the value 1 is assumed. The priority value is increased by a value 0.1 for each humintlang attribute for the same media and direction. An asterisk on a humintlang attribute alone or together with a priority number indicates that a language specified in the actual media and direction is wanted in combination with another modality in the same direction, also marked with an asterisk. Examples: m=audio ... humintlang-send:en humintlang-recv:* humintlang-recv:en m=text ... humintlang-recv:* humintlang-recv:en This means that the user want to send spoken English and receive a combination of both spoken and typed English simultaneously back. m=video ... humintlang-send:ase humintlang-recv:ase m=text ... humintlang-send:5 humintlang-send:en humintlang-recv:5 humintlang-recv:en This means that the user prefers to use American sign language both ways, but as a possible selection on lower preference level use text both ways. ---------------------------------------------------------end of insertion--------------------- The fact that the humintlang attribute now can have values that are not language tags needs to be reflected in a few other places in the draft. > > All - In all our discussions I see two things that we want here: [1] > we want a simple and easily implementable solution/s and [2] > solution/s that cover all the use cases. I think we can agree that > going ahead with a simple solutions which is extensible covers both of > these needs. It allows us to get something out there which can be > implemented, and it allows us to answer all the use cases with > extensibility which we will work on next (I appreciate this isn’t > immediate but it’s favourable to making a complex solution now which > is too difficult to implement). All advice I have received on this has > suggested this is the best route forward. We can't wait with an extension for something we have a need for now. The above addition no 6. is a simple notation for what we were missing. > > Given we’re well over the time that we should have agreed on this I > suggest we call rough consensus for this here. I understand there may > be some frustration, but really this method solves for both needs and > so is sensible. > > Bernard and Alexey - please check this and input if you see fit! > > Natasha > /Gunnar > > Natasha Rooney | Technologist, Web and Internet, W3C & IETF | GSMA | > nrooney@gsma.com | +44 (0) 7730 219 765 | > @thisNatasha | Skype: nrooney@gsm.org > > >> On May 17, 2016, at 10:56 PM, Gunnar Hellström >> > wrote: >> >> Den 2016-05-17 kl. 23:17, skrev Randall Gellens: >> >>> Gunnar, >>> >>> I think we can start with what we have now: the offerer offers all >>> media/languages it wants, and the answerer accepts those it supports. >> Yes, but we need a bit more than we have today to express that. >> Language usage are logically linked. >>> In many cases this will be exactly what's desired, while in some >>> cases there will be extra media that are not used. >> I am not bothered about extra media. Offered media shall not be >> rejected just because they do not have agreed language contents. >>> >>> This gives us something simple that has the best chance of rapid and >>> wide deployment. We can then build on this if need be. >> We already have the need. 3GPP cannot use user profiles in emergency >> registration mode, so we need to be able to express user needs this >> way to the degree that they can be served well in emergency calls. >> For that we need to >> clarify language in some places in the draft so that we do not end up >> equally fuzzy as RFC 4566, >> We need to delete our interpretation of RFC 4566, >> we need to express preference with scope among all media. >> and we need to express when languages are needed together and when >> they are to select from. >> >> You have accepted some edit proposals that we have discussed and >> modified others to something that we have not yet seen. I would like >> to see the draft as it is now so that we can see what more needs to >> be changed. >> >>> >>> >>> At 8:01 AM +0200 5/17/16, Gunnar Hellström wrote: >>> >>>> Randall, >>>> >>>> Can you accept that our goal is to select the most appropriate >>>> language(s) for the call? >>>> >>>> This includes providing guidance to the answering part so that the >>>> answer can be made in the most appropriate language(s). >>>> >>>> That is stated in the charter: >>>> >>>> "While the two use cases are in different contexts (real time and >>>> non-real-time), the fundamental goal is the same: to enable >>>> selection of >>>> the best-fit language(s) for a specific situation. " >>>> >>>> It is not sufficient to use the indications to select which media >>>> shall be enabled, and then let the users sort out which language to >>>> use. >>>> >>>> The user needs guidance if it is most appropriate to start the >>>> conversation in voice, sign language or text or a combination of >>>> these modalities. If not, the call will start with confusion about >>>> what is the most efficient means for them to communicate. >>>> >>>> That is why the preference indication needs to have: >>>> >>>> a) a common scope over all media, and >>>> >>>> b) an indication if two modalities simultaneously are desired for >>>> reception. >>>> >>>> Can we agree on that and move on to find a simple way of >>>> expressing these needs? >>>> >>>> /Gunnar >>>> >>>> >>>> >>>> >>>> Den 2016-05-17 kl. 05:25, skrev Randall Gellens: >>>> >>>>> At 8:28 PM -0600 5/16/16, Doug Ewell wrote: >>>>> >>>>>> Except that there is still disagreement on whether the mechanism >>>>>> is needed for SLIM 1.0. >>>>>> >>>>> >>>>> And we have a call for consensus by the chairs. >>>>> >>>> >>>> -- >>>> ----------------------------------------- >>>> 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 > > This email and its attachments are intended for the above named only > and may be confidential. If they have come to you in error you must > take no action based on them, nor must you copy or show them to > anyone; please reply to this email or call +44 207 356 0600 and > highlight the error. > -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 --------------617F10DE89B59668A3619BEA Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit



Den 2016-05-18 kl. 19:08, skrev Natasha Rooney:
Randall - the last edit we see of the doc is from March, is this the most recent one? If not can you submit an edit soon?
We had e-mail list discussion around April 8-10 under the subject "[Slim] Wording about selection in draft-ietf-slim-negotiating-human-language-01"
that ended with some agreed changes and some in-principle agreed changes but no agreed wording. That is what I refer to when I say I want to see what the latest edits ended up in.

That mainly covered the ambition to be more exact than RFC 4566 lang specification.

So, when we get that, we can judge:
1. If it is clear when the indications reflect a selection possibility or a combination requirement.

There are a couple of other things we need to modify also before progressing to any kind of consensus.

2. In 5. Delete our interpretation of the lang attribute. It is sufficient to say that it is not enough detailed because it does not provide directionality.

3. In 5. insert specification on how lang and humintlang relates. The easiest way is to say that lang should not be used in sdp where humintlang is used. Is that too drastic?

4. Do we really need the * parameter for "do not fail call" introduced in 6.2 and explained in 6.3?  It will be most common to want to have that effect, thus requiring to add the * in most media specifications. Can we simplify the syntax by having "do not fail call" as the default and delete the description of the * ? I suggest that we delete it.
If not, the description of the syntax of how the * is included needs to be inserted in the syntax description in section 6.2 and an example added.

5. In this part of 6.2:
"In cases where the user
   wishes to use one media for sending and another for receiving (such
   as a speech-impaired user who wishes to send using text and receive
   using audio), one of the two MAY be unset.  In cases where a media is
   not primarily intended for language (for example, a video or audio
   stream intended for background only) both SHOULD be unset.  In other
   cases, both SHOULD have the same values in the same order.  The two
   SHOULD NOT be set to languages which are difficult to match together"

Clarify that "two" and "both" refers to the humintlang-send and humintlang-recv attributes for a medium.
( the attribute names are too far back so when searching for what "two" and "both" refers to you end up in confusion).

6. And, yet another proposal to insert a simple indication for preference betweeen media, and one for distinguishing selection versus combination.
The needs come from accessibility needs, and fulfilling accessibility needs has strong policy support, so it would be bad to say that that must wait for another version of the document when we already now have specified the need.

--------------------------------------------------In 6.2 insert:----------------------------------------------------------------------
A single digit numeric value on a humintlang attribute represents a starting priority for the humintlang attributes of the same medium and direction, with one being the highest priority.  If no such value is indicated, the value 1 is assumed. The priority value is increased by a value 0.1 for each humintlang attribute for the same media and direction.
An asterisk on a humintlang attribute alone or together with a priority number indicates that a language specified in the actual media and direction is wanted in combination with another modality in the same direction, also marked with an asterisk.

Examples:
m=audio ...
humintlang-send:en
humintlang-recv:*
humintlang-recv:en
m=text ...
humintlang-recv:*
humintlang-recv:en

This means that the user want to send spoken English and receive a combination of both spoken and typed English simultaneously  back.

m=video ...
humintlang-send:ase
humintlang-recv:ase
m=text ...
humintlang-send:5
humintlang-send:en
humintlang-recv:5
humintlang-recv:en

This means that the user prefers to use American sign language both ways, but as a possible selection on lower preference level use text both ways.
---------------------------------------------------------end of insertion---------------------
 
The fact that the humintlang attribute now can have values that are not language tags needs to be reflected in a few other places in the draft.



 

 


All - In all our discussions I see two things that we want here: [1] we want a simple and easily implementable solution/s and [2] solution/s that cover all the use cases. I think we can agree that going ahead with a simple solutions which is extensible covers both of these needs. It allows us to get something out there which can be implemented, and it allows us to answer all the use cases with extensibility which we will work on next (I appreciate this isn’t immediate but it’s favourable to making a complex solution now which is too difficult to implement). All advice I have received on this has suggested this is the best route forward.
We can't wait with an extension for something we have a need for now.
The above addition no 6. is a simple notation for what we were missing.

Given we’re well over the time that we should have agreed on this I suggest we call rough consensus for this here. I understand there may be some frustration, but really this method solves for both needs and so is sensible.

Bernard and Alexey - please check this and input if you see fit!

Natasha

/Gunnar

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


On May 17, 2016, at 10:56 PM, Gunnar Hellström <gunnar.hellstrom@omnitor.se> wrote:

Den 2016-05-17 kl. 23:17, skrev Randall Gellens:

Gunnar,

I think we can start with what we have now: the offerer offers all media/languages it wants, and the answerer accepts those it supports.
Yes, but we need a bit more than we have today to express that. Language usage are logically linked.
In many cases this will be exactly what's desired, while in some cases there will be extra media that are not used.
I am not bothered about extra media. Offered media shall not be rejected just because they do not have agreed language contents.

This gives us something simple that has the best chance of rapid and wide deployment.  We can then build on this if need be.
We already have the need. 3GPP cannot use user profiles in emergency registration mode, so we need to be able to express user needs this way to the degree that they can be served well in emergency calls.
For that we need to
clarify language in some places in the draft so that we do not end up equally fuzzy as RFC 4566,
We need to delete our interpretation of RFC 4566,
we need to express preference with scope among all media.
and we need to express when languages are needed together and when they are to select from.

You have accepted some edit proposals that we have discussed and modified others to something that we have not  yet seen. I would like to see the draft as it is now so that we can see what more needs to be changed.  



At 8:01 AM +0200 5/17/16, Gunnar Hellström wrote:

 Randall,

 Can you accept that our goal is to select the most appropriate language(s) for the call?

 This includes providing guidance to the answering part so that the answer can be made in the most appropriate language(s).

 That is stated in the charter:

 "While the two use cases are in different contexts (real time and
 non-real-time), the fundamental goal is the same: to enable selection of
 the best-fit language(s) for a specific situation. "

 It is not sufficient to use the indications to select which media shall be enabled, and then let the users sort out which language to use.

 The user needs guidance if it is most appropriate to start the conversation in voice, sign language or text or a combination of these modalities. If not, the call will start with confusion about what is the most efficient means for them to communicate.

 That is why the preference indication needs to have:

 a) a common scope over all media, and

 b) an indication if two modalities simultaneously are desired for reception.

 Can we agree on that and move on to find a simple way of expressing these needs?

 /Gunnar




 Den 2016-05-17 kl. 05:25, skrev Randall Gellens:

 At 8:28 PM -0600 5/16/16, Doug Ewell wrote:

 Except that there is still disagreement on whether the mechanism is needed for SLIM 1.0.


 And we have a call for consensus by the chairs.


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

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



-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288
_______________________________________________
SLIM mailing list
SLIM@ietf.org
https://www.ietf.org/mailman/listinfo/slim

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


-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288
--------------617F10DE89B59668A3619BEA-- From nobody Wed May 18 16:33:02 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 8440212D7C3 for ; Wed, 18 May 2016 16:33:00 -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: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 f4xXQR0iUTqi for ; Wed, 18 May 2016 16:32:59 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 96ECB12D7B0 for ; Wed, 18 May 2016 16:32:59 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Wed, 18 May 2016 16:32:58 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20160516083958.665a7a7059d7ee80bb4d670165c8327d.5e281af085.wbe@email0 3.godaddy.com> <7C5A334F88FD45E0A7770AFA6CB33C82@DougEwell> <57289c9f-a63a-0466-eeb7-845f1f1421ae@omnitor.se> <363ab6da-abdb-357b-e942-5284b085d451@omnitor.se> X-Mailer: Eudora for Mac OS X Date: Wed, 18 May 2016 16:32:57 -0700 To: Natasha Rooney , Gunnar =?iso-8859-1?Q?Hellstr=F6m?= , Randall Gellens , "slim@ietf.org" , "bernard.aboba@gmail.com" From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 Archived-At: Cc: Alexey Melnikov Subject: Re: [Slim] Seeking rough consensus for draft-ietf-slim-negotiating-human-language 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, 18 May 2016 23:33:00 -0000 At 5:08 PM +0000 5/18/16, Natasha Rooney wrote: > Randall - the last edit we see of the doc is from March, is this > the most recent one? If not can you submit an edit soon? This is the most recent version. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- This is a nasty, rotten business. --Robert L. Crandall, CEO & President of American Airlines From nobody Wed May 18 23:10: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 96B9B12D0A4 for ; Wed, 18 May 2016 23:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 HftjJOoY3bgW for ; Wed, 18 May 2016 23:10:10 -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 6D48712B04D for ; Wed, 18 May 2016 23:10:09 -0700 (PDT) X-Halon-ID: 503fcf78-1d88-11e6-81fe-0050569116f7 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.2] (unknown [87.96.161.49]) by bin-vsp-out-03.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Thu, 19 May 2016 08:09:57 +0200 (CEST) To: Bernard Aboba , slim@ietf.org References: <5706CD04.4060707@omnitor.se> <5706E617.8020400@omnitor.se> <570AAD38.1090705@omnitor.se> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <94c29316-6d7b-8c7b-1dd5-7f669b0f4d9f@omnitor.se> Date: Thu, 19 May 2016 08:09:55 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <570AAD38.1090705@omnitor.se> Content-Type: multipart/alternative; boundary="------------93DD5E613528B1280393F849" Archived-At: Subject: Re: [Slim] Claim of consensus on meaning of RFC 4566 "lang" attribute 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, 19 May 2016 06:10:13 -0000 This is a multi-part message in MIME format. --------------93DD5E613528B1280393F849 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Bernard, I got the impression that you wanted to collect earlier discussions on the intentions and interpretations of the 'lang' attribute in RFC 4566 in order to get to a conclusion for the reference of it in the work in SLIM (or MMUSIC). Was that the intention? Did you get to any conclusion? I think the reasoning about RFC 4566 lang attribute in the current humintlang-01 draft expresses the wrong conclusion and thereby increases the confusion around its usage. It is sufficient in our draft to say that the lang attribute cannot express directionality and therefore we need to introduce something new. As stated in the mail below, the lang attribute was introduced in the sdp specification as a response to requirements for language negotiation in a draft that became RFC 2277. The section in RFC 2277 that talks about it is: " 4.4. Considerations for language negotiation Protocols where users have text presented to them in response to user actions MUST provide for support of multiple languages. How this is done will vary between protocols; for instance, in some cases, a negotiation where the client proposes a set of languages and the server replies with one is appropriate; in other cases, a server may choose to send multiple variants of a text and let the client pick which one to display. Negotiation is useful in the case where one side of the protocol exchange is able to present text in multiple languages to the other side, and the other side has a preference for one of these; the most common example is the text part of error responses, or Web pages that are available in multiple languages. Negotiating a language should be regarded as a permanent requirement of the protocol that will not go away at any time in the future. In many cases, it should be possible to include it as part of the connection establishment, together with authentication and other preferences negotiation." Here it is only talk about selecting*_a_* single language. According to the mail sent when the attribute was introduced in the SDP specification, the wording in RFC 4566 was intended to match this requirement. The interpretation in our SLIM draft that the lang attribute always aims at usage of ALL specified languages together in a session is therefore wrong. It is about selection of the single initial language in the call. This conclusion leaves the RFC 4566 lang attribute without a way to require use of multiple languages together in a session. That is a valid case, but more seldom needed than selecting a single initial language. But, since RFC 4566 lang is not sufficient, we do not need to go deeper in the analysis of it but just to say that it does not handle directionality. /Gunnar Den 2016-04-10 kl. 21:44, skrev Gunnar Hellström: > The very origin of the 'lang' sdp attribute is its announcement last > in this e-mail from 1997-11-23 > https://mailarchive.ietf.org/arch/msg/mmusic/hEU4yCmc31ib4Vk23aCQPfm5QvQ > > It is said to fulfill a requirement from a draft that later became RFC > 2277. > > /Gunnar > > > > > > Den 2016-04-08 kl. 00:58, skrev Gunnar Hellström: >> Bernard, >> Also the discussion we had in SLIM in October explains the history of >> the 'lang' attribute. >> Starting with mail with subject "The use of multiple lang attributes >> in SDP" on 2015-10-04. >> >> Linking it back to a need to describe language negotiation in RFC 2277. >> >> This background makes it clear that the intention was for selection >> and negotiation. >> >> /Gunnar >> >> >> >> Den 2016-04-07 kl. 23:11, skrev Gunnar Hellström: >>> I had a discussion in mmusic in October 2015 under the subject: >>> "Clarification for multiple lang attributes in rfc4566bis" >>> Starting at: >>> https://mailarchive.ietf.org/arch/search/?email_list=mmusic&qdr=y&q=rfc4566bis >>> >>> /Gunnar >>> >>> >>> >>> Den 2016-04-07 kl. 22:08, skrev Bernard Aboba: >>>> Here is what we have in RFC 4566bis >>>> (https://tools.ietf.org/html/draft-ietf-mmusic-rfc4566bis-16#page-36): >>>> >>>> Multiple lang attributes can be provided either at session or media >>>> level if the session or media has capabilities to use multiple >>>> languages, in which case the order of the attributes indicates the >>>> order of preference of the various languages in the session or media, >>>> from most preferred to least preferred. >>>> >>>> As a session-level attribute, lang specifies a language capability >>>> for the session being described. As a media-level attribute, it >>>> specifies a language capability for that media, overriding any >>>> session-level language(s) specified. >>>> The "lang" attribute value must be a single [RFC5646 ] language tag in >>>> US-ASCII. A "lang" attribute SHOULD be specified when a session is >>>> of sufficient scope to cross geographic boundaries where the language >>>> of recipients cannot be assumed, or where the session has >>>> capabilities in languages different from the locally assumed norm. >>>> >>>> Events during the session can influence which language(s) are used, >>>> and the participants are not strictly bound to only use the declared >>>> languages. >>>> >>>> >>>> On Thu, Apr 7, 2016 at 1:03 PM, Bernard Aboba >>>> wrote: >>>> >>>> In today's meeting, we had folks pointing to discussions of the >>>> meaning of the "lang" attribute in previous meetings (in >>>> MMUSIC). Can people post pointers to those previous discussions? >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 --------------93DD5E613528B1280393F849 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Bernard,

I got the impression that you wanted to collect earlier discussions on the intentions and interpretations of the 'lang' attribute in RFC 4566 in order to get to a conclusion for the reference of it in the work in SLIM (or MMUSIC).

Was that the intention? Did you get to any conclusion?


I think the reasoning about RFC 4566 lang attribute in the current humintlang-01 draft expresses the wrong conclusion and thereby increases the confusion around its usage. It is sufficient in our draft to say that the lang attribute cannot express directionality and therefore we need to introduce something new.
As stated in the mail below, the lang attribute was introduced in the sdp specification as a response to requirements for language negotiation in a draft that became RFC 2277. The section in RFC 2277 that talks about it is:
"

4.4.  Considerations for language negotiation

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

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

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

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

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

Here it is only talk about selecting a single language. According to the mail sent when the attribute was introduced in the SDP specification, the wording in RFC 4566 was intended to match this requirement. The interpretation in our SLIM draft that the lang attribute always aims at usage of ALL specified languages together in a session is therefore wrong. It is about selection of the single initial language in the call. 

This conclusion leaves the RFC 4566 lang attribute without a way to require use of multiple languages together in a session. That is a valid case, but more seldom needed than selecting a single initial language.

But, since RFC 4566 lang is not sufficient, we do not need to go deeper in the analysis of it but just to say that it does not handle directionality.

/Gunnar



Den 2016-04-10 kl. 21:44, skrev Gunnar Hellström:
The very origin of the 'lang' sdp attribute is its announcement last in this e-mail from 1997-11-23
https://mailarchive.ietf.org/arch/msg/mmusic/hEU4yCmc31ib4Vk23aCQPfm5QvQ

It is said to fulfill a requirement from a draft that later became RFC 2277.

/Gunnar



 

Den 2016-04-08 kl. 00:58, skrev Gunnar Hellström:
Bernard,
Also the discussion we had in SLIM in October explains the history of the 'lang' attribute.
Starting with mail with subject "The use of multiple lang attributes in SDP" on 2015-10-04.

Linking it back to a need to describe language negotiation in RFC 2277.

This background makes it clear that the intention was for selection and negotiation.

/Gunnar



Den 2016-04-07 kl. 23:11, skrev Gunnar Hellström:
I had a discussion in mmusic in October 2015 under the subject:
"Clarification for multiple lang attributes in rfc4566bis"
Starting at:
https://mailarchive.ietf.org/arch/search/?email_list=mmusic&qdr=y&q=rfc4566bis

/Gunnar



Den 2016-04-07 kl. 22:08, skrev Bernard Aboba:
Here is what we have in RFC 4566bis (https://tools.ietf.org/html/draft-ietf-mmusic-rfc4566bis-16#page-36): 

   Multiple lang attributes can be provided either at session or media
   level if the session or media has capabilities to use multiple
   languages, in which case the order of the attributes indicates the
   order of preference of the various languages in the session or media,
   from most preferred to least preferred.

   As a session-level attribute, lang specifies a language capability
   for the session being described.  As a media-level attribute, it
   specifies a language capability for that media, overriding any
   session-level language(s) specified.

   The "lang" attribute value must be a single [RFC5646] language tag in
   US-ASCII.  A "lang" attribute SHOULD be specified when a session is
   of sufficient scope to cross geographic boundaries where the language
   of recipients cannot be assumed, or where the session has
   capabilities in languages different from the locally assumed norm.

   Events during the session can influence which language(s) are used,
   and the participants are not strictly bound to only use the declared
   languages.


On Thu, Apr 7, 2016 at 1:03 PM, Bernard Aboba <bernard.aboba@gmail.com> wrote:
In today's meeting, we had folks pointing to discussions of the meaning of the "lang" attribute in previous meetings (in MMUSIC).  Can people post pointers to those previous discussions?  



_______________________________________________
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
--------------93DD5E613528B1280393F849-- From nobody Thu May 19 23:55:39 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 3C8F212B013 for ; Thu, 19 May 2016 23:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0WmkMeh8kAyc for ; Thu, 19 May 2016 23:55:34 -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 F236F12B008 for ; Thu, 19 May 2016 23:55:33 -0700 (PDT) X-Halon-ID: ce269581-1e57-11e6-8615-005056917f90 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.2] (unknown [87.96.161.49]) by bin-vsp-out-02.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Fri, 20 May 2016 08:55:14 +0200 (CEST) To: Natasha Rooney , Randall Gellens , "slim@ietf.org" , "bernard.aboba@gmail.com" References: <20160516083958.665a7a7059d7ee80bb4d670165c8327d.5e281af085.wbe@email0 3.godaddy.com> <7C5A334F88FD45E0A7770AFA6CB33C82@DougEwell> <57289c9f-a63a-0466-eeb7-845f1f1421ae@omnitor.se> <363ab6da-abdb-357b-e942-5284b085d451@omnitor.se> <405724e5-61aa-1144-6a2c-7c08fb599c98@omnitor.se> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <434a2375-f806-a326-6137-706f1d7d9f92@omnitor.se> Date: Fri, 20 May 2016 08:55:20 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <405724e5-61aa-1144-6a2c-7c08fb599c98@omnitor.se> Content-Type: multipart/alternative; boundary="------------50BE9BACA682ACE9C48B4B64" Archived-At: Cc: Alexey Melnikov Subject: Re: [Slim] Seeking rough consensus for draft-ietf-slim-negotiating-human-language - compromise proposal 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, 20 May 2016 06:55:38 -0000 This is a multi-part message in MIME format. --------------50BE9BACA682ACE9C48B4B64 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit I have a compromise proposal. Let us test if we can get somewhere by introducing it. Let us delete the use of the asterisk '*' for the 'do not drop' notation, and let 'do not drop' be the default. Let us reuse the asterisk attached to the end of a language tag be used for both a priority indication with the whole sdp as scope, and an indication of grouping. Initial change proposals ( there will be more follow-up changes, but these are the main ones ) ---------------change in 6.2 from--------------------------------------------------------------- In an offer, each language tag value MAY have an asterisk appended as the last character (after the registry value). The asterisk indicates a request by the caller to not fail the call if there is no language in common. SeeSection 6.3 for more information and discussion. -------------------to------------------------------------- In an offer, language tag values MAY have an asterisk appended as the last character (after the registry value). The asterisk indicates a main preference for the indicated language. SeeSection 6.3 for more information and discussion. ----------------------------end of change in 6.2--------------------- -------------------Replace 6.3 with this---------------------------------- 6.3 Main preference If a user has a strong preference for using a language over the other indicated languages, this preference can be indicated by including an asterisk '*' last in the value of the preferred language and direction indication. One such preference indication can be used per direction to indicate main preference. This preference has scope across all media. Two or more such preference indications can be used per direction to indicate a strong preference or capability to use the indicated languages in the indicated direction simultaneously together. Examples: Example 1; a calling user, who strongly prefers to use spoken English supported by reception of rapidly added text captioning of the received speech can indicate this preference by the following abbreviated sdp. This indication can be used by the callee or by the involved services to make efforts to invoke a way of adding text to the speech answers. m=audio ... humintlang-send:en humintlang-recv:en* m=text ... humintlang-recv:en* Example 2; a calling user, who prefers to use American sign language both ways, but want to indicate that text in English both ways is an accepted alternative on lower preference level can indicate this preference by the following abbreviated sdp: This indication can be used by the called party to make efforts to answer with sign language competent personnel, but if that is not available be assured that a text conversation will also be successful. m=video ... humintlang-send:ase* humintlang-recv:ase* m=text ... humintlang-send:en humintlang-recv:en -------------------------------end of changes------------------------------------------------ Discussion: This compromise satisfies most use cases for which global preference and grouping are needed, but has some drawbacks compared to a system with finer graded preferences. 1. For the grouping example above with receiving spoken English and English text, it cannot be seen what is best if it is not possible to provide the combination. There is no clue if it would be reasonably possible to provide only text or only spoken English. 2. The notation is only usable for a single preference combination. It is not possible to indicate a number of sign languages, all preferred over typed English. This drawback appears because the same notation is used for main preference as for grouping indication. I want anyway to provide this compromise proposal, because it does not introduce any extra complexity and it solves the main so far unsolved use cases. /Gunnar Den 2016-05-19 kl. 00:23, skrev Gunnar Hellström: > Den 2016-05-18 kl. 19:08, skrev Natasha Rooney: >> Randall - the last edit we see of the doc is from March, is this the >> most recent one? If not can you submit an edit soon? > We had e-mail list discussion around April 8-10 under the subject > "[Slim] Wording about selection in > draft-ietf-slim-negotiating-human-language-01" > that ended with some agreed changes and some in-principle agreed > changes but no agreed wording. That is what I refer to when I say I > want to see what the latest edits ended up in. > > That mainly covered the ambition to be more exact than RFC 4566 lang > specification. > > So, when we get that, we can judge: > 1. If it is clear when the indications reflect a selection possibility > or a combination requirement. > > There are a couple of other things we need to modify also before > progressing to any kind of consensus. > > 2. In 5. Delete our interpretation of the lang attribute. It is > sufficient to say that it is not enough detailed because it does not > provide directionality. > > 3. In 5. insert specification on how lang and humintlang relates. The > easiest way is to say that lang should not be used in sdp where > humintlang is used. Is that too drastic? > > 4. Do we really need the * parameter for "do not fail call" introduced > in 6.2 and explained in 6.3? It will be most common to want to have > that effect, thus requiring to add the * in most media specifications. > Can we simplify the syntax by having "do not fail call" as the default > and delete the description of the * ? I suggest that we delete it. > If not, the description of the syntax of how the * is included needs > to be inserted in the syntax description in section 6.2 and an example > added. > > 5. In this part of 6.2: > "In cases where the user > wishes to use one media for sending and another for receiving (such > as a speech-impaired user who wishes to send using text and receive > using audio), one of the two MAY be unset. In cases where a media is > not primarily intended for language (for example, a video or audio > stream intended for background only) both SHOULD be unset. In other > cases, both SHOULD have the same values in the same order. The two > SHOULD NOT be set to languages which are difficult to match together" > > Clarify that "two" and "both" refers to the humintlang-send and > humintlang-recv attributes for a medium. > ( the attribute names are too far back so when searching for what > "two" and "both" refers to you end up in confusion). > > 6. And, yet another proposal to insert a simple indication for > preference betweeen media, and one for distinguishing selection versus > combination. > The needs come from accessibility needs, and fulfilling accessibility > needs has strong policy support, so it would be bad to say that that > must wait for another version of the document when we already now have > specified the need. > > --------------------------------------------------In 6.2 > insert:---------------------------------------------------------------------- > A single digit numeric value on a humintlang attribute represents a > starting priority for the humintlang attributes of the same medium and > direction, with one being the highest priority. If no such value is > indicated, the value 1 is assumed. The priority value is increased by > a value 0.1 for each humintlang attribute for the same media and > direction. > An asterisk on a humintlang attribute alone or together with a > priority number indicates that a language specified in the actual > media and direction is wanted in combination with another modality in > the same direction, also marked with an asterisk. > > Examples: > m=audio ... > humintlang-send:en > humintlang-recv:* > humintlang-recv:en > m=text ... > humintlang-recv:* > humintlang-recv:en > > This means that the user want to send spoken English and receive a > combination of both spoken and typed English simultaneously back. > > m=video ... > humintlang-send:ase > humintlang-recv:ase > m=text ... > humintlang-send:5 > humintlang-send:en > humintlang-recv:5 > humintlang-recv:en > > This means that the user prefers to use American sign language both > ways, but as a possible selection on lower preference level use text > both ways. > ---------------------------------------------------------end of > insertion--------------------- > > The fact that the humintlang attribute now can have values that are > not language tags needs to be reflected in a few other places in the > draft. > > > > > > > >> >> All - In all our discussions I see two things that we want here: [1] >> we want a simple and easily implementable solution/s and [2] >> solution/s that cover all the use cases. I think we can agree that >> going ahead with a simple solutions which is extensible covers both >> of these needs. It allows us to get something out there which can be >> implemented, and it allows us to answer all the use cases with >> extensibility which we will work on next (I appreciate this isn’t >> immediate but it’s favourable to making a complex solution now which >> is too difficult to implement). All advice I have received on this >> has suggested this is the best route forward. > We can't wait with an extension for something we have a need for now. > The above addition no 6. is a simple notation for what we were missing. >> >> Given we’re well over the time that we should have agreed on this I >> suggest we call rough consensus for this here. I understand there may >> be some frustration, but really this method solves for both needs and >> so is sensible. >> >> Bernard and Alexey - please check this and input if you see fit! >> >> Natasha >> > /Gunnar >> >> Natasha Rooney | Technologist, Web and Internet, W3C & IETF | GSMA | >> nrooney@gsma.com | +44 (0) 7730 219 765 | >> @thisNatasha | Skype: nrooney@gsm.org >> >> >>> On May 17, 2016, at 10:56 PM, Gunnar Hellström >>> > >>> wrote: >>> >>> Den 2016-05-17 kl. 23:17, skrev Randall Gellens: >>> >>>> Gunnar, >>>> >>>> I think we can start with what we have now: the offerer offers all >>>> media/languages it wants, and the answerer accepts those it supports. >>> Yes, but we need a bit more than we have today to express that. >>> Language usage are logically linked. >>>> In many cases this will be exactly what's desired, while in some >>>> cases there will be extra media that are not used. >>> I am not bothered about extra media. Offered media shall not be >>> rejected just because they do not have agreed language contents. >>>> >>>> This gives us something simple that has the best chance of rapid >>>> and wide deployment. We can then build on this if need be. >>> We already have the need. 3GPP cannot use user profiles in emergency >>> registration mode, so we need to be able to express user needs this >>> way to the degree that they can be served well in emergency calls. >>> For that we need to >>> clarify language in some places in the draft so that we do not end >>> up equally fuzzy as RFC 4566, >>> We need to delete our interpretation of RFC 4566, >>> we need to express preference with scope among all media. >>> and we need to express when languages are needed together and when >>> they are to select from. >>> >>> You have accepted some edit proposals that we have discussed and >>> modified others to something that we have not yet seen. I would >>> like to see the draft as it is now so that we can see what more >>> needs to be changed. >>> >>>> >>>> >>>> At 8:01 AM +0200 5/17/16, Gunnar Hellström wrote: >>>> >>>>> Randall, >>>>> >>>>> Can you accept that our goal is to select the most appropriate >>>>> language(s) for the call? >>>>> >>>>> This includes providing guidance to the answering part so that >>>>> the answer can be made in the most appropriate language(s). >>>>> >>>>> That is stated in the charter: >>>>> >>>>> "While the two use cases are in different contexts (real time and >>>>> non-real-time), the fundamental goal is the same: to enable >>>>> selection of >>>>> the best-fit language(s) for a specific situation. " >>>>> >>>>> It is not sufficient to use the indications to select which media >>>>> shall be enabled, and then let the users sort out which language >>>>> to use. >>>>> >>>>> The user needs guidance if it is most appropriate to start the >>>>> conversation in voice, sign language or text or a combination of >>>>> these modalities. If not, the call will start with confusion about >>>>> what is the most efficient means for them to communicate. >>>>> >>>>> That is why the preference indication needs to have: >>>>> >>>>> a) a common scope over all media, and >>>>> >>>>> b) an indication if two modalities simultaneously are desired for >>>>> reception. >>>>> >>>>> Can we agree on that and move on to find a simple way of >>>>> expressing these needs? >>>>> >>>>> /Gunnar >>>>> >>>>> >>>>> >>>>> >>>>> Den 2016-05-17 kl. 05:25, skrev Randall Gellens: >>>>> >>>>>> At 8:28 PM -0600 5/16/16, Doug Ewell wrote: >>>>>> >>>>>>> Except that there is still disagreement on whether the >>>>>>> mechanism is needed for SLIM 1.0. >>>>>>> >>>>>> >>>>>> And we have a call for consensus by the chairs. >>>>>> >>>>> >>>>> -- >>>>> ----------------------------------------- >>>>> 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 >> >> This email and its attachments are intended for the above named only >> and may be confidential. If they have come to you in error you must >> take no action based on them, nor must you copy or show them to >> anyone; please reply to this email or call +44 207 356 0600 and >> highlight the error. >> > > -- > ----------------------------------------- > Gunnar Hellström > Omnitor > gunnar.hellstrom@omnitor.se > +46 708 204 288 > > > _______________________________________________ > 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 --------------50BE9BACA682ACE9C48B4B64 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

I have a compromise proposal. Let us test if we can get somewhere by introducing it.

Let us delete the use of the asterisk '*' for the 'do not drop' notation, and let 'do not drop' be the default.

Let us reuse the asterisk attached to the end of a language tag be used for both a priority indication with the whole sdp as scope, and an indication of grouping.

Initial change proposals ( there will be more follow-up changes, but these are the main ones )

---------------change in 6.2 from---------------------------------------------------------------

 In an offer, each language tag value MAY have an asterisk appended as
   the last character (after the registry value).  The asterisk
   indicates a request by the caller to not fail the call if there is no
   language in common.  See Section 6.3 for more information and
   discussion.
-------------------to-------------------------------------
 In an offer, language tag values MAY have an asterisk appended as
   the last character (after the registry value).  The asterisk
   indicates a main preference for the indicated language.  See Section 6.3 
   for more information and discussion.
----------------------------end of change in 6.2---------------------

-------------------Replace 6.3 with this----------------------------------

6.3 Main preference

If a user has a strong preference for using a language over the other 
indicated languages, this preference can be indicated by including an 
asterisk '*' last in the value of the preferred language and direction 
indication.

One such preference indication can be used per direction to indicate 
main preference. This preference has scope across all media.

Two or more such preference indications can be used per direction to 
indicate a strong preference or capability to use the indicated languages
in the indicated direction simultaneously together.

Examples:
Example 1;  a calling user, who strongly prefers to use spoken English
 supported by reception of rapidly added text captioning of the received 
 speech can indicate this preference by the following abbreviated sdp.
 This indication can be used by the callee or by the involved services 
 to make efforts to invoke a way of adding text to the speech answers. 
 
   m=audio ...
    humintlang-send:en
    humintlang-recv:en*
   m=text ...
    humintlang-recv:en*
  
Example 2; a calling user, who prefers to use American sign language both
  ways, but want to indicate that text in English both ways is an accepted 
  alternative on lower preference level can indicate this preference by the
  following abbreviated sdp:
  This indication can be used by the called party to make efforts to answer
  with sign language competent personnel, but if that is not available be 
  assured that a text conversation will also be successful.  
 
   m=video ...
    humintlang-send:ase*
    humintlang-recv:ase*
   m=text ...
    humintlang-send:en
    humintlang-recv:en

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

Discussion: This compromise satisfies most use cases for which global preference and grouping are needed, but has some drawbacks compared to a system with finer graded preferences.

1. For the grouping example above with receiving spoken English and English text, it cannot be seen what is best if it is not possible to provide the combination. There is no clue if it would be reasonably possible to provide only text or only spoken English.

2. The notation is only usable for a single preference combination.
 It is not possible to indicate a number of sign languages, all preferred over typed English.
This drawback appears because the same notation is used for main preference as for grouping indication.

I want anyway to provide this compromise proposal, because it does not introduce any extra complexity and it solves the main so far unsolved use cases.

/Gunnar


Den 2016-05-19 kl. 00:23, skrev Gunnar Hellström:
Den 2016-05-18 kl. 19:08, skrev Natasha Rooney:
Randall - the last edit we see of the doc is from March, is this the most recent one? If not can you submit an edit soon?
We had e-mail list discussion around April 8-10 under the subject "[Slim] Wording about selection in draft-ietf-slim-negotiating-human-language-01"
that ended with some agreed changes and some in-principle agreed changes but no agreed wording. That is what I refer to when I say I want to see what the latest edits ended up in.

That mainly covered the ambition to be more exact than RFC 4566 lang specification.

So, when we get that, we can judge:
1. If it is clear when the indications reflect a selection possibility or a combination requirement.

There are a couple of other things we need to modify also before progressing to any kind of consensus.

2. In 5. Delete our interpretation of the lang attribute. It is sufficient to say that it is not enough detailed because it does not provide directionality.

3. In 5. insert specification on how lang and humintlang relates. The easiest way is to say that lang should not be used in sdp where humintlang is used. Is that too drastic?

4. Do we really need the * parameter for "do not fail call" introduced in 6.2 and explained in 6.3?  It will be most common to want to have that effect, thus requiring to add the * in most media specifications. Can we simplify the syntax by having "do not fail call" as the default and delete the description of the * ? I suggest that we delete it.
If not, the description of the syntax of how the * is included needs to be inserted in the syntax description in section 6.2 and an example added.

5. In this part of 6.2:
"In cases where the user
   wishes to use one media for sending and another for receiving (such
   as a speech-impaired user who wishes to send using text and receive
   using audio), one of the two MAY be unset.  In cases where a media is
   not primarily intended for language (for example, a video or audio
   stream intended for background only) both SHOULD be unset.  In other
   cases, both SHOULD have the same values in the same order.  The two
   SHOULD NOT be set to languages which are difficult to match together"

Clarify that "two" and "both" refers to the humintlang-send and humintlang-recv attributes for a medium.
( the attribute names are too far back so when searching for what "two" and "both" refers to you end up in confusion).

6. And, yet another proposal to insert a simple indication for preference betweeen media, and one for distinguishing selection versus combination.
The needs come from accessibility needs, and fulfilling accessibility needs has strong policy support, so it would be bad to say that that must wait for another version of the document when we already now have specified the need.

--------------------------------------------------In 6.2 insert:----------------------------------------------------------------------
A single digit numeric value on a humintlang attribute represents a starting priority for the humintlang attributes of the same medium and direction, with one being the highest priority.  If no such value is indicated, the value 1 is assumed. The priority value is increased by a value 0.1 for each humintlang attribute for the same media and direction.
An asterisk on a humintlang attribute alone or together with a priority number indicates that a language specified in the actual media and direction is wanted in combination with another modality in the same direction, also marked with an asterisk.

Examples:
m=audio ...
humintlang-send:en
humintlang-recv:*
humintlang-recv:en
m=text ...
humintlang-recv:*
humintlang-recv:en

This means that the user want to send spoken English and receive a combination of both spoken and typed English simultaneously  back.

m=video ...
humintlang-send:ase
humintlang-recv:ase
m=text ...
humintlang-send:5
humintlang-send:en
humintlang-recv:5
humintlang-recv:en

This means that the user prefers to use American sign language both ways, but as a possible selection on lower preference level use text both ways.
---------------------------------------------------------end of insertion---------------------
 
The fact that the humintlang attribute now can have values that are not language tags needs to be reflected in a few other places in the draft.



 

 


All - In all our discussions I see two things that we want here: [1] we want a simple and easily implementable solution/s and [2] solution/s that cover all the use cases. I think we can agree that going ahead with a simple solutions which is extensible covers both of these needs. It allows us to get something out there which can be implemented, and it allows us to answer all the use cases with extensibility which we will work on next (I appreciate this isn’t immediate but it’s favourable to making a complex solution now which is too difficult to implement). All advice I have received on this has suggested this is the best route forward.
We can't wait with an extension for something we have a need for now.
The above addition no 6. is a simple notation for what we were missing.

Given we’re well over the time that we should have agreed on this I suggest we call rough consensus for this here. I understand there may be some frustration, but really this method solves for both needs and so is sensible.

Bernard and Alexey - please check this and input if you see fit!

Natasha

/Gunnar

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


On May 17, 2016, at 10:56 PM, Gunnar Hellström <gunnar.hellstrom@omnitor.se> wrote:

Den 2016-05-17 kl. 23:17, skrev Randall Gellens:

Gunnar,

I think we can start with what we have now: the offerer offers all media/languages it wants, and the answerer accepts those it supports.
Yes, but we need a bit more than we have today to express that. Language usage are logically linked.
In many cases this will be exactly what's desired, while in some cases there will be extra media that are not used.
I am not bothered about extra media. Offered media shall not be rejected just because they do not have agreed language contents.

This gives us something simple that has the best chance of rapid and wide deployment.  We can then build on this if need be.
We already have the need. 3GPP cannot use user profiles in emergency registration mode, so we need to be able to express user needs this way to the degree that they can be served well in emergency calls.
For that we need to
clarify language in some places in the draft so that we do not end up equally fuzzy as RFC 4566,
We need to delete our interpretation of RFC 4566,
we need to express preference with scope among all media.
and we need to express when languages are needed together and when they are to select from.

You have accepted some edit proposals that we have discussed and modified others to something that we have not  yet seen. I would like to see the draft as it is now so that we can see what more needs to be changed.  



At 8:01 AM +0200 5/17/16, Gunnar Hellström wrote:

 Randall,

 Can you accept that our goal is to select the most appropriate language(s) for the call?

 This includes providing guidance to the answering part so that the answer can be made in the most appropriate language(s).

 That is stated in the charter:

 "While the two use cases are in different contexts (real time and
 non-real-time), the fundamental goal is the same: to enable selection of
 the best-fit language(s) for a specific situation. "

 It is not sufficient to use the indications to select which media shall be enabled, and then let the users sort out which language to use.

 The user needs guidance if it is most appropriate to start the conversation in voice, sign language or text or a combination of these modalities. If not, the call will start with confusion about what is the most efficient means for them to communicate.

 That is why the preference indication needs to have:

 a) a common scope over all media, and

 b) an indication if two modalities simultaneously are desired for reception.

 Can we agree on that and move on to find a simple way of expressing these needs?

 /Gunnar




 Den 2016-05-17 kl. 05:25, skrev Randall Gellens:

 At 8:28 PM -0600 5/16/16, Doug Ewell wrote:

 Except that there is still disagreement on whether the mechanism is needed for SLIM 1.0.


 And we have a call for consensus by the chairs.


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

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



-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288
_______________________________________________
SLIM mailing list
SLIM@ietf.org
https://www.ietf.org/mailman/listinfo/slim

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


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


_______________________________________________
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
--------------50BE9BACA682ACE9C48B4B64-- From nobody Fri May 20 11:02: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 E354712D5E8 for ; Fri, 20 May 2016 11:02:07 -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 Qn3Qrh5SCNXl for ; Fri, 20 May 2016 11:02:04 -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 6634D12D59F for ; Fri, 20 May 2016 11:02:04 -0700 (PDT) Received: by mail-qg0-x235.google.com with SMTP id j18so16158129qge.2 for ; Fri, 20 May 2016 11:02:04 -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=gUbhVokjv9Eok5tiNbsHnSV+5hSFuh5rpVPWKy99qAY=; b=tQmpLQCmgJ2l4eddlKUb7sq68BeqW3MD5a9MQR3YEdFIJAjLpyI8V3DGm8KqTAZO0+ gRSFIQkFkM+528GuN152I25SNgeWiIojxQoPjSiSzUylJd6AhgwSsyanZW/MKERkxsns K3j0AQyjdBERxYFN9+Nu71Tzss8A5A9X/sKRLgAsIE42FRk72jZWsW6I+nyolyW0CoRX UVUPGNWMz2gVjpNeYgQQwg5PSaphtFpAio+vYwfLiAW61QY+eo12sqQp8CrSlHWizft/ kZ29R2nzo+dKWvBBYjwx6MK/StKb4TZpeM0H9mK4RoPZf/5X44K0vBtkVVfNZxGG1kFP YBew== 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=gUbhVokjv9Eok5tiNbsHnSV+5hSFuh5rpVPWKy99qAY=; b=E44oJMHwUmeZAGj7alhJ+MqlCWAT1diCgvSrtVj0o7DDEKxx7iYvxhMK8RrYxy9IIB lU0mwHsrH3ROki1wLbJ4GeyNx+thvSS2Jvw3YBNxxkJSZ4KS+XIJoBo23b6jU/Z1iomL BALXmdvhn6HOo78lynUeoarjnOF0KjjWVO5OfTb2mjwr6bIpoycMNT4bcjuyJSIK88R/ G6TJL7fTD2Mjet4GyMD7iEvV3Wvmh7/9nlKDC9sZY4oKvEliAROarbafufbY0S2ojpEp Ywp/TPYk1r5JzY72J73t3ygyZ5GTBF1HhI7NWwuUN20xuhCcTyMlyP1N+Ec+UkZkCulM 7j7A== X-Gm-Message-State: AOPr4FWpsu0haXF85WPQ5LQjkrtjUOJgsFCHtSNQo2ULiEgK8eF+HeG1zMzRjgdP/MejIg== X-Received: by 10.140.43.166 with SMTP id e35mr4750214qga.72.1463767323444; Fri, 20 May 2016 11:02:03 -0700 (PDT) Received: from [10.33.192.30] ([156.154.81.54]) by smtp.gmail.com with ESMTPSA id r130sm9242840qha.25.2016.05.20.11.02.02 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 20 May 2016 11:02:02 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_3D5DC423-17B4-42DE-825F-BE63C00A7CB5" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Brian Rosen In-Reply-To: <434a2375-f806-a326-6137-706f1d7d9f92@omnitor.se> Date: Fri, 20 May 2016 14:01:59 -0400 Message-Id: <4C5ADDF5-6D93-4A8E-9EE7-D116217BAADA@brianrosen.net> References: <20160516083958.665a7a7059d7ee80bb4d670165c8327d.5e281af085.wbe@email0 3.godaddy.com> <7C5A334F88FD45E0A7770AFA6CB33C82@DougEwell> <57289c9f-a63a-0466-eeb7-845f1f1421ae@omnitor.se> <363ab6da-abdb-357b-e942-5284b085d451@omnitor.se> <405724e5-61aa-1144-6a2c-7c08fb599c98@omnitor.se> <434a2375-f806-a326-6137-706f1d7d9f92@omnitor.se> To: =?utf-8?Q?Gunnar_Hellstr=C3=B6m?= X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "slim@ietf.org" , Natasha Rooney , Alexey Melnikov , Randall Gellens , "bernard.aboba@gmail.com" Subject: Re: [Slim] Seeking rough consensus for draft-ietf-slim-negotiating-human-language - compromise proposal 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, 20 May 2016 18:02:08 -0000 --Apple-Mail=_3D5DC423-17B4-42DE-825F-BE63C00A7CB5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I personally don=92t want to have anything like =93main preference=94 = or grouping that confuses the per-media characteristic of SDP. Brian > On May 20, 2016, at 2:55 AM, Gunnar Hellstr=F6m = wrote: >=20 > I have a compromise proposal. Let us test if we can get somewhere by = introducing it. >=20 > Let us delete the use of the asterisk '*' for the 'do not drop' = notation, and let 'do not drop' be the default. >=20 > Let us reuse the asterisk attached to the end of a language tag be = used for both a priority indication with the whole sdp as scope, and an = indication of grouping. >=20 > Initial change proposals ( there will be more follow-up changes, but = these are the main ones ) > ---------------change in 6.2 = from--------------------------------------------------------------- >=20 > In an offer, each language tag value MAY have an asterisk appended as > the last character (after the registry value). The asterisk > indicates a request by the caller to not fail the call if there is = no > language in common. See Section 6.3 = for more information and > discussion. > -------------------to------------------------------------- > In an offer, language tag values MAY have an asterisk appended as > the last character (after the registry value). The asterisk > indicates a main preference for the indicated language. See = Section 6.3 = =20 > for more information and discussion. > ----------------------------end of change in 6.2--------------------- >=20 > -------------------Replace 6.3 with = this---------------------------------- >=20 > 6.3 Main preference >=20 > If a user has a strong preference for using a language over the other=20= > indicated languages, this preference can be indicated by including an=20= > asterisk '*' last in the value of the preferred language and direction=20= > indication. >=20 > One such preference indication can be used per direction to indicate=20= > main preference. This preference has scope across all media. >=20 > Two or more such preference indications can be used per direction to=20= > indicate a strong preference or capability to use the indicated = languages > in the indicated direction simultaneously together. >=20 > Examples: > Example 1; a calling user, who strongly prefers to use spoken English > supported by reception of rapidly added text captioning of the = received=20 > speech can indicate this preference by the following abbreviated sdp. > This indication can be used by the callee or by the involved services=20= > to make efforts to invoke a way of adding text to the speech answers.=20= > =20 > m=3Daudio ... > humintlang-send:en > humintlang-recv:en* > m=3Dtext ... > humintlang-recv:en* > =20 > Example 2; a calling user, who prefers to use American sign language = both > ways, but want to indicate that text in English both ways is an = accepted=20 > alternative on lower preference level can indicate this preference = by the > following abbreviated sdp: > This indication can be used by the called party to make efforts to = answer > with sign language competent personnel, but if that is not available = be=20 > assured that a text conversation will also be successful. =20 > =20 > m=3Dvideo ... > humintlang-send:ase* > humintlang-recv:ase* > m=3Dtext ... > humintlang-send:en > humintlang-recv:en > -------------------------------end of = changes------------------------------------------------ >=20 > Discussion: This compromise satisfies most use cases for which global = preference and grouping are needed, but has some drawbacks compared to a = system with finer graded preferences. >=20 > 1. For the grouping example above with receiving spoken English and = English text, it cannot be seen what is best if it is not possible to = provide the combination. There is no clue if it would be reasonably = possible to provide only text or only spoken English. >=20 > 2. The notation is only usable for a single preference combination.=20 > It is not possible to indicate a number of sign languages, all = preferred over typed English. > This drawback appears because the same notation is used for main = preference as for grouping indication. >=20 > I want anyway to provide this compromise proposal, because it does not = introduce any extra complexity and it solves the main so far unsolved = use cases. > /Gunnar >=20 > Den 2016-05-19 kl. 00:23, skrev Gunnar Hellstr=F6m: >> Den 2016-05-18 kl. 19:08, skrev Natasha Rooney: >>> Randall - the last edit we see of the doc is from March, is this the = most recent one? If not can you submit an edit soon? >> We had e-mail list discussion around April 8-10 under the subject = "[Slim] Wording about selection in = draft-ietf-slim-negotiating-human-language-01" >> that ended with some agreed changes and some in-principle agreed = changes but no agreed wording. That is what I refer to when I say I want = to see what the latest edits ended up in. >>=20 >> That mainly covered the ambition to be more exact than RFC 4566 lang = specification. >>=20 >> So, when we get that, we can judge: >> 1. If it is clear when the indications reflect a selection = possibility or a combination requirement.=20 >>=20 >> There are a couple of other things we need to modify also before = progressing to any kind of consensus.=20 >>=20 >> 2. In 5. Delete our interpretation of the lang attribute. It is = sufficient to say that it is not enough detailed because it does not = provide directionality. >>=20 >> 3. In 5. insert specification on how lang and humintlang relates. The = easiest way is to say that lang should not be used in sdp where = humintlang is used. Is that too drastic? >>=20 >> 4. Do we really need the * parameter for "do not fail call" = introduced in 6.2 and explained in 6.3? It will be most common to want = to have that effect, thus requiring to add the * in most media = specifications. Can we simplify the syntax by having "do not fail call" = as the default and delete the description of the * ? I suggest that we = delete it. >> If not, the description of the syntax of how the * is included needs = to be inserted in the syntax description in section 6.2 and an example = added. >>=20 >> 5. In this part of 6.2:=20 >> "In cases where the user >> wishes to use one media for sending and another for receiving = (such >> as a speech-impaired user who wishes to send using text and = receive >> using audio), one of the two MAY be unset. In cases where a media = is >> not primarily intended for language (for example, a video or audio >> stream intended for background only) both SHOULD be unset. In = other >> cases, both SHOULD have the same values in the same order. The = two >> SHOULD NOT be set to languages which are difficult to match = together" >>=20 >> Clarify that "two" and "both" refers to the humintlang-send and = humintlang-recv attributes for a medium.=20 >> ( the attribute names are too far back so when searching for what = "two" and "both" refers to you end up in confusion). >>=20 >> 6. And, yet another proposal to insert a simple indication for = preference betweeen media, and one for distinguishing selection versus = combination. >> The needs come from accessibility needs, and fulfilling accessibility = needs has strong policy support, so it would be bad to say that that = must wait for another version of the document when we already now have = specified the need.=20 >>=20 >> --------------------------------------------------In 6.2 = insert:-------------------------------------------------------------------= --- >> A single digit numeric value on a humintlang attribute represents a = starting priority for the humintlang attributes of the same medium and = direction, with one being the highest priority. If no such value is = indicated, the value 1 is assumed. The priority value is increased by a = value 0.1 for each humintlang attribute for the same media and = direction.=20 >> An asterisk on a humintlang attribute alone or together with a = priority number indicates that a language specified in the actual media = and direction is wanted in combination with another modality in = the same direction, also marked with an asterisk. >>=20 >> Examples: >> m=3Daudio ... >> humintlang-send:en >> humintlang-recv:* >> humintlang-recv:en >> m=3Dtext ... >> humintlang-recv:* >> humintlang-recv:en >>=20 >> This means that the user want to send spoken English and receive a = combination of both spoken and typed English simultaneously back. >>=20 >> m=3Dvideo ... >> humintlang-send:ase >> humintlang-recv:ase >> m=3Dtext ... >> humintlang-send:5 >> humintlang-send:en >> humintlang-recv:5 >> humintlang-recv:en >>=20 >> This means that the user prefers to use American sign language both = ways, but as a possible selection on lower preference level use text = both ways. >> ---------------------------------------------------------end of = insertion--------------------- >> =20 >> The fact that the humintlang attribute now can have values that are = not language tags needs to be reflected in a few other places in the = draft. >>=20 >>=20 >>=20 >> =20 >>=20 >> =20 >>=20 >>>=20 >>> All - In all our discussions I see two things that we want here: [1] = we want a simple and easily implementable solution/s and [2] solution/s = that cover all the use cases. I think we can agree that going ahead with = a simple solutions which is extensible covers both of these needs. It = allows us to get something out there which can be implemented, and it = allows us to answer all the use cases with extensibility which we will = work on next (I appreciate this isn=92t immediate but it=92s favourable = to making a complex solution now which is too difficult to implement). = All advice I have received on this has suggested this is the best route = forward. >> We can't wait with an extension for something we have a need for now. >> The above addition no 6. is a simple notation for what we were = missing. >>>=20 >>> Given we=92re well over the time that we should have agreed on this = I suggest we call rough consensus for this here. I understand there may = be some frustration, but really this method solves for both needs and so = is sensible. >>>=20 >>> Bernard and Alexey - please check this and input if you see fit! >>>=20 >>> Natasha >>>=20 >> /Gunnar >>>=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 >>>> On May 17, 2016, at 10:56 PM, Gunnar Hellstr=F6m = > = wrote: >>>>=20 >>>> Den 2016-05-17 kl. 23:17, skrev Randall Gellens: >>>>> Gunnar,=20 >>>>>=20 >>>>> I think we can start with what we have now: the offerer offers all = media/languages it wants, and the answerer accepts those it supports.=20 >>>> Yes, but we need a bit more than we have today to express that. = Language usage are logically linked. >>>>> In many cases this will be exactly what's desired, while in some = cases there will be extra media that are not used.=20 >>>> I am not bothered about extra media. Offered media shall not be = rejected just because they do not have agreed language contents. >>>>>=20 >>>>> This gives us something simple that has the best chance of rapid = and wide deployment. We can then build on this if need be. >>>> We already have the need. 3GPP cannot use user profiles in = emergency registration mode, so we need to be able to express user needs = this way to the degree that they can be served well in emergency calls.=20= >>>> For that we need to=20 >>>> clarify language in some places in the draft so that we do not end = up equally fuzzy as RFC 4566,=20 >>>> We need to delete our interpretation of RFC 4566, >>>> we need to express preference with scope among all media.=20 >>>> and we need to express when languages are needed together and when = they are to select from. >>>>=20 >>>> You have accepted some edit proposals that we have discussed and = modified others to something that we have not yet seen. I would like to = see the draft as it is now so that we can see what more needs to be = changed. =20 >>>>=20 >>>>>=20 >>>>>=20 >>>>> At 8:01 AM +0200 5/17/16, Gunnar Hellstr=F6m wrote:=20 >>>>>=20 >>>>>> Randall,=20 >>>>>>=20 >>>>>> Can you accept that our goal is to select the most appropriate = language(s) for the call?=20 >>>>>>=20 >>>>>> This includes providing guidance to the answering part so that = the answer can be made in the most appropriate language(s).=20 >>>>>>=20 >>>>>> That is stated in the charter:=20 >>>>>>=20 >>>>>> "While the two use cases are in different contexts (real time = and=20 >>>>>> non-real-time), the fundamental goal is the same: to enable = selection of=20 >>>>>> the best-fit language(s) for a specific situation. "=20 >>>>>>=20 >>>>>> It is not sufficient to use the indications to select which = media shall be enabled, and then let the users sort out which language = to use.=20 >>>>>>=20 >>>>>> The user needs guidance if it is most appropriate to start the = conversation in voice, sign language or text or a combination of these = modalities. If not, the call will start with confusion about what is the = most efficient means for them to communicate.=20 >>>>>>=20 >>>>>> That is why the preference indication needs to have:=20 >>>>>>=20 >>>>>> a) a common scope over all media, and=20 >>>>>>=20 >>>>>> b) an indication if two modalities simultaneously are desired = for reception.=20 >>>>>>=20 >>>>>> Can we agree on that and move on to find a simple way of = expressing these needs?=20 >>>>>>=20 >>>>>> /Gunnar=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Den 2016-05-17 kl. 05:25, skrev Randall Gellens:=20 >>>>>>=20 >>>>>>> At 8:28 PM -0600 5/16/16, Doug Ewell wrote:=20 >>>>>>>=20 >>>>>>>> Except that there is still disagreement on whether the = mechanism is needed for SLIM 1.0.=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>> And we have a call for consensus by the chairs.=20 >>>>>>>=20 >>>>>>=20 >>>>>> --=20 >>>>>> -----------------------------------------=20 >>>>>> Gunnar Hellstr=F6m=20 >>>>>> Omnitor=20 >>>>>> = = gunnar.hellstrom@omnitor.se = =20 >>>>>> +46 708 204 288=20 >>>>>>=20 >>>>>> _______________________________________________=20 >>>>>> SLIM mailing list=20 >>>>>> SLIM@ietf.org =20 >>>>>> https://www.ietf.org/mailman/listinfo/slim = =20 >>>>>=20 >>>>>=20 >>>>=20 >>>> --=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 = >>>=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 >> ----------------------------------------- >> Gunnar Hellstr=F6m >> Omnitor >> gunnar.hellstrom@omnitor.se >> +46 708 204 288 >>=20 >>=20 >> _______________________________________________ >> SLIM mailing list >> SLIM@ietf.org >> https://www.ietf.org/mailman/listinfo/slim = >=20 > --=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 --Apple-Mail=_3D5DC423-17B4-42DE-825F-BE63C00A7CB5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I personally don=92t want to have anything like =93main = preference=94  or grouping that confuses the per-media = characteristic of SDP.

Brian


On May 20, 2016, at 2:55 AM, Gunnar Hellstr=F6m <gunnar.hellstrom@omnitor.se> wrote:

=20 =20

I = have a compromise proposal. Let us test if we can get somewhere by introducing it.

Let us delete the use of the = asterisk '*' for the 'do not drop' notation, and let 'do not drop' be the default.

Let= us reuse the asterisk attached to the end of a language tag be used for both a priority indication with the whole sdp as scope, and an indication of grouping.

Initial = change proposals ( there will be more follow-up changes, but these are the main ones )

---------------change in 6.2 = from---------------------------------------------------------------

 In an offer, each language tag value =
MAY have an asterisk appended as
   the last character (after the registry value).  The asterisk
   indicates a request by the caller to not fail the call if there is no
   language in common.  See Section 6.3 for more information and
   discussion.
-------------------to-------------------------------------
 In an offer, language tag values MAY have an asterisk appended as
   the last character (after the registry value).  The asterisk
   indicates a main preference for the indicated language.  See Section 6.3=20
   for more information and discussion.
----------------------------end of change in 6.2---------------------

-------------------Replace 6.3 with =
this----------------------------------

6.3 Main preference

If a user has a strong preference for using a language over the other=20
indicated languages, this preference can be indicated by including an=20
asterisk '*' last in the value of the preferred language and direction=20=

indication.

One such preference indication can be used per direction to indicate=20
main preference. This preference has scope across all media.

Two or more such preference indications can be used per direction to=20
indicate a strong preference or capability to use the indicated =
languages
in the indicated direction simultaneously together.

Examples:
Example 1;  a calling user, who strongly prefers to use spoken English
 supported by reception of rapidly added text captioning of the received=20=

 speech can indicate this preference by the following abbreviated sdp.
 This indication can be used by the callee or by the involved services=20=

 to make efforts to invoke a way of adding text to the speech answers.=20=

=20
   m=3Daudio ...
    humintlang-send:en
    humintlang-recv:en*
   m=3Dtext ...
    humintlang-recv:en*
 =20
Example 2; a calling user, who prefers to use American sign language =
both
  ways, but want to indicate that text in English both ways is an =
accepted=20
  alternative on lower preference level can indicate this preference by =
the
  following abbreviated sdp:
  This indication can be used by the called party to make efforts to =
answer
  with sign language competent personnel, but if that is not available =
be=20
  assured that a text conversation will also be successful. =20
 
   m=3Dvideo ...
    humintlang-send:ase*
    humintlang-recv:ase*
   m=3Dtext ...
    humintlang-send:en
    humintlang-recv:en

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

Discussion: This compromise satisfies most use cases for = which global preference and grouping are needed, but has some drawbacks compared to a system with finer graded preferences.

1. For the grouping example above with receiving spoken = English and English text, it cannot be seen what is best if it is not possible to provide the combination. There is no clue if it would be reasonably possible to provide only text or only spoken English.

2. The notation is only usable for a = single preference combination.
 It is not possible to indicate a number of sign languages, = all preferred over typed English.
This drawback appears because the same notation is used for main preference as for grouping indication.

I want = anyway to provide this compromise proposal, because it does not introduce any extra complexity and it solves the main so far unsolved use cases.

/Gunnar


Den 2016-05-19 kl. 00:23, skrev = Gunnar Hellstr=F6m:
Den 2016-05-18 kl. 19:08, skrev Natasha Rooney:
Randall - the last edit we see of the doc is from March, is this the most recent one? If not can you submit an edit soon?
We had e-mail list discussion around April 8-10 under the subject "[Slim] Wording about selection in draft-ietf-slim-negotiating-human-language-01"
that ended with some agreed changes and some in-principle agreed changes but no agreed wording. That is what I refer to when I say I want to see what the latest edits ended up in.

That mainly covered the ambition to be more exact than RFC 4566 lang specification.

So, when we get that, we can judge:
1. If it is clear when the indications reflect a selection possibility or a combination requirement.

There are a couple of other things we need to modify also before progressing to any kind of consensus.

2. In 5. Delete our interpretation of the lang attribute. It is sufficient to say that it is not enough detailed because it does not provide directionality.

3. In 5. insert specification on how lang and humintlang relates. The easiest way is to say that lang should not be used in sdp where humintlang is used. Is that too drastic?

4. Do we really need the * parameter for "do not fail call" introduced in 6.2 and explained in 6.3?  It will be most = common to want to have that effect, thus requiring to add the * in most media specifications. Can we simplify the syntax by having "do not fail call" as the default and delete the description of the * ? I suggest that we delete it.
If not, the description of the syntax of how the * is included needs to be inserted in the syntax description in section 6.2 and an example added.

5. In this part of 6.2:
"In cases where the user
   wishes to use one media for sending and another for = receiving (such
   as a speech-impaired user who wishes to send using = text and receive
   using audio), one of the two MAY be unset.  In = cases where a media is
   not primarily intended for language (for example, a = video or audio
   stream intended for background only) both SHOULD be = unset.  In other
   cases, both SHOULD have the same values in the same = order.  The two
   SHOULD NOT be set to languages which are difficult to = match together"

Clarify that "two" and "both" refers to the humintlang-send and humintlang-recv attributes for a medium.
( the attribute names are too far back so when searching for what "two" and "both" refers to you end up in confusion).

6. And, yet another proposal to insert a simple indication for preference betweeen media, and one for distinguishing selection versus combination.
The needs come from accessibility needs, and fulfilling accessibility needs has strong policy support, so it would be bad to say that that must wait for another version of the document when we already now have specified the need.

--------------------------------------------------In 6.2 = insert:-------------------------------------------------------------------= ---
A single digit numeric value on a humintlang attribute represents a starting priority for the humintlang attributes of the same medium and direction, with one being the highest priority.  = If no such value is indicated, the value 1 is assumed. The priority value is increased by a value 0.1 for each humintlang attribute for the same media and direction.
An asterisk on a humintlang attribute alone or together with a priority number indicates that a language specified in the actual media and direction is wanted in combination with another modality in the same direction, also marked with an asterisk.

Examples:
m=3Daudio ...
humintlang-send:en
humintlang-recv:*
humintlang-recv:en
m=3Dtext ...
humintlang-recv:*
humintlang-recv:en

This means that the user want to send spoken English and receive a combination of both spoken and typed English simultaneously  = back.

m=3Dvideo ...
humintlang-send:ase
humintlang-recv:ase
m=3Dtext ...
humintlang-send:5
humintlang-send:en
humintlang-recv:5
humintlang-recv:en

This means that the user prefers to use American sign language both ways, but as a possible selection on lower preference level use text both ways.
---------------------------------------------------------end of insertion---------------------
 
The fact that the humintlang attribute now can have values that are not language tags needs to be reflected in a few other places in the draft.



 

 


All - In all our discussions I see two things that we want here: [1] we want a simple and easily implementable solution/s and [2] solution/s that cover all the use cases. I think we can agree that going ahead with a simple solutions which is extensible covers both of these needs. It allows us to get something out there which can be implemented, and it allows us to answer all the use cases with extensibility which we will work on next (I appreciate this isn=92t immediate but it=92s favourable to making a complex solution now which is too difficult to implement). All advice I have received on this has suggested this is the best route forward.
We can't wait with an extension for something we have a need for now.
The above addition no 6. is a simple notation for what we were missing.

Given we=92re well over the time that we should have agreed on this I suggest we call rough consensus for this here. I understand there may be some frustration, but really this method solves for both needs and so is = sensible.

Bernard and Alexey - please check this and input if you see fit!

Natasha

/Gunnar

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


On May 17, 2016, at 10:56 PM, Gunnar = Hellstr=F6m <gunnar.hellstrom@omnitor.se> wrote:

Den 2016-05-17 kl. 23:17, skrev Randall Gellens:

Gunnar,

I think we can start with what we have now: the offerer offers all media/languages it wants, and the answerer accepts those it supports.
Yes, but we need a bit more than we have today to express that. Language usage are logically linked.
In many cases this will be exactly what's desired, while in some cases there will be extra media that are not used.
I am not bothered about extra media. Offered media shall not be rejected just because they do not have agreed language contents.

This gives us something simple that has the best chance of rapid and wide deployment.  We can then build on this if need be.
We already have the need. 3GPP cannot use user profiles in emergency registration mode, so we need to be able to express user needs this way to the degree that they can be served well in emergency calls.
For that we need to
clarify language in some places in the draft so that we do not end up equally fuzzy as RFC 4566,
We need to delete our interpretation of RFC 4566,
we need to express preference with scope among all media.
and we need to express when languages are needed together and when they are to select from.

You have accepted some edit proposals that we have discussed and modified others to something that we have not  yet seen. I would like to see the draft as it = is now so that we can see what more needs to be changed. =  



At 8:01 AM +0200 5/17/16, Gunnar Hellstr=F6m wrote: =

 Randall, =

 Can you accept that our goal is to select the = most appropriate language(s) for the call?

 This includes providing guidance to the = answering part so that the answer can be made in the most appropriate language(s).

 That is stated in the charter:

 "While the two use cases are in different = contexts (real time and
 non-real-time), the fundamental goal is the = same: to enable selection of
 the best-fit language(s) for a specific = situation. "

 It is not sufficient to use the indications to select which media shall be enabled, and then let the users sort out which language to use.

 The user needs guidance if it is most = appropriate to start the conversation in voice, sign language or text or a combination of these modalities. If not, the call will start with confusion about what is the most efficient means for them to communicate.

 That is why the preference indication needs to have:

 a) a common scope over all media, and

 b) an indication if two modalities = simultaneously are desired for reception.

 Can we agree on that and move on to find a = simple way of expressing these needs?

 /Gunnar




 Den 2016-05-17 kl. 05:25, skrev Randall = Gellens:

 At 8:28 = PM -0600 5/16/16, Doug Ewell wrote:

 Except = that there is still disagreement on whether the mechanism is needed for SLIM 1.0.


 And we have a call for consensus by the = chairs.


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

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



--=20
-----------------------------------------
Gunnar Hellstr=F6m
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288
_______________________________________________
SLIM mailing list
SLIM@ietf.org
https://www.ietf.org/m= ailman/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. 


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


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


--=20
-----------------------------------------
Gunnar Hellstr=F6m
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288
_______________________________________________
SLIM = mailing list
SLIM@ietf.org
https://www.ietf.org/mailman/listinfo/slim

= --Apple-Mail=_3D5DC423-17B4-42DE-825F-BE63C00A7CB5-- From nobody Fri May 20 12:29: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 46FAB12D613 for ; Fri, 20 May 2016 12:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 7f9r_IPkR_Pp for ; Fri, 20 May 2016 12:29:35 -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 E13F712D5FF for ; Fri, 20 May 2016 12:29:34 -0700 (PDT) X-Halon-ID: 23682121-1ec1-11e6-8615-005056917f90 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.4] (unknown [87.96.161.49]) by bin-vsp-out-02.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Fri, 20 May 2016 21:29:15 +0200 (CEST) To: slim@ietf.org References: <20160516083958.665a7a7059d7ee80bb4d670165c8327d.5e281af085.wbe@email0 3.godaddy.com> <7C5A334F88FD45E0A7770AFA6CB33C82@DougEwell> <57289c9f-a63a-0466-eeb7-845f1f1421ae@omnitor.se> <363ab6da-abdb-357b-e942-5284b085d451@omnitor.se> <405724e5-61aa-1144-6a2c-7c08fb599c98@omnitor.se> <434a2375-f806-a326-6137-706f1d7d9f92@omnitor.se> <4C5ADDF5-6D93-4A8E-9EE7-D116217BAADA@brianrosen.net> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <882047f1-cb9c-1093-9f03-80475b56d6d9@omnitor.se> Date: Fri, 20 May 2016 21:29:20 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <4C5ADDF5-6D93-4A8E-9EE7-D116217BAADA@brianrosen.net> Content-Type: multipart/alternative; boundary="------------A311994138721341917F81A2" Archived-At: Subject: Re: [Slim] Seeking rough consensus for draft-ietf-slim-negotiating-human-language - compromise proposal 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, 20 May 2016 19:29:40 -0000 This is a multi-part message in MIME format. --------------A311994138721341917F81A2 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Den 2016-05-20 kl. 20:01, skrev Brian Rosen: > I personally don’t want to have anything like “main preference” or > grouping that confuses the per-media characteristic of SDP. But looking at the needs of users and service providers, there are logical relations between media. They do not need to influence the decision on which media to start, but to which terminal to route the call, and what info to provide to the answering party and possibly what extra service to link in on the call. All these are depending on relations between language in different media, so I cannot see how we can avoid at least the proposed minimal form of preference across media and minimal grouping. Can you accept it even if you do not want it? Was this compromise proposal better than the previous one with explicit preference value per list of humintlang attributes? /Gunnar > > Brian > > >> On May 20, 2016, at 2:55 AM, Gunnar Hellström >> > wrote: >> >> I have a compromise proposal. Let us test if we can get somewhere by >> introducing it. >> >> Let us delete the use of the asterisk '*' for the 'do not drop' >> notation, and let 'do not drop' be the default. >> >> Let us reuse the asterisk attached to the end of a language tag be >> used for both a priority indication with the whole sdp as scope, and >> an indication of grouping. >> >> Initial change proposals ( there will be more follow-up changes, but >> these are the main ones ) >> >> ---------------change in 6.2 >> from--------------------------------------------------------------- >> >> In an offer, each language tag value MAY have an asterisk appended as >> the last character (after the registry value). The asterisk >> indicates a request by the caller to not fail the call if there is no >> language in common. SeeSection 6.3 >> for more information and >> discussion. >> -------------------to------------------------------------- >> In an offer, language tag values MAY have an asterisk appended as >> the last character (after the registry value). The asterisk >> indicates a main preference for the indicated language. SeeSection 6.3 >> >> for more information and discussion. >> ----------------------------end of change in 6.2--------------------- >> >> -------------------Replace 6.3 with this---------------------------------- >> >> 6.3 Main preference >> >> If a user has a strong preference for using a language over the other >> indicated languages, this preference can be indicated by including an >> asterisk '*' last in the value of the preferred language and direction >> indication. >> >> One such preference indication can be used per direction to indicate >> main preference. This preference has scope across all media. >> >> Two or more such preference indications can be used per direction to >> indicate a strong preference or capability to use the indicated languages >> in the indicated direction simultaneously together. >> >> Examples: >> Example 1; a calling user, who strongly prefers to use spoken English >> supported by reception of rapidly added text captioning of the received >> speech can indicate this preference by the following abbreviated sdp. >> This indication can be used by the callee or by the involved services >> to make efforts to invoke a way of adding text to the speech answers. >> >> m=audio ... >> humintlang-send:en >> humintlang-recv:en* >> m=text ... >> humintlang-recv:en* >> >> Example 2; a calling user, who prefers to use American sign language both >> ways, but want to indicate that text in English both ways is an accepted >> alternative on lower preference level can indicate this preference by the >> following abbreviated sdp: >> This indication can be used by the called party to make efforts to answer >> with sign language competent personnel, but if that is not available be >> assured that a text conversation will also be successful. >> >> m=video ... >> humintlang-send:ase* >> humintlang-recv:ase* >> m=text ... >> humintlang-send:en >> humintlang-recv:en >> >> -------------------------------end of >> changes------------------------------------------------ >> >> Discussion: This compromise satisfies most use cases for which global >> preference and grouping are needed, but has some drawbacks compared >> to a system with finer graded preferences. >> >> 1. For the grouping example above with receiving spoken English and >> English text, it cannot be seen what is best if it is not possible to >> provide the combination. There is no clue if it would be reasonably >> possible to provide only text or only spoken English. >> >> 2. The notation is only usable for a single preference combination. >> It is not possible to indicate a number of sign languages, all >> preferred over typed English. >> This drawback appears because the same notation is used for main >> preference as for grouping indication. >> >> I want anyway to provide this compromise proposal, because it does >> not introduce any extra complexity and it solves the main so far >> unsolved use cases. >> >> /Gunnar >> >> >> Den 2016-05-19 kl. 00:23, skrev Gunnar Hellström: >>> Den 2016-05-18 kl. 19:08, skrev Natasha Rooney: >>>> Randall - the last edit we see of the doc is from March, is this >>>> the most recent one? If not can you submit an edit soon? >>> We had e-mail list discussion around April 8-10 under the subject >>> "[Slim] Wording about selection in >>> draft-ietf-slim-negotiating-human-language-01" >>> that ended with some agreed changes and some in-principle agreed >>> changes but no agreed wording. That is what I refer to when I say I >>> want to see what the latest edits ended up in. >>> >>> That mainly covered the ambition to be more exact than RFC 4566 lang >>> specification. >>> >>> So, when we get that, we can judge: >>> 1. If it is clear when the indications reflect a selection >>> possibility or a combination requirement. >>> >>> There are a couple of other things we need to modify also before >>> progressing to any kind of consensus. >>> >>> 2. In 5. Delete our interpretation of the lang attribute. It is >>> sufficient to say that it is not enough detailed because it does not >>> provide directionality. >>> >>> 3. In 5. insert specification on how lang and humintlang relates. >>> The easiest way is to say that lang should not be used in sdp where >>> humintlang is used. Is that too drastic? >>> >>> 4. Do we really need the * parameter for "do not fail call" >>> introduced in 6.2 and explained in 6.3? It will be most common to >>> want to have that effect, thus requiring to add the * in most media >>> specifications. Can we simplify the syntax by having "do not fail >>> call" as the default and delete the description of the * ? I suggest >>> that we delete it. >>> If not, the description of the syntax of how the * is included needs >>> to be inserted in the syntax description in section 6.2 and an >>> example added. >>> >>> 5. In this part of 6.2: >>> "In cases where the user >>> wishes to use one media for sending and another for receiving (such >>> as a speech-impaired user who wishes to send using text and receive >>> using audio), one of the two MAY be unset. In cases where a media is >>> not primarily intended for language (for example, a video or audio >>> stream intended for background only) both SHOULD be unset. In other >>> cases, both SHOULD have the same values in the same order. The two >>> SHOULD NOT be set to languages which are difficult to match together" >>> >>> Clarify that "two" and "both" refers to the humintlang-send and >>> humintlang-recv attributes for a medium. >>> ( the attribute names are too far back so when searching for what >>> "two" and "both" refers to you end up in confusion). >>> >>> 6. And, yet another proposal to insert a simple indication for >>> preference betweeen media, and one for distinguishing selection >>> versus combination. >>> The needs come from accessibility needs, and fulfilling >>> accessibility needs has strong policy support, so it would be bad to >>> say that that must wait for another version of the document when we >>> already now have specified the need. >>> >>> --------------------------------------------------In 6.2 >>> insert:---------------------------------------------------------------------- >>> A single digit numeric value on a humintlang attribute represents a >>> starting priority for the humintlang attributes of the same medium >>> and direction, with one being the highest priority. If no such >>> value is indicated, the value 1 is assumed. The priority value is >>> increased by a value 0.1 for each humintlang attribute for the same >>> media and direction. >>> An asterisk on a humintlang attribute alone or together with a >>> priority number indicates that a language specified in the actual >>> media and direction is wanted in combination with another modality >>> in the same direction, also marked with an asterisk. >>> >>> Examples: >>> m=audio ... >>> humintlang-send:en >>> humintlang-recv:* >>> humintlang-recv:en >>> m=text ... >>> humintlang-recv:* >>> humintlang-recv:en >>> >>> This means that the user want to send spoken English and receive a >>> combination of both spoken and typed English simultaneously back. >>> >>> m=video ... >>> humintlang-send:ase >>> humintlang-recv:ase >>> m=text ... >>> humintlang-send:5 >>> humintlang-send:en >>> humintlang-recv:5 >>> humintlang-recv:en >>> >>> This means that the user prefers to use American sign language both >>> ways, but as a possible selection on lower preference level use text >>> both ways. >>> ---------------------------------------------------------end of >>> insertion--------------------- >>> >>> The fact that the humintlang attribute now can have values that are >>> not language tags needs to be reflected in a few other places in the >>> draft. >>> >>> >>> >>> >>> >>> >>> >>>> >>>> All - In all our discussions I see two things that we want here: >>>> [1] we want a simple and easily implementable solution/s and [2] >>>> solution/s that cover all the use cases. I think we can agree that >>>> going ahead with a simple solutions which is extensible covers both >>>> of these needs. It allows us to get something out there which can >>>> be implemented, and it allows us to answer all the use cases with >>>> extensibility which we will work on next (I appreciate this isn’t >>>> immediate but it’s favourable to making a complex solution now >>>> which is too difficult to implement). All advice I have received on >>>> this has suggested this is the best route forward. >>> We can't wait with an extension for something we have a need for now. >>> The above addition no 6. is a simple notation for what we were missing. >>>> >>>> Given we’re well over the time that we should have agreed on this I >>>> suggest we call rough consensus for this here. I understand there >>>> may be some frustration, but really this method solves for both >>>> needs and so is sensible. >>>> >>>> Bernard and Alexey - please check this and input if you see fit! >>>> >>>> Natasha >>>> >>> /Gunnar >>>> >>>> Natasha Rooney | Technologist, Web and Internet, W3C & IETF | GSMA >>>> | nrooney@gsma.com | +44 (0) 7730 219 765 >>>> | @thisNatasha | Skype: nrooney@gsm.org >>>> >>>> >>>>> On May 17, 2016, at 10:56 PM, Gunnar Hellström >>>>> > >>>>> wrote: >>>>> >>>>> Den 2016-05-17 kl. 23:17, skrev Randall Gellens: >>>>> >>>>>> Gunnar, >>>>>> >>>>>> I think we can start with what we have now: the offerer offers >>>>>> all media/languages it wants, and the answerer accepts those it >>>>>> supports. >>>>> Yes, but we need a bit more than we have today to express that. >>>>> Language usage are logically linked. >>>>>> In many cases this will be exactly what's desired, while in some >>>>>> cases there will be extra media that are not used. >>>>> I am not bothered about extra media. Offered media shall not be >>>>> rejected just because they do not have agreed language contents. >>>>>> >>>>>> This gives us something simple that has the best chance of rapid >>>>>> and wide deployment. We can then build on this if need be. >>>>> We already have the need. 3GPP cannot use user profiles in >>>>> emergency registration mode, so we need to be able to express user >>>>> needs this way to the degree that they can be served well in >>>>> emergency calls. >>>>> For that we need to >>>>> clarify language in some places in the draft so that we do not end >>>>> up equally fuzzy as RFC 4566, >>>>> We need to delete our interpretation of RFC 4566, >>>>> we need to express preference with scope among all media. >>>>> and we need to express when languages are needed together and when >>>>> they are to select from. >>>>> >>>>> You have accepted some edit proposals that we have discussed and >>>>> modified others to something that we have not yet seen. I would >>>>> like to see the draft as it is now so that we can see what more >>>>> needs to be changed. >>>>> >>>>>> >>>>>> >>>>>> At 8:01 AM +0200 5/17/16, Gunnar Hellström wrote: >>>>>> >>>>>>> Randall, >>>>>>> >>>>>>> Can you accept that our goal is to select the most appropriate >>>>>>> language(s) for the call? >>>>>>> >>>>>>> This includes providing guidance to the answering part so that >>>>>>> the answer can be made in the most appropriate language(s). >>>>>>> >>>>>>> That is stated in the charter: >>>>>>> >>>>>>> "While the two use cases are in different contexts (real time and >>>>>>> non-real-time), the fundamental goal is the same: to enable >>>>>>> selection of >>>>>>> the best-fit language(s) for a specific situation. " >>>>>>> >>>>>>> It is not sufficient to use the indications to select which >>>>>>> media shall be enabled, and then let the users sort out which >>>>>>> language to use. >>>>>>> >>>>>>> The user needs guidance if it is most appropriate to start the >>>>>>> conversation in voice, sign language or text or a combination of >>>>>>> these modalities. If not, the call will start with confusion >>>>>>> about what is the most efficient means for them to communicate. >>>>>>> >>>>>>> That is why the preference indication needs to have: >>>>>>> >>>>>>> a) a common scope over all media, and >>>>>>> >>>>>>> b) an indication if two modalities simultaneously are desired >>>>>>> for reception. >>>>>>> >>>>>>> Can we agree on that and move on to find a simple way of >>>>>>> expressing these needs? >>>>>>> >>>>>>> /Gunnar >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Den 2016-05-17 kl. 05:25, skrev Randall Gellens: >>>>>>> >>>>>>>> At 8:28 PM -0600 5/16/16, Doug Ewell wrote: >>>>>>>> >>>>>>>>> Except that there is still disagreement on whether the >>>>>>>>> mechanism is needed for SLIM 1.0. >>>>>>>>> >>>>>>>> >>>>>>>> And we have a call for consensus by the chairs. >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> ----------------------------------------- >>>>>>> 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 >>>> >>>> This email and its attachments are intended for the above named >>>> only and may be confidential. If they have come to you in error you >>>> must take no action based on them, nor must you copy or show them >>>> to anyone; please reply to this email or call +44 207 356 0600 and >>>> highlight the error. >>>> >>> >>> -- >>> ----------------------------------------- >>> Gunnar Hellström >>> Omnitor >>> gunnar.hellstrom@omnitor.se >>> +46 708 204 288 >>> >>> >>> _______________________________________________ >>> SLIM mailing list >>> SLIM@ietf.org >>> https://www.ietf.org/mailman/listinfo/slim >> >> -- >> ----------------------------------------- >> Gunnar Hellström >> Omnitor >> gunnar.hellstrom@omnitor.se >> +46 708 204 288 >> _______________________________________________ >> SLIM mailing list >> SLIM@ietf.org >> https://www.ietf.org/mailman/listinfo/slim > > > > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 --------------A311994138721341917F81A2 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Den 2016-05-20 kl. 20:01, skrev Brian Rosen:

I personally don’t want to have anything like “main preference”  or grouping that confuses the per-media characteristic of SDP.
But looking at the needs of users and service providers, there are logical relations between media.
They do not need to influence the decision on which media to start, but to which terminal to route the call, and what info to provide to the answering party and possibly what extra service to link in on the call.  All these are depending on relations between language in different media, so I cannot see how we can avoid at least the proposed minimal form of preference across media and minimal grouping.

Can you accept it even if you do not want it?

Was this compromise proposal better than the previous one with explicit preference value per list of humintlang attributes?

/Gunnar

Brian


On May 20, 2016, at 2:55 AM, Gunnar Hellström <gunnar.hellstrom@omnitor.se> wrote:

I have a compromise proposal. Let us test if we can get somewhere by introducing it.

Let us delete the use of the asterisk '*' for the 'do not drop' notation, and let 'do not drop' be the default.

Let us reuse the asterisk attached to the end of a language tag be used for both a priority indication with the whole sdp as scope, and an indication of grouping.

Initial change proposals ( there will be more follow-up changes, but these are the main ones )

---------------change in 6.2 from---------------------------------------------------------------

 In an offer, each language tag value MAY have an asterisk appended as
   the last character (after the registry value).  The asterisk
   indicates a request by the caller to not fail the call if there is no
   language in common.  See Section 6.3 for more information and
   discussion.
-------------------to-------------------------------------
 In an offer, language tag values MAY have an asterisk appended as
   the last character (after the registry value).  The asterisk
   indicates a main preference for the indicated language.  See Section 6.3 
   for more information and discussion.
----------------------------end of change in 6.2---------------------

-------------------Replace 6.3 with this----------------------------------

6.3 Main preference

If a user has a strong preference for using a language over the other 
indicated languages, this preference can be indicated by including an 
asterisk '*' last in the value of the preferred language and direction 
indication.

One such preference indication can be used per direction to indicate 
main preference. This preference has scope across all media.

Two or more such preference indications can be used per direction to 
indicate a strong preference or capability to use the indicated languages
in the indicated direction simultaneously together.

Examples:
Example 1;  a calling user, who strongly prefers to use spoken English
 supported by reception of rapidly added text captioning of the received 
 speech can indicate this preference by the following abbreviated sdp.
 This indication can be used by the callee or by the involved services 
 to make efforts to invoke a way of adding text to the speech answers. 
 
   m=audio ...
    humintlang-send:en
    humintlang-recv:en*
   m=text ...
    humintlang-recv:en*
  
Example 2; a calling user, who prefers to use American sign language both
  ways, but want to indicate that text in English both ways is an accepted 
  alternative on lower preference level can indicate this preference by the
  following abbreviated sdp:
  This indication can be used by the called party to make efforts to answer
  with sign language competent personnel, but if that is not available be 
  assured that a text conversation will also be successful.  
 
   m=video ...
    humintlang-send:ase*
    humintlang-recv:ase*
   m=text ...
    humintlang-send:en
    humintlang-recv:en

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

Discussion: This compromise satisfies most use cases for which global preference and grouping are needed, but has some drawbacks compared to a system with finer graded preferences.

1. For the grouping example above with receiving spoken English and English text, it cannot be seen what is best if it is not possible to provide the combination. There is no clue if it would be reasonably possible to provide only text or only spoken English.

2. The notation is only usable for a single preference combination.
 It is not possible to indicate a number of sign languages, all preferred over typed English.
This drawback appears because the same notation is used for main preference as for grouping indication.

I want anyway to provide this compromise proposal, because it does not introduce any extra complexity and it solves the main so far unsolved use cases.

/Gunnar


Den 2016-05-19 kl. 00:23, skrev Gunnar Hellström:
Den 2016-05-18 kl. 19:08, skrev Natasha Rooney:
Randall - the last edit we see of the doc is from March, is this the most recent one? If not can you submit an edit soon?
We had e-mail list discussion around April 8-10 under the subject "[Slim] Wording about selection in draft-ietf-slim-negotiating-human-language-01"
that ended with some agreed changes and some in-principle agreed changes but no agreed wording. That is what I refer to when I say I want to see what the latest edits ended up in.

That mainly covered the ambition to be more exact than RFC 4566 lang specification.

So, when we get that, we can judge:
1. If it is clear when the indications reflect a selection possibility or a combination requirement.

There are a couple of other things we need to modify also before progressing to any kind of consensus.

2. In 5. Delete our interpretation of the lang attribute. It is sufficient to say that it is not enough detailed because it does not provide directionality.

3. In 5. insert specification on how lang and humintlang relates. The easiest way is to say that lang should not be used in sdp where humintlang is used. Is that too drastic?

4. Do we really need the * parameter for "do not fail call" introduced in 6.2 and explained in 6.3?  It will be most common to want to have that effect, thus requiring to add the * in most media specifications. Can we simplify the syntax by having "do not fail call" as the default and delete the description of the * ? I suggest that we delete it.
If not, the description of the syntax of how the * is included needs to be inserted in the syntax description in section 6.2 and an example added.

5. In this part of 6.2:
"In cases where the user
   wishes to use one media for sending and another for receiving (such
   as a speech-impaired user who wishes to send using text and receive
   using audio), one of the two MAY be unset.  In cases where a media is
   not primarily intended for language (for example, a video or audio
   stream intended for background only) both SHOULD be unset.  In other
   cases, both SHOULD have the same values in the same order.  The two
   SHOULD NOT be set to languages which are difficult to match together"

Clarify that "two" and "both" refers to the humintlang-send and humintlang-recv attributes for a medium.
( the attribute names are too far back so when searching for what "two" and "both" refers to you end up in confusion).

6. And, yet another proposal to insert a simple indication for preference betweeen media, and one for distinguishing selection versus combination.
The needs come from accessibility needs, and fulfilling accessibility needs has strong policy support, so it would be bad to say that that must wait for another version of the document when we already now have specified the need.

--------------------------------------------------In 6.2 insert:----------------------------------------------------------------------
A single digit numeric value on a humintlang attribute represents a starting priority for the humintlang attributes of the same medium and direction, with one being the highest priority.  If no such value is indicated, the value 1 is assumed. The priority value is increased by a value 0.1 for each humintlang attribute for the same media and direction.
An asterisk on a humintlang attribute alone or together with a priority number indicates that a language specified in the actual media and direction is wanted in combination with another modality in the same direction, also marked with an asterisk.

Examples:
m=audio ...
humintlang-send:en
humintlang-recv:*
humintlang-recv:en
m=text ...
humintlang-recv:*
humintlang-recv:en

This means that the user want to send spoken English and receive a combination of both spoken and typed English simultaneously  back.

m=video ...
humintlang-send:ase
humintlang-recv:ase
m=text ...
humintlang-send:5
humintlang-send:en
humintlang-recv:5
humintlang-recv:en

This means that the user prefers to use American sign language both ways, but as a possible selection on lower preference level use text both ways.
---------------------------------------------------------end of insertion---------------------
 
The fact that the humintlang attribute now can have values that are not language tags needs to be reflected in a few other places in the draft.



 

 


All - In all our discussions I see two things that we want here: [1] we want a simple and easily implementable solution/s and [2] solution/s that cover all the use cases. I think we can agree that going ahead with a simple solutions which is extensible covers both of these needs. It allows us to get something out there which can be implemented, and it allows us to answer all the use cases with extensibility which we will work on next (I appreciate this isn’t immediate but it’s favourable to making a complex solution now which is too difficult to implement). All advice I have received on this has suggested this is the best route forward.
We can't wait with an extension for something we have a need for now.
The above addition no 6. is a simple notation for what we were missing.

Given we’re well over the time that we should have agreed on this I suggest we call rough consensus for this here. I understand there may be some frustration, but really this method solves for both needs and so is sensible.

Bernard and Alexey - please check this and input if you see fit!

Natasha

/Gunnar

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


On May 17, 2016, at 10:56 PM, Gunnar Hellström <gunnar.hellstrom@omnitor.se> wrote:

Den 2016-05-17 kl. 23:17, skrev Randall Gellens:

Gunnar,

I think we can start with what we have now: the offerer offers all media/languages it wants, and the answerer accepts those it supports.
Yes, but we need a bit more than we have today to express that. Language usage are logically linked.
In many cases this will be exactly what's desired, while in some cases there will be extra media that are not used.
I am not bothered about extra media. Offered media shall not be rejected just because they do not have agreed language contents.

This gives us something simple that has the best chance of rapid and wide deployment.  We can then build on this if need be.
We already have the need. 3GPP cannot use user profiles in emergency registration mode, so we need to be able to express user needs this way to the degree that they can be served well in emergency calls.
For that we need to
clarify language in some places in the draft so that we do not end up equally fuzzy as RFC 4566,
We need to delete our interpretation of RFC 4566,
we need to express preference with scope among all media.
and we need to express when languages are needed together and when they are to select from.

You have accepted some edit proposals that we have discussed and modified others to something that we have not  yet seen. I would like to see the draft as it is now so that we can see what more needs to be changed.  



At 8:01 AM +0200 5/17/16, Gunnar Hellström wrote:

 Randall,

 Can you accept that our goal is to select the most appropriate language(s) for the call?

 This includes providing guidance to the answering part so that the answer can be made in the most appropriate language(s).

 That is stated in the charter:

 "While the two use cases are in different contexts (real time and
 non-real-time), the fundamental goal is the same: to enable selection of
 the best-fit language(s) for a specific situation. "

 It is not sufficient to use the indications to select which media shall be enabled, and then let the users sort out which language to use.

 The user needs guidance if it is most appropriate to start the conversation in voice, sign language or text or a combination of these modalities. If not, the call will start with confusion about what is the most efficient means for them to communicate.

 That is why the preference indication needs to have:

 a) a common scope over all media, and

 b) an indication if two modalities simultaneously are desired for reception.

 Can we agree on that and move on to find a simple way of expressing these needs?

 /Gunnar




 Den 2016-05-17 kl. 05:25, skrev Randall Gellens:

 At 8:28 PM -0600 5/16/16, Doug Ewell wrote:

 Except that there is still disagreement on whether the mechanism is needed for SLIM 1.0.


 And we have a call for consensus by the chairs.


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

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



-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288
_______________________________________________
SLIM mailing list
SLIM@ietf.org
https://www.ietf.org/mailman/listinfo/slim

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


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


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


-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288
_______________________________________________
SLIM mailing list
SLIM@ietf.org
https://www.ietf.org/mailman/listinfo/slim



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


-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288
--------------A311994138721341917F81A2-- From nobody Fri May 20 12:45:01 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 13BB712D4FD for ; Fri, 20 May 2016 12:45:00 -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 ExaQ753ciDgh for ; Fri, 20 May 2016 12:44:56 -0700 (PDT) Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA86D12D5CE for ; Fri, 20 May 2016 12:44:55 -0700 (PDT) Received: by mail-qg0-x22f.google.com with SMTP id w36so65710515qge.3 for ; Fri, 20 May 2016 12:44:55 -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=RFGEauowYJ0+8BvNJsXKjyIT70TP/sUoT0Ju7YxkoPY=; b=GDmtzdeDgR+iU3aRC/YclhEoJjYtgogoCnv1ge/Azip9thSoYWfb1BdbGJnHVWi+Lr 6wJPDiCUTHZSw3AcN/4ZiYc7wJJMpl/LylDSSN4vu6G1wOqPdc4jGdKqFurSvZet4Wk4 UUr72cZ+hquL+2s5bIAMiG75rmyZhzWtz/LggyXuAy2ede8vzNcYw3VY/qtYgC+bYvtO tnR7ihl9+hsWKRCbdgkQEHmGdjCU3qBGl3Tl03zEsgcKH98l87jflfGjANUnwUruBHGO wugyfkzOJ6VfSn12YfamNt8lVpnWP37K+/czChER7kkquDuXrkY1oBcFSBcs6WhZQhqh 56bA== 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=RFGEauowYJ0+8BvNJsXKjyIT70TP/sUoT0Ju7YxkoPY=; b=mCbplrRsog7HbMsPEZPYSlWa/g+kap57Csst1/a6hTT6fz5BLTj1+O5YTPWBksnhgg 9AHuo1PeUSiCNKI4XpLSDq/ukUDlJbpDkm3aHj3E1GNEdVn67uMSGBhCHFzF2WwRdOHw Ca57nRCTTFBBftz4pnZvtodkYhfyuE38V7ZzGid7EUAoFowiU1exUtbLrHKbY7G+9nfe +Kl/UujSUvxjVHndqK7U8VL1Ac7zAmtEjTLLIb7SNZUXw9WHSe4bIZ8h2An3AhmM/sRy MaQFlEtnjlzKbbxKP9Ge5BBP1dv7IUXRrUPfWCwqxT0MdGcFCCJZAR0P1Hz84jgzPBAN r0RA== X-Gm-Message-State: AOPr4FXBFF1gBJAwOO3V37Ey2tgqHx0H+wgOcqlAAwkMpO3Dtkm3YJ7J6jCZYoLAuuDrhA== X-Received: by 10.140.38.111 with SMTP id s102mr5171524qgs.32.1463773494674; Fri, 20 May 2016 12:44:54 -0700 (PDT) Received: from [10.33.192.30] ([156.154.81.54]) by smtp.gmail.com with ESMTPSA id y67sm9340752qhb.43.2016.05.20.12.44.53 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 20 May 2016 12:44:54 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_4CDAB49C-60A4-4C83-8C70-9A19E2D9591C" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Brian Rosen In-Reply-To: <882047f1-cb9c-1093-9f03-80475b56d6d9@omnitor.se> Date: Fri, 20 May 2016 15:44:51 -0400 Message-Id: <269AC87F-6928-4280-82B5-D5DEF9947CAB@brianrosen.net> References: <20160516083958.665a7a7059d7ee80bb4d670165c8327d.5e281af085.wbe@email0 3.godaddy.com> <7C5A334F88FD45E0A7770AFA6CB33C82@DougEwell> <57289c9f-a63a-0466-eeb7-845f1f1421ae@omnitor.se> <363ab6da-abdb-357b-e942-5284b085d451@omnitor.se> <405724e5-61aa-1144-6a2c-7c08fb599c98@omnitor.se> <434a2375-f806-a326-6137-706f1d7d9f92@omnitor.se> <4C5ADDF5-6D93-4A8E-9EE7-D116217BAADA@brianrosen.net> <882047f1-cb9c-1093-9f03-80475b56d6d9@omnitor.se> To: =?utf-8?Q?Gunnar_Hellstr=C3=B6m?= X-Mailer: Apple Mail (2.3124) Archived-At: Cc: slim@ietf.org Subject: Re: [Slim] Seeking rough consensus for draft-ietf-slim-negotiating-human-language - compromise proposal 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, 20 May 2016 19:45:00 -0000 --Apple-Mail=_4CDAB49C-60A4-4C83-8C70-9A19E2D9591C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 While I agree there are corner cases simpler mechanisms won=92t cover, I = think they are rare enough that the complexity introduced in every = implementation to allow the corner case to work is not acceptable. I am not in favor of adopting this proposal. I don=92t think either of these proposals is the right way to do = grouping, and I don=92t want to do grouping at this time, so arguing = over which is better is pointless. I=92d probably use RFC5888 as a = starting point and define groups of media and languages in the offer, = which the answer can select from. Brian > On May 20, 2016, at 3:29 PM, Gunnar Hellstr=F6m = wrote: >=20 > Den 2016-05-20 kl. 20:01, skrev Brian Rosen: >=20 >> I personally don=92t want to have anything like =93main preference=94 = or grouping that confuses the per-media characteristic of SDP. > But looking at the needs of users and service providers, there are = logical relations between media.=20 > They do not need to influence the decision on which media to start, = but to which terminal to route the call, and what info to provide to the = answering party and possibly what extra service to link in on the call. = All these are depending on relations between language in different = media, so I cannot see how we can avoid at least the proposed minimal = form of preference across media and minimal grouping. >=20 > Can you accept it even if you do not want it? >=20 > Was this compromise proposal better than the previous one with = explicit preference value per list of humintlang attributes? >=20 > /Gunnar >>=20 >> Brian >>=20 >>=20 >>> On May 20, 2016, at 2:55 AM, Gunnar Hellstr=F6m = > = wrote: >>>=20 >>> I have a compromise proposal. Let us test if we can get somewhere by = introducing it. >>>=20 >>> Let us delete the use of the asterisk '*' for the 'do not drop' = notation, and let 'do not drop' be the default. >>>=20 >>> Let us reuse the asterisk attached to the end of a language tag be = used for both a priority indication with the whole sdp as scope, and an = indication of grouping. >>>=20 >>> Initial change proposals ( there will be more follow-up changes, but = these are the main ones ) >>>=20 >>> ---------------change in 6.2 = from--------------------------------------------------------------- >>>=20 >>> In an offer, each language tag value MAY have an asterisk appended = as >>> the last character (after the registry value). The asterisk >>> indicates a request by the caller to not fail the call if there = is no >>> language in common. See Section 6.3 = for more information and >>> discussion. >>> -------------------to------------------------------------- >>> In an offer, language tag values MAY have an asterisk appended as >>> the last character (after the registry value). The asterisk >>> indicates a main preference for the indicated language. See = Section 6.3 = =20 >>> for more information and discussion. >>> ----------------------------end of change in = 6.2--------------------- >>>=20 >>> -------------------Replace 6.3 with = this---------------------------------- >>>=20 >>> 6.3 Main preference >>>=20 >>> If a user has a strong preference for using a language over the = other=20 >>> indicated languages, this preference can be indicated by including = an=20 >>> asterisk '*' last in the value of the preferred language and = direction=20 >>> indication. >>>=20 >>> One such preference indication can be used per direction to indicate=20= >>> main preference. This preference has scope across all media. >>>=20 >>> Two or more such preference indications can be used per direction to=20= >>> indicate a strong preference or capability to use the indicated = languages >>> in the indicated direction simultaneously together. >>>=20 >>> Examples: >>> Example 1; a calling user, who strongly prefers to use spoken = English >>> supported by reception of rapidly added text captioning of the = received=20 >>> speech can indicate this preference by the following abbreviated = sdp. >>> This indication can be used by the callee or by the involved = services=20 >>> to make efforts to invoke a way of adding text to the speech = answers.=20 >>> =20 >>> m=3Daudio ... >>> humintlang-send:en >>> humintlang-recv:en* >>> m=3Dtext ... >>> humintlang-recv:en* >>> =20 >>> Example 2; a calling user, who prefers to use American sign language = both >>> ways, but want to indicate that text in English both ways is an = accepted=20 >>> alternative on lower preference level can indicate this preference = by the >>> following abbreviated sdp: >>> This indication can be used by the called party to make efforts to = answer >>> with sign language competent personnel, but if that is not = available be=20 >>> assured that a text conversation will also be successful. =20 >>> =20 >>> m=3Dvideo ... >>> humintlang-send:ase* >>> humintlang-recv:ase* >>> m=3Dtext ... >>> humintlang-send:en >>> humintlang-recv:en >>> -------------------------------end of = changes------------------------------------------------ >>>=20 >>> Discussion: This compromise satisfies most use cases for which = global preference and grouping are needed, but has some drawbacks = compared to a system with finer graded preferences. >>>=20 >>> 1. For the grouping example above with receiving spoken English and = English text, it cannot be seen what is best if it is not possible to = provide the combination. There is no clue if it would be reasonably = possible to provide only text or only spoken English. >>>=20 >>> 2. The notation is only usable for a single preference combination.=20= >>> It is not possible to indicate a number of sign languages, all = preferred over typed English. >>> This drawback appears because the same notation is used for main = preference as for grouping indication. >>>=20 >>> I want anyway to provide this compromise proposal, because it does = not introduce any extra complexity and it solves the main so far = unsolved use cases. >>>=20 >>> /Gunnar >>>=20 >>>=20 >>>=20 >>> Den 2016-05-19 kl. 00:23, skrev Gunnar Hellstr=F6m: >>>> Den 2016-05-18 kl. 19:08, skrev Natasha Rooney: >>>>> Randall - the last edit we see of the doc is from March, is this = the most recent one? If not can you submit an edit soon? >>>> We had e-mail list discussion around April 8-10 under the subject = "[Slim] Wording about selection in = draft-ietf-slim-negotiating-human-language-01" >>>> that ended with some agreed changes and some in-principle agreed = changes but no agreed wording. That is what I refer to when I say I want = to see what the latest edits ended up in. >>>>=20 >>>> That mainly covered the ambition to be more exact than RFC 4566 = lang specification. >>>>=20 >>>> So, when we get that, we can judge: >>>> 1. If it is clear when the indications reflect a selection = possibility or a combination requirement.=20 >>>>=20 >>>> There are a couple of other things we need to modify also before = progressing to any kind of consensus.=20 >>>>=20 >>>> 2. In 5. Delete our interpretation of the lang attribute. It is = sufficient to say that it is not enough detailed because it does not = provide directionality. >>>>=20 >>>> 3. In 5. insert specification on how lang and humintlang relates. = The easiest way is to say that lang should not be used in sdp where = humintlang is used. Is that too drastic? >>>>=20 >>>> 4. Do we really need the * parameter for "do not fail call" = introduced in 6.2 and explained in 6.3? It will be most common to want = to have that effect, thus requiring to add the * in most media = specifications. Can we simplify the syntax by having "do not fail call" = as the default and delete the description of the * ? I suggest that we = delete it. >>>> If not, the description of the syntax of how the * is included = needs to be inserted in the syntax description in section 6.2 and an = example added. >>>>=20 >>>> 5. In this part of 6.2:=20 >>>> "In cases where the user >>>> wishes to use one media for sending and another for receiving = (such >>>> as a speech-impaired user who wishes to send using text and = receive >>>> using audio), one of the two MAY be unset. In cases where a = media is >>>> not primarily intended for language (for example, a video or = audio >>>> stream intended for background only) both SHOULD be unset. In = other >>>> cases, both SHOULD have the same values in the same order. The = two >>>> SHOULD NOT be set to languages which are difficult to match = together" >>>>=20 >>>> Clarify that "two" and "both" refers to the humintlang-send and = humintlang-recv attributes for a medium.=20 >>>> ( the attribute names are too far back so when searching for what = "two" and "both" refers to you end up in confusion). >>>>=20 >>>> 6. And, yet another proposal to insert a simple indication for = preference betweeen media, and one for distinguishing selection versus = combination. >>>> The needs come from accessibility needs, and fulfilling = accessibility needs has strong policy support, so it would be bad to say = that that must wait for another version of the document when we already = now have specified the need.=20 >>>>=20 >>>> --------------------------------------------------In 6.2 = insert:-------------------------------------------------------------------= --- >>>> A single digit numeric value on a humintlang attribute represents a = starting priority for the humintlang attributes of the same medium and = direction, with one being the highest priority. If no such value is = indicated, the value 1 is assumed. The priority value is increased by a = value 0.1 for each humintlang attribute for the same media and = direction.=20 >>>> An asterisk on a humintlang attribute alone or together with a = priority number indicates that a language specified in the actual media = and direction is wanted in combination with another modality in the same = direction, also marked with an asterisk. >>>>=20 >>>> Examples: >>>> m=3Daudio ... >>>> humintlang-send:en >>>> humintlang-recv:* >>>> humintlang-recv:en >>>> m=3Dtext ... >>>> humintlang-recv:* >>>> humintlang-recv:en >>>>=20 >>>> This means that the user want to send spoken English and receive a = combination of both spoken and typed English simultaneously back. >>>>=20 >>>> m=3Dvideo ... >>>> humintlang-send:ase >>>> humintlang-recv:ase >>>> m=3Dtext ... >>>> humintlang-send:5 >>>> humintlang-send:en >>>> humintlang-recv:5 >>>> humintlang-recv:en >>>>=20 >>>> This means that the user prefers to use American sign language both = ways, but as a possible selection on lower preference level use text = both ways. >>>> ---------------------------------------------------------end of = insertion--------------------- >>>> =20 >>>> The fact that the humintlang attribute now can have values that are = not language tags needs to be reflected in a few other places in the = draft. >>>>=20 >>>>=20 >>>>=20 >>>> =20 >>>>=20 >>>> =20 >>>>=20 >>>>>=20 >>>>> All - In all our discussions I see two things that we want here: = [1] we want a simple and easily implementable solution/s and [2] = solution/s that cover all the use cases. I think we can agree that going = ahead with a simple solutions which is extensible covers both of these = needs. It allows us to get something out there which can be implemented, = and it allows us to answer all the use cases with extensibility which we = will work on next (I appreciate this isn=92t immediate but it=92s = favourable to making a complex solution now which is too difficult to = implement). All advice I have received on this has suggested this is the = best route forward. >>>> We can't wait with an extension for something we have a need for = now. >>>> The above addition no 6. is a simple notation for what we were = missing. >>>>>=20 >>>>> Given we=92re well over the time that we should have agreed on = this I suggest we call rough consensus for this here. I understand there = may be some frustration, but really this method solves for both needs = and so is sensible. >>>>>=20 >>>>> Bernard and Alexey - please check this and input if you see fit! >>>>>=20 >>>>> Natasha >>>>>=20 >>>> /Gunnar >>>>>=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 >>>>>> On May 17, 2016, at 10:56 PM, Gunnar Hellstr=F6m < = gunnar.hellstrom@omnitor.se = > wrote: >>>>>>=20 >>>>>> Den 2016-05-17 kl. 23:17, skrev Randall Gellens: >>>>>>=20 >>>>>>> Gunnar,=20 >>>>>>>=20 >>>>>>> I think we can start with what we have now: the offerer offers = all media/languages it wants, and the answerer accepts those it = supports.=20 >>>>>> Yes, but we need a bit more than we have today to express that. = Language usage are logically linked. >>>>>>> In many cases this will be exactly what's desired, while in some = cases there will be extra media that are not used.=20 >>>>>> I am not bothered about extra media. Offered media shall not be = rejected just because they do not have agreed language contents. >>>>>>>=20 >>>>>>> This gives us something simple that has the best chance of rapid = and wide deployment. We can then build on this if need be. >>>>>> We already have the need. 3GPP cannot use user profiles in = emergency registration mode, so we need to be able to express user needs = this way to the degree that they can be served well in emergency calls.=20= >>>>>> For that we need to=20 >>>>>> clarify language in some places in the draft so that we do not = end up equally fuzzy as RFC 4566,=20 >>>>>> We need to delete our interpretation of RFC 4566, >>>>>> we need to express preference with scope among all media.=20 >>>>>> and we need to express when languages are needed together and = when they are to select from. >>>>>>=20 >>>>>> You have accepted some edit proposals that we have discussed and = modified others to something that we have not yet seen. I would like to = see the draft as it is now so that we can see what more needs to be = changed. =20 >>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> At 8:01 AM +0200 5/17/16, Gunnar Hellstr=F6m wrote:=20 >>>>>>>=20 >>>>>>>> Randall,=20 >>>>>>>>=20 >>>>>>>> Can you accept that our goal is to select the most appropriate = language(s) for the call?=20 >>>>>>>>=20 >>>>>>>> This includes providing guidance to the answering part so that = the answer can be made in the most appropriate language(s).=20 >>>>>>>>=20 >>>>>>>> That is stated in the charter:=20 >>>>>>>>=20 >>>>>>>> "While the two use cases are in different contexts (real time = and=20 >>>>>>>> non-real-time), the fundamental goal is the same: to enable = selection of=20 >>>>>>>> the best-fit language(s) for a specific situation. "=20 >>>>>>>>=20 >>>>>>>> It is not sufficient to use the indications to select which = media shall be enabled, and then let the users sort out which language = to use.=20 >>>>>>>>=20 >>>>>>>> The user needs guidance if it is most appropriate to start the = conversation in voice, sign language or text or a combination of these = modalities. If not, the call will start with confusion about what is the = most efficient means for them to communicate.=20 >>>>>>>>=20 >>>>>>>> That is why the preference indication needs to have:=20 >>>>>>>>=20 >>>>>>>> a) a common scope over all media, and=20 >>>>>>>>=20 >>>>>>>> b) an indication if two modalities simultaneously are desired = for reception.=20 >>>>>>>>=20 >>>>>>>> Can we agree on that and move on to find a simple way of = expressing these needs?=20 >>>>>>>>=20 >>>>>>>> /Gunnar=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Den 2016-05-17 kl. 05:25, skrev Randall Gellens:=20 >>>>>>>>=20 >>>>>>>>> At 8:28 PM -0600 5/16/16, Doug Ewell wrote:=20 >>>>>>>>>=20 >>>>>>>>>> Except that there is still disagreement on whether the = mechanism is needed for SLIM 1.0.=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> And we have a call for consensus by the chairs.=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>> --=20 >>>>>>>> -----------------------------------------=20 >>>>>>>> Gunnar Hellstr=F6m=20 >>>>>>>> Omnitor=20 >>>>>>>> = = gunnar.hellstrom@omnitor.se = =20 >>>>>>>> +46 708 204 288=20 >>>>>>>>=20 >>>>>>>> _______________________________________________=20 >>>>>>>> SLIM mailing list=20 >>>>>>>> SLIM@ietf.org =20 >>>>>>>> https://www.ietf.org/mailman/listinfo/slim = =20 >>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>> --=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 = >>>>>=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 >>>> --=20 >>>> ----------------------------------------- >>>> Gunnar Hellstr=F6m >>>> Omnitor >>>> gunnar.hellstrom@omnitor.se >>>> +46 708 204 288 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> SLIM mailing list >>>> SLIM@ietf.org >>>> https://www.ietf.org/mailman/listinfo/slim = >>>=20 >>> --=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 = >>=20 >>=20 >>=20 >> _______________________________________________ >> SLIM mailing list >> SLIM@ietf.org >> https://www.ietf.org/mailman/listinfo/slim = >=20 > --=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 = --Apple-Mail=_4CDAB49C-60A4-4C83-8C70-9A19E2D9591C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 While I agree there are corner cases simpler mechanisms won=92t= cover, I think they are rare enough that the complexity introduced in = every implementation to allow the corner case to work is not = acceptable.

I am not = in favor of adopting this proposal.

I don=92t think either of these = proposals is the right way to do grouping, and I don=92t want to do = grouping at this time, so arguing over which is better is pointless. =  I=92d probably use RFC5888 as a starting point and define groups = of media and languages in the offer, which the answer can select = from.

Brian

On = May 20, 2016, at 3:29 PM, Gunnar Hellstr=F6m <gunnar.hellstrom@omnitor.se> wrote:

Den 2016-05-20 kl. 20:01, skrev Brian Rosen:

I personally don=92t want to have = anything like =93main preference=94  or grouping that confuses the = per-media characteristic of SDP.
But looking at the needs of users and service = providers, there are logical relations between media. 
They do not need to influence the decision on which media to = start, but to which terminal to route the call, and what info to provide = to the answering party and possibly what extra service to link in on the = call.  All these are depending on relations between language in = different media, so I cannot see how we can avoid at least the proposed = minimal form of preference across media and minimal grouping.

Can you accept it even if you do not want = it?

Was this compromise = proposal better than the previous one with explicit preference value per = list of humintlang attributes?

/Gunnar

Brian


On May 20, 2016, at 2:55 AM, Gunnar Hellstr=F6m= <gunnar.hellstrom@omnitor.se> wrote:

I have a = compromise proposal. Let us test if we can get somewhere by introducing = it.

Let us delete the use of the asterisk '*' for the = 'do not drop' notation, and let 'do not drop' be the default.

Let us reuse the asterisk attached to the end of a language = tag be used for both a priority indication with the whole sdp as scope, = and an indication of grouping.

Initial change proposals = ( there will be more follow-up changes, but these are the main ones )

---------------change in 6.2 = from---------------------------------------------------------------

In an offer, each language tag value = MAY have an asterisk appended as the last character (after the registry value). The asterisk indicates a request by the caller to not fail the call if there is no language in common. See Section 6.3 for more information and discussion. -------------------to------------------------------------- In an offer, language tag values MAY have an asterisk appended as the last character (after the registry value). The asterisk indicates a main preference for the indicated language. See Section 6.3=20 for more information and discussion. ----------------------------end of change in 6.2--------------------- -------------------Replace 6.3 with = this---------------------------------- 6.3 Main preference If a user has a strong preference for using a language over the other=20 indicated languages, this preference can be indicated by including an=20 asterisk '*' last in the value of the preferred language and direction=20= indication. One such preference indication can be used per direction to indicate=20 main preference. This preference has scope across all media. Two or more such preference indications can be used per direction to=20 indicate a strong preference or capability to use the indicated = languages in the indicated direction simultaneously together. Examples: Example 1; a calling user, who strongly prefers to use spoken English supported by reception of rapidly added text captioning of the received=20= speech can indicate this preference by the following abbreviated sdp. This indication can be used by the callee or by the involved services=20= to make efforts to invoke a way of adding text to the speech answers.=20= =20 m=3Daudio ... humintlang-send:en humintlang-recv:en* m=3Dtext ... humintlang-recv:en* =20 Example 2; a calling user, who prefers to use American sign language = both ways, but want to indicate that text in English both ways is an = accepted=20 alternative on lower preference level can indicate this preference by = the following abbreviated sdp: This indication can be used by the called party to make efforts to = answer with sign language competent personnel, but if that is not available = be=20 assured that a text conversation will also be successful. =20   m=3Dvideo ... humintlang-send:ase* humintlang-recv:ase* m=3Dtext ... humintlang-send:en humintlang-recv:en

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

Discussion: This compromise satisfies most use cases for = which global preference and grouping are needed, but has some drawbacks = compared to a system with finer graded preferences.

1. = For the grouping example above with receiving spoken English and English = text, it cannot be seen what is best if it is not possible to provide = the combination. There is no clue if it would be reasonably possible to = provide only text or only spoken English.

2. The = notation is only usable for a single preference combination. 
 It is = not possible to indicate a number of sign languages, all preferred over = typed English.
This drawback appears because the same = notation is used for main preference as for grouping indication.

I want anyway to provide this compromise proposal, because it = does not introduce any extra complexity and it solves the main so far = unsolved use cases.

/Gunnar


Den 2016-05-19 kl. 00:23, skrev Gunnar = Hellstr=F6m:
Den 2016-05-18 kl. 19:08, = skrev Natasha Rooney:
Randall - the last edit we see of the doc is from March, is = this the most recent one? If not can you submit an edit soon?
We had e-mail list discussion around April 8-10 = under the subject "[Slim] Wording about selection in = draft-ietf-slim-negotiating-human-language-01"
that ended = with some agreed changes and some in-principle agreed changes but no = agreed wording. That is what I refer to when I say I want to see what = the latest edits ended up in.

That mainly = covered the ambition to be more exact than RFC 4566 lang = specification.

So, when we get that, we can = judge:
1. If it is clear when the indications reflect a = selection possibility or a combination requirement. 

There are a couple of other things we need to modify also = before progressing to any kind of consensus. 

2. In 5. Delete our interpretation of the lang attribute. It = is sufficient to say that it is not enough detailed because it does not = provide directionality.

3. In 5. insert = specification on how lang and humintlang relates. The easiest way is to = say that lang should not be used in sdp where humintlang is used. Is = that too drastic?

4. Do we really need the = * parameter for "do not fail call" introduced in 6.2 and explained in = 6.3?  It will be most common to want to have that effect, thus = requiring to add the * in most media specifications. Can we simplify the = syntax by having "do not fail call" as the default and delete the = description of the * ? I suggest that we delete it.
If = not, the description of the syntax of how the * is included needs to be = inserted in the syntax description in section 6.2 and an example = added.

5. In this part of 6.2: 
"In cases = where the user
   wishes to use one media for = sending and another for receiving (such
   as a speech-impaired user = who wishes to send using text and receive
   using audio), one of the = two MAY be unset.  In cases where a media is
   not primarily intended for = language (for example, a video or audio
   stream intended for = background only) both SHOULD be unset.  In other
   cases, both SHOULD have the = same values in the same order.  The two
   SHOULD NOT be set to = languages which are difficult to match together"

Clarify that "two" and "both" refers to the humintlang-send = and humintlang-recv attributes for a medium. 
( the = attribute names are too far back so when searching for what "two" and = "both" refers to you end up in confusion).

6.= And, yet another proposal to insert a simple indication for preference = betweeen media, and one for distinguishing selection versus = combination.
The needs come from accessibility needs, and = fulfilling accessibility needs has strong policy support, so it would be = bad to say that that must wait for another version of the document when = we already now have specified the need. 

--------------------------------------------------In 6.2 = insert:-------------------------------------------------------------------= ---
A single digit numeric value on a humintlang attribute = represents a starting priority for the humintlang attributes of the same = medium and direction, with one being the highest priority.  If no = such value is indicated, the value 1 is assumed. The priority value is = increased by a value 0.1 for each humintlang attribute for the same = media and direction. An asterisk on a humintlang attribute alone or together with = a priority number indicates that a language specified in the actual = media and direction is wanted in combination with another modality in = the same direction, also marked with an asterisk.

Examples:
m=3Daudio ...
humintlang-send:en
humintlang-recv:*
humintlang-recv:en
m=3Dtext ...
humintlang-recv:*
humintlang-recv:en

This means that the user want to send spoken = English and receive a combination of both spoken and typed English = simultaneously  back.

m=3Dvideo ...
humintlang-send:ase
humintlang-recv:ase
m=3Dtext ...
humintlang-send:5
humintlang-send:en
humintlang-recv:5
humintlang-recv:en

This means = that the user prefers to use American sign language both ways, but as a = possible selection on lower preference level use text both ways.
---------------------------------------------------------end = of insertion---------------------
  
The fact = that the humintlang attribute now can have values that are not language = tags needs to be reflected in a few other places in the draft.



 

 


All - In all our discussions I see two things that = we want here: [1] we want a simple and easily implementable solution/s = and [2] solution/s that cover all the use cases. I think we can agree = that going ahead with a simple solutions which is extensible covers both = of these needs. It allows us to get something out there which can be = implemented, and it allows us to answer all the use cases with = extensibility which we will work on next (I appreciate this isn=92t = immediate but it=92s favourable to making a complex solution now which = is too difficult to implement). All advice I have received on this has = suggested this is the best route = forward.
We can't wait with an = extension for something we have a need for now.
The above = addition no 6. is a simple notation for what we were missing.

Given = we=92re well over the time that we should have agreed on this I suggest = we call rough consensus for this here. I understand there may be some = frustration, but really this method solves for both needs and so is = sensible.

Bernard and Alexey - please check this and input if = you see fit!

Natasha

/Gunnar

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


On May = 17, 2016, at 10:56 PM, Gunnar Hellstr=F6m <gunnar.hellstrom@omnitor.se> wrote:

Den 2016-05-17 kl. 23:17, skrev Randall Gellens:

Gunnar, 

I think we can start with what we have now: = the offerer offers all media/languages it wants, and the answerer = accepts those it supports. 
Yes, but we need a bit more than we have today = to express that. Language usage are logically linked.
In many cases this will be exactly what's = desired, while in some cases there will be extra media that are not = used. 
I am not bothered about extra media. Offered = media shall not be rejected just because they do not have agreed = language contents.

This gives us something simple that has the = best chance of rapid and wide deployment.  We can then build on = this if need be.
We already have the need. 3GPP cannot use = user profiles in emergency registration mode, so we need to be able to = express user needs this way to the degree that they can be served well = in emergency calls. 
For that we need to 
clarify = language in some places in the draft so that we do not end up equally = fuzzy as RFC 4566, 
We need to delete our interpretation of RFC 4566,
we need to express preference with scope among all = media. 
and we need to express when languages are needed together and = when they are to select from.

You have = accepted some edit proposals that we have discussed and modified others = to something that we have not  yet seen. I would like to see the = draft as it is now so that we can see what more needs to be changed. =   



At 8:01 AM +0200 5/17/16, = Gunnar Hellstr=F6m wrote: 

 Randall, 

 Can you accept that our goal is to select the most = appropriate language(s) for the call? 

 This includes providing guidance to the answering part = so that the answer can be made in the most appropriate language(s). 

 That is stated in the charter: 

 "While the two use cases are in different contexts = (real time and 
 non-real-time), the fundamental goal is the same: to = enable selection of 
 the best-fit language(s) for a specific situation. = " 

 It is not sufficient to use the indications to select = which media shall be enabled, and then let the users sort out which = language to use. 

 The user needs guidance if it is most = appropriate to start the conversation in voice, sign language or text or = a combination of these modalities. If not, the call will start with = confusion about what is the most efficient means for them to = communicate. 

 That is why the preference indication = needs to have: 

 a) a common scope over all media, = and 

 b) an indication if two modalities simultaneously are = desired for reception. 

 Can we agree on that and move on to find a simple way = of expressing these needs? 

 /Gunnar 




 Den = 2016-05-17 kl. 05:25, skrev Randall Gellens: 

 At 8:28 PM -0600 = 5/16/16, Doug Ewell wrote: 

 Except that there = is still disagreement on whether the mechanism is needed for SLIM = 1.0. 


 And we have a call for = consensus by the chairs. 


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

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



--=20
-----------------------------------------
Gunnar Hellstr=F6m
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 =
288
_______________________________________________
SLIM mailing list
SLIM@ietf.org
https://www.ietf.org/m= ailman/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. 


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


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


--=20
-----------------------------------------
Gunnar Hellstr=F6m
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 =
288
_______________________________________________
SLIM mailing list
SLIM@ietf.org
https://www.ietf.org/m= ailman/listinfo/slim



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


--=20
-----------------------------------------
Gunnar Hellstr=F6m
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288
_______________________________________________
SLIM mailing list
SLIM@ietf.org
https://www.ietf.org/mailman/listinfo/slim

= --Apple-Mail=_4CDAB49C-60A4-4C83-8C70-9A19E2D9591C-- From nobody Sat May 21 07:39: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 54F7D12D155 for ; Sat, 21 May 2016 07:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CtRKOoDMeE4v for ; Sat, 21 May 2016 07:39:34 -0700 (PDT) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::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 528D012D0FF for ; Sat, 21 May 2016 07:39:34 -0700 (PDT) Received: by mail-pf0-x235.google.com with SMTP id c189so51898030pfb.3 for ; Sat, 21 May 2016 07:39:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3wvyNs/NkA4Rlob7lmTsMZ2f4CMD3nLZ9uFU0sfsB7k=; b=TvgKgi43mh1DJzgck2xhlWWOX+FghqiA5WQ1FwV4c+fNGa+N5/08lemPlkYC5IA2Ct 6Crlv/O92rhJP2sDNTfX6TcZHbs3ESZQDpINs+1S9p+RF+sniy6TjobYET9P6a6QWrhA Og2X03NghSmL/kot8JJkWrt4xehb5PfCXb/NW5BXgBOPkcw4Dfim4KAGlvPxSRa/8hLp 7sDBxmRihU4B22usCIicbzdSXC4qPxzcuJCBbzAWVxnIMnbRPT53zn5vwO5NjCOcUa07 rqjHx4SlifxbgY00Aifw7DUyZcpCPPJAv3aZCWpzcBepQmfHwsC8dxN4rcPx42ZTNwyO eqeg== 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 :content-transfer-encoding:message-id:references:to; bh=3wvyNs/NkA4Rlob7lmTsMZ2f4CMD3nLZ9uFU0sfsB7k=; b=eWh0Prp/702Nx3N08zokxbh0egJuRwVDbXV6jjBzPCOsqu0p600k/FWgJQI1FlrqvV 2BlIe6jTioE+Mbr395IXtWHE7AuNWxydg55zCza/bfe/uMBO4yIDi4MWESSxwgwRWWDH R7XcHjsRHidZk0DyQ3q1I1luAw8muy+w7YLJBks78F2iTLH7NsSAPWb7uEXVQMlXKIFt Ez6LA4eN2wU4/oDrOTEKPtiEO2/IAlrxGAs1zfTOEJzhgKiVW/3BlU560x5p37+L8RsZ 9yzeF5kQSFU0aIvYkYTdIt4SkwWfawLc2c/OpKv20f0alVFhmVLqFBOLHP+2rZh2f0Z5 7gLg== X-Gm-Message-State: AOPr4FX94jns0FSiHvVBRrlHVXIJwwZz4MaCxuzRVnTKz/OVW3U0sHu8R+LwKWwehIWkhw== X-Received: by 10.98.89.207 with SMTP id k76mr13461029pfj.166.1463841573652; Sat, 21 May 2016 07:39:33 -0700 (PDT) Received: from [192.168.1.104] (c-24-19-245-25.hsd1.wa.comcast.net. [24.19.245.25]) by smtp.gmail.com with ESMTPSA id t14sm34688502pfj.12.2016.05.21.07.39.32 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 21 May 2016 07:39:32 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPad Mail (13E238) In-Reply-To: Date: Sat, 21 May 2016 07:39:31 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <179bc991-af2d-a726-d8ba-71a8c2f5322d@omnitor.se> To: Paul Kyzivat Archived-At: Cc: slim@ietf.org Subject: Re: [Slim] Seeking rough consensus for draft-ietf-slim-negotiating-human-language 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, 21 May 2016 14:39:35 -0000 On May 15, 2016, at 11:40, Paul Kyzivat wrote: >=20 > I am ok with this approach *if* we agree that there is no implicit assumpt= ion about preference. Absent anything else, I think we must assume that the o= fferer wants *all* m-lines in the offer to be accepted, and intends to use t= hem all. >=20 > My fear is that implementers will make some assumption, but they won't all= make the same assumption. Then there are surprises when something unexpecte= d happens. [BA] I agree that this is very important. At worst, if we assume the offerer= wants all m-lines, we might end up with more modes/languages than we need, w= ith no indication of preference. This might lead to some fumbling (e.g. peer= s might need to figure out which modes/languages to use) but communications c= an be established, and having everything available might actually be an adva= ntage in some cases (e.g. troubles with audio or bad video so text is needed= even though it is lower preference).= From nobody Sat May 21 08:17:53 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 15B0B12D14A for ; Sat, 21 May 2016 08:17:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 72XHKVUGoH2D for ; Sat, 21 May 2016 08:17:50 -0700 (PDT) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) (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 C008012D10E for ; Sat, 21 May 2016 08:17:50 -0700 (PDT) Received: by mail-pf0-x229.google.com with SMTP id c189so52073109pfb.3 for ; Sat, 21 May 2016 08:17:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=BrH32oJS9YFcCozjHko4aH0Lnoh5UXA70gxFM6z64wU=; b=WQk8qCcTSVgfT32SzkhvX5KKoZDHJOSdSYkHyYFsPEL7Zxeaiijh759wIfPpZxcGzE lNzQ2THBNsilx04wGMIyuXmzucYUDq+O4oCFdtwc/cwElmv7A5WYkWoNnCc14ZCRZsB5 Kh+1ae+l47SS+LKmeYRzxi5IFFE5fqioAqH6fx0RDunMZ1Yn7ZmoWoa0te+ksN/gT2Xu 9+kDrVzF9TlDGhvhWMOiEFtx4MUh/mTxCZrlObwmjuboqAHHQj40V+ZCYSK4kOCjZeTH Dq/h71B2MMNzFT97m/tq7wAK/CaMzn19k56XPjQ5jgUPCivrfreq/ksBS1/7Pzm/5wZY xDLg== 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 :content-transfer-encoding:message-id:references:to; bh=BrH32oJS9YFcCozjHko4aH0Lnoh5UXA70gxFM6z64wU=; b=X+akdI05FspRY09O/EpLLJxkVsUk2E6MSY7IkIGVMsLJnpNMHK3zYLyhIcrcQqwkW+ v2afSYT9low3AiXebiy7S0wyBb/QktMItNpJLPPWEyKobI9ps9QIiO2p7CdOY3w1J6ys OuSSEmsBPkkNOgdf8H2zq1mxz+jzhvrIomRf9CN3R8ZZ7aSZhKwRK1A3R6BiA0WQ7lUz R/AyDC7+9bLh1l1S/kedRGPNxeF6Tlr3Yqe/X/ljlH/MyP1r70em4LtfgXwiaqQmqo42 0LW2AtQMmcXJEZaRZQJKq8VgmRJM0CMAFygt3YQcUZvgAgNCEcY2QMGSfKXgVMDfMgna 0IJQ== X-Gm-Message-State: AOPr4FV6ZMOSJLpqv5XgrD7IRmRbmlQhZT9PqgXSTMj/uC3v4uKpqJXrx+5zkkAtnCc6Nw== X-Received: by 10.98.1.202 with SMTP id 193mr13687511pfb.10.1463843870295; Sat, 21 May 2016 08:17:50 -0700 (PDT) Received: from [192.168.1.104] (c-24-19-245-25.hsd1.wa.comcast.net. [24.19.245.25]) by smtp.gmail.com with ESMTPSA id r197sm10216056pfr.55.2016.05.21.08.17.49 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 21 May 2016 08:17:49 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-561D5B36-AA3F-4348-8461-25748639890A Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPad Mail (13E238) In-Reply-To: <57289c9f-a63a-0466-eeb7-845f1f1421ae@omnitor.se> Date: Sat, 21 May 2016 08:17:48 -0700 Content-Transfer-Encoding: 7bit Message-Id: <791D2A26-DDD2-4E0E-B602-FAAF9DDC1E74@gmail.com> References: <20160516083958.665a7a7059d7ee80bb4d670165c8327d.5e281af085.wbe@email0 3.godaddy.com> <7C5A334F88FD45E0A7770AFA6CB33C82@DougEwell> <57289c9f-a63a-0466-eeb7-845f1f1421ae@omnitor.se> To: =?utf-8?Q?Gunnar_Hellstr=C3=B6m?= Archived-At: Cc: slim@ietf.org, Randall Gellens Subject: Re: [Slim] Seeking rough consensus for draft-ietf-slim-negotiating-human-language 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, 21 May 2016 15:17:52 -0000 --Apple-Mail-561D5B36-AA3F-4348-8461-25748639890A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On May 16, 2016, at 23:01, Gunnar Hellstr=C3=B6m wrote: > It is not sufficient to use the indications to select which media shall be= enabled, and then let the users sort out which language to use.=20 >=20 > The user needs guidance if it is most appropriate to start the conversatio= n in voice, sign language or text or a combination of these modalities. If n= ot, the call will start with confusion about what is the most efficient mean= s for them to communicate. >=20 [BA] In conferencing scenarios where participants can join late, how would p= reference work? In those scenarios participants might have different prefere= nces and only negotiating the most preferred for each participant seems like= it could result in a broken conference where media/languages with low prefe= rence might actually be needed but that could not be determined until later.= --Apple-Mail-561D5B36-AA3F-4348-8461-25748639890A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On May 16, 2016, at 23:01, G= unnar Hellstr=C3=B6m <gunn= ar.hellstrom@omnitor.se> wrote:

It is not sufficient to use the indications to select which media shall be enabled, and then let the users sort out which language to use.

The user needs guidance if it is most appropriate to start the conversation in voice, sign language or text or a combination of these modalities. If not, the call will start with confusion about what is the most efficient means for them to communicate.

[BA] In conferencing scenarios where participants can join late, h= ow would preference work? In those scenarios participants might have differe= nt preferences and only negotiating the most preferred for each participant s= eems like it could result in a broken conference where media/languages with l= ow preference might actually be needed but that could not be determined unti= l later.
= --Apple-Mail-561D5B36-AA3F-4348-8461-25748639890A-- From nobody Sat May 21 08:30:05 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 0631212D1B9 for ; Sat, 21 May 2016 08:30:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fR_u3uQ-gxtG for ; Sat, 21 May 2016 08:30:01 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 888E812D0C2 for ; Sat, 21 May 2016 08:30:01 -0700 (PDT) Received: by mail-pa0-x22e.google.com with SMTP id tb2so31654067pac.2 for ; Sat, 21 May 2016 08:30:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Bz7HTF9pS2Vxsh8LqG424VsdDmWV0lsRZUYcHcm4ssA=; b=RYaESdOfHd+x7+3lFuy4FXrpYwGsrXuUIjPhFiJi8SRw3tl2ZeqOHe749leMdQ5qyI rP2f/qZuRBZOMYoYu1Iv/1CdfziMuaLeNlrXNG367yG0U89uMaOp03/HLlXv/wKeitEU C4rinLAw5DJ9bpl4aOlXhz83OvlNQvbEThdXd6h59KC/LNeJv18KQEJYNins4FBhyDMq wy0iS0Q8vkSaLpZ9AGO+wIphL4WF1EACbR4Ky14DuXZZURSo/ujVjsO0hbT4o4sf8Rfb vJACP6PdwWt0ZcBDr7xXz4VhN8R+o1y9Iik3+8eKiZutCEXuxk+Ow/LZsmvphVlvFjzr 8M9w== 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 :content-transfer-encoding:message-id:references:to; bh=Bz7HTF9pS2Vxsh8LqG424VsdDmWV0lsRZUYcHcm4ssA=; b=NIvi9uxnf0qaHUPe12ibRwH7iIg6fzrKp4O/nrr3EA39LUmNOdJcJ068qAPdtHtKHB PaKu5/eVuNa1KQvITWoLRJk9GT/10sBUyvy70vrwJ/5BSXeH9RLfS5OkkUiL6Y8v6c7q XrY3FRT486NALM1KRvAmMwEOpbBl8I7AtLXMIBehFnzV2Hv4dSxQWj3W3exkQMNcolvO SyZbot5NqxX7UpERp+zKQdAPzPa1UFwTsL7YJt6I6gbOlzftHDfGhT+18rRDl2mPsDdO WuMSC8ZW43Zxfv0xAU1uVnHOiU8Yuh7PpsLRErjGt8Pz3jPtkpshFkNfybcbDyP+NaHc sulQ== X-Gm-Message-State: AOPr4FWlTnf0KzSl/DLhxxZpxWr6V3Ows0rH8DgL6IXliTIWp8YlyRJqmOt4T518uBs/oQ== X-Received: by 10.66.55.101 with SMTP id r5mr13667985pap.146.1463844601123; Sat, 21 May 2016 08:30:01 -0700 (PDT) Received: from [192.168.1.104] (c-24-19-245-25.hsd1.wa.comcast.net. [24.19.245.25]) by smtp.gmail.com with ESMTPSA id m184sm34935800pfb.22.2016.05.21.08.29.59 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 21 May 2016 08:30:00 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPad Mail (13E238) In-Reply-To: Date: Sat, 21 May 2016 08:29:59 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4DD4C6F1-913F-4B11-8EC9-5FFC706ED368@gmail.com> References: <20160516083958.665a7a7059d7ee80bb4d670165c8327d.5e281af085.wbe@email0 3.godaddy.com> <7C5A334F88FD45E0A7770AFA6CB33C82@DougEwell> <57289c9f-a63a-0466-eeb7-845f1f1421ae@omnitor.se> To: Randall Gellens Archived-At: Cc: slim@ietf.org, =?utf-8?Q?Gunnar_Hellstr=C3=B6m?= Subject: Re: [Slim] Seeking rough consensus for draft-ietf-slim-negotiating-human-language 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, 21 May 2016 15:30:03 -0000 On May 17, 2016, at 14:17, Randall Gellens wrote= : >=20 > while in some cases there will be extra media that are not used. [BA] There may be use cases where negotiating media/languages without prefer= ence works whereas preference does not. For example, the "extra media" may not be determinable until after the call i= s in progress (e.g. conferences). You have a working camera and prefer signi= ng and so do others so you started out the conference that way. I join late b= ut I have no camera, so I can only send text. If text was possible for every= one but low preference so they did not negotiate it, now we have a problem, w= hereas without preference I can send text from the start.= From nobody Sat May 21 13:23:04 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 1A9B412D189 for ; Sat, 21 May 2016 13:23:02 -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 xZt5mrO-OzvP for ; Sat, 21 May 2016 13:22:59 -0700 (PDT) Received: from bin-vsp-out-01.atm.binero.net (vsp-unauthed02.binero.net [195.74.38.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8BB212B007 for ; Sat, 21 May 2016 13:22:58 -0700 (PDT) X-Halon-ID: cccb1666-1f91-11e6-9294-005056917a89 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.7] (unknown [87.96.161.49]) by bin-vsp-out-01.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Sat, 21 May 2016 22:22:54 +0200 (CEST) To: slim@ietf.org References: <20160516083958.665a7a7059d7ee80bb4d670165c8327d.5e281af085.wbe@email0 3.godaddy.com> <7C5A334F88FD45E0A7770AFA6CB33C82@DougEwell> <57289c9f-a63a-0466-eeb7-845f1f1421ae@omnitor.se> <4DD4C6F1-913F-4B11-8EC9-5FFC706ED368@gmail.com> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <0508393f-4f6e-c6df-9616-9f85a20ff131@omnitor.se> Date: Sat, 21 May 2016 22:22:46 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <4DD4C6F1-913F-4B11-8EC9-5FFC706ED368@gmail.com> Content-Type: multipart/alternative; boundary="------------2BC3AD077BFCC26782E0BE64" Archived-At: Subject: Re: [Slim] Seeking rough consensus for draft-ietf-slim-negotiating-human-language 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, 21 May 2016 20:23:02 -0000 This is a multi-part message in MIME format. --------------2BC3AD077BFCC26782E0BE64 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Den 2016-05-21 kl. 17:29, skrev Bernard Aboba: > On May 17, 2016, at 14:17, Randall Gellens wrote: >> while in some cases there will be extra media that are not used. > [BA] There may be use cases where negotiating media/languages without preference works whereas preference does not. > > For example, the "extra media" may not be determinable until after the call is in progress (e.g. conferences). You have a working camera and prefer signing and so do others so you started out the conference that way. I join late but I have no camera, so I can only send text. If text was possible for everyone but low preference so they did not negotiate it, now we have a problem, whereas without preference I can send text from the start. We have said that the prime intention with the humintlang attributes are not to guide which media are connected. The intention is to guide what competence to allocate to the call and how to start communicating in the call. So, when you arrive late, the other users likely have text enabled and you can start asking in text if they can be kind to involve you in the communication by text. "there will be extra media that are not used" means that these extra media are connected, but not used for the main language contents. ( until you arrive ) I think it is also stated somewhere that the negotiation just helps with the initial conversation establishment, and the result does not limit the users from changing to other languages during the call. However, I don't find right now where that was specified. if we do not ave that statement anywhere, it should be introduced. Gunnar > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 --------------2BC3AD077BFCC26782E0BE64 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Den 2016-05-21 kl. 17:29, skrev Bernard Aboba:

On May 17, 2016, at 14:17, Randall Gellens <rg+ietf@randy.pensive.org> wrote:

while in some cases there will be extra media that are not used.

[BA] There may be use cases where negotiating media/languages without preference works whereas preference does not.

For example, the "extra media" may not be determinable until after the call is in progress (e.g. conferences). You have a working camera and prefer signing and so do others so you started out the conference that way. I join late but I have no camera, so I can only send text. If text was possible for everyone but low preference so they did not negotiate it, now we have a problem, whereas without preference I can send text from the start.
We have said that the prime intention with the humintlang attributes are not to guide which media are connected. The intention is to guide what competence to allocate to the call and how to start communicating in the call.

So, when you arrive late, the other users likely have text enabled and you can start asking in text if they can be kind to involve you in the communication by text.

"there will be extra media that are not used" means that these extra media are connected, but not used for the main language contents. ( until you arrive )

I think it is also stated somewhere that the negotiation just helps with the initial conversation establishment, and the result does not limit the users from changing to other languages during the call. However, I don't find right now where that was specified. if we do not ave that statement anywhere, it should be introduced.

Gunnar

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


-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288
--------------2BC3AD077BFCC26782E0BE64-- From nobody Sat May 21 15:31: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 D38EE12D52F for ; Sat, 21 May 2016 15:31:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ElPvsuUqu9a for ; Sat, 21 May 2016 15:31:53 -0700 (PDT) Received: from mail-pf0-x243.google.com (mail-pf0-x243.google.com [IPv6:2607:f8b0:400e:c00::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6388812B028 for ; Sat, 21 May 2016 15:31:53 -0700 (PDT) Received: by mail-pf0-x243.google.com with SMTP id g132so14886572pfb.3 for ; Sat, 21 May 2016 15:31:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=wriXQmZK+gbXDL//fObKgN46Kk6jpdQQXV3QXYvp3Qg=; b=pc2/dQVBywwNiv0Q9bPCrM5S7CLpJlyuYmLTkayPwg+PjIxeCohdzwfa5DVODfvCmx m9mQ3bKSI9YTLqZwgAZOnDhjHzMuhWpzzWKh95N93P2aOKthPwpcBS05iPajbEukwvg6 DQo0+Lo/my6EUbuodDcOsFUUZXhLIFqWJ1GTBlCbQDslyElaMbMsMRqI1qdU1QYWzrHA f6+uDRgRN+skhPYldwfLYsy+sNSa75M+Cmx9LNASZhvoQ3IAMqmJp/+YQvDMPQOJ+yNc 9PjuMouKxtM/9g7U8eO2P3E9vWb4BD+/XvhmZuU4B7m4ab8vPcenPDvLHBGTpGgBILJG 5fzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=wriXQmZK+gbXDL//fObKgN46Kk6jpdQQXV3QXYvp3Qg=; b=TNoEtKOg6dvbb8UDeHoY+uHpqjOW2aH1bbecc4neQ42MfuVA1BvLpjZV/gIy2bsdMl TRARD4RbbTSA5HmtgAHX4vYCzOjAfM2X6NWc+TpbWRbNvGZa1KXRYJx24U8XjvXTEQeM z1vAemlghtuXpQLKwXNK8PW/V6zZVWZYorXnnDuneo2kk1Ma3IY9B+psXa1yULk4hLSr aUvfRBghyADiKGIk5yvBgSMRudbjtk7H+MyJ9gC1flhrkPv9kG83rMhY75yuMIUUQt9X Qf3wWTvgyykOO8RdPn662L1AqOYMo7ZBUp+ciGqt1wCj0PwgBtAlrzEQkSg+GWXy+6jb NpDA== X-Gm-Message-State: AOPr4FURPoKgm0oJAxKyFwqMqoIqy0nPwxMG8X4S0DLyPSoRUssfQ6+gWZdV35rJ2y/6PQ== X-Received: by 10.98.49.134 with SMTP id x128mr15486378pfx.45.1463869912915; Sat, 21 May 2016 15:31:52 -0700 (PDT) Received: from [10.79.125.237] (mobile-166-176-186-254.mycingular.net. [166.176.186.254]) by smtp.gmail.com with ESMTPSA id l67sm3442467pfi.10.2016.05.21.15.31.51 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 21 May 2016 15:31:51 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Bernard Aboba Mime-Version: 1.0 (1.0) Date: Sat, 21 May 2016 15:31:47 -0700 Message-Id: References: <20160516083958.665a7a7059d7ee80bb4d670165c8327d.5e281af085.wbe@email0 3.godaddy.com> <7C5A334F88FD45E0A7770AFA6CB33C82@DougEwell> <57289c9f-a63a-0466-eeb7-845f1f1421ae@omnitor.se> <4DD4C6F1-913F-4B11-8EC9-5FFC706ED368@gmail.com> <0508393f-4f6e-c6df-9616-9f85a20ff131@omnitor.se> In-Reply-To: <0508393f-4f6e-c6df-9616-9f85a20ff131@omnitor.se> To: =?utf-8?Q?Gunnar_Hellstr=C3=B6m?= X-Mailer: iPhone Mail (13F69) Archived-At: Cc: slim@ietf.org Subject: Re: [Slim] Seeking rough consensus for draft-ietf-slim-negotiating-human-language 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, 21 May 2016 22:31:55 -0000 On May 21, 2016, at 1:22 PM, Gunnar Hellstr=C3=B6m wrote: > We have said that the prime intention with the humintlang attributes are n= ot to guide which media are connected. The intention is to guide what compet= ence to allocate to the call and how to start communicating in the call.=20 >=20 > So, when you arrive late, the other users likely have text enabled and you= can start asking in text if they can be kind to involve you in the communic= ation by text.=20 >=20 > "there will be extra media that are not used" means that these extra media= are connected, but not used for the main language contents. ( until you arr= ive ) [BA] Agree that is how the current draft works. But if we were to group medi= a and language together, would it continue to work that way?=20 > I think it is also stated somewhere that the negotiation just helps with t= he initial conversation establishment, and the result does not limit the use= rs from changing to other languages during the call. However, I don't find r= ight now where that was specified. if we do not have that statement anywhere= , it should be introduced.=20 [BA] Is it correct to assume that the language change can occur without nego= tiation, assuming that the media/language to be used is within the negotiate= d envelope?= From nobody Sat May 21 23:36:43 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 0B36712B032 for ; Sat, 21 May 2016 23:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 GVqA1qu0jcZO for ; Sat, 21 May 2016 23:36:39 -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 72F2A12B026 for ; Sat, 21 May 2016 23:36:38 -0700 (PDT) X-Halon-ID: 7d958613-1fe7-11e6-8616-005056917f90 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.2] (unknown [87.96.161.49]) by bin-vsp-out-02.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Sun, 22 May 2016 08:36:18 +0200 (CEST) To: Bernard Aboba References: <20160516083958.665a7a7059d7ee80bb4d670165c8327d.5e281af085.wbe@email0 3.godaddy.com> <7C5A334F88FD45E0A7770AFA6CB33C82@DougEwell> <57289c9f-a63a-0466-eeb7-845f1f1421ae@omnitor.se> <4DD4C6F1-913F-4B11-8EC9-5FFC706ED368@gmail.com> <0508393f-4f6e-c6df-9616-9f85a20ff131@omnitor.se> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: Date: Sun, 22 May 2016 08:36:23 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------AB5C0E4597C8486868982A1A" Archived-At: Cc: slim@ietf.org Subject: Re: [Slim] Seeking rough consensus for draft-ietf-slim-negotiating-human-language 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, 22 May 2016 06:36:42 -0000 This is a multi-part message in MIME format. --------------AB5C0E4597C8486868982A1A Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Den 2016-05-22 kl. 00:31, skrev Bernard Aboba: > On May 21, 2016, at 1:22 PM, Gunnar Hellström wrote: >> We have said that the prime intention with the humintlang attributes are not to guide which media are connected. The intention is to guide what competence to allocate to the call and how to start communicating in the call. >> >> So, when you arrive late, the other users likely have text enabled and you can start asking in text if they can be kind to involve you in the communication by text. >> >> "there will be extra media that are not used" means that these extra media are connected, but not used for the main language contents. ( until you arrive ) > [BA] Agree that is how the current draft works. But if we were to group media and language together, would it continue to work that way? [GH]Yes, the users in your example of sign language users, also prepared to conduct a text conversation would not request grouping of sign language and text. They would indicate text on a lower preference than sign language. When they find that the sign language preference is met, they can conduct the main conversation in sign language and have the text stream for occasional items that fits better there. When you jump into the call with only text, you need to ask them if they can accept to accommodate for you to participate as well, but that is not given. They did not request grouping of sign language and text, they only marked relative priority. So they have no means to provide the whole content of the conference in both sign language and text. So it is up for discussion among them if they shall leave their preferred modality and accept to use text for your sake. If they instead had requested to receive both sign language and text and grouped them, it would mean that they had very strong preference for being provided with both simultaneously. (e.g. by being deaf-blind with some residual vision that make received sign language of value but not sufficient.) That would require an interpreter to participate in the call. Then you could likely easier jump in with your text-only capability. >> I think it is also stated somewhere that the negotiation just helps with the initial conversation establishment, and the result does not limit the users from changing to other languages during the call. However, I don't find right now where that was specified. if we do not have that statement anywhere, it should be introduced. > [BA] Is it correct to assume that the language change can occur without negotiation, assuming that the media/language to be used is within the negotiated envelope? [GH] No. We cannot control the human users. Once they have got support to know how to start the conversation they are free to deviate as far as they wish, also using other media than they started with. They can say "Oh, have you also learnt Welsh! Me too, let us try how far we can use it." And they switch mid-call to something that was not at all indicated in the humintlang attributes. We cannot force them to renegotiate sdp for that switch. In a formal conference announced to be held in spoken English, there might be a chairman stopping such changes, saying "sorry, you are leaving us behind, we announced this as a conference in English, so we should stick to that". We have not discussed handling of formal announced conferences. It could use the humintlang mechanisms, and then, if it has a fixed set of interpreters, it would indicate sending of the corresponding languages with grouping. But I assume that CLUE or XCON goes deeper in such aspects and we can concentrate on the ad-hoc call. The RFC 4566 lang specification starts with "This can be a session-level attribute or a media-level attribute. As a session-level attribute, it specifies the default language for the session being described." I suggest that we include something like that in our draft. E.g. "The goal is to support negotiating the language(s) to use at least initially in the call." /Gunnar > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 --------------AB5C0E4597C8486868982A1A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Den 2016-05-22 kl. 00:31, skrev Bernard Aboba:
On May 21, 2016, at 1:22 PM, Gunnar Hellström <gunnar.hellstrom@omnitor.se> wrote:

We have said that the prime intention with the humintlang attributes are not to guide which media are connected. The intention is to guide what competence to allocate to the call and how to start communicating in the call. 

So, when you arrive late, the other users likely have text enabled and you can start asking in text if they can be kind to involve you in the communication by text. 

"there will be extra media that are not used" means that these extra media are connected, but not used for the main language contents. ( until you arrive )

[BA] Agree that is how the current draft works. But if we were to group media and language together, would it continue to work that way?
[GH]Yes, the users in your example of sign language users, also prepared to conduct a text conversation would not request grouping of sign language and text. They would indicate text on a lower preference than sign language.
When they find that the sign language preference is met, they can conduct the main conversation in sign language and have the text stream for occasional items that fits better there.

When you jump into the call with only text, you need to ask them if they can accept to accommodate for you to participate as well, but that is not given.  They did not request grouping of sign language and text, they only marked relative priority. So they have no means to provide the whole content of the conference in both sign language and text. So it is up for discussion among them if they shall leave their preferred modality and accept to use text for your sake. 

If they instead had requested to receive both sign language and text and grouped them, it would mean that they had very strong preference for being provided with both simultaneously. (e.g. by being deaf-blind with some residual vision that make received sign language of value but not sufficient.) That would require an interpreter to participate in the call.  Then you could likely easier jump in with your text-only capability.


 
I think it is also stated somewhere that the negotiation just helps with the initial conversation establishment, and the result does not limit the users from changing to other languages during the call. However, I don't find right now where that was specified. if we do not have that statement anywhere, it should be introduced. 

[BA] Is it correct to assume that the language change can occur without negotiation, assuming that the media/language to be used is within the negotiated envelope?
[GH] No. We cannot control the human users. Once they have got support to know how to start the conversation they are free to deviate as far as they wish, also using other media than they started with. They can say "Oh, have you also learnt Welsh! Me too, let us try how far we can use it." And they switch mid-call to something that was not at all indicated in the humintlang attributes. We cannot force them to renegotiate sdp for that switch.

In a formal conference announced to be held in spoken English, there might be a chairman stopping such changes, saying "sorry, you are leaving us behind, we announced this as a conference in English, so we should stick to that".

We have not discussed handling of formal announced conferences. It could use the humintlang mechanisms, and then, if it has a fixed set of interpreters, it would indicate sending of the corresponding languages with grouping. But I assume that CLUE or XCON goes deeper in such aspects and we can concentrate on the ad-hoc call.  

The RFC 4566 lang specification starts with
"This can be a session-level attribute or a media-level attribute. 
      As a session-level attribute, it specifies the default language
      for the session being described."

I suggest that we include something like that in our draft. E.g.
"The goal is to support negotiating the language(s) to use at least initially in the call." 

/Gunnar


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


-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288
--------------AB5C0E4597C8486868982A1A-- From nobody Sun May 22 04:30: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 3ED4C12D0E9 for ; Sun, 22 May 2016 04:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.398 X-Spam-Level: X-Spam-Status: No, score=0.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MANY_SPAN_IN_TEXT=2.999, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DHuvs1tAyvBN for ; Sun, 22 May 2016 04:30:42 -0700 (PDT) Received: from bin-vsp-out-05.atm.binero.net (bin-mail-out-05.binero.net [195.74.38.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 503D812B00A for ; Sun, 22 May 2016 04:30:39 -0700 (PDT) X-Halon-ID: 9be7e001-2010-11e6-9ca0-005056913f0f Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.4] (unknown [87.96.161.49]) by bin-vsp-out-05.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Sun, 22 May 2016 13:30:38 +0200 (CEST) To: Brian Rosen References: <20160516083958.665a7a7059d7ee80bb4d670165c8327d.5e281af085.wbe@email0 3.godaddy.com> <7C5A334F88FD45E0A7770AFA6CB33C82@DougEwell> <57289c9f-a63a-0466-eeb7-845f1f1421ae@omnitor.se> <363ab6da-abdb-357b-e942-5284b085d451@omnitor.se> <405724e5-61aa-1144-6a2c-7c08fb599c98@omnitor.se> <434a2375-f806-a326-6137-706f1d7d9f92@omnitor.se> <4C5ADDF5-6D93-4A8E-9EE7-D116217BAADA@brianrosen.net> <882047f1-cb9c-1093-9f03-80475b56d6d9@omnitor.se> <269AC87F-6928-4280-82B5-D5DEF9947CAB@brianrosen.net> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: Date: Sun, 22 May 2016 13:30:23 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <269AC87F-6928-4280-82B5-D5DEF9947CAB@brianrosen.net> Content-Type: multipart/alternative; boundary="------------40619FE6FB70352A926E5177" Archived-At: Cc: slim@ietf.org Subject: Re: [Slim] Seeking rough consensus for draft-ietf-slim-negotiating-human-language - compromise proposal 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, 22 May 2016 11:30:46 -0000 This is a multi-part message in MIME format. --------------40619FE6FB70352A926E5177 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Den 2016-05-20 kl. 21:44, skrev Brian Rosen: > While I agree there are corner cases simpler mechanisms won’t cover, I > think they are rare enough that the complexity introduced in every > implementation to allow the corner case to work is not acceptable. > > I am not in favor of adopting this proposal. > > I don’t think either of these proposals is the right way to do > grouping, and I don’t want to do grouping at this time, so arguing > over which is better is pointless. I’d probably use RFC5888 as a > starting point and define groups of media and languages in the offer, > which the answer can select from. [GH] When looking at this idea, I first got afraid that it would increase the length and complexity of an SDP near infinity, considering that we for each media description might have a number of lines for ICE candidates, a number of lines for rtcp-feedback announcements and sdpneg alternatives for AVP, AVPF, SAVP and SAVPF. Repeating them for alternative language groupings does not look attractive. But getting inspiration from the lip synch grouping in RFC 5888 I see that it might be possible to define a notation that does not cost too much in SDP length increase to achieve what we want for the simple cases we have been discussing. It would require us to define a new type of grouping in the RFC 5888 style. Let us call it Language Preference grouping LP. Something like this: --------------------------------------------------------------------------------------------------------- x Language Priority (LP) An application that receives a session description that contains media descriptions that are marked using LP semantics SHOULD make efforts to provide language support according to the indicated priority. Two directions of Language Priority are defined: LPR specifies that the languages indicated for reception in the marked media descriptors are prioritized. LPS specifies that the languages indicated for sending in the marked media descriptors are prioritized. One or more media descriptions MAY be assigned Language Priority. When one media description is given Language Priority, it means that the languages indicated in that media description with the indicated direction is strongly preferred over languages in other media descriptions with the same direction. When more than one media description is given Language Priority, it means that there is a strong preference to use the languages in these media descriptions and direction simultaneously together. X.1 Examples of LP Example 1; a calling user, who strongly prefers to use spoken English supported by reception of text captioning of the received speech can indicate this preference by the following abbreviated sdp. This indication can be used by the callee or by the involved services to make efforts to invoke a way of adding text to the speech answers. a=group:LPR 1 2 m=audio ... a=humintlang-send:en a=humintlang-recv:en a=mid:1 m=text ... a=humintlang-recv:en a=mid:2 Example 2; a calling user, who prefers to use American sign language both ways, but want to indicate that text in English both ways is an accepted alternative on lower preference level can indicate this preference by the following abbreviated sdp: This indication can be used by the called party to make efforts to answer with sign language competent personnel, but if that is not available be assured that a text conversation will also be successful. a=group:LPR 1 a=group:LPS 2 m=video ... a=humintlang-send:ase a=humintlang-recv:ase a=mid:1 a=mid:2 m=text ... a=humintlang-send:en a=humintlang-recv:en a=mid:3 Note that although the third media stream is not present in the group line, it still has to contain a "mid" attribute (mid:3). ----------------------------------------------------------------------------------------------------- Would you like this better? /Gunnar > > Brian > >> On May 20, 2016, at 3:29 PM, Gunnar Hellström >> > wrote: >> >> Den 2016-05-20 kl. 20:01, skrev Brian Rosen: >> >>> I personally don’t want to have anything like “main preference” or >>> grouping that confuses the per-media characteristic of SDP. >> But looking at the needs of users and service providers, there are >> logical relations between media. >> They do not need to influence the decision on which media to start, >> but to which terminal to route the call, and what info to provide to >> the answering party and possibly what extra service to link in on the >> call. All these are depending on relations between language in >> different media, so I cannot see how we can avoid at least the >> proposed minimal form of preference across media and minimal grouping. >> >> Can you accept it even if you do not want it? >> >> Was this compromise proposal better than the previous one with >> explicit preference value per list of humintlang attributes? >> >> /Gunnar >>> >>> Brian >>> >>> >>>> On May 20, 2016, at 2:55 AM, Gunnar Hellström >>>> > >>>> wrote: >>>> >>>> I have a compromise proposal. Let us test if we can get somewhere >>>> by introducing it. >>>> >>>> Let us delete the use of the asterisk '*' for the 'do not drop' >>>> notation, and let 'do not drop' be the default. >>>> >>>> Let us reuse the asterisk attached to the end of a language tag be >>>> used for both a priority indication with the whole sdp as scope, >>>> and an indication of grouping. >>>> >>>> Initial change proposals ( there will be more follow-up changes, >>>> but these are the main ones ) >>>> >>>> ---------------change in 6.2 >>>> from--------------------------------------------------------------- >>>> >>>> In an offer, each language tag value MAY have an asterisk appended as >>>> the last character (after the registry value). The asterisk >>>> indicates a request by the caller to not fail the call if there is no >>>> language in common. SeeSection 6.3 >>>> for more information and >>>> discussion. >>>> -------------------to------------------------------------- >>>> In an offer, language tag values MAY have an asterisk appended as >>>> the last character (after the registry value). The asterisk >>>> indicates a main preference for the indicated language. SeeSection 6.3 >>>> >>>> for more information and discussion. >>>> ----------------------------end of change in 6.2--------------------- >>>> >>>> -------------------Replace 6.3 with this---------------------------------- >>>> >>>> 6.3 Main preference >>>> >>>> If a user has a strong preference for using a language over the other >>>> indicated languages, this preference can be indicated by including an >>>> asterisk '*' last in the value of the preferred language and direction >>>> indication. >>>> >>>> One such preference indication can be used per direction to indicate >>>> main preference. This preference has scope across all media. >>>> >>>> Two or more such preference indications can be used per direction to >>>> indicate a strong preference or capability to use the indicated languages >>>> in the indicated direction simultaneously together. >>>> >>>> Examples: >>>> Example 1; a calling user, who strongly prefers to use spoken English >>>> supported by reception of rapidly added text captioning of the received >>>> speech can indicate this preference by the following abbreviated sdp. >>>> This indication can be used by the callee or by the involved services >>>> to make efforts to invoke a way of adding text to the speech answers. >>>> >>>> m=audio ... >>>> humintlang-send:en >>>> humintlang-recv:en* >>>> m=text ... >>>> humintlang-recv:en* >>>> >>>> Example 2; a calling user, who prefers to use American sign language both >>>> ways, but want to indicate that text in English both ways is an accepted >>>> alternative on lower preference level can indicate this preference by the >>>> following abbreviated sdp: >>>> This indication can be used by the called party to make efforts to answer >>>> with sign language competent personnel, but if that is not available be >>>> assured that a text conversation will also be successful. >>>> >>>> m=video ... >>>> humintlang-send:ase* >>>> humintlang-recv:ase* >>>> m=text ... >>>> humintlang-send:en >>>> humintlang-recv:en >>>> >>>> -------------------------------end of >>>> changes------------------------------------------------ >>>> >>>> Discussion: This compromise satisfies most use cases for which >>>> global preference and grouping are needed, but has some drawbacks >>>> compared to a system with finer graded preferences. >>>> >>>> 1. For the grouping example above with receiving spoken English and >>>> English text, it cannot be seen what is best if it is not possible >>>> to provide the combination. There is no clue if it would be >>>> reasonably possible to provide only text or only spoken English. >>>> >>>> 2. The notation is only usable for a single preference combination. >>>> It is not possible to indicate a number of sign languages, all >>>> preferred over typed English. >>>> This drawback appears because the same notation is used for main >>>> preference as for grouping indication. >>>> >>>> I want anyway to provide this compromise proposal, because it does >>>> not introduce any extra complexity and it solves the main so far >>>> unsolved use cases. >>>> >>>> /Gunnar >>>> >>>> >>>> Den 2016-05-19 kl. 00:23, skrev Gunnar Hellström: >>>>> Den 2016-05-18 kl. 19:08, skrev Natasha Rooney: >>>>>> Randall - the last edit we see of the doc is from March, is this >>>>>> the most recent one? If not can you submit an edit soon? >>>>> We had e-mail list discussion around April 8-10 under the subject >>>>> "[Slim] Wording about selection in >>>>> draft-ietf-slim-negotiating-human-language-01" >>>>> that ended with some agreed changes and some in-principle agreed >>>>> changes but no agreed wording. That is what I refer to when I say >>>>> I want to see what the latest edits ended up in. >>>>> >>>>> That mainly covered the ambition to be more exact than RFC 4566 >>>>> lang specification. >>>>> >>>>> So, when we get that, we can judge: >>>>> 1. If it is clear when the indications reflect a selection >>>>> possibility or a combination requirement. >>>>> >>>>> There are a couple of other things we need to modify also before >>>>> progressing to any kind of consensus. >>>>> >>>>> 2. In 5. Delete our interpretation of the lang attribute. It is >>>>> sufficient to say that it is not enough detailed because it does >>>>> not provide directionality. >>>>> >>>>> 3. In 5. insert specification on how lang and humintlang relates. >>>>> The easiest way is to say that lang should not be used in sdp >>>>> where humintlang is used. Is that too drastic? >>>>> >>>>> 4. Do we really need the * parameter for "do not fail call" >>>>> introduced in 6.2 and explained in 6.3? It will be most common to >>>>> want to have that effect, thus requiring to add the * in most >>>>> media specifications. Can we simplify the syntax by having "do not >>>>> fail call" as the default and delete the description of the * ? I >>>>> suggest that we delete it. >>>>> If not, the description of the syntax of how the * is included >>>>> needs to be inserted in the syntax description in section 6.2 and >>>>> an example added. >>>>> >>>>> 5. In this part of 6.2: >>>>> "In cases where the user >>>>> wishes to use one media for sending and another for receiving (such >>>>> as a speech-impaired user who wishes to send using text and receive >>>>> using audio), one of the two MAY be unset. In cases where a media is >>>>> not primarily intended for language (for example, a video or audio >>>>> stream intended for background only) both SHOULD be unset. In other >>>>> cases, both SHOULD have the same values in the same order. The two >>>>> SHOULD NOT be set to languages which are difficult to match together" >>>>> >>>>> Clarify that "two" and "both" refers to the humintlang-send and >>>>> humintlang-recv attributes for a medium. >>>>> ( the attribute names are too far back so when searching for what >>>>> "two" and "both" refers to you end up in confusion). >>>>> >>>>> 6. And, yet another proposal to insert a simple indication for >>>>> preference betweeen media, and one for distinguishing selection >>>>> versus combination. >>>>> The needs come from accessibility needs, and fulfilling >>>>> accessibility needs has strong policy support, so it would be bad >>>>> to say that that must wait for another version of the document >>>>> when we already now have specified the need. >>>>> >>>>> --------------------------------------------------In 6.2 >>>>> insert:---------------------------------------------------------------------- >>>>> A single digit numeric value on a humintlang attribute represents >>>>> a starting priority for the humintlang attributes of the same >>>>> medium and direction, with one being the highest priority. If no >>>>> such value is indicated, the value 1 is assumed. The priority >>>>> value is increased by a value 0.1 for each humintlang attribute >>>>> for the same media and direction. >>>>> An asterisk on a humintlang attribute alone or together with a >>>>> priority number indicates that a language specified in the actual >>>>> media and direction is wanted in combination with another modality >>>>> in the same direction, also marked with an asterisk. >>>>> >>>>> Examples: >>>>> m=audio ... >>>>> humintlang-send:en >>>>> humintlang-recv:* >>>>> humintlang-recv:en >>>>> m=text ... >>>>> humintlang-recv:* >>>>> humintlang-recv:en >>>>> >>>>> This means that the user want to send spoken English and receive a >>>>> combination of both spoken and typed English simultaneously back. >>>>> >>>>> m=video ... >>>>> humintlang-send:ase >>>>> humintlang-recv:ase >>>>> m=text ... >>>>> humintlang-send:5 >>>>> humintlang-send:en >>>>> humintlang-recv:5 >>>>> humintlang-recv:en >>>>> >>>>> This means that the user prefers to use American sign language >>>>> both ways, but as a possible selection on lower preference level >>>>> use text both ways. >>>>> ---------------------------------------------------------end of >>>>> insertion--------------------- >>>>> >>>>> The fact that the humintlang attribute now can have values that >>>>> are not language tags needs to be reflected in a few other places >>>>> in the draft. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> >>>>>> All - In all our discussions I see two things that we want here: >>>>>> [1] we want a simple and easily implementable solution/s and [2] >>>>>> solution/s that cover all the use cases. I think we can agree >>>>>> that going ahead with a simple solutions which is extensible >>>>>> covers both of these needs. It allows us to get something out >>>>>> there which can be implemented, and it allows us to answer all >>>>>> the use cases with extensibility which we will work on next (I >>>>>> appreciate this isn’t immediate but it’s favourable to making a >>>>>> complex solution now which is too difficult to implement). All >>>>>> advice I have received on this has suggested this is the best >>>>>> route forward. >>>>> We can't wait with an extension for something we have a need for now. >>>>> The above addition no 6. is a simple notation for what we were >>>>> missing. >>>>>> >>>>>> Given we’re well over the time that we should have agreed on this >>>>>> I suggest we call rough consensus for this here. I understand >>>>>> there may be some frustration, but really this method solves for >>>>>> both needs and so is sensible. >>>>>> >>>>>> Bernard and Alexey - please check this and input if you see fit! >>>>>> >>>>>> Natasha >>>>>> >>>>> /Gunnar >>>>>> >>>>>> Natasha Rooney | Technologist, Web and Internet, W3C & IETF | >>>>>> GSMA | nrooney@gsma.com | +44 (0) 7730 219 765 | @thisNatasha | >>>>>> Skype: nrooney@gsm.org >>>>>> >>>>>> >>>>>>> On May 17, 2016, at 10:56 PM, Gunnar Hellström >>>>>>> wrote: >>>>>>> >>>>>>> Den 2016-05-17 kl. 23:17, skrev Randall Gellens: >>>>>>> >>>>>>>> Gunnar, >>>>>>>> >>>>>>>> I think we can start with what we have now: the offerer offers >>>>>>>> all media/languages it wants, and the answerer accepts those it >>>>>>>> supports. >>>>>>> Yes, but we need a bit more than we have today to express that. >>>>>>> Language usage are logically linked. >>>>>>>> In many cases this will be exactly what's desired, while in >>>>>>>> some cases there will be extra media that are not used. >>>>>>> I am not bothered about extra media. Offered media shall not be >>>>>>> rejected just because they do not have agreed language contents. >>>>>>>> >>>>>>>> This gives us something simple that has the best chance of >>>>>>>> rapid and wide deployment. We can then build on this if need be. >>>>>>> We already have the need. 3GPP cannot use user profiles in >>>>>>> emergency registration mode, so we need to be able to express >>>>>>> user needs this way to the degree that they can be served well >>>>>>> in emergency calls. >>>>>>> For that we need to >>>>>>> clarify language in some places in the draft so that we do not >>>>>>> end up equally fuzzy as RFC 4566, >>>>>>> We need to delete our interpretation of RFC 4566, >>>>>>> we need to express preference with scope among all media. >>>>>>> and we need to express when languages are needed together and >>>>>>> when they are to select from. >>>>>>> >>>>>>> You have accepted some edit proposals that we have discussed and >>>>>>> modified others to something that we have not yet seen. I would >>>>>>> like to see the draft as it is now so that we can see what more >>>>>>> needs to be changed. >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> At 8:01 AM +0200 5/17/16, Gunnar Hellström wrote: >>>>>>>> >>>>>>>>> Randall, >>>>>>>>> >>>>>>>>> Can you accept that our goal is to select the most >>>>>>>>> appropriate language(s) for the call? >>>>>>>>> >>>>>>>>> This includes providing guidance to the answering part so >>>>>>>>> that the answer can be made in the most appropriate language(s). >>>>>>>>> >>>>>>>>> That is stated in the charter: >>>>>>>>> >>>>>>>>> "While the two use cases are in different contexts (real time and >>>>>>>>> non-real-time), the fundamental goal is the same: to enable >>>>>>>>> selection of >>>>>>>>> the best-fit language(s) for a specific situation. " >>>>>>>>> >>>>>>>>> It is not sufficient to use the indications to select which >>>>>>>>> media shall be enabled, and then let the users sort out which >>>>>>>>> language to use. >>>>>>>>> >>>>>>>>> The user needs guidance if it is most appropriate to start >>>>>>>>> the conversation in voice, sign language or text or a >>>>>>>>> combination of these modalities. If not, the call will start >>>>>>>>> with confusion about what is the most efficient means for them >>>>>>>>> to communicate. >>>>>>>>> >>>>>>>>> That is why the preference indication needs to have: >>>>>>>>> >>>>>>>>> a) a common scope over all media, and >>>>>>>>> >>>>>>>>> b) an indication if two modalities simultaneously are desired >>>>>>>>> for reception. >>>>>>>>> >>>>>>>>> Can we agree on that and move on to find a simple way of >>>>>>>>> expressing these needs? >>>>>>>>> >>>>>>>>> /Gunnar >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Den 2016-05-17 kl. 05:25, skrev Randall Gellens: >>>>>>>>> >>>>>>>>>> At 8:28 PM -0600 5/16/16, Doug Ewell wrote: >>>>>>>>>> >>>>>>>>>>> Except that there is still disagreement on whether the >>>>>>>>>>> mechanism is needed for SLIM 1.0. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> And we have a call for consensus by the chairs. >>>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> ----------------------------------------- >>>>>>>>> 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 >>>>>> >>>>>> This email and its attachments are intended for the above named >>>>>> only and may be confidential. If they have come to you in error >>>>>> you must take no action based on them, nor must you copy or show >>>>>> them to anyone; please reply to this email or call +44 207 356 >>>>>> 0600 and highlight the error. >>>>>> >>>>> >>>>> -- >>>>> ----------------------------------------- >>>>> Gunnar Hellström >>>>> Omnitor >>>>> gunnar.hellstrom@omnitor.se >>>>> +46 708 204 288 >>>>> >>>>> >>>>> _______________________________________________ >>>>> SLIM mailing list >>>>> SLIM@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/slim >>>> >>>> -- >>>> ----------------------------------------- >>>> Gunnar Hellström >>>> Omnitor >>>> gunnar.hellstrom@omnitor.se >>>> +46 708 204 288 >>>> _______________________________________________ >>>> SLIM mailing list >>>> SLIM@ietf.org >>>> https://www.ietf.org/mailman/listinfo/slim >>> >>> >>> >>> _______________________________________________ >>> SLIM mailing list >>> SLIM@ietf.org >>> https://www.ietf.org/mailman/listinfo/slim >> >> -- >> ----------------------------------------- >> Gunnar Hellström >> Omnitor >> gunnar.hellstrom@omnitor.se >> +46 708 204 288 >> _______________________________________________ >> 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 --------------40619FE6FB70352A926E5177 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Den 2016-05-20 kl. 21:44, skrev Brian Rosen:

While I agree there are corner cases simpler mechanisms won’t cover, I think they are rare enough that the complexity introduced in every implementation to allow the corner case to work is not acceptable.

I am not in favor of adopting this proposal.

I don’t think either of these proposals is the right way to do grouping, and I don’t want to do grouping at this time, so arguing over which is better is pointless.  I’d probably use RFC5888 as a starting point and define groups of media and languages in the offer, which the answer can select from.
[GH]
When looking at this idea, I first got afraid that it would increase the length and complexity of an SDP near infinity, considering that we for each media description might have a number of lines for ICE candidates, a number of lines for rtcp-feedback announcements and sdpneg alternatives for AVP, AVPF, SAVP and SAVPF. Repeating them for alternative language groupings does not look attractive.

But getting inspiration from the lip synch grouping in RFC 5888 I see that it might be possible to define a notation that does not cost too much in SDP length increase to achieve what we want for the simple cases we have been discussing.

It would require us to define a new type of grouping in the RFC 5888 style.
Let us call it Language Preference grouping LP.
Something like this:
---------------------------------------------------------------------------------------------------------
x Language Priority (LP)

   An application that receives a session description that contains 
   media descriptions that are marked using LP semantics SHOULD make 
   efforts to provide language support according to the indicated priority.

   Two directions of Language Priority are defined:
	LPR specifies that the languages indicated for reception in the marked media descriptors are prioritized.
	LPS specifies that the languages indicated for sending in the marked media descriptors are prioritized. 

   One or more media descriptions MAY be assigned Language Priority. 
   When one media description is given Language Priority, it means that
   the languages indicated in that media description with the indicated direction is strongly preferred 
   over languages in other media descriptions with the same direction.

   When more than one media description is given Language Priority, it means 
   that there is a strong preference to use the languages in these media 
   descriptions and direction simultaneously together. 

X.1 Examples of LP
   
Example 1;  a calling user, who strongly prefers to use spoken English
 supported by reception of text captioning of the received 
 speech can indicate this preference by the following abbreviated sdp.
 This indication can be used by the callee or by the involved services 
 to make efforts to invoke a way of adding text to the speech answers. 
 
a=group:LPR 1 2
   m=audio ...
   a=humintlang-send:en
   a=humintlang-recv:en
   a=mid:1
   m=text ...
   a=humintlang-recv:en
   a=mid:2

 Example 2; a calling user, who prefers to use American sign language both
  ways, but want to indicate that text in English both ways is an accepted 
  alternative on lower preference level can indicate this preference by the
  following abbreviated sdp:
  This indication can be used by the called party to make efforts to answer
  with sign language competent personnel, but if that is not available be 
  assured that a text conversation will also be successful.  
 
a=group:LPR 1
a=group:LPS 2
  m=video ...
  a=humintlang-send:ase
  a=humintlang-recv:ase
a=mid:1
a=mid:2
   m=text ...
   a=humintlang-send:en
   a=humintlang-recv:en
a=mid:3

   Note that although the third media stream is not present in the group
   line, it still has to contain a "mid" attribute (mid:3).
-----------------------------------------------------------------------------------------------------
 Would you like this better?

/Gunnar

Brian

On May 20, 2016, at 3:29 PM, Gunnar Hellström <gunnar.hellstrom@omnitor.se> wrote:

Den 2016-05-20 kl. 20:01, skrev Brian Rosen:

I personally don’t want to have anything like “main preference”  or grouping that confuses the per-media characteristic of SDP.
But looking at the needs of users and service providers, there are logical relations between media. 
They do not need to influence the decision on which media to start, but to which terminal to route the call, and what info to provide to the answering party and possibly what extra service to link in on the call.  All these are depending on relations between language in different media, so I cannot see how we can avoid at least the proposed minimal form of preference across media and minimal grouping.

Can you accept it even if you do not want it?

Was this compromise proposal better than the previous one with explicit preference value per list of humintlang attributes?

/Gunnar

Brian


On May 20, 2016, at 2:55 AM, Gunnar Hellström <gunnar.hellstrom@omnitor.se> wrote:

I have a compromise proposal. Let us test if we can get somewhere by introducing it.

Let us delete the use of the asterisk '*' for the 'do not drop' notation, and let 'do not drop' be the default.

Let us reuse the asterisk attached to the end of a language tag be used for both a priority indication with the whole sdp as scope, and an indication of grouping.

Initial change proposals ( there will be more follow-up changes, but these are the main ones )

---------------change in 6.2 from---------------------------------------------------------------

 In an offer, each language tag value MAY have an asterisk appended as
   the last character (after the registry value).  The asterisk
   indicates a request by the caller to not fail the call if there is no
   language in common.  See Section 6.3 for more information and
   discussion.
-------------------to-------------------------------------
 In an offer, language tag values MAY have an asterisk appended as
   the last character (after the registry value).  The asterisk
   indicates a main preference for the indicated language.  See Section 6.3 
   for more information and discussion.
----------------------------end of change in 6.2---------------------

-------------------Replace 6.3 with this----------------------------------

6.3 Main preference

If a user has a strong preference for using a language over the other 
indicated languages, this preference can be indicated by including an 
asterisk '*' last in the value of the preferred language and direction 
indication.

One such preference indication can be used per direction to indicate 
main preference. This preference has scope across all media.

Two or more such preference indications can be used per direction to 
indicate a strong preference or capability to use the indicated languages
in the indicated direction simultaneously together.

Examples:
Example 1;  a calling user, who strongly prefers to use spoken English
 supported by reception of rapidly added text captioning of the received 
 speech can indicate this preference by the following abbreviated sdp.
 This indication can be used by the callee or by the involved services 
 to make efforts to invoke a way of adding text to the speech answers. 
 
   m=audio ...
    humintlang-send:en
    humintlang-recv:en*
   m=text ...
    humintlang-recv:en*
  
Example 2; a calling user, who prefers to use American sign language both
  ways, but want to indicate that text in English both ways is an accepted 
  alternative on lower preference level can indicate this preference by the
  following abbreviated sdp:
  This indication can be used by the called party to make efforts to answer
  with sign language competent personnel, but if that is not available be 
  assured that a text conversation will also be successful.  
 
   m=video ...
    humintlang-send:ase*
    humintlang-recv:ase*
   m=text ...
    humintlang-send:en
    humintlang-recv:en

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

Discussion: This compromise satisfies most use cases for which global preference and grouping are needed, but has some drawbacks compared to a system with finer graded preferences.

1. For the grouping example above with receiving spoken English and English text, it cannot be seen what is best if it is not possible to provide the combination. There is no clue if it would be reasonably possible to provide only text or only spoken English.

2. The notation is only usable for a single preference combination. 
 It is not possible to indicate a number of sign languages, all preferred over typed English.
This drawback appears because the same notation is used for main preference as for grouping indication.

I want anyway to provide this compromise proposal, because it does not introduce any extra complexity and it solves the main so far unsolved use cases.

/Gunnar


Den 2016-05-19 kl. 00:23, skrev Gunnar Hellström:
Den 2016-05-18 kl. 19:08, skrev Natasha Rooney:
Randall - the last edit we see of the doc is from March, is this the most recent one? If not can you submit an edit soon?
We had e-mail list discussion around April 8-10 under the subject "[Slim] Wording about selection in draft-ietf-slim-negotiating-human-language-01"
that ended with some agreed changes and some in-principle agreed changes but no agreed wording. That is what I refer to when I say I want to see what the latest edits ended up in.

That mainly covered the ambition to be more exact than RFC 4566 lang specification.

So, when we get that, we can judge:
1. If it is clear when the indications reflect a selection possibility or a combination requirement. 

There are a couple of other things we need to modify also before progressing to any kind of consensus. 

2. In 5. Delete our interpretation of the lang attribute. It is sufficient to say that it is not enough detailed because it does not provide directionality.

3. In 5. insert specification on how lang and humintlang relates. The easiest way is to say that lang should not be used in sdp where humintlang is used. Is that too drastic?

4. Do we really need the * parameter for "do not fail call" introduced in 6.2 and explained in 6.3?  It will be most common to want to have that effect, thus requiring to add the * in most media specifications. Can we simplify the syntax by having "do not fail call" as the default and delete the description of the * ? I suggest that we delete it.
If not, the description of the syntax of how the * is included needs to be inserted in the syntax description in section 6.2 and an example added.

5. In this part of 6.2: 
"In cases where the user
   wishes to use one media for sending and another for receiving (such
   as a speech-impaired user who wishes to send using text and receive
   using audio), one of the two MAY be unset.  In cases where a media is
   not primarily intended for language (for example, a video or audio
   stream intended for background only) both SHOULD be unset.  In other
   cases, both SHOULD have the same values in the same order.  The two
   SHOULD NOT be set to languages which are difficult to match together"

Clarify that "two" and "both" refers to the humintlang-send and humintlang-recv attributes for a medium. 
( the attribute names are too far back so when searching for what "two" and "both" refers to you end up in confusion).

6. And, yet another proposal to insert a simple indication for preference betweeen media, and one for distinguishing selection versus combination.
The needs come from accessibility needs, and fulfilling accessibility needs has strong policy support, so it would be bad to say that that must wait for another version of the document when we already now have specified the need. 

--------------------------------------------------In 6.2 insert:----------------------------------------------------------------------
A single digit numeric value on a humintlang attribute represents a starting priority for the humintlang attributes of the same medium and direction, with one being the highest priority.  If no such value is indicated, the value 1 is assumed. The priority value is increased by a value 0.1 for each humintlang attribute for the same media and direction. 
An asterisk on a humintlang attribute alone or together with a priority number indicates that a language specified in the actual media and direction is wanted in combination with another modality in the same direction, also marked with an asterisk.

Examples:
m=audio ...
humintlang-send:en
humintlang-recv:*
humintlang-recv:en
m=text ...
humintlang-recv:*
humintlang-recv:en

This means that the user want to send spoken English and receive a combination of both spoken and typed English simultaneously  back.

m=video ...
humintlang-send:ase
humintlang-recv:ase
m=text ...
humintlang-send:5
humintlang-send:en
humintlang-recv:5
humintlang-recv:en

This means that the user prefers to use American sign language both ways, but as a possible selection on lower preference level use text both ways.
---------------------------------------------------------end of insertion---------------------
  
The fact that the humintlang attribute now can have values that are not language tags needs to be reflected in a few other places in the draft.



 

 


All - In all our discussions I see two things that we want here: [1] we want a simple and easily implementable solution/s and [2] solution/s that cover all the use cases. I think we can agree that going ahead with a simple solutions which is extensible covers both of these needs. It allows us to get something out there which can be implemented, and it allows us to answer all the use cases with extensibility which we will work on next (I appreciate this isn’t immediate but it’s favourable to making a complex solution now which is too difficult to implement). All advice I have received on this has suggested this is the best route forward.
We can't wait with an extension for something we have a need for now.
The above addition no 6. is a simple notation for what we were missing.

Given we’re well over the time that we should have agreed on this I suggest we call rough consensus for this here. I understand there may be some frustration, but really this method solves for both needs and so is sensible.

Bernard and Alexey - please check this and input if you see fit!

Natasha

/Gunnar

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


On May 17, 2016, at 10:56 PM, Gunnar Hellström <gunnar.hellstrom@omnitor.se> wrote:

Den 2016-05-17 kl. 23:17, skrev Randall Gellens:

Gunnar, 

I think we can start with what we have now: the offerer offers all media/languages it wants, and the answerer accepts those it supports. 
Yes, but we need a bit more than we have today to express that. Language usage are logically linked.
In many cases this will be exactly what's desired, while in some cases there will be extra media that are not used. 
I am not bothered about extra media. Offered media shall not be rejected just because they do not have agreed language contents.

This gives us something simple that has the best chance of rapid and wide deployment.  We can then build on this if need be.
We already have the need. 3GPP cannot use user profiles in emergency registration mode, so we need to be able to express user needs this way to the degree that they can be served well in emergency calls. 
For that we need to 
clarify language in some places in the draft so that we do not end up equally fuzzy as RFC 4566, 
We need to delete our interpretation of RFC 4566,
we need to express preference with scope among all media. 
and we need to express when languages are needed together and when they are to select from.

You have accepted some edit proposals that we have discussed and modified others to something that we have not  yet seen. I would like to see the draft as it is now so that we can see what more needs to be changed.   



At 8:01 AM +0200 5/17/16, Gunnar Hellström wrote: 

 Randall, 

 Can you accept that our goal is to select the most appropriate language(s) for the call? 

 This includes providing guidance to the answering part so that the answer can be made in the most appropriate language(s). 

 That is stated in the charter: 

 "While the two use cases are in different contexts (real time and 
 non-real-time), the fundamental goal is the same: to enable selection of 
 the best-fit language(s) for a specific situation. " 

 It is not sufficient to use the indications to select which media shall be enabled, and then let the users sort out which language to use. 

 The user needs guidance if it is most appropriate to start the conversation in voice, sign language or text or a combination of these modalities. If not, the call will start with confusion about what is the most efficient means for them to communicate. 

 That is why the preference indication needs to have: 

 a) a common scope over all media, and 

 b) an indication if two modalities simultaneously are desired for reception. 

 Can we agree on that and move on to find a simple way of expressing these needs? 

 /Gunnar 




 Den 2016-05-17 kl. 05:25, skrev Randall Gellens: 

 At 8:28 PM -0600 5/16/16, Doug Ewell wrote: 

 Except that there is still disagreement on whether the mechanism is needed for SLIM 1.0. 


 And we have a call for consensus by the chairs. 


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

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



-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288
_______________________________________________
SLIM mailing list
SLIM@ietf.org
https://www.ietf.org/mailman/listinfo/slim

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


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


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


-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288
_______________________________________________
SLIM mailing list
SLIM@ietf.org
https://www.ietf.org/mailman/listinfo/slim



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


-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288
_______________________________________________
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
--------------40619FE6FB70352A926E5177-- From nobody Sun May 22 22:57: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 54F0A12D51C for ; Sun, 22 May 2016 22:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 y1MVr-MBSS2O for ; Sun, 22 May 2016 22:57:22 -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 B559412D1DD for ; Sun, 22 May 2016 22:57:21 -0700 (PDT) X-Halon-ID: 308bd203-20ab-11e6-81fe-0050569116f7 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.5] (unknown [77.53.228.40]) by bin-vsp-out-03.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Mon, 23 May 2016 07:57:10 +0200 (CEST) To: Randall Gellens , slim@ietf.org References: <20160516083958.665a7a7059d7ee80bb4d670165c8327d.5e281af085.wbe@email0 3.godaddy.com> <7C5A334F88FD45E0A7770AFA6CB33C82@DougEwell> <57289c9f-a63a-0466-eeb7-845f1f1421ae@omnitor.se> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <73464fa5-24a1-3ce3-a50f-577b45fe9ad0@omnitor.se> Date: Mon, 23 May 2016 07:57:07 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------B8E0AB5E06EA3586B7D5C3E2" Archived-At: Subject: [Slim] Coding for the use cases in draft-ietf-slim-negotiating-human-language 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, 23 May 2016 05:57:25 -0000 This is a multi-part message in MIME format. --------------B8E0AB5E06EA3586B7D5C3E2 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Randall, Den 2016-05-17 kl. 23:17, skrev Randall Gellens: > Gunnar, > > I think we can start with what we have now: the offerer offers all > media/languages it wants, and the answerer accepts those it supports. > In many cases this will be exactly what's desired, while in some cases > there will be extra media that are not used. I do not see how this would work with the use cases that are already in the draft. Can you please explain your view? The sixth paragraph in the introduction says: " By treating language as another attribute that is negotiated along with other aspects of a media stream, it becomes possible to accommodate a range of users' needs and called party facilities.*For example,**some users may be able to speak several languages, but have a preference*. Some called parties may support some of those languages internally but require the use of a translation service for others, or may have a limited number of call takers able to use certain languages.*Another example would be a user who is able to speak but is deaf or hard-of-hearing and requires a voice stream plus a text stream (known as voice carry over). * Making language a media attribute allows the standard session negotiation mechanism to handle this by providing the information and mechanism for the endpoints to make appropriate decisions." Here we have the different cases mentioned that I try to find a suitable notation for: One is "some users may be able to speak several languages, but have a preference" An example can be a user who prefers to receive spoken English, but can accept to read English instead as a less preferred alternative. How would you code that? The other case is "a user who is able to speak but is deaf or hard-of-hearing and requires a voice stream plus a text stream (known as voice carry over)" An example can be a user who prefers to receive spoken English, and needs to get it complemented with a written transcription in English. How would you code that? I cannot see how the important difference between these cases can be expressed with the notation in the current draft. The different additional notations we have discussed lately can express this difference. They have different advantages and shortcomings. I slightly prefer the compromise proposal redefining the meaning of the asterisk, because of its simplicity and because it works on single language level. What is your preference? /Gunnar > > This gives us something simple that has the best chance of rapid and > wide deployment. We can then build on this if need be. > > At 8:01 AM +0200 5/17/16, Gunnar Hellström wrote: > >> Randall, >> >> Can you accept that our goal is to select the most appropriate >> language(s) for the call? >> >> This includes providing guidance to the answering part so that the >> answer can be made in the most appropriate language(s). >> >> That is stated in the charter: >> >> "While the two use cases are in different contexts (real time and >> non-real-time), the fundamental goal is the same: to enable >> selection of >> the best-fit language(s) for a specific situation. " >> >> It is not sufficient to use the indications to select which media >> shall be enabled, and then let the users sort out which language to use. >> >> The user needs guidance if it is most appropriate to start the >> conversation in voice, sign language or text or a combination of >> these modalities. If not, the call will start with confusion about >> what is the most efficient means for them to communicate. >> >> That is why the preference indication needs to have: >> >> a) a common scope over all media, and >> >> b) an indication if two modalities simultaneously are desired for >> reception. >> >> Can we agree on that and move on to find a simple way of expressing >> these needs? >> >> /Gunnar >> >> >> >> >> Den 2016-05-17 kl. 05:25, skrev Randall Gellens: >> >>> At 8:28 PM -0600 5/16/16, Doug Ewell wrote: >>> >>>> Except that there is still disagreement on whether the mechanism >>>> is needed for SLIM 1.0. >>>> >>> >>> And we have a call for consensus by the chairs. >>> >> >> -- >> ----------------------------------------- >> 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 --------------B8E0AB5E06EA3586B7D5C3E2 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Randall,

Den 2016-05-17 kl. 23:17, skrev Randall Gellens:
Gunnar,

I think we can start with what we have now: the offerer offers all media/languages it wants, and the answerer accepts those it supports.  In many cases this will be exactly what's desired, while in some cases there will be extra media that are not used.
I do not see how this would work with the use cases that are already in the draft. Can you please explain your view?
The sixth paragraph in the introduction says:

" By treating language as another attribute that is negotiated along with other aspects of a media stream, it becomes possible to accommodate a range of users' needs and called party facilities. For example, some users may be able to speak several languages, but have a preference. Some called parties may support some of those languages internally but require the use of a translation service for others, or may have a limited number of call takers able to use certain languages. Another example would be a user who is able to speak but is deaf or hard-of-hearing and requires a voice stream plus a text stream (known as voice carry over). Making language a media attribute allows the standard session negotiation mechanism to handle this by providing the information and mechanism for the endpoints to make appropriate decisions."


Here we have the different cases mentioned that I try to find a suitable notation for:

One is "some users may be able to speak several languages, but have a preference"

An example can be a user who prefers to receive spoken English, but can accept to read English instead as a less preferred alternative.
How would you code that?

The other case is "a user who is able to speak but is deaf or hard-of-hearing and requires a voice stream plus
a text stream (known as voice carry over)"

An example can be a user who prefers to receive spoken English, and needs to get it complemented with a written
transcription in English.
How would you code that?

I cannot see how the important difference between these cases can be expressed with the notation in the current draft.

The different additional notations we have discussed lately can express this difference. They have different advantages and shortcomings. I slightly prefer the compromise proposal redefining the meaning of the asterisk, because of its simplicity and because it works on single language level. What is your preference?

/Gunnar


This gives us something simple that has the best chance of rapid and wide deployment.  We can then build on this if need be.

At 8:01 AM +0200 5/17/16, Gunnar Hellström wrote:

 Randall,

 Can you accept that our goal is to select the most appropriate language(s) for the call?

 This includes providing guidance to the answering part so that the answer can be made in the most appropriate language(s).

 That is stated in the charter:

 "While the two use cases are in different contexts (real time and
 non-real-time), the fundamental goal is the same: to enable selection of
 the best-fit language(s) for a specific situation. "

 It is not sufficient to use the indications to select which media shall be enabled, and then let the users sort out which language to use.

 The user needs guidance if it is most appropriate to start the conversation in voice, sign language or text or a combination of these modalities. If not, the call will start with confusion about what is the most efficient means for them to communicate.

 That is why the preference indication needs to have:

 a) a common scope over all media, and

 b) an indication if two modalities simultaneously are desired for reception.

 Can we agree on that and move on to find a simple way of expressing these needs?

 /Gunnar




 Den 2016-05-17 kl. 05:25, skrev Randall Gellens:

 At 8:28 PM -0600 5/16/16, Doug Ewell wrote:

 Except that there is still disagreement on whether the mechanism is needed for SLIM 1.0.


 And we have a call for consensus by the chairs.


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

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



-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288
--------------B8E0AB5E06EA3586B7D5C3E2-- From nobody Mon May 23 06:50:41 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 45A5912D8D3 for ; Mon, 23 May 2016 06:50:40 -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 waJnkP41_EaB for ; Mon, 23 May 2016 06:50:37 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81C2012B034 for ; Mon, 23 May 2016 06:50:36 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id n63so107912880qkf.0 for ; Mon, 23 May 2016 06:50:36 -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=jnV9ZloXJRPsQhDraVShEkJWijW66W5ILIBZtm3dd2k=; b=Rs82XYCo+dWaj2yoVOQA0WN3c+E2hiBRl0gmk/CjKpFrVvxS5/xbltlAXN0tN90nzc upSxRKe0mRwqJ/HpiUyNKYJkMNFly/0+QPbIeYlDBNKpFpeEsWRczc0kY2qa2eGGloK8 HytDky0udbX+d1HZXMLdn6G6Z6QMPdJqFXpnhstdMN3CbJz/gImPnpBdsflk6k3jfbDH +MPT3R08p6qTkSszOs8AeeNteOdDn4w+0bjryL7SGKDzpDsqWto/8onsMbFmaqIVlzk5 U2is/iKjP3wt/2nl/p38MBNM6RjZFWH3vq420VX2ErsqqC8xsrwoRbhvpnvSw35RlMAw cPfg== 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=jnV9ZloXJRPsQhDraVShEkJWijW66W5ILIBZtm3dd2k=; b=Md+VwjSQUWidt7bmt16BLvn9366BnZ8Ux5gzfnf0HdP2cpznelJhc0HRwohhRY12Q7 woZQRPy4sRLwvoYJ4m36uniYuVDWysUjLcMaf0h0VqeNTVHNNLMksNeptnTDOIBVUdzG sJKMGXr33OmIoGMxdRrqxqrUQlO0Syx9PeusTwOtLtS8/di3jPvtYvWeK0MonlsTEKna bm6F5wYDlKehlGLaIAQWoDPhnNtM20qEWhvjb4YVqeNULpv7ptsUhCT1eFiRnhValVUe tjVOjFCuBvZU4tm1TBv/bJKsoVo5OShlcbzW3hWDeN5LJQ+ruy9FISBu4tFVHyPe25Qi 6Ajw== X-Gm-Message-State: AOPr4FXn5UVqG2nv+I3S0nEd/Vf3URvv61EHv/G0wB9X7UFGu0Q0qqMkUGeVZOs1IqsfXg== X-Received: by 10.55.76.84 with SMTP id z81mr16269491qka.17.1464011435419; Mon, 23 May 2016 06:50:35 -0700 (PDT) Received: from [10.33.192.30] ([156.154.81.54]) by smtp.gmail.com with ESMTPSA id 132sm8147772qhn.26.2016.05.23.06.50.34 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 23 May 2016 06:50:34 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_98FA3CAC-4060-44F2-9AF2-2200A96ABE6E" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Brian Rosen In-Reply-To: <73464fa5-24a1-3ce3-a50f-577b45fe9ad0@omnitor.se> Date: Mon, 23 May 2016 09:50:31 -0400 Message-Id: References: <20160516083958.665a7a7059d7ee80bb4d670165c8327d.5e281af085.wbe@email0 3.godaddy.com> <7C5A334F88FD45E0A7770AFA6CB33C82@DougEwell> <57289c9f-a63a-0466-eeb7-845f1f1421ae@omnitor.se> <73464fa5-24a1-3ce3-a50f-577b45fe9ad0@omnitor.se> To: =?utf-8?Q?Gunnar_Hellstr=C3=B6m?= X-Mailer: Apple Mail (2.3124) Archived-At: Cc: slim@ietf.org, Randall Gellens Subject: Re: [Slim] Coding for the use cases in draft-ietf-slim-negotiating-human-language 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, 23 May 2016 13:50:40 -0000 --Apple-Mail=_98FA3CAC-4060-44F2-9AF2-2200A96ABE6E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Inline > On May 23, 2016, at 1:57 AM, Gunnar Hellstr=F6m = wrote: >=20 > Randall, >=20 > Den 2016-05-17 kl. 23:17, skrev Randall Gellens: >> Gunnar,=20 >>=20 >> I think we can start with what we have now: the offerer offers all = media/languages it wants, and the answerer accepts those it supports. = In many cases this will be exactly what's desired, while in some cases = there will be extra media that are not used.=20 > I do not see how this would work with the use cases that are already = in the draft. Can you please explain your view? > The sixth paragraph in the introduction says: > " By treating language as another attribute that is negotiated along = with other aspects of a media stream, it becomes possible to accommodate = a range of users' needs and called party facilities. For example, some = users may be able to speak several languages, but have a preference. = Some called parties may support some of those languages internally but = require the use of a translation service for others, or may have a = limited number of call takers able to use certain languages. Another = example would be a user who is able to speak but is deaf or = hard-of-hearing and requires a voice stream plus a text stream (known as = voice carry over). Making language a media attribute allows the standard = session negotiation mechanism to handle this by providing the = information and mechanism for the endpoints to make appropriate = decisions." >=20 >=20 > Here we have the different cases mentioned that I try to find a = suitable notation for: >=20 > One is "some users may be able to speak several languages, but have a = preference" >=20 > An example can be a user who prefers to receive spoken English, but = can accept to read English instead as a less preferred alternative. > How would you code that? This is not an example of =93able to speak several languages, but have a = preference". An example of that would be =93I know English well, but = can manage Spanish, so English or Spanish with a preference for = English=94. It=92s preference of language within one media. To get what you want you ask for two streams, one text one audio, both = in English, and you get more than you need. The preference is not among = media streams, it=92s language within a stream. >=20 > The other case is "a user who is able to speak but is deaf or = hard-of-hearing and requires a voice stream plus=20 > a text stream (known as voice carry over)" >=20 > An example can be a user who prefers to receive spoken English, and = needs to get it complemented with a written=20 > transcription in English.=20 > How would you code that? Audio english, text English. No preferences. >=20 > I cannot see how the important difference between these cases can be = expressed with the notation in the current draft. >=20 > The different additional notations we have discussed lately can = express this difference. They have different advantages and = shortcomings. I slightly prefer the compromise proposal redefining the = meaning of the asterisk, because of its simplicity and because it works = on single language level. What is your preference? >=20 > /Gunnar >=20 >>=20 >> This gives us something simple that has the best chance of rapid and = wide deployment. We can then build on this if need be.=20 >>=20 >> At 8:01 AM +0200 5/17/16, Gunnar Hellstr=F6m wrote:=20 >>=20 >>> Randall,=20 >>>=20 >>> Can you accept that our goal is to select the most appropriate = language(s) for the call?=20 >>>=20 >>> This includes providing guidance to the answering part so that the = answer can be made in the most appropriate language(s).=20 >>>=20 >>> That is stated in the charter:=20 >>>=20 >>> "While the two use cases are in different contexts (real time and=20= >>> non-real-time), the fundamental goal is the same: to enable = selection of=20 >>> the best-fit language(s) for a specific situation. "=20 >>>=20 >>> It is not sufficient to use the indications to select which media = shall be enabled, and then let the users sort out which language to use.=20= >>>=20 >>> The user needs guidance if it is most appropriate to start the = conversation in voice, sign language or text or a combination of these = modalities. If not, the call will start with confusion about what is the = most efficient means for them to communicate.=20 >>>=20 >>> That is why the preference indication needs to have:=20 >>>=20 >>> a) a common scope over all media, and=20 >>>=20 >>> b) an indication if two modalities simultaneously are desired for = reception.=20 >>>=20 >>> Can we agree on that and move on to find a simple way of expressing = these needs?=20 >>>=20 >>> /Gunnar=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> Den 2016-05-17 kl. 05:25, skrev Randall Gellens:=20 >>>=20 >>>> At 8:28 PM -0600 5/16/16, Doug Ewell wrote:=20 >>>>=20 >>>>> Except that there is still disagreement on whether the mechanism = is needed for SLIM 1.0.=20 >>>>>=20 >>>>=20 >>>> And we have a call for consensus by the chairs.=20 >>>>=20 >>>=20 >>> --=20 >>> -----------------------------------------=20 >>> Gunnar Hellstr=F6m=20 >>> Omnitor=20 >>> = gunnar.hellstrom@omnitor.se = =20 >>> +46 708 204 288=20 >>>=20 >>> _______________________________________________=20 >>> SLIM mailing list=20 >>> SLIM@ietf.org =20 >>> https://www.ietf.org/mailman/listinfo/slim = =20 >>=20 >>=20 >=20 > --=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 --Apple-Mail=_98FA3CAC-4060-44F2-9AF2-2200A96ABE6E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Inline

On May 23, 2016, at 1:57 AM, = Gunnar Hellstr=F6m <gunnar.hellstrom@omnitor.se> wrote:

=20 =20

Randall,

Den 2016-05-17 kl. 23:17, skrev = Randall Gellens:
Gunnar,

I think we can start with what we have now: the offerer offers all media/languages it wants, and the answerer accepts those it supports.  In many cases this will be exactly what's desired, while in some cases there will be extra media that are not used.
I do not see how this would work with the use cases that are already in the draft. Can you please explain your view?
The sixth paragraph in the introduction says:

" By = treating language as another attribute that is negotiated along with other aspects of a media stream, it becomes possible to accommodate a range of users' needs and called party facilities. For = example, some users may be able to speak several languages, but have a preference. Some called parties may support some of those languages internally but require the use of a translation service for others, or may have a limited number of call takers able to use certain languages. Another example = would be a user who is able to speak but is deaf or hard-of-hearing and requires a voice stream plus a text stream (known as voice carry over). Making language a media attribute allows the standard session negotiation mechanism to handle this by providing the information and mechanism for the endpoints to make appropriate decisions."


Here we have the different cases mentioned that I try to find a suitable notation for:

One is "some users may be able to speak several languages, but have a preference"

An example can be a user who prefers to receive spoken English, but can accept to read English instead as a less preferred = alternative.
How would you code that?
This = is not an example of =93able to speak several languages, but have a = preference".  An example of that would be =93I know English well, = but can manage Spanish, so English or Spanish with a preference for = English=94. It=92s preference of language within one = media.

To get what you want you ask = for two streams, one text one audio, both in English, and you get more = than you need.  The preference is not among media streams, it=92s = language within a stream.


The other case is "a user who is able to speak but is deaf or hard-of-hearing and requires a voice stream plus
a text stream (known as voice carry over)"

An example can be a user who prefers to receive spoken English, and needs to get it complemented with a written
transcription in English.
How would you code that?
Audio = english, text English.
No preferences.


I cannot see how the important difference between these cases can be expressed with the notation in the current draft.

The different additional notations we have discussed lately can express this difference. They have different advantages and shortcomings. I slightly prefer the compromise proposal redefining the meaning of the asterisk, because of its simplicity and because it works on single language level. What is your preference?

/Gunnar


This gives us something simple that has the best chance of rapid and wide deployment.  We can then build on this if need be.

At 8:01 AM +0200 5/17/16, Gunnar Hellstr=F6m wrote:

 Randall,

 Can you accept that our goal is to select the most = appropriate language(s) for the call?

 This includes providing guidance to the answering part so = that the answer can be made in the most appropriate language(s).

 That is stated in the charter:

 "While the two use cases are in different contexts (real = time and
 non-real-time), the fundamental goal is the same: to = enable selection of
 the best-fit language(s) for a specific situation. "

 It is not sufficient to use the indications to select = which media shall be enabled, and then let the users sort out which language to use.

 The user needs guidance if it is most appropriate to start = the conversation in voice, sign language or text or a combination of these modalities. If not, the call will start with confusion about what is the most efficient means for them to communicate.

 That is why the preference indication needs to have:

 a) a common scope over all media, and

 b) an indication if two modalities simultaneously are = desired for reception.

 Can we agree on that and move on to find a simple way of expressing these needs?

 /Gunnar




 Den 2016-05-17 kl. 05:25, skrev Randall Gellens:

 At 8:28 PM -0600 = 5/16/16, Doug Ewell wrote:

 Except that there = is still disagreement on whether the mechanism is needed for SLIM 1.0.


 And we have a call for consensus by the chairs.


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

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



--=20
-----------------------------------------
Gunnar Hellstr=F6m
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288
_______________________________________________
SLIM = mailing list
SLIM@ietf.org
https://www.ietf.org/mailman/listinfo/slim

= --Apple-Mail=_98FA3CAC-4060-44F2-9AF2-2200A96ABE6E-- From nobody Mon May 23 07:56:57 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 3CBFA12B01A for ; Mon, 23 May 2016 07:56:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 7vP8ZqhxyRQt for ; Mon, 23 May 2016 07:56:51 -0700 (PDT) Received: from bin-vsp-out-05.atm.binero.net (bin-mail-out-06.binero.net [195.74.38.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CF9C12D94B for ; Mon, 23 May 2016 07:56:48 -0700 (PDT) X-Halon-ID: 93ec9507-20f6-11e6-9ca0-005056913f0f Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.5] (unknown [77.53.228.40]) by bin-vsp-out-05.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Mon, 23 May 2016 16:56:49 +0200 (CEST) To: Brian Rosen References: <20160516083958.665a7a7059d7ee80bb4d670165c8327d.5e281af085.wbe@email0 3.godaddy.com> <7C5A334F88FD45E0A7770AFA6CB33C82@DougEwell> <57289c9f-a63a-0466-eeb7-845f1f1421ae@omnitor.se> <73464fa5-24a1-3ce3-a50f-577b45fe9ad0@omnitor.se> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: Date: Mon, 23 May 2016 16:56:33 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------C4B18B2154B549D571AA04A1" Archived-At: Cc: slim@ietf.org, Randall Gellens Subject: Re: [Slim] Coding for the use cases in draft-ietf-slim-negotiating-human-language 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, 23 May 2016 14:56:55 -0000 This is a multi-part message in MIME format. --------------C4B18B2154B549D571AA04A1 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Brian, Thanks for a good effort. Den 2016-05-23 kl. 15:50, skrev Brian Rosen: > Inline > >> On May 23, 2016, at 1:57 AM, Gunnar Hellström >> > wrote: >> >> Randall, >> >> Den 2016-05-17 kl. 23:17, skrev Randall Gellens: >>> Gunnar, >>> >>> I think we can start with what we have now: the offerer offers all >>> media/languages it wants, and the answerer accepts those it >>> supports. In many cases this will be exactly what's desired, while >>> in some cases there will be extra media that are not used. >> I do not see how this would work with the use cases that are already >> in the draft. Can you please explain your view? >> The sixth paragraph in the introduction says: >> >> " By treating language as another attribute that is negotiated along >> with other aspects of a media stream, it becomes possible to >> accommodate a range of users' needs and called party facilities.*For >> example,**some users may be able to speak several languages, but have >> a preference*. Some called parties may support some of those >> languages internally but require the use of a translation service for >> others, or may have a limited number of call takers able to use >> certain languages.*Another example would be a user who is able to >> speak but is deaf or hard-of-hearing and requires a voice stream plus >> a text stream (known as voice carry over). * Making language a media >> attribute allows the standard session negotiation mechanism to handle >> this by providing the information and mechanism for the endpoints to >> make appropriate decisions." >> >> >> Here we have the different cases mentioned that I try to find a >> suitable notation for: >> >> One is "some users may be able to speak several languages, but have a >> preference" >> >> An example can be a user who prefers to receive spoken English, but >> can accept to read English instead as a less preferred alternative. >> How would you code that? > This is not an example of “able to speak several languages, but have a > preference". An example of that would be “I know English well, but > can manage Spanish, so English or Spanish with a preference for > English”. It’s preference of language within one media. [GH] For me it is an example “able to speak several languages, but have a preference". For what reason should we make a difference between media, when the preference of users can be across media limits. We are defining this to satisfy common user needs. > > To get what you want you ask for two streams, one text one audio, both > in English, and you get more than you need. The preference is not > among media streams, it’s language within a stream. [GH]We need it to reflect user needs and that is preference among media streams. With your interpretation, we would assign relay services when we do not need any. That is waste of resources and causes delays and a bit less privacy. That should be avoided. > >> >> The other case is "a user who is able to speak but is deaf or >> hard-of-hearing and requires a voice stream plus >> a text stream (known as voice carry over)" >> >> An example can be a user who prefers to receive spoken English, and >> needs to get it complemented with a written >> transcription in English. >> How would you code that? > Audio english, text English. > No preferences. [GH] What do you mean that the evaluation rule would be? Would it be: try to satisfy the highest possible preferred language in each direction in all media specifications together? ( with preference only applied between languages in the same media and direction. ) That interpretation would satisfy the grouping need, but not the need for preference regardless of media. It is likely more common to have a need to indicate preference between languages in different media than a need to have two languages/modalities together. But we should satisfy both. Gunnar > >> >> I cannot see how the important difference between these cases can be >> expressed with the notation in the current draft. >> >> The different additional notations we have discussed lately can >> express this difference. They have different advantages and >> shortcomings. I slightly prefer the compromise proposal redefining >> the meaning of the asterisk, because of its simplicity and because it >> works on single language level. What is your preference? >> >> /Gunnar >> >>> >>> This gives us something simple that has the best chance of rapid and >>> wide deployment. We can then build on this if need be. >>> >>> At 8:01 AM +0200 5/17/16, Gunnar Hellström wrote: >>> >>>> Randall, >>>> >>>> Can you accept that our goal is to select the most appropriate >>>> language(s) for the call? >>>> >>>> This includes providing guidance to the answering part so that the >>>> answer can be made in the most appropriate language(s). >>>> >>>> That is stated in the charter: >>>> >>>> "While the two use cases are in different contexts (real time and >>>> non-real-time), the fundamental goal is the same: to enable >>>> selection of >>>> the best-fit language(s) for a specific situation. " >>>> >>>> It is not sufficient to use the indications to select which media >>>> shall be enabled, and then let the users sort out which language to >>>> use. >>>> >>>> The user needs guidance if it is most appropriate to start the >>>> conversation in voice, sign language or text or a combination of >>>> these modalities. If not, the call will start with confusion about >>>> what is the most efficient means for them to communicate. >>>> >>>> That is why the preference indication needs to have: >>>> >>>> a) a common scope over all media, and >>>> >>>> b) an indication if two modalities simultaneously are desired for >>>> reception. >>>> >>>> Can we agree on that and move on to find a simple way of >>>> expressing these needs? >>>> >>>> /Gunnar >>>> >>>> >>>> >>>> >>>> Den 2016-05-17 kl. 05:25, skrev Randall Gellens: >>>> >>>>> At 8:28 PM -0600 5/16/16, Doug Ewell wrote: >>>>> >>>>>> Except that there is still disagreement on whether the mechanism >>>>>> is needed for SLIM 1.0. >>>>>> >>>>> >>>>> And we have a call for consensus by the chairs. >>>>> >>>> >>>> -- >>>> ----------------------------------------- >>>> Gunnar Hellström >>>> Omnitor >>>> gunnar.hellstrom@omnitor.se >>>> +46 708 204 288 >>>> >>>> _______________________________________________ >>>> SLIM mailing list >>>> SLIM@ietf.org >>>> https://www.ietf.org/mailman/listinfo/slim >>> >>> >> >> -- >> ----------------------------------------- >> Gunnar Hellström >> Omnitor >> gunnar.hellstrom@omnitor.se >> +46 708 204 288 >> _______________________________________________ >> SLIM mailing list >> SLIM@ietf.org >> https://www.ietf.org/mailman/listinfo/slim > > > > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 --------------C4B18B2154B549D571AA04A1 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Brian,

Thanks for a good effort.



Den 2016-05-23 kl. 15:50, skrev Brian Rosen:
Inline

On May 23, 2016, at 1:57 AM, Gunnar Hellström <gunnar.hellstrom@omnitor.se> wrote:

Randall,

Den 2016-05-17 kl. 23:17, skrev Randall Gellens:
Gunnar,

I think we can start with what we have now: the offerer offers all media/languages it wants, and the answerer accepts those it supports.  In many cases this will be exactly what's desired, while in some cases there will be extra media that are not used.
I do not see how this would work with the use cases that are already in the draft. Can you please explain your view?
The sixth paragraph in the introduction says:

" By treating language as another attribute that is negotiated along with other aspects of a media stream, it becomes possible to accommodate a range of users' needs and called party facilities. For example, some users may be able to speak several languages, but have a preference. Some called parties may support some of those languages internally but require the use of a translation service for others, or may have a limited number of call takers able to use certain languages. Another example would be a user who is able to speak but is deaf or hard-of-hearing and requires a voice stream plus a text stream (known as voice carry over). Making language a media attribute allows the standard session negotiation mechanism to handle this by providing the information and mechanism for the endpoints to make appropriate decisions."


Here we have the different cases mentioned that I try to find a suitable notation for:

One is "some users may be able to speak several languages, but have a preference"

An example can be a user who prefers to receive spoken English, but can accept to read English instead as a less preferred alternative.
How would you code that?
This is not an example of “able to speak several languages, but have a preference".  An example of that would be “I know English well, but can manage Spanish, so English or Spanish with a preference for English”. It’s preference of language within one media.
[GH] For me it is an example “able to speak several languages, but have a preference". For what reason should we make a difference between media, when the preference of users can be across media limits. We are defining this to satisfy common user needs.

To get what you want you ask for two streams, one text one audio, both in English, and you get more than you need.  The preference is not among media streams, it’s language within a stream.
[GH]We need it to reflect user needs and that is preference among media streams.
With your interpretation, we would assign relay services when we do not need any. That is waste of resources and causes delays and a bit less privacy. That should be avoided.



The other case is "a user who is able to speak but is deaf or hard-of-hearing and requires a voice stream plus
a text stream (known as voice carry over)"

An example can be a user who prefers to receive spoken English, and needs to get it complemented with a written
transcription in English.
How would you code that?
Audio english, text English.
No preferences.
[GH] What do you mean that the evaluation rule would be?
Would it be: try to satisfy the highest possible preferred language in each direction in all media specifications together?  ( with preference only applied between languages in the same media and direction. )

That interpretation would satisfy the grouping need, but not the need for preference regardless of media. It is likely more common to have a need to indicate preference between languages in different media than a need to have two languages/modalities together. But we should satisfy both.

Gunnar


 


I cannot see how the important difference between these cases can be expressed with the notation in the current draft.

The different additional notations we have discussed lately can express this difference. They have different advantages and shortcomings. I slightly prefer the compromise proposal redefining the meaning of the asterisk, because of its simplicity and because it works on single language level. What is your preference?

/Gunnar


This gives us something simple that has the best chance of rapid and wide deployment.  We can then build on this if need be.

At 8:01 AM +0200 5/17/16, Gunnar Hellström wrote:

 Randall,

 Can you accept that our goal is to select the most appropriate language(s) for the call?

 This includes providing guidance to the answering part so that the answer can be made in the most appropriate language(s).

 That is stated in the charter:

 "While the two use cases are in different contexts (real time and
 non-real-time), the fundamental goal is the same: to enable selection of
 the best-fit language(s) for a specific situation. "

 It is not sufficient to use the indications to select which media shall be enabled, and then let the users sort out which language to use.

 The user needs guidance if it is most appropriate to start the conversation in voice, sign language or text or a combination of these modalities. If not, the call will start with confusion about what is the most efficient means for them to communicate.

 That is why the preference indication needs to have:

 a) a common scope over all media, and

 b) an indication if two modalities simultaneously are desired for reception.

 Can we agree on that and move on to find a simple way of expressing these needs?

 /Gunnar




 Den 2016-05-17 kl. 05:25, skrev Randall Gellens:

 At 8:28 PM -0600 5/16/16, Doug Ewell wrote:

 Except that there is still disagreement on whether the mechanism is needed for SLIM 1.0.


 And we have a call for consensus by the chairs.


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

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



-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288
_______________________________________________
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
--------------C4B18B2154B549D571AA04A1-- From nobody Mon May 23 09:29:40 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 94B9712D9EE for ; Mon, 23 May 2016 09:29:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 6qsgU04F63is for ; Mon, 23 May 2016 09:29:38 -0700 (PDT) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9856F12D9B0 for ; Mon, 23 May 2016 09:29:37 -0700 (PDT) Received: by mail-qg0-x233.google.com with SMTP id f92so91561565qgf.0 for ; Mon, 23 May 2016 09:29:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9Ex2g3Lwcg71d4dO+1R61eYoIqY6NxeNlO05tv/fgMc=; b=1w1lsD7+nYJHsbGDzb4mcwD0lj9enaYnyCAkSN3BHAyS2dDgdzMolZF4usbJ8jv6eE BnnwTylvgf41n1+z2Scgo1MwII3br9JwWPLehKiA+xsFOdeA1s6KKgVW+b90OXTD8bhq M4LFrpeVjeMMuFla+HK4z1taRFFBt0llQNXoBNlqDQnCqT63kfxgYosrm0HnRM2om7fP bmrMqRS/+TydAe3oMUt95O7XKyb9SYKWuuTQpZfnDK0azut32Etij7JPGFyAvsc3gh6a cw/Xzf4JwvztqpbsoiKMV1+CcyBmPbpydCuTp93ZtJIeeJamEhlPfL4pGCRoV3qzHlpk VFEA== 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 :content-transfer-encoding:message-id:references:to; bh=9Ex2g3Lwcg71d4dO+1R61eYoIqY6NxeNlO05tv/fgMc=; b=BOaJZ3FeVNCEXmG8Xl9RJeG2xF51gJYWygww4U1Nwizc5/Dg8BLvcSVDCjkwBQJyeW FAL2PVxpWuGS76sr5u9iIRILpmIZ1ibk4Qmlrz9ZE1muVLqRu8ddBTiwbHiAE3CpjGT3 aMHUL4OK5kRE5dyFZ2aDLviNUMEnyutTu8zvq/BYJuJBX4Oacwez9kqGpv0BYkrm4rez CBfTLWtZowErqSeTJ8JqKVDhc7+0L5x5PPBGKtEZw7SJLhTmZvzVnXLRUL/YHljLYSKA mofmYAtrEqdtK6a0H+Cc4FvbetpLTZU86r5tsK8RjLmAmhwJtmvQTcGcFfaXTdlI6KXX XxHw== X-Gm-Message-State: AOPr4FWsMkCfXhbz1IQJvfQ4sEch5Xuv00O+MGGcJT0++nAnbSqKGeK06fUcIHySAu7MPg== X-Received: by 10.140.40.99 with SMTP id w90mr15930076qgw.42.1464020976690; Mon, 23 May 2016 09:29:36 -0700 (PDT) Received: from [10.33.192.30] ([156.154.81.54]) by smtp.gmail.com with ESMTPSA id s19sm3264537qhb.7.2016.05.23.09.29.35 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 23 May 2016 09:29:36 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Brian Rosen In-Reply-To: Date: Mon, 23 May 2016 12:29:33 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <66EB6B7A-FFF1-4ECE-89EC-650D37C36544@brianrosen.net> References: <20160516083958.665a7a7059d7ee80bb4d670165c8327d.5e281af085.wbe@email0 3.godaddy.com> <7C5A334F88FD45E0A7770AFA6CB33C82@DougEwell> <57289c9f-a63a-0466-eeb7-845f1f1421ae@omnitor.se> <73464fa5-24a1-3ce3-a50f-577b45fe9ad0@omnitor.se> To: =?windows-1252?Q?Gunnar_Hellstr=F6m?= X-Mailer: Apple Mail (2.3124) Archived-At: Cc: slim@ietf.org, Randall Gellens Subject: Re: [Slim] Coding for the use cases in draft-ietf-slim-negotiating-human-language 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, 23 May 2016 16:29:39 -0000 >>>=20 >>> Here we have the different cases mentioned that I try to find a = suitable notation for: >>>=20 >>> One is "some users may be able to speak several languages, but have = a preference" >>>=20 >>> An example can be a user who prefers to receive spoken English, but = can accept to read English instead as a less preferred alternative. >>> How would you code that? >> This is not an example of =93able to speak several languages, but = have a preference". An example of that would be =93I know English well, = but can manage Spanish, so English or Spanish with a preference for = English=94. It=92s preference of language within one media. > [GH] For me it is an example =93able to speak several languages, but = have a preference". For what reason should we make a difference between = media, when the preference of users can be across media limits. We are = defining this to satisfy common user needs.=20 I don=92t think we=92re treating spoken English as a different language = from written English. Same language, different media. If that=92s not what =93some users may be able to speak several = languages but have a preference=94 means, then we need to revisit the = use case document. >>=20 >> To get what you want you ask for two streams, one text one audio, = both in English, and you get more than you need. The preference is not = among media streams, it=92s language within a stream. > [GH]We need it to reflect user needs and that is preference among = media streams.=20 > With your interpretation, we would assign relay services when we do = not need any. That is waste of resources and causes delays and a bit = less privacy. That should be avoided.=20 I don=92t think I am alone in thinking that preference was per media, = and not between media. This effort isn=92t designed to extend SDP in = ways beyond signaling human language preferences within a media stream. =20= Several of us (I=92m looking at you Paul) have had conversations on how = to signal a request for interpreters (transcoders). I think we also = might need a way to label a stream as a translated version of another = stream, in the same or different media. That=92s label, not negotiate, = although at some point if you can label it, it can be turned into an = offer/answer negotiation. But that is out of scope of this work group. >=20 >>=20 >>>=20 >>> The other case is "a user who is able to speak but is deaf or = hard-of-hearing and requires a voice stream plus=20 >>> a text stream (known as voice carry over)" >>>=20 >>> An example can be a user who prefers to receive spoken English, and = needs to get it complemented with a written=20 >>> transcription in English.=20 >>> How would you code that? >> Audio english, text English. >> No preferences. > [GH] What do you mean that the evaluation rule would be? > Would it be: try to satisfy the highest possible preferred language in = each direction in all media specifications together? ( with preference = only applied between languages in the same media and direction. ) I think that you negotiate language in each stream independently of any = other stream. I don=92t think this effort is intended to provide a way to negotiate = relationships between streams or media. It=92s just language on a = stream. If our charter intended us to extend SDP to negotiate = relationships/grouping between streams, it would have been stated = explicitly, and we would have had to discuss why that capability wasn=92t = a lot more general (not limited to human language issues). >=20 > That interpretation would satisfy the grouping need, but not the need = for preference regardless of media. It is likely more common to have a = need to indicate preference between languages in different media than a = need to have two languages/modalities together. But we should satisfy = both. >=20 From nobody Mon May 23 10:12:05 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 5D59F12D11A for ; Mon, 23 May 2016 10:12:04 -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 UZVhNrMRhZru for ; Mon, 23 May 2016 10:12:03 -0700 (PDT) Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACE3012D11D for ; Mon, 23 May 2016 10:12:02 -0700 (PDT) Received: from resomta-ch2-14v.sys.comcast.net ([69.252.207.110]) by comcast with SMTP id 4tKLbti1nbFYY4tOcbSlpB; Mon, 23 May 2016 17:12:02 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1464023522; bh=H2XO9Dt3TmBmgP4b9a6A0Li0en9LgVwVYXDXDAUzhoY=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=LhtyAssF8OWo0JSj1G/a26cmjEtWJOghL5ZTqAFUMQyakr0S7+FVx/P1cDpjK7na/ u1F5isCGrIg9xF0SsXal/ilcB3DC+Yptvo30ujNSyUrffXw6GgZsJT1lqJrij6wnn9 92lUULRswJU5/WrrUtedmWgdy8QwbD3hisrQ+b8AX0lIpGts/C/BnxrwFMx25VdGoa NVW71j1nqXZBwjYjBqmDm+7Uf6lCh6cBiTkiNIIyvsCDbQLnv0ei5Ny8s1G4z8Tdp+ JMWqyR67pl2d/YbjzX3bQiNDKGpwujMsCoizG6ESwk2EMBPFk7+OUfQZaBqLGdNLrf 5GwaEJKy6ANyQ== Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-14v.sys.comcast.net with comcast id xtC11s00W3KdFy101tC1zN; Mon, 23 May 2016 17:12:01 +0000 To: slim@ietf.org References: <20160516083958.665a7a7059d7ee80bb4d670165c8327d.5e281af085.wbe@email0 3.godaddy.com> <7C5A334F88FD45E0A7770AFA6CB33C82@DougEwell> <57289c9f-a63a-0466-eeb7-845f1f1421ae@omnitor.se> <73464fa5-24a1-3ce3-a50f-577b45fe9ad0@omnitor.se> <66EB6B7A-FFF1-4ECE-89EC-650D37C36544@brianrosen.net> From: Paul Kyzivat Message-ID: <3e4c9883-b071-2e50-623f-219bcfae01c7@alum.mit.edu> Date: Mon, 23 May 2016 13:11:46 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <66EB6B7A-FFF1-4ECE-89EC-650D37C36544@brianrosen.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Slim] Coding for the use cases in draft-ietf-slim-negotiating-human-language 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, 23 May 2016 17:12:04 -0000 On 5/23/16 12:29 PM, Brian Rosen wrote: > Several of us (I’m looking at you Paul) have had conversations on how to signal a request for interpreters (transcoders). I think we also might need a way to label a stream as a translated version of another stream, in the same or different media. That’s label, not negotiate, although at some point if you can label it, it can be turned into an offer/answer negotiation. Yes. > But that is out of scope of this work group. Yes. That was settled some time ago. I've been resisting jumping into this conversation because I don't have anything new to add. Given the current scope I think it makes sense to keep things simple. I understand that this may turn out to be insufficient for identifying the need for interpretation, and for what sort of interpretation. We can deal with that if/when we get to it. Thanks, Paul From nobody Mon May 23 13:12: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 61A4E12DB4B for ; Mon, 23 May 2016 13:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 D9LZRaIH1DfW for ; Mon, 23 May 2016 13:12:44 -0700 (PDT) Received: from bin-vsp-out-05.atm.binero.net (bin-mail-out-06.binero.net [195.74.38.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B91C012DB49 for ; Mon, 23 May 2016 13:12:41 -0700 (PDT) X-Halon-ID: b4babe24-2122-11e6-9ca0-005056913f0f Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.2] (unknown [77.53.228.40]) by bin-vsp-out-05.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Mon, 23 May 2016 22:12:42 +0200 (CEST) To: Paul Kyzivat , slim@ietf.org References: <20160516083958.665a7a7059d7ee80bb4d670165c8327d.5e281af085.wbe@email0 3.godaddy.com> <7C5A334F88FD45E0A7770AFA6CB33C82@DougEwell> <57289c9f-a63a-0466-eeb7-845f1f1421ae@omnitor.se> <73464fa5-24a1-3ce3-a50f-577b45fe9ad0@omnitor.se> <66EB6B7A-FFF1-4ECE-89EC-650D37C36544@brianrosen.net> <3e4c9883-b071-2e50-623f-219bcfae01c7@alum.mit.edu> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <9d3e4bee-1363-fde9-e402-522c08e30535@omnitor.se> Date: Mon, 23 May 2016 22:12:26 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <3e4c9883-b071-2e50-623f-219bcfae01c7@alum.mit.edu> Content-Type: multipart/alternative; boundary="------------65834A6495812ED2C234CA77" Archived-At: Subject: Re: [Slim] Coding for the use cases in draft-ietf-slim-negotiating-human-language 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, 23 May 2016 20:12:47 -0000 This is a multi-part message in MIME format. --------------65834A6495812ED2C234CA77 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Den 2016-05-23 kl. 19:11, skrev Paul Kyzivat: > On 5/23/16 12:29 PM, Brian Rosen wrote: > >> Several of us (I’m looking at you Paul) have had conversations on how >> to signal a request for interpreters (transcoders). I think we also >> might need a way to label a stream as a translated version of another >> stream, in the same or different media. That’s label, not negotiate, >> although at some point if you can label it, it can be turned into an >> offer/answer negotiation. > > Yes. [GH] it is specified in rfc6497, the t- extension to RFC 5646. Example ja-t-it The content is Japanese, transformed from Italian. > >> But that is out of scope of this work group. > > Yes. That was settled some time ago. [GH] Yes > > I've been resisting jumping into this conversation because I don't > have anything new to add. Given the current scope I think it makes > sense to keep things simple. > > I understand that this may turn out to be insufficient for identifying > the need for interpretation, and for what sort of interpretation. We > can deal with that if/when we get to it. [GH] The idea is to declare the language needs, not the interpretation needs. The declaration shall be in sufficient detail to enable involved parties to get the call going efficiently. That includes to be able to judge if interpretation is needed. But that depends on what capabilities the answering party has initially. We are at that level of needs, and have been so for some years now. (12!) It is time to get it solved and not pushed more into the future. Thanks Gunnar > > Thanks, > Paul > > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 --------------65834A6495812ED2C234CA77 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit



Den 2016-05-23 kl. 19:11, skrev Paul Kyzivat:
On 5/23/16 12:29 PM, Brian Rosen wrote:

Several of us (I’m looking at you Paul) have had conversations on how to signal a request for interpreters (transcoders).  I think we also might need a way to label a stream as a translated version of another stream, in the same or different media.  That’s label, not negotiate, although at some point if you can label it, it can be turned into an offer/answer negotiation.

Yes.
[GH] it is specified in rfc6497, the t- extension to RFC 5646.
Example     ja-t-it  The content is Japanese, transformed from Italian.


But that is out of scope of this work group.

Yes. That was settled some time ago.
[GH] Yes

I've been resisting jumping into this conversation because I don't have anything new to add. Given the current scope I think it makes sense to keep things simple.

I understand that this may turn out to be insufficient for identifying the need for interpretation, and for what sort of interpretation. We can deal with that if/when we get to it.
[GH] The idea is to declare the language needs, not the interpretation needs. The declaration shall be in sufficient detail to enable involved parties to get the call going efficiently. That includes to be able to judge if interpretation is needed. But that depends on what capabilities the answering party has initially.
We are at that level of needs, and have been so for some years now. (12!) It is time to get it solved and not pushed more into the future.

Thanks
Gunnar

    Thanks,
    Paul

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

-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288
--------------65834A6495812ED2C234CA77-- From nobody Mon May 23 13:40:28 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 E502312DB68 for ; Mon, 23 May 2016 13:40:27 -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=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xv_zVK0lVe9s for ; Mon, 23 May 2016 13:40:26 -0700 (PDT) Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5CE612B03B for ; Mon, 23 May 2016 13:31:09 -0700 (PDT) Received: by mail-qg0-x22f.google.com with SMTP id e93so17582030qgf.2 for ; Mon, 23 May 2016 13:31:09 -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=kTG7bzRqqjf08rBkQwIdiiS1+0q8r3h4G/pPz1B9ar4=; b=TPrVFypfckWdwQewpbsXsqh88fES/rJqCdL71coDakypVwYwJMByDZIQEVDY9MRn33 JdyG1Ovpc0wvjhkoAfGFVOPUP7Zqrr3kPS5OHAttaKV4EHSkx2kF+5kbmhnl6DlvQ/v3 F8YhabIdeP3L61xEVzMgkCDXtELGqGJ3+03ysnJZ43QuAVHar/A0c6/Nbyl9L10QL7f0 hTWVWZdKicNT1xh04QUM5zREKKfPd3rv//61a7Frb7GlhsGZroFnsGCJ0Yg7idmbsZP2 CN5Qw03ZYpgh3zpH8QV1gErYpjAVTsDNs7nxyK+5qzTN+1TOJ9OIDHe8dJcLlqT+W+kz aIMQ== 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=kTG7bzRqqjf08rBkQwIdiiS1+0q8r3h4G/pPz1B9ar4=; b=SdtYMo8tkCxzT+zbtI2f4eFe7gnGWkN9DRLI+xFLnjtCF9oOZ1lwAbZmp71/okAQZX 6HfOnRzdd6pC9cnAbS0OVMdeNuH6AEHuwoomUEiF0xa2EcjYSFuNACVYcL/5UDRRwoSy q10fOr57d8fSGnuBTF22XT1rEgta1www6N3XVKu8y+3ondhLwOUzsslcl0lp6N9MfdFx nMKCUKxDCx6vnAUdH/uy7Qsbeqlb7kFY+so8CnEkvW5c/OHeuSynqOJeIo/9/B7NmLH1 NqnYCGxtJbyJFOZw09fxy5txmIvPSKaxOKZZaAqXd7ugHPhts3n19ZiQl7sOth25TEDL RisQ== X-Gm-Message-State: ALyK8tLtOTnS6fpZS8E1HIu/wKv9Z1VBMnAilMw5xSjq/6zmFEWPPz9nFAjDVgvOsmhy/w== X-Received: by 10.140.140.200 with SMTP id 191mr99954qhm.0.1464035468991; Mon, 23 May 2016 13:31:08 -0700 (PDT) Received: from [10.33.192.30] ([156.154.81.54]) by smtp.gmail.com with ESMTPSA id o128sm2416705qkb.40.2016.05.23.13.31.08 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 23 May 2016 13:31:08 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_229DE82D-3E82-4023-B677-E10EC041EC70" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Brian Rosen In-Reply-To: <9d3e4bee-1363-fde9-e402-522c08e30535@omnitor.se> Date: Mon, 23 May 2016 16:31:03 -0400 Message-Id: References: <20160516083958.665a7a7059d7ee80bb4d670165c8327d.5e281af085.wbe@email0 3.godaddy.com> <7C5A334F88FD45E0A7770AFA6CB33C82@DougEwell> <57289c9f-a63a-0466-eeb7-845f1f1421ae@omnitor.se> <73464fa5-24a1-3ce3-a50f-577b45fe9ad0@omnitor.se> <66EB6B7A-FFF1-4ECE-89EC-650D37C36544@brianrosen.net> <3e4c9883-b071-2e50-623f-219bcfae01c7@alum.mit.edu> <9d3e4bee-1363-fde9-e402-522c08e30535@omnitor.se> To: =?utf-8?Q?Gunnar_Hellstr=C3=B6m?= X-Mailer: Apple Mail (2.3124) Archived-At: Cc: slim@ietf.org, Paul Kyzivat Subject: Re: [Slim] Coding for the use cases in draft-ietf-slim-negotiating-human-language 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, 23 May 2016 20:40:28 -0000 --Apple-Mail=_229DE82D-3E82-4023-B677-E10EC041EC70 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I=92m done. I don=92t think we need to do this. =20 Chairs can decide what to do. Brian > On May 23, 2016, at 4:12 PM, Gunnar Hellstr=F6m = wrote: >=20 >=20 >=20 > Den 2016-05-23 kl. 19:11, skrev Paul Kyzivat: >> On 5/23/16 12:29 PM, Brian Rosen wrote:=20 >>=20 >>> Several of us (I=92m looking at you Paul) have had conversations on = how to signal a request for interpreters (transcoders). I think we also = might need a way to label a stream as a translated version of another = stream, in the same or different media. That=92s label, not negotiate, = although at some point if you can label it, it can be turned into an = offer/answer negotiation.=20 >>=20 >> Yes.=20 > [GH] it is specified in rfc6497, the t- extension to RFC 5646. > Example ja-t-it The content is Japanese, transformed from = Italian. >=20 >>=20 >>> But that is out of scope of this work group.=20 >>=20 >> Yes. That was settled some time ago.=20 > [GH] Yes >>=20 >> I've been resisting jumping into this conversation because I don't = have anything new to add. Given the current scope I think it makes sense = to keep things simple.=20 >>=20 >> I understand that this may turn out to be insufficient for = identifying the need for interpretation, and for what sort of = interpretation. We can deal with that if/when we get to it.=20 > [GH] The idea is to declare the language needs, not the interpretation = needs. The declaration shall be in sufficient detail to enable involved = parties to get the call going efficiently. That includes to be able to = judge if interpretation is needed. But that depends on what capabilities = the answering party has initially. > We are at that level of needs, and have been so for some years now. = (12!) It is time to get it solved and not pushed more into the future.=20= >=20 > Thanks > Gunnar >>=20 >> Thanks,=20 >> Paul=20 >>=20 >> _______________________________________________=20 >> SLIM mailing list=20 >> SLIM@ietf.org =20 >> https://www.ietf.org/mailman/listinfo/slim = =20 >=20 > --=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 --Apple-Mail=_229DE82D-3E82-4023-B677-E10EC041EC70 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I=92m done.

I don=92t think we need to do this.  

Chairs can decide what = to do.

Brian

On = May 23, 2016, at 4:12 PM, Gunnar Hellstr=F6m <gunnar.hellstrom@omnitor.se> wrote:

=20 =20



Den 2016-05-23 kl. 19:11, skrev Paul Kyzivat:
On 5/23/16 12:29 PM, Brian Rosen wrote:

Several of us (I=92m looking = at you Paul) have had conversations on how to signal a request for interpreters (transcoders).  I think we also might need a = way to label a stream as a translated version of another stream, in the same or different media.  That=92s label, not negotiate, = although at some point if you can label it, it can be turned into an offer/answer negotiation.

Yes.
[GH] it is specified in rfc6497, the t- extension to RFC 5646.
Example     ja-t-it  The content is =
Japanese, transformed from Italian.


But that is out of scope of = this work group.

Yes. That was settled some time ago.
[GH] Yes

I've been resisting jumping into this conversation because I don't have anything new to add. Given the current scope I think it makes sense to keep things simple.

I understand that this may turn out to be insufficient for identifying the need for interpretation, and for what sort of interpretation. We can deal with that if/when we get to it.
[GH] The idea is to declare the language needs, not the interpretation needs. The declaration shall be in sufficient detail to enable involved parties to get the call going efficiently. That includes to be able to judge if interpretation is needed. But that depends on what capabilities the answering party has initially.
We are at that level of needs, and have been so for some years now. (12!) It is time to get it solved and not pushed more into the future.

Thanks
Gunnar

    Thanks,
    Paul

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

--=20
-----------------------------------------
Gunnar Hellstr=F6m
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288
_______________________________________________
SLIM = mailing list
SLIM@ietf.org
https://www.ietf.org/mailman/listinfo/slim

= --Apple-Mail=_229DE82D-3E82-4023-B677-E10EC041EC70-- From nobody Mon May 23 13:56: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 4884112DBD0 for ; Mon, 23 May 2016 13:56:37 -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 HSq9eM4ksFf0 for ; Mon, 23 May 2016 13:56:34 -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 B582512DB96 for ; Mon, 23 May 2016 13:56:16 -0700 (PDT) X-Halon-ID: c77903d6-2128-11e6-9295-005056917a89 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.2] (unknown [77.53.228.40]) by bin-vsp-out-01.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Mon, 23 May 2016 22:56:11 +0200 (CEST) To: Brian Rosen References: <20160516083958.665a7a7059d7ee80bb4d670165c8327d.5e281af085.wbe@email0 3.godaddy.com> <7C5A334F88FD45E0A7770AFA6CB33C82@DougEwell> <57289c9f-a63a-0466-eeb7-845f1f1421ae@omnitor.se> <73464fa5-24a1-3ce3-a50f-577b45fe9ad0@omnitor.se> <66EB6B7A-FFF1-4ECE-89EC-650D37C36544@brianrosen.net> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <508dd412-59ca-52b1-78a0-876e89ff7e51@omnitor.se> Date: Mon, 23 May 2016 22:56:01 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <66EB6B7A-FFF1-4ECE-89EC-650D37C36544@brianrosen.net> Content-Type: multipart/alternative; boundary="------------3B824147649949828D0A16D9" Archived-At: Cc: slim@ietf.org, Randall Gellens Subject: Re: [Slim] Coding for the use cases in draft-ietf-slim-negotiating-human-language 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, 23 May 2016 20:56:37 -0000 This is a multi-part message in MIME format. --------------3B824147649949828D0A16D9 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Den 2016-05-23 kl. 18:29, skrev Brian Rosen: >>>> Here we have the different cases mentioned that I try to find a suitable notation for: >>>> >>>> One is "some users may be able to speak several languages, but have a preference" >>>> >>>> An example can be a user who prefers to receive spoken English, but can accept to read English instead as a less preferred alternative. >>>> How would you code that? >>> This is not an example of “able to speak several languages, but have a preference". An example of that would be “I know English well, but can manage Spanish, so English or Spanish with a preference for English”. It’s preference of language within one media. >> [GH] For me it is an example “able to speak several languages, but have a preference". For what reason should we make a difference between media, when the preference of users can be across media limits. We are defining this to satisfy common user needs. > I don’t think we’re treating spoken English as a different language from written English. Same language, different media. [GH]Yes, we are dealing with language/modality/direction combinations. RFC 5646 has a weakness in that it does not differ between spoken and written language in the tags, but we compensate for that by placing the tag together with the media that is suitable for the modality to be used. And it is essential that we deal with language in different modalities as separate. Some users are not able to type but can speak. > > If that’s not what “some users may be able to speak several languages but have a preference” means, then we need to revisit the use case document. > > >>> To get what you want you ask for two streams, one text one audio, both in English, and you get more than you need. The preference is not among media streams, it’s language within a stream. >> [GH]We need it to reflect user needs and that is preference among media streams. >> With your interpretation, we would assign relay services when we do not need any. That is waste of resources and causes delays and a bit less privacy. That should be avoided. > I don’t think I am alone in thinking that preference was per media, and not between media. This effort isn’t designed to extend SDP in ways beyond signaling human language preferences within a media stream. [GH] I hoped that I had explained the need sufficiently to realize that there is a need to specify priority for language between media. And since it is a soft indication, not tightly tied to negotiation of media usage, you do not need to be afraid if it seems to extend sdp to handle priorities between media. It is mainly about how to use the negotiated media for language contents. 3GPP TS 122.228 clause 7.5.2 says: "A UE should support negotiation of the user's desired language(s) (as defined in IANA [29]) and modalities for spoken, signed and written languages. The system should be able to negotiate the user's desired language(s) and modalities, per media stream and/or session, in order of preference." ETSI TR 103 201 refers to SLIM in many places. e.g. clause 6.5.4 and 7.2.3.3. http://www.etsi.org/deliver/etsi_tr/103200_103299/103201/01.01.01_60/tr_103201v010101p.pdf These are clear indications that the need is here now, and has been for some years. Did you like the proposal for how to code preference and grouping in RFC 5888 notation? /Gunnar > > > Several of us (I’m looking at you Paul) have had conversations on how to signal a request for interpreters (transcoders). I think we also might need a way to label a stream as a translated version of another stream, in the same or different media. That’s label, not negotiate, although at some point if you can label it, it can be turned into an offer/answer negotiation. > > But that is out of scope of this work group. > >>>> The other case is "a user who is able to speak but is deaf or hard-of-hearing and requires a voice stream plus >>>> a text stream (known as voice carry over)" >>>> >>>> An example can be a user who prefers to receive spoken English, and needs to get it complemented with a written >>>> transcription in English. >>>> How would you code that? >>> Audio english, text English. >>> No preferences. >> [GH] What do you mean that the evaluation rule would be? >> Would it be: try to satisfy the highest possible preferred language in each direction in all media specifications together? ( with preference only applied between languages in the same media and direction. ) > I think that you negotiate language in each stream independently of any other stream. > > I don’t think this effort is intended to provide a way to negotiate relationships between streams or media. It’s just language on a stream. > > If our charter intended us to extend SDP to negotiate relationships/grouping between streams, it would have been stated explicitly, and we would have had to discuss why that capability wasn’t a lot more general (not limited to human language issues). > > >> That interpretation would satisfy the grouping need, but not the need for preference regardless of media. It is likely more common to have a need to indicate preference between languages in different media than a need to have two languages/modalities together. But we should satisfy both. >> -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 --------------3B824147649949828D0A16D9 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Den 2016-05-23 kl. 18:29, skrev Brian Rosen:
Here we have the different cases mentioned that I try to find a suitable notation for:

One is "some users may be able to speak several languages, but have a preference"

An example can be a user who prefers to receive spoken English, but can accept to read English instead as a less preferred alternative.
How would you code that?

This is not an example of “able to speak several languages, but have a preference".  An example of that would be “I know English well, but can manage Spanish, so English or Spanish with a preference for English”. It’s preference of language within one media.

[GH] For me it is an example “able to speak several languages, but have a preference". For what reason should we make a difference between media, when the preference of users can be across media limits. We are defining this to satisfy common user needs. 

I don’t think we’re treating spoken English as a different language from written English.  Same language, different media.
[GH]Yes, we are dealing with language/modality/direction combinations.  RFC 5646 has a weakness in that it does not differ between spoken and written language in the tags, but we compensate for that by placing the tag together with the media that is suitable for the modality to be used. And it is essential that we deal with language in different modalities as separate. Some users are not able to type but can speak. 

If that’s not what “some users may be able to speak several languages but have a preference” means, then we need to revisit the use case document.



To get what you want you ask for two streams, one text one audio, both in English, and you get more than you need.  The preference is not among media streams, it’s language within a stream.

[GH]We need it to reflect user needs and that is preference among media streams. 
With your interpretation, we would assign relay services when we do not need any. That is waste of resources and causes delays and a bit less privacy. That should be avoided. 

I don’t think I am alone in thinking that preference was per media, and not between media.  This effort isn’t designed to extend SDP in ways beyond signaling human language preferences within a media stream.
[GH] I hoped that I had explained the need sufficiently to realize that there is a need to specify priority for language between media.
And since it is a soft indication, not tightly tied to negotiation of media usage, you do not need to be afraid if it seems to extend sdp to handle priorities between media. It is mainly about how to use the negotiated media for language contents.

3GPP TS 122.228 clause 7.5.2 says: "A UE should support negotiation of the user's desired language(s) (as defined in IANA [29]) and modalities for spoken, signed and written languages. The system should be able to negotiate the user's desired language(s) and modalities, per media stream and/or session, in order of preference."

ETSI TR 103 201 refers to SLIM in many places. e.g. clause 6.5.4 and 7.2.3.3.
http://www.etsi.org/deliver/etsi_tr/103200_103299/103201/01.01.01_60/tr_103201v010101p.pdf

These are clear indications that the need is here now, and has been for some years.

Did you like the proposal for how to code preference and grouping in RFC 5888 notation?

/Gunnar
  

Several of us (I’m looking at you Paul) have had conversations on how to signal a request for interpreters (transcoders).  I think we also might need a way to label a stream as a translated version of another stream, in the same or different media.  That’s label, not negotiate, although at some point if you can label it, it can be turned into an offer/answer negotiation.

But that is out of scope of this work group.



        

          

          

            
The other case is "a user who is able to speak but is deaf or hard-of-hearing and requires a voice stream plus 
a text stream (known as voice carry over)"

An example can be a user who prefers to receive spoken English, and needs to get it complemented with a written 
transcription in English. 
How would you code that?


          

          
Audio english, text English.
No preferences.


        

        
[GH] What do you mean that the evaluation rule would be?
Would it be: try to satisfy the highest possible preferred language in each direction in all media specifications together?  ( with preference only applied between languages in the same media and direction. )


      

      
I think that you negotiate language in each stream independently of any other stream.

I don’t think this effort is intended to provide a way to negotiate relationships between streams or media.  It’s just language on a stream.

If our charter intended us to extend SDP to negotiate relationships/grouping between streams, it would have been stated explicitly, and we would have had to discuss why that capability wasn’t a lot more general (not limited to human language issues).




      

        
That interpretation would satisfy the grouping need, but not the need for preference regardless of media. It is likely more common to have a need to indicate preference between languages in different media than a need to have two languages/modalities together. But we should satisfy both.



      

      

    

    

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

  


--------------3B824147649949828D0A16D9--


From nobody Mon May 23 15:00:16 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 CCE7812D5A3 for ; Mon, 23 May 2016 15:00:15 -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 hjXv3cLjekel for ; Mon, 23 May 2016 15:00:14 -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 5852812D5A4 for ; Mon, 23 May 2016 15:00:14 -0700 (PDT)
Received: from localhost ([72.167.218.134]) by p3plwbeout03-05.prod.phx3.secureserver.net with bizsmtp id xy0D1s0022uaRjc01y0Ddt; Mon, 23 May 2016 15:00:13 -0700
X-SID: xy0D1s0022uaRjc01
Received: (qmail 31767 invoked by uid 99); 23 May 2016 22:00:13 -0000
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"
X-Originating-IP: 208.51.143.189
User-Agent: Workspace Webmail 6.2.9
Message-Id: <20160523150011.665a7a7059d7ee80bb4d670165c8327d.b02a30483a.wbe@email03.godaddy.com>
From: "Doug Ewell" 
To: "=?UTF-8?Q?Gunnar=5FHellstr=C3=B6m?=" , "Brian Rosen" 
Date: Mon, 23 May 2016 15:00:11 -0700
Mime-Version: 1.0
Archived-At: 
Cc: slim@ietf.org, Randall Gellens 
Subject: Re: [Slim] Coding for the use cases in draft-ietf-slim-negotiating-human-language
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, 23 May 2016 22:00:16 -0000

Gunnar Hellstr=C3=B6m wrote:=0A=0A> RFC 5646 has a weakness in that it does=
 not differ between spoken and=0A> written language in the tags,=0A=0ANope.=
 It was a conscious decision in the development of RFC 5646 (and=0A4646 bef=
ore it) not to treat modality as an attribute of language. We=0Ahad a hard =
enough time getting people to accept script subtags.=0A=0A--=0ADoug Ewell |=
 http://ewellic.org | Thornton, CO =F0=9F=87=BA=F0=9F=87=B8=0A


From nobody Mon May 23 22:34:19 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 4025E12D62E for ; Mon, 23 May 2016 22:34: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 J2vwAAXWqFd4 for ; Mon, 23 May 2016 22:34:15 -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 0496912D625 for ; Mon, 23 May 2016 22:34:14 -0700 (PDT)
X-Halon-ID: 20346ba7-2171-11e6-81fe-0050569116f7
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.2] (unknown [77.53.228.40]) by bin-vsp-out-03.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Tue, 24 May 2016 07:34:03 +0200 (CEST)
To: Doug Ewell 
References: <20160523150011.665a7a7059d7ee80bb4d670165c8327d.b02a30483a.wbe@email03.godaddy.com>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: 
Date: Tue, 24 May 2016 07:34:00 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0
MIME-Version: 1.0
In-Reply-To: <20160523150011.665a7a7059d7ee80bb4d670165c8327d.b02a30483a.wbe@email03.godaddy.com>
Content-Type: multipart/alternative; boundary="------------56208F15D4A6A82511BA67BA"
Archived-At: 
Cc: slim@ietf.org
Subject: Re: [Slim] Coding for the use cases in draft-ietf-slim-negotiating-human-language
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, 24 May 2016 05:34:18 -0000

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

Den 2016-05-24 kl. 00:00, skrev Doug Ewell:
> Gunnar Hellström wrote:
>
>> RFC 5646 has a weakness in that it does not differ between spoken and
>> written language in the tags,
> Nope. It was a conscious decision in the development of RFC 5646 (and
> 4646 before it) not to treat modality as an attribute of language. We
> had a hard enough time getting people to accept script subtags.
Right. I could have expressed it in another way.
We could have had this effort to create modality-tags ( spoken, signed 
and written ) and direction-tags ( send and receive ) and ways to 
combine them with the existing language tags and media tags to form a 
way to express preferences and capabilities for human communication.

But we did not do that complementing high level work. We instead borrow 
the sdp structure to get a linkage between language and the modality. 
One reason is that the result need identified media streams, so by 
having the negotiation linked to media streams we do not have any 
problems knowing where to send or receive the language.

Sadly, this makes our work limited to traditional SIP, and only where 
all media is communicated in media streams carrying their original MIME 
type names audio, video and text. We should right now start working on 
next case, where this model does not fit. That is webrtc, where only 
audio and video have their right names, and text is embedded in a data 
channel. It is out of scope for the current work, but a task to do.

/Gunnar
>
> --
> Doug Ewell | http://ewellic.org | Thornton, CO 🇺🇸
>

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


--------------56208F15D4A6A82511BA67BA
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    Den 2016-05-24 kl. 00:00, skrev Doug Ewell:

    

      
Gunnar Hellström wrote:



      

        
RFC 5646 has a weakness in that it does not differ between spoken and
written language in the tags,


      

      
Nope. It was a conscious decision in the development of RFC 5646 (and
4646 before it) not to treat modality as an attribute of language. We
had a hard enough time getting people to accept script subtags.

    

    Right. I could have expressed it in another way. 

    We could have had this effort to create modality-tags ( spoken,
    signed and written ) and direction-tags ( send and receive ) and
    ways to combine them with the existing language tags and media tags
    to form a way to express preferences and capabilities for human
    communication. 

    

    But we did not do that complementing high level work. We instead
    borrow the sdp structure to get a linkage between language and the
    modality. One reason is that the result need identified media
    streams, so by having the negotiation linked to media streams we do
    not have any problems knowing where to send or receive the language.
    

    

    Sadly, this makes our work limited to traditional SIP, and only
    where all media is communicated in media streams carrying their
    original MIME type names audio, video and text. We should right now
    start working on next case, where this model does not fit. That is
    webrtc, where only audio and video have their right names, and text
    is embedded in a data channel. It is out of scope for the current
    work, but a task to do.

    

    /Gunnar

    

      

--
Doug Ewell | http://ewellic.org | Thornton, CO 🇺🇸



    

    

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

  


--------------56208F15D4A6A82511BA67BA--