From nobody Wed May 3 16:14:42 2017 Return-Path: X-Original-To: slim@ietf.org Delivered-To: slim@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 293FB12783A; Wed, 3 May 2017 16:14:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: slim@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149385328211.4765.6727276237856291257@ietfa.amsl.com> Date: Wed, 03 May 2017 16:14:42 -0700 Archived-At: Subject: [Slim] I-D Action: draft-ietf-slim-multilangcontent-07.txt X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 23:14:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Selection of Language for Internet Media of the IETF. Title : Multiple Language Content Type Authors : Nik Tomkinson Nathaniel Borenstein Filename : draft-ietf-slim-multilangcontent-07.txt Pages : 19 Date : 2017-05-03 Abstract: This document defines an addition to the Multipurpose Internet Mail Extensions (MIME) standard to make it possible to send one message that contains multiple language versions of the same information. The translations would be identified by a language tag and selected by the email client based on a user's language settings. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-slim-multilangcontent/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-slim-multilangcontent-07 https://datatracker.ietf.org/doc/html/draft-ietf-slim-multilangcontent-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-slim-multilangcontent-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu May 4 02:02:12 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3314129C00 for ; Thu, 4 May 2017 02:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fpRpHKR4HD_C for ; Thu, 4 May 2017 02:02:09 -0700 (PDT) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7318129C06 for ; Thu, 4 May 2017 02:02:02 -0700 (PDT) Received: by mail-lf0-x22c.google.com with SMTP id j1so4122148lfh.2 for ; Thu, 04 May 2017 02:02:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=uMMriiwe8xOIuBE6f5gJ/61atSswb6xRjJhsMIwtmAU=; b=X2k8oVm1ayado3gpCVeK/91X6EEqA+Rmvj4k+csV708EvmY34gO29OLBN0g2V5F3Es n2DHUIzKBE0pJzM/n3IkCkZLbD2HJInfupYW9loBEVB2HJYwjQ3varX0HR65RUJjWE7+ latXJ3fm5/A7ezR2P0efsnTJm217ziYMn9IofHmnae1P+H0gNZOcTjYBwxX0E4K4lMEJ 7t62RO9+G3SY+M3KE1BpCkdBs2iii9Q9dOo+FuFTE+MbYOBhCCjzWyfb/husXaUG/jCe xaeReV2tobhBbZhQFjTk9LzFh8is0TOO9GF5pEa58tsi5OX2J/WRELhze55Fne6IueGy gAJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=uMMriiwe8xOIuBE6f5gJ/61atSswb6xRjJhsMIwtmAU=; b=QknyzA8WBvFlW0lc5P+XB0ibTlRiMO90ELb+qkn+uZIPOMnBIhPMVIqdEp+H9aIxPK 8B8AgxbU6I+h0pt5JAYEUc9pVudxVFxIcTuvTm0rD5AQ4fxg3RzQGFWShoCVvzkQFjT0 etDqBSK9IDZ4PJxGlVqei3g0tIuNq7SZqm4TZvIXrMFrd9DSEU2+MMpyMbFpS5U5kgSZ B+eOYhRDjPsFZvx83MAjLff2Mfzue79rBqV+qsqCw2YoK3+DSCDNf6tQG60H4fRlNUQp BqCSXMzpFXSLdolUkqDtjaWFBP+O0OHFho+ls2I+BOR9+h+lYo5XZ4ULW8j4GoaUyYJt e6vA== X-Gm-Message-State: AN3rC/6phgx4ro3EBAeABtTOMip98nW64Lov91Hg2fKkXwHjJwq0ZP6r f3ZYFA4PRr0jPp8tjrKfcGMSJ59Z9mT3 X-Received: by 10.46.1.197 with SMTP id f66mr15779920lji.83.1493888520860; Thu, 04 May 2017 02:02:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.145.11 with HTTP; Thu, 4 May 2017 02:02:00 -0700 (PDT) In-Reply-To: <149385328211.4765.6727276237856291257@ietfa.amsl.com> References: <149385328211.4765.6727276237856291257@ietfa.amsl.com> From: Nik Tomkinson Date: Thu, 4 May 2017 10:02:00 +0100 Message-ID: To: slim@ietf.org Content-Type: multipart/alternative; boundary=001a1142c8dc9eb84d054eaf0619 Archived-At: Subject: Re: [Slim] I-D Action: draft-ietf-slim-multilangcontent-07.txt X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 09:02:11 -0000 --001a1142c8dc9eb84d054eaf0619 Content-Type: text/plain; charset=UTF-8 Hi All, this latest version just contains an update to the Encoding Considerations in the IANA Registration Template to incorporate Gunnar's suggestion on the media types list which Alexey and Sean also agreed with. Hopefully this should be the final change. Nik. On 4 May 2017 at 00:14, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Selection of Language for Internet Media > of the IETF. > > Title : Multiple Language Content Type > Authors : Nik Tomkinson > Nathaniel Borenstein > Filename : draft-ietf-slim-multilangcontent-07.txt > Pages : 19 > Date : 2017-05-03 > > Abstract: > This document defines an addition to the Multipurpose Internet Mail > Extensions (MIME) standard to make it possible to send one message > that contains multiple language versions of the same information. > The translations would be identified by a language tag and selected > by the email client based on a user's language settings. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-slim-multilangcontent/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-slim-multilangcontent-07 > https://datatracker.ietf.org/doc/html/draft-ietf-slim-multilangcontent-07 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-slim-multilangcontent-07 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim > -- ----------------------------------------------------------------- Multiple Language Content Type Internet Draft: https://datatracker.ietf.org/doc/draft-ietf-slim-multilangcontent/ ----------------------------------------------------------------- --001a1142c8dc9eb84d054eaf0619 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi All,=C2=A0

this latest version just = contains an update to the Encoding Considerations in the IANA Registration = Template to incorporate Gunnar's suggestion on the media types list whi= ch Alexey and Sean also agreed with.

Hopefully thi= s should be the final change.

Nik.

On 4 May 2017 at 00:1= 4, <internet-drafts@ietf.org> wrote:

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

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Multiple Language Content Type
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Nik = Tomkinson
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Nathaniel Borenstein
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-slim-multilangcontent-07.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 19
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-05-03

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

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

There are also htmlized versions available at:
https://tools.ietf.org/html/draf= t-ietf-slim-multilangcontent-07
https://datatracker.ietf.or= g/doc/html/draft-ietf-slim-multilangcontent-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?= url2=3Ddraft-ietf-slim-multilangcontent-07


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

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

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



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

<= /div>
--001a1142c8dc9eb84d054eaf0619-- From nobody Thu May 4 02:21:47 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F519129C26 for ; Thu, 4 May 2017 02:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gsmasso.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XPYo4dn0d5qX for ; Thu, 4 May 2017 02:21:43 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0076.outbound.protection.outlook.com [104.47.2.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8D8D129C35 for ; Thu, 4 May 2017 02:21:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=GSMASSO.onmicrosoft.com; s=selector1-gsma-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=nFj5ZRFrhNGd2nClg+p6AaXg/ruu/TgWsdZGM9b85Ho=; b=PAWTM2N5IN3pV1YuqXL+4X/PI81R0fELpwsj2luDiXdeUshy9uDr2ah06ChSOzGYFsBFcPq+i7XKbhdWg152OJgtFBqh7NX2riYW/ALQkxG6f1iZ0Ze/e5egTi6P42em5mBMmCYXRNLTPVSSfIs/z118wCDP20OAGMGqd27W37A= Received: from AM2PR04MB0802.eurprd04.prod.outlook.com (10.160.56.28) by AM2PR04MB0804.eurprd04.prod.outlook.com (10.160.57.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1075.11; Thu, 4 May 2017 09:21:28 +0000 Received: from AM2PR04MB0802.eurprd04.prod.outlook.com ([fe80::c094:3686:6937:5c6a]) by AM2PR04MB0802.eurprd04.prod.outlook.com ([fe80::c094:3686:6937:5c6a%15]) with mapi id 15.01.1075.010; Thu, 4 May 2017 09:21:27 +0000 From: Natasha Rooney To: Nik Tomkinson CC: "slim@ietf.org" Thread-Topic: [Slim] I-D Action: draft-ietf-slim-multilangcontent-07.txt Thread-Index: AQHSxGMPnsVR2knw4E28eApnMqerXqHj4WcAgAAFb4A= Date: Thu, 4 May 2017 09:21:27 +0000 Message-ID: <77919F9E-5F57-42E1-9052-FF71138D2E94@gsma.com> References: <149385328211.4765.6727276237856291257@ietfa.amsl.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=gsma.com; x-originating-ip: [62.189.0.100] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM2PR04MB0804; 7:/vy+2WmBmNcbPx1iCoeDzE6C8EuerwNmU5sMfjztBcoKexXUYebAU8klvr+tsAeI1SQL+Ejqq9N4sqswzy7z+lEpZt9eQy2NaBH4PeIRUvX+Vk58czSK+OtYhQnEwbXUoAU/KiEmnpLSAFaBVt59QBMtHDJOyJQlLaBNV6K6e+1sM0leNFgLPZIL5JJ1s1h0Sr1fJ3Zh4hG/Ir4mBL4iaPwcE5mqkGwSG1e1nswEzr8GGMMPUZRc1JIRaMkAvyMe/ddSeuID3elNDsaj8MlXOpnlbotxz0iGwDfDVpA0bT5cJxkbESxto/izHXOP0n/Lr7XmslPaLa5VloY+3B8ETw== x-ms-office365-filtering-correlation-id: f099cd58-be7a-4af8-8779-08d492cef189 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:AM2PR04MB0804; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(6041248)(20161123564025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123562025)(20161123555025)(6072148); SRVR:AM2PR04MB0804; BCL:0; PCL:0; RULEID:; SRVR:AM2PR04MB0804; x-forefront-prvs: 02973C87BC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39410400002)(39400400002)(39850400002)(39840400002)(39450400003)(24454002)(53754006)(377424004)(86362001)(6512007)(7736002)(57306001)(2906002)(6916009)(2950100002)(7906003)(4326008)(5250100002)(5890100001)(3280700002)(110136004)(38730400002)(6246003)(53936002)(236005)(3846002)(6116002)(66066001)(102836003)(3660700001)(36756003)(2900100001)(39060400002)(229853002)(53546009)(83716003)(189998001)(230783001)(106356001)(6436002)(6506006)(33656002)(5660300001)(50226002)(82746002)(50986999)(25786009)(8676002)(8936002)(478600001)(606005)(6306002)(54896002)(6486002)(99286003)(81166006)(76176999); DIR:OUT; SFP:1101; SCL:1; SRVR:AM2PR04MB0804; H:AM2PR04MB0802.eurprd04.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_77919F9E5F5742E19052FF71138D2E94gsmacom_" MIME-Version: 1.0 X-OriginatorOrg: gsma.com X-MS-Exchange-CrossTenant-originalarrivaltime: 04 May 2017 09:21:27.6891 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72a4ff82-fec3-469d-aafb-ac8276216699 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR04MB0804 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: AM2PR04MB0802.eurprd04.prod.outlook.com X-MS-Exchange-CrossPremises-TransportTrafficType: Email X-MS-Exchange-CrossPremises-TransportTrafficSubType: X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-originalclientipaddress: 62.189.0.100 X-MS-Exchange-CrossPremises-transporttraffictype: Email X-MS-Exchange-CrossPremises-transporttrafficsubtype: X-MS-Exchange-CrossPremises-disclaimer-hash: 78ca8040c6722e32c2f5b0a45bf37e74b9409d645a53be96aa19958e0cee0f00 X-MS-Exchange-CrossPremises-antispam-scancontext: DIR:Originating; SFV:NSPM; SKIP:0; X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-OrganizationHeadersPreserved: AM2PR04MB0804.eurprd04.prod.outlook.com Archived-At: Subject: Re: [Slim] I-D Action: draft-ietf-slim-multilangcontent-07.txt X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 09:21:45 -0000 --_000_77919F9E5F5742E19052FF71138D2E94gsmacom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Nik! Team - please take a look at the doc and send any issues you identify to th= e list! Natasha Rooney | Internet Engineering Director | Internet and Web Team | Te= chnology | GSMA | nrooney@gsma.com | +44 (0) 7730 = 219 765 | @thisNatasha | Skype: nrooney@gsm.org On 4 May 2017, at 10:02, Nik Tomkinson > wrote: Hi All, this latest version just contains an update to the Encoding Considerations = in the IANA Registration Template to incorporate Gunnar's suggestion on the= media types list which Alexey and Sean also agreed with. Hopefully this should be the final change. Nik. On 4 May 2017 at 00:14, > wrote: A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Selection of Language for Internet Media o= f the IETF. Title : Multiple Language Content Type Authors : Nik Tomkinson Nathaniel Borenstein Filename : draft-ietf-slim-multilangcontent-07.txt Pages : 19 Date : 2017-05-03 Abstract: This document defines an addition to the Multipurpose Internet Mail Extensions (MIME) standard to make it possible to send one message that contains multiple language versions of the same information. The translations would be identified by a language tag and selected by the email client based on a user's language settings. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-slim-multilangcontent/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-slim-multilangcontent-07 https://datatracker.ietf.org/doc/html/draft-ietf-slim-multilangcontent-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-slim-multilangcontent-07 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ SLIM mailing list SLIM@ietf.org https://www.ietf.org/mailman/listinfo/slim -- ----------------------------------------------------------------- Multiple Language Content Type Internet Draft: https://datatracker.ietf.org/doc/draft-ietf-slim-multilangcontent/ ----------------------------------------------------------------- _______________________________________________ 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_77919F9E5F5742E19052FF71138D2E94gsmacom_ Content-Type: text/html; charset="us-ascii" Content-ID: <7E87DDD769037041BF86470797D3F708@eurprd04.prod.outlook.com> Content-Transfer-Encoding: quoted-printable Thanks Nik! 

Team - please take a look at the doc and send any issues yo= u identify to the list!

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

On 4 May 2017, at 10:02, Nik Tomkinson <rfc.nik.tomkinson@gmail.com&g= t; wrote:

Hi All, 

this latest version just contains an update to the Encoding= Considerations in the IANA Registration Template to incorporate Gunnar's s= uggestion on the media types list which Alexey and Sean also agreed with.

Hopefully this should be the final change.

Nik.

On 4 May 2017 at 00:14, <internet-drafts@ietf.org> wrote:

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

        Title           := Multiple Language Content Type
        Authors         : Nik = Tomkinson
                     = ;     Nathaniel Borenstein
        Filename        : draft-iet= f-slim-multilangcontent-07.txt
        Pages           := 19
        Date            := 2017-05-03

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


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

There are also htmlized versions available at:
https://tools.ietf.org/htm= l/draft-ietf-slim-multilangcontent-07 https://datatrac= ker.ietf.org/doc/html/draft-ietf-slim-multi= langcontent-07

A diff from the previous version is available at:
https://www.ietf.o= rg/rfcdiff?url2=3Ddraft-ietf-slim-multilang= content-07


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

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

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



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

_______________________________________________
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_77919F9E5F5742E19052FF71138D2E94gsmacom_-- From nobody Sun May 28 15:03:34 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B66C412941C for ; Sun, 28 May 2017 15:03:32 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fBBYSRLPA5gt for ; Sun, 28 May 2017 15:03:31 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 9B71C12949B for ; Sun, 28 May 2017 15:03:31 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Sun, 28 May 2017 15:05:45 -0700 Mime-Version: 1.0 Message-Id: X-Mailer: Eudora for Mac OS X Date: Sun, 28 May 2017 14:57:09 -0700 To: slim@ietf.org From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Archived-At: Subject: [Slim] Collapse attribute syntax to one line in draft-ietf-slim-negotiating-human-language X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 May 2017 22:03:32 -0000 In response to Adam Roach's comments as well as other comments, I intend to update the draft to collapse the attribute syntax to one line; each attribute can occur at most once per media, with all languages on the same line. This will further reduce the size of the SDP block. If you object to this, please reply. Here is the section of Adam's review: At 8:31 PM +0000 3/28/17, Sabrina Tanamal via RT wrote: > I'll note that much of this can be fixed if the syntax is collapsed so > that each media section can have at most one hlang-send and one > hlang-receive, each of which contain a list of one or more languages > that can be sent or received. This is also much more consistent with the > way SDP attributes are used in general. The presence of a "*" token on > that line would indicate the "call should happen even without matching > languages" characteristic; since there is only one place to add this > indicator, the ambiguity of some lines indicating it and others not > disappears. The preceding example would collapse to: > > m=audio 49250 RTP/AVP 20 > a=hlang-send:es eu en * > a=hlang-recv:es eu en * > > ...and the example text would be revised to remove the implication that > *sending* "es" necessarily implies *receiving* "es". > > I'll further note that the majority of SDP libraries I've worked with > would make accessing the all-on-one-line format easier than > one-line-per-language as well. Here is the proposed ABNF: Attribute Syntax: hlang-value = Language-Tag *( SP Language-tag ) [ SP asterisk ] ; Language-Tag as defined in BCP 47 asterisk = "*" ; an asterisk (ASCII %2A) character sp = 1*" " ; one or more ASCII space (%20) characters -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- If forced to travel on an airplane, try and get in the cabin with the Captain, so you can keep an eye on him and nudge him if he falls asleep or point out any mountains looming up ahead ... --Mike Harding, The Armchair Anarchist's Almanac. From nobody Sun May 28 15:04:23 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 528C412949E for ; Sun, 28 May 2017 15:04:22 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i7UrHai-B-SU for ; Sun, 28 May 2017 15:04:21 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 8BC1612949B for ; Sun, 28 May 2017 15:04:21 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Sun, 28 May 2017 15:06:34 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Mailer: Eudora for Mac OS X Date: Sun, 28 May 2017 15:04:14 -0700 To: Bernard Aboba From: Randall Gellens Cc: slim@ietf.org, Gunnar =?iso-8859-1?Q?Hellstr=F6m?= , Natasha Rooney , Adam Roach Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Archived-At: Subject: Re: [Slim] [IANA #949701] expert review for draft-ietf-slim-negotiating-human-language (sdp-parameters) X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 May 2017 22:04:22 -0000 At 2:55 PM -0700 4/24/17, Bernard Aboba wrote: > Randall Gellens said: > > "The WG explicitly decided to take routing out of scope to advance > the simple proposal in the draft." > > [BA] While it is correct that the WG decided to leave routing out > of scope for this document, the text does say anything about this, > so that even an expert reader could be confused. Could we add some > clarifying text? I'll add the following paragraph to the Introduction: To reduce the complexity of the solution, this draft focuses on negotiating language per media; routing is out of scope. > > Adam Roach said: > > "I'll note that much of this can be fixed if the syntax is collapsed" > > [BA] I didn't see a reply to Adam's suggestion, which aside from > the syntax issues would address concerns about SDP size. I'm happy to make this change, although since it is technical rather than editorial and the document went through IETF last call, I think we need to make sure no one in the WG objects to the change. I sent a separate email with the proposed updated ABNF for the syntax (there will of course be edits to the examples as well). -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- I can't even program a VCR, and I'm on-line!!! --AOL user (in AOL ad) From nobody Sun May 28 15:06:27 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAF9D12949F for ; Sun, 28 May 2017 15: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: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h0nd8jiopliC for ; Sun, 28 May 2017 15:06:25 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 51E5712949E for ; Sun, 28 May 2017 15: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); Sun, 28 May 2017 15:08:38 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Mailer: Eudora for Mac OS X Date: Sun, 28 May 2017 15:06:17 -0700 To: Bernard Aboba , Gunnar =?iso-8859-1?Q?Hellstr=F6m?= From: Randall Gellens Cc: slim@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Slim] Ticket 29 X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 May 2017 22:06:27 -0000 At 2:59 PM -0700 4/24/17, Bernard Aboba wrote: > Right. > > Randall - can we fix the spelling so that we can close Ticket 29? =46ixed in -09. > > On Wed, Mar 29, 2017 at 12:18 PM, Gunnar=20 > Hellstr=F6m=20 > <gunnar.hellstrom@omnitor.se>=20 > wrote: > > > > Den 2017-03-29 kl. 01:37, skrev Randall Gellens: > > The revised draft (-08, published 2/26) added=20 > "MUX Category: NORMAL" to the IANA=20 > registrations. This was per IANA review and my=20 > own review of=20 > draft-ietf-mmusic-sdp-mux-attributes. > > Right. > but the spelling should be: > Mux Category: NORMAL > > > > The draft did not change ""Usage Level: media". > > Right. > There is a draft for transport of real-time=20 > text in a WebRTC data channel, so the addition=20 > of likely ",dsca(t140)" will be needed=20 > eventually, but I think we need to wait with=20 > that addition until the draft is approved and=20 > the subprotocol name surely assigned. > > /Gunnar > > > > --Randy > > At 8:01 PM +0000 3/28/17, Natasha Rooney wrote: > > Hi all, > > Bernard and I are going through open issues on=20 > the drafts today at IETF98. With regards to=20 > ticket 29, we would like to know if there is=20 > working group support for the following change?=20 > Please look at the ticket if you require more=20 > info: > >=20 > <https://trac.ietf.org/trac/sli= m/ticket/29>https://trac.ietf.org= /trac/slim/ticket/29 > > ******** Suggested Change ********* > Section 6 has the form for attribute=20 > registration by IANA. There are a couple of=20 > fields missing that will be important for use=20 > of the specification in the WebRTC environment.=20 > Include these fields if that is allowable=20 > according to current IANA procedures and if=20 > that does not delay the publication of this=20 > draft. These fields are needed for use of text=20 > media in WebRTC. > > Change suggested: > > "Usage Level: media" > to: > "Usage Level: media, dcsa(subprotocol)" > > Insert in two locations in the registration forms: > "Mux Category: NORMAL" > > 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 error=20 > you must take no action based on them, nor must=20 > you copy or show them to anyone; please reply=20 > to this email or call=20 > +44 207 356 0600=20 > and highlight the error. > > > _______________________________________________ > SLIM mailing list > SLIM@ietf.org >=20 > https://www.ietf.org/mailman/l= istinfo/slim > > > > > -- > ----------------------------------------- > Gunnar Hellstr=F6m > Omnitor > gunnar.hellstrom@omnitor.se > +46 708 204 288 > > > _______________________________________________ > SLIM mailing list > SLIM@ietf.org >=20 > https://www.ietf.org/mailman/l= istinfo/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: --------------- The last good thing written in C was Franz Schubert's Ninth Symphony. From nobody Sun May 28 15:09:19 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E40E512949A for ; Sun, 28 May 2017 15:09:18 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AUa3ZK_5cDsY for ; Sun, 28 May 2017 15:09:17 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 91A4F12941C for ; Sun, 28 May 2017 15:09:17 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Sun, 28 May 2017 15:11:32 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <7b110177-5bc9-ac41-5819-ec5354a4dced@omnitor.se> X-Mailer: Eudora for Mac OS X Date: Sun, 28 May 2017 15:09:10 -0700 To: Bernard Aboba From: Randall Gellens Cc: slim@ietf.org, Alexey Melnikov , Natasha Rooney , Adam Roach , Gunnar =?iso-8859-1?Q?Hellstr=F6m?= Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Archived-At: Subject: Re: [Slim] [IANA #949701] expert review for draft-ietf-slim-negotiating-human-language (sdp-parameters) and issue 37 X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 May 2017 22:09:19 -0000 At 3:13 PM -0700 4/24/17, Bernard Aboba wrote: > Gunnar said: > > "I notice that the comments and solution proposal on the syntax > concerns from the IANA review has a lot in common with Issue 34. > > https://trac.ietf.org/trac/slim/ticket/34 > > Both propose a one-line format for all languages in one media > and direction, and both are puzzled by the diffuse placement rules > for the asterisk parameter. > A solution could be searched on these together." > > [BA] Yes, there does appear to be commonality in these 3 > independent reviews - which is what lead to the suggestion that the > draft go back to the WG. I don't think the draft needs to re-run WG LC or IETF LC; I think can consider the edit to be a LC comment revision and therefore explicitly asking the group if anyone objects to the change is sufficient. > Randall -- is there some obvious reason why a syntax collapse > cannot be considered? I've done the edits in my version of -09 and sent an explicit message to the group asking if anyone objects. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Honk if you hate bumper stickers that say "Honk if ..." From nobody Sun May 28 15:15:19 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7657C12949A for ; Sun, 28 May 2017 15:15:18 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QTDQ-gUEVr-e for ; Sun, 28 May 2017 15:15:16 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id C016412941C for ; Sun, 28 May 2017 15:15:16 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Sun, 28 May 2017 15:17:31 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Mailer: Eudora for Mac OS X Date: Sun, 28 May 2017 15:15:11 -0700 To: Bernard Aboba , slim@ietf.org From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Archived-At: Subject: Re: [Slim] Open Issues on draft-ietf-slim-negotiating-human-language X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 May 2017 22:15:18 -0000 I think the edits so far address #19, #27, 28 so they can be closed. #38, #39 are addressed in -09 so I will post that and those can be closed. I think #26, #29, #32, #34, #35 were not accepted. --Randy At 11:25 AM -0700 4/25/17, Bernard Aboba wrote: > Currently 10 Issues remain open from IETF Last Call: > > https://trac.ietf.org/trac/slim/report/1 > > > These include: > > TicketSummaryComponentVersionMilestoneTypeOwnerStatusCreated#27The > cases in the "Silly states" section 5.4 are not all > silly.negotiating-human-language2.0milestone1defectgunnar.hellstrom@omnitor.senewMar > 22, > 2017#19Use > Media Type registration > templatemultilangcontentenhancementrfc.nik.tomkinson@gmail.comassignedAug > 17, > 2016#28Examples > section 5.5 requires > expansionnegotiating-human-language2.0milestone1defectrg+ietf@randy.pensive.orgassignedMar > 22, > 2017#32Audio/Video > Coordinationnegotiating-human-language2.0milestone1defectrg+ietf@randy.pensive.orgnewMar > 22, > 2017#34Use > the Accept-Language > syntaxnegotiating-human-language2.0milestone1defectrg+ietf@randy.pensive.orgassignedMar > 22, > 2017#35Have > an attribute to abbreviate the bidirectionally-symmetric > casenegotiating-human-language2.0milestone1defectrg+ietf@randy.pensive.orgassignedMar > 22, > 2017#38Routing > out of > scopenegotiating-human-language1.0milestone1defectdraft-ietf-slim-negotiating-human-language@ietf.orgnewApr > 25, > 2017#39Syntax > Collapsenegotiating-human-language1.0milestone1defectdraft-ietf-slim-negotiating-human-language@ietf.orgnewApr > 25, > 2017#26Make > use of the asterisk modifier on media level with session scope also > for media level > purposesnegotiating-human-language2.0milestone1enhancementgunnar.hellstrom@omnitor.senewMar > 22, > 2017#29Include > more fields for attribute registration from 4566bis > > _______________________________________________ > 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: --------------- ... Any resemblance between the above views and those of my employer, my terminal, or the view out my window are purely coincidental. Any resemblance between the above and my own views is non-deterministic. The question of the existence of views in the absence of anyone to hold them is left as an exercise for the reader. The question of the existence of the reader is left as an exercise for the second god coefficient. (A discussion of non-orthogonal, non-integral polytheism is beyond the scope of this article.) From nobody Mon May 29 05:55:05 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A00512778D for ; Mon, 29 May 2017 05:55:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zZ6lBnCUSTge for ; Mon, 29 May 2017 05:55:02 -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 A236612956D for ; Mon, 29 May 2017 05:55:01 -0700 (PDT) X-Halon-ID: 03c63845-446e-11e7-bca7-0050569116f7 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [77.53.231.21]) by bin-vsp-out-03.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Mon, 29 May 2017 14:54:55 +0200 (CEST) To: slim@ietf.org References: From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: Date: Mon, 29 May 2017 14:54:53 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Slim] Collapse attribute syntax to one line in draft-ietf-slim-negotiating-human-language X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 12:55:04 -0000 Den 2017-05-28 kl. 23:57, skrev Randall Gellens: > In response to Adam Roach's comments as well as other comments, I > intend to update the draft to collapse the attribute syntax to one > line; each attribute can occur at most once per media, with all > languages on the same line. This will further reduce the size of the > SDP block. > > If you object to this, please reply. I am glad to see a one-line syntax, but I would as well as Dale Worley expressed in issue #34, prefer to use the full Accept-Language syntax including the q-values. Thus a syntax according to this example: m=audio 49250 RTP/AVP 20 a=hlang-send: es; q=0.5, eu; q=0.3, en;q=0.1, * a=hlang-recv:es; q=0.5, eu; q=0.3, en;q=0.1, * This format provides the following benefits 1. Satisfies both Dales and Adam's and other's review proposals 2. Is a good base for the extensions I am asked to propose, to enable preference between languages in different media, and preference for simultaneous languages in different media in the same direction. These two extensions are essential for making the draft useful in real cases. We can introduce cross-media validity of the q-values, and a rule for how preference for simultaneous media should be expressed. With other syntax proposals, such extensions will be much less clean. 3. Solves a problem for persons who want to express equal preference for a set of languages, e.g. a proffessional call center. Other syntaxes require a preference grading even when the user does not want to express any preference. 4. Makes it possible to satisfy Bernard's request for a way to specify subtitling, issue #34. (also included in 2 above) 5. May possibly open for a motivation to keep the asterisk as a media and directional parameter. But I have problems to define how we can motivate the placement of the asterisk. Can it be: "An asterisk included in an attribute value means that the call should not be denied because of lack of language matching in that media and direction. An asterisk included in each attribute value in the sdp means that the call should not be denied because of no language matching at all. The lack of an asterisk in an attribute value means a desire to get the call denied if no language match is found for the corresponding media and direction." I do not think that this differentiation betwen reasons to deny the call is useful, but the description motivates the placement of the asterisk on media and direction level, and gives us a possiblity to keep the asterisk parameter. I have not seen us reject issue #34, so I see the above as the appropriate solution on issues #34 and #39. Regards Gunnar > > Here is the section of Adam's review: > > At 8:31 PM +0000 3/28/17, Sabrina Tanamal via RT wrote: >> I'll note that much of this can be fixed if the syntax is collapsed so >> that each media section can have at most one hlang-send and one >> hlang-receive, each of which contain a list of one or more languages >> that can be sent or received. This is also much more consistent with >> the >> way SDP attributes are used in general. The presence of a "*" token on >> that line would indicate the "call should happen even without matching >> languages" characteristic; since there is only one place to add this >> indicator, the ambiguity of some lines indicating it and others not >> disappears. The preceding example would collapse to: >> >> m=audio 49250 RTP/AVP 20 >> a=hlang-send:es eu en * >> a=hlang-recv:es eu en * >> >> ...and the example text would be revised to remove the implication that >> *sending* "es" necessarily implies *receiving* "es". >> >> I'll further note that the majority of SDP libraries I've worked with >> would make accessing the all-on-one-line format easier than >> one-line-per-language as well. > > Here is the proposed ABNF: > > Attribute Syntax: > > hlang-value = Language-Tag *( SP Language-tag ) [ SP asterisk ] > > ; Language-Tag as defined in BCP 47 > > asterisk = "*" ; an asterisk (ASCII %2A) character > > sp = 1*" " ; one or more ASCII space (%20) characters > -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 From nobody Mon May 29 11:15:14 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87FC8129405 for ; Mon, 29 May 2017 11:15:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ooAxgYLnlqX3 for ; Mon, 29 May 2017 11:15:10 -0700 (PDT) Received: from bin-vsp-out-02.atm.binero.net (vsp-unauthed02.binero.net [195.74.38.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06D56128B88 for ; Mon, 29 May 2017 11:15:09 -0700 (PDT) X-Halon-ID: bc6c1e8f-449a-11e7-bcc3-005056917f90 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [77.53.231.21]) by bin-vsp-out-02.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Mon, 29 May 2017 20:15:02 +0200 (CEST) To: slim@ietf.org References: From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <8f8fb511-420b-9cdd-5de0-a0d7be27766a@omnitor.se> Date: Mon, 29 May 2017 20:14:59 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Slim] Collapse attribute syntax to one line in draft-ietf-slim-negotiating-human-language X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 18:15:12 -0000 It should be noted that the syntax according to the Accept-Language does not need to include the q-values until the user want to be specific about the relative preferences. So, as long as the preferences are not of specific interest, the example would be: m=audio 49250 RTP/AVP 20 a=hlang-send: es, eu, en, * a=hlang-recv:es, eu, en, * Which is very similar to the syntax just proposed by Randall. /Gunnar Den 2017-05-29 kl. 14:54, skrev Gunnar Hellström: > Den 2017-05-28 kl. 23:57, skrev Randall Gellens: >> In response to Adam Roach's comments as well as other comments, I >> intend to update the draft to collapse the attribute syntax to one >> line; each attribute can occur at most once per media, with all >> languages on the same line. This will further reduce the size of the >> SDP block. >> >> If you object to this, please reply. > I am glad to see a one-line syntax, but I would as well as Dale Worley > expressed in issue #34, prefer to use the full Accept-Language syntax > including the q-values. > > Thus a syntax according to this example: > > m=audio 49250 RTP/AVP 20 > a=hlang-send: es; q=0.5, eu; q=0.3, en;q=0.1, * > a=hlang-recv:es; q=0.5, eu; q=0.3, en;q=0.1, * > > This format provides the following benefits > > 1. Satisfies both Dales and Adam's and other's review proposals > > 2. Is a good base for the extensions I am asked to propose, to enable > preference between languages in different media, and preference for > simultaneous languages in different media in the same direction. These > two extensions are essential for making the draft useful in real cases. > We can introduce cross-media validity of the q-values, and a rule for > how preference for simultaneous media should be expressed. With other > syntax proposals, such extensions will be much less clean. > > 3. Solves a problem for persons who want to express equal preference > for a set of languages, e.g. a proffessional call center. Other > syntaxes require a preference grading even when the user does not want > to express any preference. > > 4. Makes it possible to satisfy Bernard's request for a way to specify > subtitling, issue #34. (also included in 2 above) > > 5. May possibly open for a motivation to keep the asterisk as a media > and directional parameter. > But I have problems to define how we can motivate the placement of the > asterisk. > Can it be: > "An asterisk included in an attribute value means that the call should > not be denied because of lack of language matching in that media and > direction. An asterisk included in each attribute value in the sdp > means that the call should not be denied because of no language > matching at all. > The lack of an asterisk in an attribute value means a desire to get > the call denied if no language match is found for the corresponding > media and direction." > I do not think that this differentiation betwen reasons to deny the > call is useful, but the description motivates the placement of the > asterisk on media and direction level, and gives us a possiblity to > keep the asterisk parameter. > > I have not seen us reject issue #34, so I see the above as the > appropriate solution on issues #34 and #39. > > Regards > > Gunnar > > >> >> Here is the section of Adam's review: >> >> At 8:31 PM +0000 3/28/17, Sabrina Tanamal via RT wrote: >>> I'll note that much of this can be fixed if the syntax is collapsed so >>> that each media section can have at most one hlang-send and one >>> hlang-receive, each of which contain a list of one or more languages >>> that can be sent or received. This is also much more consistent >>> with the >>> way SDP attributes are used in general. The presence of a "*" token on >>> that line would indicate the "call should happen even without matching >>> languages" characteristic; since there is only one place to add this >>> indicator, the ambiguity of some lines indicating it and others not >>> disappears. The preceding example would collapse to: >>> >>> m=audio 49250 RTP/AVP 20 >>> a=hlang-send:es eu en * >>> a=hlang-recv:es eu en * >>> >>> ...and the example text would be revised to remove the implication >>> that >>> *sending* "es" necessarily implies *receiving* "es". >>> >>> I'll further note that the majority of SDP libraries I've worked with >>> would make accessing the all-on-one-line format easier than >>> one-line-per-language as well. >> >> Here is the proposed ABNF: >> >> Attribute Syntax: >> >> hlang-value = Language-Tag *( SP Language-tag ) [ SP asterisk ] >> >> ; Language-Tag as defined in BCP 47 >> >> asterisk = "*" ; an asterisk (ASCII %2A) character >> >> sp = 1*" " ; one or more ASCII space (%20) characters >> > -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 From nobody Mon May 29 11:49:35 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C9B4129649 for ; Mon, 29 May 2017 11:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BH2y8jsiYW0g for ; Mon, 29 May 2017 11:49:31 -0700 (PDT) Received: from bin-vsp-out-03.atm.binero.net (bin-mail-out-05.binero.net [195.74.38.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8466127873 for ; Mon, 29 May 2017 11:49:30 -0700 (PDT) X-Halon-ID: 88f0ea03-449f-11e7-bca7-0050569116f7 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [77.53.231.21]) by bin-vsp-out-03.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Mon, 29 May 2017 20:49:24 +0200 (CEST) To: Randall Gellens , Bernard Aboba , slim@ietf.org References: From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: Date: Mon, 29 May 2017 20:49:23 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Slim] Open Issues on draft-ietf-slim-negotiating-human-language X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 18:49:33 -0000 Den 2017-05-29 kl. 00:15, skrev Randall Gellens: > I think the edits so far address #19, #27, 28 so they can be closed. > #38, #39 are addressed in -09 so I will post that and those can be > closed. I think #26, #29, #32, #34, #35 were not accepted. This is my view: #26 can be left non-accepted if #34 is accepted. But if #34 is not accepted, we could need #26. #29 is ok to not accept. All other aspects of the attribute registrations are solved. #34: I have not seen anything about not accepting it, so I suggest to accept it. #35 syntax for bidirectionally symmetric cases - will increase complexity - I would suggest to not accept it, but I cannot remember that we concluded that before. #32 requires the two extensions about relative preference and simultaneity to be solved. We have not said that we would not accept #32. I suggest that we accept it. Gunnar > > --Randy > > At 11:25 AM -0700 4/25/17, Bernard Aboba wrote: > >> Currently 10 Issues remain open from IETF Last Call: >> >> https://trac.ietf.org/trac/slim/report/1 >> >> >> >> These include: >> >> TicketSummaryComponentVersionMilestoneTypeOwnerStatusCreated#27The >> cases in the "Silly states" section 5.4 are not all >> silly.negotiating-human-language2.0milestone1defectgunnar.hellstrom@omnitor.senewMar >> 22, >> 2017#19Use >> Media Type registration >> templatemultilangcontentenhancementrfc.nik.tomkinson@gmail.comassignedAug >> 17, >> 2016#28Examples >> section 5.5 requires >> expansionnegotiating-human-language2.0milestone1defectrg+ietf@randy.pensive.orgassignedMar >> 22, >> 2017#32Audio/Video >> Coordinationnegotiating-human-language2.0milestone1defectrg+ietf@randy.pensive.orgnewMar >> 22, >> 2017#34Use >> the Accept-Language >> syntaxnegotiating-human-language2.0milestone1defectrg+ietf@randy.pensive.orgassignedMar >> 22, >> 2017#35Have >> an attribute to abbreviate the bidirectionally-symmetric >> casenegotiating-human-language2.0milestone1defectrg+ietf@randy.pensive.orgassignedMar >> 22, >> 2017#38Routing >> out of >> scopenegotiating-human-language1.0milestone1defectdraft-ietf-slim-negotiating-human-language@ietf.orgnewApr >> 25, >> 2017#39Syntax >> Collapsenegotiating-human-language1.0milestone1defectdraft-ietf-slim-negotiating-human-language@ietf.orgnewApr >> 25, >> 2017#26Make >> use of the asterisk modifier on media level with session scope also >> for media level >> purposesnegotiating-human-language2.0milestone1enhancementgunnar.hellstrom@omnitor.senewMar >> 22, >> 2017#29Include >> more fields for attribute registration from 4566bis >> >> _______________________________________________ >> SLIM mailing list >> SLIM@ietf.org >> https://www.ietf.org/mailman/listinfo/slim > > -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 From nobody Mon May 29 13:37:32 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 053D4129437 for ; Mon, 29 May 2017 13:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kcO2tRnFIujG for ; Mon, 29 May 2017 13:37:28 -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 A3DA61205D3 for ; Mon, 29 May 2017 13:37:27 -0700 (PDT) X-Halon-ID: 9d1be29b-44ae-11e7-bca7-0050569116f7 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [77.53.231.21]) by bin-vsp-out-03.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Mon, 29 May 2017 22:37:20 +0200 (CEST) To: slim@ietf.org References: <8f8fb511-420b-9cdd-5de0-a0d7be27766a@omnitor.se> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: Date: Mon, 29 May 2017 22:37:19 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <8f8fb511-420b-9cdd-5de0-a0d7be27766a@omnitor.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Slim] Collapse attribute syntax to one line in draft-ietf-slim-negotiating-human-language X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 20:37:31 -0000 By accepting Issue #34, the extensions needed for the two missing functions could be adding the following to chapter 5: ----------------an introduction of the q-values in section 5.2 by something like this------------------------------ The values constitute a list of languages in order of preference according to the q-value optionally provided with each language. If the q-value is omitted, the value 1 is assumed. -----------------Explanation of the q-value use in separate sections------------------------- 5.x Preference indication and evaluation Each language may be assigned a preference by a q-value parameter with value between 0 and 1. The value is valid for preference assignment between all languages indicated for the same direction among all media. The higher value, the higher preference. The language to use is decided by matching the languages and preferences in an incoming indication with the preferences and capabilities of the receiving party. The best matching language(s) per direction are indicated in the response and used initially in the session. This kind of indication is intended for indication of relative preference between language in different alternative media, such as a high preference for written language but an acceptance to use spoken language. 5.y Indication of preference for simultaneous use of more than one medium in a direction There are situations when it is required or strongly desired to use two languages in different media simultaneously in the same direction. This is indicated by assigning q-values less than one, and with a value less or equal to 0.1 apart for such languages. Indication of the same q-value means that the languages are required together. Indication of different q-values not more than 0.1 apart means that the lower valued language is desired simultaneously but may be omitted. The possibilities by the answering part to respond to the expressed preferences should be indicated in the answer. This kind of indication is intended for indication of need or capability to provide simultaneous subtitling in text of what is said in audio or video, or need or capability to provide a view of the speaker. ------------------------------------------------ And the following to the examples, incurrent section 5.5: ---------------------------------------------------------------------------------------------- An offer for written English both ways as highest priority, and American Sign language both ways as second preference alternative. m=video 51372 RTP/AVP 34 a=hlang-send: ase; q=0.4, * a=hlang-recv: ase; q=0.4, * m=text 45020 RTP/AVP 103 104 a=hlang-recv: en; q=0.6, * a=hlang-send: en; q=0.6, * An answer, accepting only the written English: m=video 51372 RTP/AVP 34 m=text 45020 RTP/AVP 103 104 a=hlang-recv: en; q=0.6, * a=hlang-send: en; q=0.6, * An offer for reception of written English as highest priority, and a preference for also receiving speech. And an offer to send speech at highest priority but an acceptance to send text as an alternative. m=audio 51372 RTP/AVP 0 a=hlang-send: en; q=0.4, * a=hlang-recv: en; q=0.4, * m=text 45020 RTP/AVP 103 104 a=hlang-recv: en; q=0.41, * a=hlang-send: en; q=0.1, * An answer, accepting to send both English audio and text, and receive only spoken English: m=audio 51372 RTP/AVP 0 a=hlang-send: en; q=0.4, * a=hlang-recv; en; q=0.4 m=text 45020 RTP/AVP 103 104 a=hlang-send: en; q=0.4, * ----------------------------------------------------------------------------------------------- There are other places in need of changes as well, this was the main items. This would of course be easiest to introduce now. If done as a later extension, we will have some mild interop issues, as well as a need to prepare wording in the current draft so that it does not contradict the extension. Regards Gunnar Den 2017-05-29 kl. 20:14, skrev Gunnar Hellström: > It should be noted that the syntax according to the Accept-Language > does not need to include the q-values until the user want to be > specific about the relative preferences. > > So, as long as the preferences are not of specific interest, the > example would be: > > m=audio 49250 RTP/AVP 20 > a=hlang-send: es, eu, en, * > a=hlang-recv:es, eu, en, * > > Which is very similar to the syntax just proposed by Randall. > > /Gunnar > > > > Den 2017-05-29 kl. 14:54, skrev Gunnar Hellström: >> Den 2017-05-28 kl. 23:57, skrev Randall Gellens: >>> In response to Adam Roach's comments as well as other comments, I >>> intend to update the draft to collapse the attribute syntax to one >>> line; each attribute can occur at most once per media, with all >>> languages on the same line. This will further reduce the size of >>> the SDP block. >>> >>> If you object to this, please reply. >> I am glad to see a one-line syntax, but I would as well as Dale >> Worley expressed in issue #34, prefer to use the full Accept-Language >> syntax including the q-values. >> >> Thus a syntax according to this example: >> >> m=audio 49250 RTP/AVP 20 >> a=hlang-send: es; q=0.5, eu; q=0.3, en;q=0.1, * >> a=hlang-recv:es; q=0.5, eu; q=0.3, en;q=0.1, * >> >> This format provides the following benefits >> >> 1. Satisfies both Dales and Adam's and other's review proposals >> >> 2. Is a good base for the extensions I am asked to propose, to enable >> preference between languages in different media, and preference for >> simultaneous languages in different media in the same direction. >> These two extensions are essential for making the draft useful in >> real cases. >> We can introduce cross-media validity of the q-values, and a rule for >> how preference for simultaneous media should be expressed. With other >> syntax proposals, such extensions will be much less clean. >> >> 3. Solves a problem for persons who want to express equal preference >> for a set of languages, e.g. a proffessional call center. Other >> syntaxes require a preference grading even when the user does not >> want to express any preference. >> >> 4. Makes it possible to satisfy Bernard's request for a way to >> specify subtitling, issue #34. (also included in 2 above) >> >> 5. May possibly open for a motivation to keep the asterisk as a media >> and directional parameter. >> But I have problems to define how we can motivate the placement of >> the asterisk. >> Can it be: >> "An asterisk included in an attribute value means that the call >> should not be denied because of lack of language matching in that >> media and direction. An asterisk included in each attribute value in >> the sdp means that the call should not be denied because of no >> language matching at all. >> The lack of an asterisk in an attribute value means a desire to get >> the call denied if no language match is found for the corresponding >> media and direction." >> I do not think that this differentiation betwen reasons to deny the >> call is useful, but the description motivates the placement of the >> asterisk on media and direction level, and gives us a possiblity to >> keep the asterisk parameter. >> >> I have not seen us reject issue #34, so I see the above as the >> appropriate solution on issues #34 and #39. >> >> Regards >> >> Gunnar >> >> >>> >>> Here is the section of Adam's review: >>> >>> At 8:31 PM +0000 3/28/17, Sabrina Tanamal via RT wrote: >>>> I'll note that much of this can be fixed if the syntax is >>>> collapsed so >>>> that each media section can have at most one hlang-send and one >>>> hlang-receive, each of which contain a list of one or more languages >>>> that can be sent or received. This is also much more consistent >>>> with the >>>> way SDP attributes are used in general. The presence of a "*" >>>> token on >>>> that line would indicate the "call should happen even without >>>> matching >>>> languages" characteristic; since there is only one place to add this >>>> indicator, the ambiguity of some lines indicating it and others not >>>> disappears. The preceding example would collapse to: >>>> >>>> m=audio 49250 RTP/AVP 20 >>>> a=hlang-send:es eu en * >>>> a=hlang-recv:es eu en * >>>> >>>> ...and the example text would be revised to remove the implication >>>> that >>>> *sending* "es" necessarily implies *receiving* "es". >>>> >>>> I'll further note that the majority of SDP libraries I've worked with >>>> would make accessing the all-on-one-line format easier than >>>> one-line-per-language as well. >>> >>> Here is the proposed ABNF: >>> >>> Attribute Syntax: >>> >>> hlang-value = Language-Tag *( SP Language-tag ) [ SP asterisk ] >>> >>> ; Language-Tag as defined in BCP 47 >>> >>> asterisk = "*" ; an asterisk (ASCII %2A) character >>> >>> sp = 1*" " ; one or more ASCII space (%20) characters >>> >> > -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 From nobody Mon May 29 15:18:06 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A375512945A for ; Mon, 29 May 2017 15:18:04 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B3PEmHaRR73R for ; Mon, 29 May 2017 15:18:03 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id E8C521270A3 for ; Mon, 29 May 2017 15:18:02 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Mon, 29 May 2017 15:20:18 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Mailer: Eudora for Mac OS X Date: Mon, 29 May 2017 15:17:58 -0700 To: Gunnar =?iso-8859-1?Q?Hellstr=F6m?= , Randall Gellens , Bernard Aboba , slim@ietf.org From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Slim] Open Issues on draft-ietf-slim-negotiating-human-language X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 22:18:04 -0000 At 8:49 PM +0200 5/29/17, Gunnar Hellstr=F6m wrote: > Den 2017-05-29 kl. 00:15, skrev Randall Gellens: >> I think the edits so far address #19, #27, 28=20 >> so they can be closed. #38, #39 are addressed=20 >> in -09 so I will post that and those can be=20 >> closed. I think #26, #29, #32, #34, #35 were=20 >> not accepted. > This is my view: > > #26 can be left non-accepted if #34 is accepted. #26 can be done with an Informational draft that=20 provides advice to implementers, as previously=20 discussed. #34 was discussed a long time ago and=20 it was decided that we did not need to add=20 complexity and that we would keep the more simple=20 syntax. > But if #34 is not accepted, we could need #26. > #29 is ok to not accept. All other aspects of=20 > the attribute registrations are solved. > > #34: I have not seen anything about not=20 > accepting it, so I suggest to accept it. > #35 syntax for bidirectionally symmetric cases=20 > - will increase complexity - I would suggest to=20 > not accept it, but I cannot remember that we=20 > concluded that before. > > #32 requires the two extensions about relative=20 > preference and simultaneity to be solved. We=20 > have not said that we would not accept #32. I=20 > suggest that we accept it. We've repeatedly decided to not add relative=20 preferences (nor any coordination between media)=20 in this draft. This can all be done in a=20 subsequent draft. --Randy > > > > Gunnar > > >> >> --Randy >> >> At 11:25 AM -0700 4/25/17, Bernard Aboba wrote: >> >>> Currently 10 Issues remain open from IETF Last Call: >>> >>>=20 >>> https://trac.ietf.org/trac/sli= m/report/1 >>> >>> >>> These include: >>> >>>=20 >>> TicketSummaryComponentVersionMilestoneTypeOwnerStatusCreated#27The=20 >>> cases in the "Silly states" section 5.4 are=20 >>> not all=20 >>> silly.negotiating-human-language2.0milestone1defectgunnar.= hellstrom@omnitor.senewMar=20 >>> 22,=20 >>> 2017#19Use=20 >>> Media Type registration=20 >>> templatemultilangcontentenhancementr= fc.nik.tomkinson@gmail.comassignedAug=20 >>> 17,=20 >>> 2016#28Examples=20 >>> section 5.5 requires=20 >>> expansionnegotiating-human-language2.0milestone1defectrg+i= etf@randy.pensive.orgassignedMar=20 >>> 22,=20 >>> 2017#32Audio/Video=20 >>> Coordinationnegotiating-human-language2.0milestone1defectr= g+ietf@randy.pensive.orgnewMar=20 >>> 22,=20 >>> 2017#34Use=20 >>> the Accept-Language=20 >>> syntaxnegotiating-human-language2.0milestone1defectrg+ietf= @randy.pensive.orgassignedMar=20 >>> 22,=20 >>> 2017#35Have=20 >>> an attribute to abbreviate the=20 >>> bidirectionally-symmetric=20 >>> casenegotiating-human-language2.0milestone1defectrg+ietf@r= andy.pensive.orgassignedMar=20 >>> 22,=20 >>> 2017#38Routing=20 >>> out of=20 >>> scopenegotiating-human-language1.0milestone1defectdraft-ietf-slim-negotiating-human-language@ietf.orgnewApr=20 >>> 25,=20 >>> 2017#39Syntax=20 >>> Collapsenegotiating-human-language1.0milestone1defectdraft-ietf-slim-negotiating-human-language@ietf.orgnewApr= =20 >>> 25,=20 >>> 2017#26Make=20 >>> use of the asterisk modifier on media level=20 >>> with session scope also for media level=20 >>> purposesnegotiating-human-language2.0milestone1enhancement= gunnar.hellstrom@omnitor.senewMar=20 >>> 22,=20 >>> 2017#29Include=20 >>> more fields for attribute registration from=20 >>> 4566bis >>> >>> _______________________________________________ >>> 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 -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- I do not need to explain why I say things. That's the interesting thing about being the President. Maybe somebody needs to explain to me why they say something, but I don't feel like I owe anybody an explanation. --George W. Bush, in an interview with Bob Woodward. From nobody Mon May 29 15:23:25 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91C48129485 for ; Mon, 29 May 2017 15:23:23 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S35RUMvH6Hy1 for ; Mon, 29 May 2017 15:23:21 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 2ADCF129484 for ; Mon, 29 May 2017 15:23:21 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Mon, 29 May 2017 15:25:36 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Mailer: Eudora for Mac OS X Date: Mon, 29 May 2017 15:23:16 -0700 To: Gunnar =?iso-8859-1?Q?Hellstr=F6m?= , slim@ietf.org From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Slim] Collapse attribute syntax to one line in draft-ietf-slim-negotiating-human-language X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 22:23:23 -0000 The use of q-values has been proposed before but=20 we have always decided to maintain a simple=20 syntax and solution. At 2:54 PM +0200 5/29/17, Gunnar Hellstr=F6m wrote: > Den 2017-05-28 kl. 23:57, skrev Randall Gellens: >> In response to Adam Roach's comments as well=20 >> as other comments, I intend to update the=20 >> draft to collapse the attribute syntax to one=20 >> line; each attribute can occur at most once=20 >> per media, with all languages on the same=20 >> line. This will further reduce the size of=20 >> the SDP block. >> >> If you object to this, please reply. > I am glad to see a one-line syntax, but I would=20 > as well as Dale Worley expressed in issue #34,=20 > prefer to use the full Accept-Language syntax=20 > including the q-values. > > Thus a syntax according to this example: > > m=3Daudio 49250 RTP/AVP 20 > a=3Dhlang-send: es; q=3D0.5, eu; q=3D0.3, en;q=3D0.1, * > a=3Dhlang-recv:es; q=3D0.5, eu; q=3D0.3, en;q=3D0.1, * > > This format provides the following benefits > > 1. Satisfies both Dales and Adam's and other's review proposals > > 2. Is a good base for the extensions I am asked=20 > to propose, to enable preference between=20 > languages in different media, and preference=20 > for simultaneous languages in different media=20 > in the same direction. These two extensions are=20 > essential for making the draft useful in real=20 > cases. > We can introduce cross-media validity of the=20 > q-values, and a rule for how preference for=20 > simultaneous media should be expressed. With=20 > other syntax proposals, such extensions will be=20 > much less clean. > > 3. Solves a problem for persons who want to=20 > express equal preference for a set of=20 > languages, e.g. a proffessional call center.=20 > Other syntaxes require a preference grading=20 > even when the user does not want to express any=20 > preference. > > 4. Makes it possible to satisfy Bernard's=20 > request for a way to specify subtitling, issue=20 > #34. (also included in 2 above) > > 5. May possibly open for a motivation to keep=20 > the asterisk as a media and directional=20 > parameter. > But I have problems to define how we can=20 > motivate the placement of the asterisk. > Can it be: > "An asterisk included in an attribute value=20 > means that the call should not be denied=20 > because of lack of language matching in that=20 > media and direction. An asterisk included in=20 > each attribute value in the sdp means that the=20 > call should not be denied because of no=20 > language matching at all. > The lack of an asterisk in an attribute value=20 > means a desire to get the call denied if no=20 > language match is found for the corresponding=20 > media and direction." > I do not think that this differentiation betwen=20 > reasons to deny the call is useful, but the=20 > description motivates the placement of the=20 > asterisk on media and direction level, and=20 > gives us a possiblity to keep the asterisk=20 > parameter. > > I have not seen us reject issue #34, so I see=20 > the above as the appropriate solution on issues=20 > #34 and #39. > > Regards > > Gunnar > >> >> Here is the section of Adam's review: >> >> At 8:31 PM +0000 3/28/17, Sabrina Tanamal via RT wrote: >>> I'll note that much of this can be fixed if the syntax is collapsed so >>> that each media section can have at most one hlang-send and one >>> hlang-receive, each of which contain a list of one or more languages >>> that can be sent or received. This is also much more consistent with t= he >>> way SDP attributes are used in general. The presence of a "*" token on >>> that line would indicate the "call should happen even without matching >>> languages" characteristic; since there is only one place to add this >>> indicator, the ambiguity of some lines indicating it and others not >>> disappears. The preceding example would collapse to: >>> >>> m=3Daudio 49250 RTP/AVP 20 >>> a=3Dhlang-send:es eu en * >>> a=3Dhlang-recv:es eu en * >>> >>> ...and the example text would be revised to remove the implication tha= t >>> *sending* "es" necessarily implies *receiving* "es". >>> >>> I'll further note that the majority of SDP libraries I've worked with >>> would make accessing the all-on-one-line format easier than >>> one-line-per-language as well. >> >> Here is the proposed ABNF: >> >> Attribute Syntax: >> >> hlang-value =3D Language-Tag *( SP Language-tag ) [ SP asterisk ] >> >> ; Language-Tag as defined in BCP 47 >> >> asterisk =3D "*" ; an asterisk (ASCII %2A) character >> >> sp =3D 1*" " ; one or more ASCII space (%20) characters >> > > -- > ----------------------------------------- > 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: --------------- In my own view, it was not merely uncomfortable, it was intolerable. It might perhaps have been endurable for a two-hour flight but an eight-hour flight is a totally different matter. --Judge Gareth Edwards QC, regards JMC's 29-inch seat pitch. The judge upheld a compensation award made to Brian Horan after he suffered deep-vein thrombosis (DVT) on his journey Manchester, England, to the Canadian ski resort of Calgary. Chester County Court, 17 April 2002. From nobody Mon May 29 15:47:05 2017 Return-Path: X-Original-To: slim@ietf.org Delivered-To: slim@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6125B12945A; Mon, 29 May 2017 15:47:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: slim@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149609802429.31311.6705278483062064519@ietfa.amsl.com> Date: Mon, 29 May 2017 15:47:04 -0700 Archived-At: Subject: [Slim] I-D Action: draft-ietf-slim-negotiating-human-language-09.txt X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 22:47:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Selection of Language for Internet Media of the IETF. Title : Negotiating Human Language in Real-Time Communications Author : Randall Gellens Filename : draft-ietf-slim-negotiating-human-language-09.txt Pages : 17 Date : 2017-05-29 Abstract: Users have various human (natural) language needs, abilities, and preferences regarding spoken, written, and signed languages. This document adds new SDP media-level attributes so that when establishing interactive communication sessions ("calls"), it is possible to negotiate (communicate and match) the caller's language and media needs with the capabilities of the called party. This is especially important with emergency calls, where a call can be handled by a call taker capable of communicating with the user, or a translator or relay operator can be bridged into the call during setup, but this applies to non-emergency calls as well (as an example, when calling a company call center). This document describes the need and a solution using new SDP media attributes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-slim-negotiating-human-language/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-slim-negotiating-human-language-09 https://datatracker.ietf.org/doc/html/draft-ietf-slim-negotiating-human-language-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-slim-negotiating-human-language-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon May 29 16:00:56 2017 Return-Path: X-Original-To: slim@ietf.org Delivered-To: slim@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 157D7126BFD; Mon, 29 May 2017 16:00:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: slim@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149609884905.14640.4714137651572553743@ietfa.amsl.com> Date: Mon, 29 May 2017 16:00:49 -0700 Archived-At: Subject: [Slim] I-D Action: draft-ietf-slim-negotiating-human-language-10.txt X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 23:00:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Selection of Language for Internet Media of the IETF. Title : Negotiating Human Language in Real-Time Communications Author : Randall Gellens Filename : draft-ietf-slim-negotiating-human-language-10.txt Pages : 17 Date : 2017-05-29 Abstract: Users have various human (natural) language needs, abilities, and preferences regarding spoken, written, and signed languages. This document adds new SDP media-level attributes so that when establishing interactive communication sessions ("calls"), it is possible to negotiate (communicate and match) the caller's language and media needs with the capabilities of the called party. This is especially important with emergency calls, where a call can be handled by a call taker capable of communicating with the user, or a translator or relay operator can be bridged into the call during setup, but this applies to non-emergency calls as well (as an example, when calling a company call center). This document describes the need and a solution using new SDP media attributes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-slim-negotiating-human-language/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-slim-negotiating-human-language-10 https://datatracker.ietf.org/doc/html/draft-ietf-slim-negotiating-human-language-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-slim-negotiating-human-language-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon May 29 16:04:37 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DF4612702E for ; Mon, 29 May 2017 16:04:35 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IVQrBu3NeAGX for ; Mon, 29 May 2017 16:04:34 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 1AD6B126BFD for ; Mon, 29 May 2017 16:04:34 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Mon, 29 May 2017 16:06:49 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Mailer: Eudora for Mac OS X Date: Mon, 29 May 2017 16:04:28 -0700 To: slim@ietf.org From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Archived-At: Subject: Re: [Slim] Collapse attribute syntax to one line in draft-ietf-slim-negotiating-human-language X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 23:04:35 -0000 I uploaded version -10, which includes the syntax change to single line, along with a few editorial clarifications. (Version -09 accidently omitted an editorial clarification.) You can see a diff of the changes from 08 to 10 here: https://www.ietf.org/rfcdiff?url1=draft-ietf-slim-negotiating-human-language-08&url2=draft-ietf-slim-negotiating-human-language-10 If there objections to the change from multi-line to single-line, this can be reverted. --Randy At 2:57 PM -0700 5/28/17, Randall Gellens wrote: > In response to Adam Roach's comments as well as other comments, I > intend to update the draft to collapse the attribute syntax to one > line; each attribute can occur at most once per media, with all > languages on the same line. This will further reduce the size of > the SDP block. > > If you object to this, please reply. > > Here is the section of Adam's review: > > At 8:31 PM +0000 3/28/17, Sabrina Tanamal via RT wrote: >> I'll note that much of this can be fixed if the syntax is collapsed so >> that each media section can have at most one hlang-send and one >> hlang-receive, each of which contain a list of one or more languages >> that can be sent or received. This is also much more consistent with the >> way SDP attributes are used in general. The presence of a "*" token on >> that line would indicate the "call should happen even without matching >> languages" characteristic; since there is only one place to add this >> indicator, the ambiguity of some lines indicating it and others not >> disappears. The preceding example would collapse to: >> >> m=audio 49250 RTP/AVP 20 >> a=hlang-send:es eu en * >> a=hlang-recv:es eu en * >> >> ...and the example text would be revised to remove the implication that >> *sending* "es" necessarily implies *receiving* "es". >> >> I'll further note that the majority of SDP libraries I've worked with >> would make accessing the all-on-one-line format easier than >> one-line-per-language as well. > > Here is the proposed ABNF: > > Attribute Syntax: > > hlang-value = Language-Tag *( SP Language-tag ) [ SP asterisk ] > > ; Language-Tag as defined in BCP 47 > > asterisk = "*" ; an asterisk (ASCII %2A) character > > sp = 1*" " ; one or more ASCII space (%20) characters > > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- > If forced to travel on an airplane, try and get in the cabin with > the Captain, so you can keep an eye on him and nudge him if he > falls asleep or point out any mountains looming up ahead ... > --Mike Harding, The Armchair Anarchist's Almanac. > > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Knowledge always desires increase; it is like fire, which must first be kindled by some external agent, but which will afterwards propagate itself. --Dr. Samuel Johnson From nobody Tue May 30 13:51:30 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F044812944A for ; Tue, 30 May 2017 13:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJQJijDCQVrH for ; Tue, 30 May 2017 13:51:26 -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 8CAD0126CD8 for ; Tue, 30 May 2017 13:51:25 -0700 (PDT) X-Halon-ID: bb70755a-4579-11e7-bcc3-005056917f90 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [77.53.231.21]) by bin-vsp-out-02.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Tue, 30 May 2017 22:51:19 +0200 (CEST) References: <149609884905.14640.4714137651572553743@ietfa.amsl.com> To: slim@ietf.org From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <54839aba-7ac8-79e4-74f8-927eb455d8af@omnitor.se> Date: Tue, 30 May 2017 22:51:16 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <149609884905.14640.4714137651572553743@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------81924E8F2BFEE78609E9EA2B" Archived-At: Subject: Re: [Slim] I-D Action: draft-ietf-slim-negotiating-human-language-10.txt X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 20:51:29 -0000 This is a multi-part message in MIME format. --------------81924E8F2BFEE78609E9EA2B Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Randall, good to see progress. I have a few edit proposals: ---Change 1--- Last two lines of 1. Introduction When the draft is ready, it is no draft anymore. Plus divide the aspects in two sentences. ----old text--- To reduce the complexity of the solution, this draft focuses on negotiating language per media; routing is out of scope. ---New text--- To keep the complexity of the solution low, this document focuses on negotiating language per media. Routing aspects are out of scope. -- end of change 1. ---- ---Change 2 -- Last lines of 5.2 We must be clear about that the result normally is alternative languages to use, normally not simultaneously. Without this clarification, we are not better than the old SDP lang attribute. ---Old text --- Note that media and language negotiation might result in more media streams being accepted than are needed by the users (e.g., if more preferred and less preferred combinations of media and language are all accepted). This is not a problem. ---New text ---- Without any further indications of preferences or requirements for simultaneity, the language indications should be seen as alternatives to select from. Media and language negotiation might result in more media streams and languages being accepted than are needed by the users (e.g., if more preferred and less preferred combinations of media and language are all accepted). ---End of change 2 --- ---Change 3--- In 5.3 sharpen up the description on how to use the asterisk. The current description confused most reviewers. ---old text---- The mechanism for indicating this preference is that, in an offer, if the last value of either 'hlang-recv' or 'hlang-send' is an asterisk, this indicates a request to not fail the call. ---new text--- The mechanism for indicating this preference is that, in an offer, if the last parameter of any 'hlang-recv' or 'hlang-send' value in the whole SDP is an asterisk, this indicates a request to not fail the call. ---end of change 3--- ----Change 4--- In 5.5, Some example shows use of sign language one way and text the other. ---Old text---- Note that, even though the examples all show the same language --New text---- Note that, even though most examples show the same language ---End of change 4---- ----Change 5----- In 6.1. SDP values are UTF-8 coded, not ASCII. ---Old text--- asterisk = "*" ; an asterisk (ASCII %2A) character sp = 1*" " ; one or more ASCII space (%20) characters ---New text--- asterisk = "*" ; an asterisk (%x2A) character SP = 1*" " ; one or more space (%x20) characters --End of change 5 ---- -- Regards Gunnar Den 2017-05-30 kl. 01:00, skrev internet-drafts@ietf.org: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Selection of Language for Internet Media of the IETF. > > Title : Negotiating Human Language in Real-Time Communications > Author : Randall Gellens > Filename : draft-ietf-slim-negotiating-human-language-10.txt > Pages : 17 > Date : 2017-05-29 > > Abstract: > Users have various human (natural) language needs, abilities, and > preferences regarding spoken, written, and signed languages. This > document adds new SDP media-level attributes so that when > establishing interactive communication sessions ("calls"), it is > possible to negotiate (communicate and match) the caller's language > and media needs with the capabilities of the called party. This is > especially important with emergency calls, where a call can be > handled by a call taker capable of communicating with the user, or a > translator or relay operator can be bridged into the call during > setup, but this applies to non-emergency calls as well (as an > example, when calling a company call center). > > This document describes the need and a solution using new SDP media > attributes. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-slim-negotiating-human-language/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-slim-negotiating-human-language-10 > https://datatracker.ietf.org/doc/html/draft-ietf-slim-negotiating-human-language-10 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-slim-negotiating-human-language-10 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 --------------81924E8F2BFEE78609E9EA2B Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Randall,

good to see progress.

I have a few edit proposals:

---Change 1---

Last two lines of 1. Introduction

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

----old text---

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

---New text---

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

-- end of change 1. ----

---Change 2 --

Last lines of 5.2

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

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

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

---End of change 2 ---

---Change 3---

In 5.3

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

---old text----

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

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

---end of change 3---

----Change 4---

In 5.5,

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

---Old text----

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

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

---End of change 4----

----Change 5-----

In 6.1.

SDP values are UTF-8 coded, not ASCII.

---Old text---


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

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

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

      SP          =  1*" " ; one or more space (%x20) characters
--End of change 5 ----

--

Regards
Gunnar



Den 2017-05-30 kl. 01:00, skrev internet-drafts@ietf.org:
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Selection of Language for Internet Media of the IETF.

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

Abstract:
   Users have various human (natural) language needs, abilities, and
   preferences regarding spoken, written, and signed languages.  This
   document adds new SDP media-level attributes so that when
   establishing interactive communication sessions ("calls"), it is
   possible to negotiate (communicate and match) the caller's language
   and media needs with the capabilities of the called party.  This is
   especially important with emergency calls, where a call can be
   handled by a call taker capable of communicating with the user, or a
   translator or relay operator can be bridged into the call during
   setup, but this applies to non-emergency calls as well (as an
   example, when calling a company call center).

   This document describes the need and a solution using new SDP media
   attributes.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-slim-negotiating-human-language/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-slim-negotiating-human-language-10
https://datatracker.ietf.org/doc/html/draft-ietf-slim-negotiating-human-language-10

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


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

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

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


-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288
--------------81924E8F2BFEE78609E9EA2B-- From nobody Tue May 30 16:56:24 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F538129485 for ; Tue, 30 May 2017 16:56:23 -0700 (PDT) X-Quarantine-ID: <25Wgtvsx5wQZ> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25Wgtvsx5wQZ for ; Tue, 30 May 2017 16:56:21 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 3851E126BFD for ; Tue, 30 May 2017 16:56:21 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Tue, 30 May 2017 16:58:36 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <54839aba-7ac8-79e4-74f8-927eb455d8af@omnitor.se> References: <149609884905.14640.4714137651572553743@ietfa.amsl.com> <54839aba-7ac8-79e4-74f8-927eb455d8af@omnitor.se> X-Mailer: Eudora for Mac OS X Date: Tue, 30 May 2017 16:56:15 -0700 To: Gunnar =?iso-8859-1?Q?Hellstr=F6m?= , slim@ietf.org From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Slim] I-D Action: draft-ietf-slim-negotiating-human-language-10.txt X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 23:56:24 -0000 At 10:51 PM +0200 5/30/17, Gunnar Hellstr=F6m wrote: > Randall, > > good to see progress. > > I have a few edit proposals: > > ---Change 1--- > > Last two lines of 1. Introduction > > When the draft is ready, it is no draft=20 > anymore. Plus divide the aspects in two=20 > sentences. > > ----old text--- > > To reduce the complexity of the solution, this draft focuses on > negotiating language per media; routing is out of scope. > > ---New text--- > > To keep the complexity of the solution low, this document focuses on > negotiating language per media. Routing aspects are out of scope. > > -- end of change 1. ---- The use of "draft" was an error, I'll change it=20 to "document." I prefer the semicolon to=20 maintain the two parts since it has closer=20 linkage between the two than would a period. > > ---Change 2 -- > > Last lines of 5.2 > > We must be clear about that the result normally=20 > is alternative languages to use, normally not=20 > simultaneously. Without this clarification, we=20 > are not better than the old SDP lang attribute. > > ---Old text --- > Note that media and language negotiation might result in more media > streams being accepted than are needed by the users (e.g., if more > preferred and less preferred combinations of media and language are > all accepted). This is not a problem. > > ---New text ---- > Without any further indications of=20 > preferences or requirements for simultaneity,=20 > the language indications should be seen as=20 > alternatives to select from. Media and language=20 > negotiation might result in more media streams=20 > and languages being accepted than are needed by=20 > the users > (e.g., if more preferred and less preferred=20 > combinations of media and language are > all accepted). > > ---End of change 2 --- I don't think it's true that we're no better off=20 than the old SDP lang attribute, for multiple=20 reasons, not least of which is that 'lang' is not=20 used for negotiating language in interactive=20 media. Further, I think the result of extra=20 streams is that there are extra streams that=20 probably won't be used. > > ---Change 3--- > > In 5.3 > > sharpen up the description on how to use the=20 > asterisk. The current description confused most=20 > reviewers. > > ---old text---- > > The mechanism for indicating this preference is that, in an offer, if > the last value of either 'hlang-recv' or 'hlang-send' is an asterisk, > this indicates a request to not fail the call. > > ---new text--- > The mechanism for indicating this preference is that, in an offer, if > the last parameter of any 'hlang-recv' or=20 > 'hlang-send' value in the whole SDP > is an asterisk, this indicates a request to not fail the call. > > ---end of change 3--- I think it's more clear to word it as so: The mechanism for indicating this preference is that, in an offer, if the last value of any 'hlang-recv' or 'hlang-send' for any media is an asterisk, this indicates a request to not fail the call. The called party MAY ignore the indication, e.g., for the emergency services use case, regardless of the absence of an asterisk, a PSAP will likely not fail the call; some call centers might reject a call even if the offer contains an asterisk. > > ----Change 4--- > > In 5.5, > > Some example shows use of sign language one way and text the other. > > ---Old text---- > > Note that, even though the examples all show the same language > > --New text---- > Note that, even though most examples show the same language > > ---End of change 4---- > > ----Change 5----- The text does say "(even when the modality=20 differs)" to cover this, but for clarification, I=20 can delete "all" and add "(or essentially the=20 same)": Note that, even though the examples show the same (or essentially the same) language being used in both directions (even when the modality differs), there is no requirement that this be the case. However, in practice, doing so is likely to increase the chances of successful matching. > > In 6.1. > > SDP values are UTF-8 coded, not ASCII. > > ---Old text--- > > > > asterisk =3D "*" ; an asterisk (ASCII %2A) character > > sp =3D 1*" " ; one or more ASCII space (%20) characters > > ---New text--- > > > asterisk =3D "*" ; an asterisk (%x2A) character > > SP =3D 1*" " ; one or more space (%x20) characters > > --End of change 5 ---- I'll change "ASCII %" to "0x" for clarity. > > -- > > Regards > Gunnar > > > Den 2017-05-30 kl. 01:00, skrev=20 > internet-drafts@ietf.org: > >> >> A New Internet-Draft is available from the=20 >> on-line Internet-Drafts directories. >> This draft is a work item of the Selection of=20 >> Language for Internet Media of the IETF. >> >> Title : Negotiating Human=20 >> Language in Real-Time Communications >> Author : Randall Gellens >> Filename : draft-ietf-slim-negotiating-human-language-10.txt >> Pages : 17 >> Date : 2017-05-29 >> >> Abstract: >> Users have various human (natural) language needs, abilities, and >> preferences regarding spoken, written, and signed languages. This >> document adds new SDP media-level attributes so that when >> establishing interactive communication sessions ("calls"), it is >> possible to negotiate (communicate and match) the caller's language >> and media needs with the capabilities of the called party. This is >> especially important with emergency calls, where a call can be >> handled by a call taker capable of communicating with the user, or a >> translator or relay operator can be bridged into the call during >> setup, but this applies to non-emergency calls as well (as an >> example, when calling a company call center). >> >> This document describes the need and a solution using new SDP media >> attributes. >> >> >> The IETF datatracker status page for this draft is: >>=20 >> https://datatracker.ietf.org/doc/draft-ietf-slim-negotiating-human-lang= uage/ >> >> There are also htmlized versions available at: >>=20 >> https://tools.ietf.org/html/draft-ietf-slim-negotiating-human-language-10 >>=20 >> https://datatracker.ietf.org/doc/html/draft-ietf-slim-negotiatin= g-human-language-10 >> >> A diff from the previous version is available at: >>=20 >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-slim-negotiating-hu= man-language-10 >> >> >> Please note that it may take a couple of minutes from the time of submis= sion >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> SLIM mailing list >> SLIM@ietf.org >>=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: --------------- Tolerance implies no lack of commitment to one's own beliefs. Rather it condemns the oppression or persecution of others. --John F. Kennedy (1960) From nobody Wed May 31 01:59:11 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B5071293EC for ; Wed, 31 May 2017 01:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Uf3e1ukkS7e9 for ; Wed, 31 May 2017 01:59:04 -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 E4453126DD9 for ; Wed, 31 May 2017 01:59:03 -0700 (PDT) X-Halon-ID: 61460d96-45df-11e7-bcc3-005056917f90 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [77.53.231.21]) by bin-vsp-out-02.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Wed, 31 May 2017 10:58:56 +0200 (CEST) To: Randall Gellens , slim@ietf.org References: <149609884905.14640.4714137651572553743@ietfa.amsl.com> <54839aba-7ac8-79e4-74f8-927eb455d8af@omnitor.se> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: Date: Wed, 31 May 2017 10:58:52 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------3B4E71254A21330F1FFF854F" Archived-At: Subject: Re: [Slim] I-D Action: draft-ietf-slim-negotiating-human-language-10.txt X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 08:59:09 -0000 This is a multi-part message in MIME format. --------------3B4E71254A21330F1FFF854F Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Randall, Your response on change proposal 2 caused a more thorough review of weak points in the reasoning in section 5.2. So, change 2 expanded to a number of sub-proposals that, when accepted, should result in less risk for mis-interpretations. See also the other comments. Thanks, Gunnar Den 2017-05-31 kl. 01:56, skrev Randall Gellens: > At 10:51 PM +0200 5/30/17, Gunnar Hellström wrote: > >> Randall, >> >> good to see progress. >> >> I have a few edit proposals: >> >> ---Change 1--- >> >> Last two lines of 1. Introduction >> >> When the draft is ready, it is no draft anymore. Plus divide the >> aspects in two sentences. >> >> ----old text--- >> >> To reduce the complexity of the solution, this draft focuses on >> negotiating language per media; routing is out of scope. >> >> ---New text--- >> >> To keep the complexity of the solution low, this document focuses on >> negotiating language per media. Routing aspects are out of scope. >> >> -- end of change 1. ---- > > The use of "draft" was an error, I'll change it to "document." I > prefer the semicolon to maintain the two parts since it has closer > linkage between the two than would a period. Accepted. > >> >> ---Change 2 -- >> >> Last lines of 5.2 >> >> We must be clear about that the result normally is alternative >> languages to use, normally not simultaneously. Without this >> clarification, we are not better than the old SDP lang attribute. >> >> ---Old text --- >> Note that media and language negotiation might result in more media >> streams being accepted than are needed by the users (e.g., if more >> preferred and less preferred combinations of media and language are >> all accepted). This is not a problem. >> >> ---New text ---- >> Without any further indications of preferences or requirements >> for simultaneity, the language indications should be seen as >> alternatives to select from. Media and language negotiation might >> result in more media streams and languages being accepted than are >> needed by the users >> (e.g., if more preferred and less preferred combinations of media >> and language are >> all accepted). >> >> ---End of change 2 --- > > I don't think it's true that we're no better off than the old SDP lang > attribute, for multiple reasons, not least of which is that 'lang' is > not used for negotiating language in interactive media. Further, I > think the result of extra streams is that there are extra streams that > probably won't be used. I just mean that it must be absolutely clear that the language indications for the same direction are alternatives to select from, and not an indication that they will be used simultaneously. (not until we have the extension sorted out that will indicate simultaneous use in specific cases). The problem we had with 'Lang' was that the intention was not absolutely clear if it was about alternatives or simultaneous usage. You read it one way and I read it another way. In 5.2 we still have wording that can be read as if offering or answering with two languages in the same direction will imply that the user is prepared to use both simultaneously. We must be sure that the normal case means that the languages are alternatives to select from. Multiple reviewers indicated that they had problems understanding our attributes. Some read it as if we have some pairing specified and others saw other relations that we have not intended. I think we need to take these warnings from independent readers and sort out any risk for mis-interpretation of our intentions. Making a new effort to sort this out completely in 5.2 gives us: --Change 2.1-- --Old text 2.1-- This document defines two media-level attributes starting with 'hlang' (short for "human interactive language") to negotiate which human language is used in each interactive media stream. --New text 2.1--- This document defines two media-level attributes starting with 'hlang' (short for "human interactive language") to negotiate which human language alternative(s) the users are prepared to use in each interactive media stream. --End of change 2.1--- --Old text 2.2--- Each can appear in an offer for a media stream. --New text 2.2--- Each can appear in an offer and answer for a media stream. --End of change 2.2--- ---Old text 2.3 --- In an offer, the 'hlang-send' value is a list of one or more language(s) the offerer is willing to use when sending using the media, and the 'hlang-recv' value is a list of one or more language(s) the offerer is willing to use when receiving using the media. ----New text 2.3--- In an offer, the 'hlang-send' value is a list of one or more alternative language(s) the offerer is willing to use when sending using the media, and the 'hlang-recv' value is a list of one or more alternative language(s) the offerer is willing to use when receiving using the media. ---End of change 2.3--- ---Old text 2.4 --- The list of languages is in preference order (first is most preferred). ---New text 2.4--- The list of alternative languages is in preference order (first is most preferred). ---End of change 2.4--- ---Change 2.5----- Requiring exactly one language per direction in the answer requires a tight coupling between the device and the user that we have avoided to specify. It would require either that the device takes the negotiation decision and dictates to the user e.g. "SPEAK GERMAN NOW !, or that there is a user interface interaction to decide which language to answer in, e.g. "The calling part may accept French or German, indicate here which one you will answer with". We do not want to dictate that kind of tight coupling, and therefore must allow a number of alternative languages in various media to appear in the answer. ---Old text 2.5--- In an answer, 'hlang-send' is the language the answerer will send when using the media (which in most cases is one of the languages in the offer's 'hlang-recv'), and 'hlang-recv' is the language the answerer expects to receive in the media (which in most cases is one of the languages in the offer's 'hlang-send'). ---New text 2.5--- In an answer, 'hlang-send' may be one or a list of alternative languages the answerer will select from for sending if using the media for language (which in most cases is one of the languages in the offer's 'hlang-recv'), and 'hlang-recv' may be one or a list of alternative languages the answerer can accept to receive if the media is used for language (which in most cases is one of the languages in the offer's 'hlang-send'). ---End of change 2.5 ---Old text 2.6--- When placing an emergency call, and in any other case where the language cannot be inferred from context, in an offer each media stream primarily intended for human language communication SHOULD specify both (or for asymmetrical language use, one of) the 'hlang- send' and 'hlang-recv' attributes. ---New text 2.6--- When placing an emergency call, and in any other case where the language cannot be inferred from context, in an offer each media stream primarily intended as an alternative for human language communication SHOULD specify both (or for asymmetrical language use, one of) the 'hlang- send' and 'hlang-recv' attributes. --End of change 2.6--- ---Old text 2.7--- Clients acting on behalf of end users are expected to set one or both 'hlang-send' and 'hlang-recv' attributes on each media stream primarily intended for human communication in an offer when placing an outgoing session, ---New text 2.7--- Clients acting on behalf of end users are expected to set one or both 'hlang-send' and 'hlang-recv' attributes on each media stream primarily intended as an alternative for human communication in an offer when placing an outgoing session, ---End of change 2.7--- ---Old text 2.8--- Note that media and language negotiation might result in more media streams being accepted than are needed by the users (e.g., if more preferred and less preferred combinations of media and language are all accepted). This is not a problem. ---New text 2.8--- Media and language negotiation might result in more media streams and language alternatives being accepted than are needed by the users (e.g., if more preferred and less preferred combinations of media and language are all accepted). The users are expected to sort out which media and language alternatives to really use in the session, possibly supported by using refined indications. ---End of change 2.8---- > >> >> ---Change 3--- >> >> In 5.3 >> >> sharpen up the description on how to use the asterisk. The current >> description confused most reviewers. >> >> ---old text---- >> >> The mechanism for indicating this preference is that, in an >> offer, if >> the last value of either 'hlang-recv' or 'hlang-send' is an >> asterisk, >> this indicates a request to not fail the call. >> >> ---new text--- >> The mechanism for indicating this preference is that, in an >> offer, if >> the last parameter of any 'hlang-recv' or 'hlang-send' value in >> the whole SDP >> is an asterisk, this indicates a request to not fail the call. >> >> ---end of change 3--- > > I think it's more clear to word it as so: > > The mechanism for indicating this preference is that, in an offer, if > the last value of any 'hlang-recv' or 'hlang-send' for any media is > an asterisk, this indicates a request to not fail the call. The > called party MAY ignore the indication, e.g., for the emergency > services use case, regardless of the absence of an asterisk, a PSAP > will likely not fail the call; some call centers might reject a call > even if the offer contains an asterisk. The important part was to change from "either" to "any", so that is good. But we should also be strict about what we call the parts of the attribute values. I prefer to call the whole string after 'hlang-recv:" or 'hlang-send:' the "value", and the separate language tags or asterisk then being "parameters" of that value. I think it is inconsistent to say that "the last value of the attribute value" may be an asterisk. Better to say that "the last parameter of the value" may be an asterisk. (I will return to the asterisk with a separate proposal for how to use its placement for something useful.) > >> >> ----Change 4--- >> >> In 5.5, >> >> Some example shows use of sign language one way and text the other. >> >> ---Old text---- >> >> Note that, even though the examples all show the same language >> >> --New text---- >> Note that, even though most examples show the same language >> >> ---End of change 4---- >> > > The text does say "(even when the modality differs)" to cover this, > but for clarification, I can delete "all" and add "(or essentially the > same)": I think of the case when a deaf-blind person prefers to send a sign language and receive a written language. These languages do not have the same language tags even if they are used in the same geographic region. We also have the working cases when I accept to receive Norweigan but speak Swedish myself, or someone accepting to receive Italian, but want to speak Spanish themselves, and other similar language mixes. These cases will more likely be satisfied not by true language matching, but by never using the request to fail the call, and let the users sort out the communication with some guidance from the indications. (both seeing what the other party expects will prepare them for the a bit unusual language mix.) Your proposed change will work for these cases. Accepted. > > Note that, even though the examples show the same (or essentially the > same) language being used in both directions (even when the modality > differs), there is no requirement that this be the case. However, in > practice, doing so is likely to increase the chances of successful > matching. > > ---Change 5--- >> >> In 6.1. >> >> SDP values are UTF-8 coded, not ASCII. >> >> ---Old text--- >> >> >> >> asterisk = "*" ; an asterisk (ASCII %2A) character >> >> sp = 1*" " ; one or more ASCII space (%20) characters >> >> ---New text--- >> >> >> asterisk = "*" ; an asterisk (%x2A) character >> >> SP = 1*" " ; one or more space (%x20) characters >> >> --End of change 5 ---- > > I'll change "ASCII %" to "0x" for clarity. Note also the change from "sp" to "SP" > >> >> -- >> >> Regards >> Gunnar >> >> >> Den 2017-05-30 kl. 01:00, skrev >> internet-drafts@ietf.org: >> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the Selection of Language for Internet >>> Media of the IETF. >>> >>> Title : Negotiating Human Language in Real-Time >>> Communications >>> Author : Randall Gellens >>> Filename : >>> draft-ietf-slim-negotiating-human-language-10.txt >>> Pages : 17 >>> Date : 2017-05-29 >>> >>> Abstract: >>> Users have various human (natural) language needs, abilities, and >>> preferences regarding spoken, written, and signed languages. This >>> document adds new SDP media-level attributes so that when >>> establishing interactive communication sessions ("calls"), it is >>> possible to negotiate (communicate and match) the caller's language >>> and media needs with the capabilities of the called party. This is >>> especially important with emergency calls, where a call can be >>> handled by a call taker capable of communicating with the user, >>> or a >>> translator or relay operator can be bridged into the call during >>> setup, but this applies to non-emergency calls as well (as an >>> example, when calling a company call center). >>> >>> This document describes the need and a solution using new SDP media >>> attributes. >>> >>> >>> The IETF datatracker status page for this draft is: >>> >>> https://datatracker.ietf.org/doc/draft-ietf-slim-negotiating-human-language/ >>> >>> >>> There are also htmlized versions available at: >>> >>> https://tools.ietf.org/html/draft-ietf-slim-negotiating-human-language-10 >>> >>> >>> https://datatracker.ietf.org/doc/html/draft-ietf-slim-negotiating-human-language-10 >>> >>> >>> A diff from the previous version is available at: >>> >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-slim-negotiating-human-language-10 >>> >>> >>> >>> Please note that it may take a couple of minutes from the time of >>> submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> >>> _______________________________________________ >>> SLIM mailing list >>> SLIM@ietf.org >>> >>> https://www.ietf.org/mailman/listinfo/slim >>> >>> >> >> -- >> ----------------------------------------- >> Gunnar Hellström >> Omnitor >> gunnar.hellstrom@omnitor.se >> +46 708 204 288 >> >> _______________________________________________ >> SLIM mailing list >> SLIM@ietf.org >> https://www.ietf.org/mailman/listinfo/slim > > -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 --------------3B4E71254A21330F1FFF854F Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Randall,

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

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

See also the other comments.

Thanks,

Gunnar


Den 2017-05-31 kl. 01:56, skrev Randall Gellens:
At 10:51 PM +0200 5/30/17, Gunnar Hellström wrote:

 Randall,

 good to see progress.

 I have a few edit proposals:

 ---Change 1---

 Last two lines of 1. Introduction

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

 ----old text---

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

 ---New text---

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

 -- end of change 1. ----

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


 ---Change 2 --

 Last lines of 5.2

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

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

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

 ---End of change 2 ---

I don't think it's true that we're no better off than the old SDP lang attribute, for multiple reasons, not least of which is that 'lang' is not used for negotiating language in interactive media.  Further, I think the result of extra streams is that there are extra streams that probably won't be used.
<GH> I just mean that it must be absolutely clear that the language indications for the same direction are alternatives to select from, and not an indication that they will be used simultaneously. (not until we have the extension sorted out that will indicate simultaneous use in specific cases). 

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

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

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

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

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


--End of change 2.1---

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


--End of change 2.2---

---Old text 2.3 ---

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


---End of change 2.3---

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


---End of change 2.4---

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

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

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

---End of change 2.5

---Old text 2.6---

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


--End of change 2.6---
 

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


---End of change 2.7---

---Old text 2.8---

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


---End of change 2.8----




 ---Change 3---

 In 5.3

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

 ---old text----

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

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

 ---end of change 3---

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

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

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

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


 ----Change 4---

 In 5.5,

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

 ---Old text----

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

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

 ---End of change 4----


The text does say "(even when the modality differs)" to cover this, but for clarification, I can delete "all" and add "(or essentially the same)":
<GH>I think of the case when a deaf-blind person prefers to send a sign language and receive a written language. These languages do not have the same language tags even if they are used in the same geographic region.

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

Your proposed change will work for these cases.   Accepted.

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


---Change 5---

 In 6.1.

 SDP values are UTF-8 coded, not ASCII.

 ---Old text---



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

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

  ---New text---


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

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

  --End of change 5 ----

I'll change "ASCII %" to "0x" for clarity.
<GH> Note also the change from "sp"   to "SP"


 --

 Regards
 Gunnar


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


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

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

 Abstract:
    Users have various human (natural) language needs, abilities, and
    preferences regarding spoken, written, and signed languages.  This
    document adds new SDP media-level attributes so that when
    establishing interactive communication sessions ("calls"), it is
    possible to negotiate (communicate and match) the caller's language
    and media needs with the capabilities of the called party.  This is
    especially important with emergency calls, where a call can be
    handled by a call taker capable of communicating with the user, or a
    translator or relay operator can be bridged into the call during
    setup, but this applies to non-emergency calls as well (as an
    example, when calling a company call center).

    This document describes the need and a solution using new SDP media
    attributes.


 The IETF datatracker status page for this draft is:

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

 There are also htmlized versions available at:

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

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

 A diff from the previous version is available at:

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


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

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

 _______________________________________________
 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
--------------3B4E71254A21330F1FFF854F-- From nobody Wed May 31 06:24:54 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5131C129438 for ; Wed, 31 May 2017 06:24:52 -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 hzZH1WvwGksQ for ; Wed, 31 May 2017 06:24:49 -0700 (PDT) Received: from bin-vsp-out-03.atm.binero.net (bin-mail-out-06.binero.net [195.74.38.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C18E8129524 for ; Wed, 31 May 2017 06:24:48 -0700 (PDT) X-Halon-ID: 830da33e-4604-11e7-bca7-0050569116f7 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [77.53.231.21]) by bin-vsp-out-03.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Wed, 31 May 2017 15:24:44 +0200 (CEST) To: slim@ietf.org References: <149609884905.14640.4714137651572553743@ietfa.amsl.com> <54839aba-7ac8-79e4-74f8-927eb455d8af@omnitor.se> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: Date: Wed, 31 May 2017 15:24:40 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------658743ECD68DC0B9772FA8E4" Archived-At: Subject: [Slim] New wording for the use of the asterisk in draft-ietf-slim-negotiating-human-language X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 13:24:52 -0000 This is a multi-part message in MIME format. --------------658743ECD68DC0B9772FA8E4 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Regarding the many review comments about the use of the asterisk parameter in draft-ietf-slim-negotiating-human-language, ( e.g. by Adam Roach on 28/3/2017) I propose the following change that both gives a meaning to the position of the asterisk and satisfies issue #26 with media preferences. I propose to use this solution if there is a decision to not satisfy Issue #34, to use the Accept-Language syntax.: --Change proposal - to draft version -10--- --First change-- in section 5.2 --old text- In an offer, each value MAY have an asterisk appended as the final value. An asterisk appended to either value in an offer indicates a request by the caller to the callee to not fail the call if there is no language in common. See Section 5.3 for more information and discussion. -new text In an offer or answer, each value MAY have an asterisk appended as the final parameter. An asterisk appended to a value in an offer indicates a that the caller has higher preference for the corresponding modality to be used in the specified direction than other modalities for the indicated direction without an asterisk. If no such preference is indicated in any hlang- attribute, it should be taken as a preference by the caller to get the call denied if no languages are in common between the caller and the callee. In an answer, the asterisk indicates a modality that is preferred by the callee to be used in the session. See Section 5.3 for more information and discussion. --end of first change---- ---second change---- In 5.3 ----old text--- 5.3. No Language in Common A consideration with the ability to negotiate language is if the call proceeds or fails if the callee does not support any of the languages requested by the caller. This document does not mandate either behavior, although it does provide a way for the caller to indicate a preference for the call succeeding when there is no language in common. It is OPTIONAL for the callee to honor this preference. For example, a PSAP is likely to attempt the call even without an indicated preference when there is no language in common, while a call center might choose to fail the call. The mechanism for indicating this preference is that, in an offer, if the last value of either 'hlang-recv' or 'hlang-send' is an asterisk, this indicates a request to not fail the call. The called party MAY ignore the indication, e.g., for the emergency services use case, regardless of the absence of an asterisk, a PSAP will likely not fail the call; some call centers might reject a call even if the offer contains an asterisk. ---New text ---- 5.3. Preferred modality and action if no match A user may have a clear preference to use one specific modality in a direction, while use of other modalities may be acceptable but lower in preference. This condition MAY be indicated by appending an asterisk as the last parameter in the corresponding humlang- value. This indication should also be seen as a preference to not have the call denied even if no indicated languages are in common. When negotiating language use for a direction, languages and modalities specified together with the asterisk should be given preference to be selected for use. No specific preference between modalities in the same direction should be indicated by appending an asterisk on all or no humlang- values for that direction. If there is a preference for denying the call when no languages match, then it is not possible to indicate any preferred modality at the same time. It is OPTIONAL for the callee to honor the preference for denying the call at no match. For example, a PSAP is likely to attempt the call even without an indicated preference when there is no language in common, while a call center might choose to fail the call. The called party MAY ignore the indication for denying the call, e.g., for the emergency services use case, regardless of the absence of an asterisk, a PSAP will likely not fail the call; some call centers might reject a call in case of no matching language even if the offer contains an asterisk. -----end of change ------------------ ---Change in 5.5---- ---Add this text as a separate example e.g. last in 5.5--- An offer requesting the following media streams: audio for the caller to send using spoken English (most preferred modality) or American Sign Language (less preferred modality), audio for the caller to receive spoken English (most preferred modality) or American Sign Language (less preferred modality), supplemental text. The offer also requests that the call proceed even if the callee does not support any of the languages. The offer is likely from a hearing person with knowledge in sign language: m=text 45020 RTP/AVP 103 104 m=audio 49250 RTP/AVP 20 a=hlang-recv:en * a=hlang-send:en * m=video 51372 RTP/AVP 31 32 a=hlang-recv: ase a=hlang-send: ase An answer for the above offer, indicating video in which the callee will send and receive American Sign Language, because that callee had no capability for spoken English. The text and audio streams are opened as supplementary streams. m=text 45020 RTP/AVP 103 104 m=audio 49250 RTP/AVP 20 m=video 51372 RTP/AVP 31 32 a=hlang-send: ase a=hlang-recv: ase ---end of change--- -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 --------------658743ECD68DC0B9772FA8E4 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Regarding the many review comments about the use of the asterisk parameter in draft-ietf-slim-negotiating-human-language, ( e.g. by Adam Roach on 28/3/2017) I propose the following change that both gives a meaning to the position of the asterisk and satisfies issue #26 with media preferences.

I propose to use this solution if there is a decision to not satisfy Issue #34, to use the Accept-Language syntax.:

--Change proposal - to draft version -10---

--First change--

in section 5.2

--old text-

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

-new text

   In an offer or answer, each value MAY have an asterisk appended as the final
   parameter.  An asterisk appended to a value in an offer indicates a
   that the caller has higher preference for the corresponding modality
 to be used in the specified direction than other modalities for the indicated 
direction without an asterisk. If no such preference is indicated in any hlang- 
attribute, it should be taken as a preference by the caller to get the call denied
if no languages are in common between the caller and the callee. 
In an answer, the asterisk indicates a modality that is preferred by the callee to be used in the session.

See Section 5.3 for more information and
   discussion.

--end of first change----

---second change----
In 5.3
----old text---


5.3.  No Language in Common

   A consideration with the ability to negotiate language is if the call
   proceeds or fails if the callee does not support any of the languages
   requested by the caller.  This document does not mandate either
   behavior, although it does provide a way for the caller to indicate a
   preference for the call succeeding when there is no language in
   common.  It is OPTIONAL for the callee to honor this preference.  For
   example, a PSAP is likely to attempt the call even without an
   indicated preference when there is no language in common, while a
   call center might choose to fail the call.

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

---New text ----


5.3. Preferred modality and action if no match

   A user may have a clear preference to use one specific modality in a 
   direction, while use of other modalities may be acceptable but lower in 
   preference. This condition MAY be indicated by appending an asterisk 
   as the last parameter in the corresponding humlang- value. This 
   indication should also be seen as a preference to not have the call
   denied even if no indicated languages are in common.

   When negotiating language use for a direction, languages and modalities
  specified together with the asterisk should be given preference to be selected for use.    

   No specific preference between modalities in the same direction should
   be indicated by appending an asterisk on all or no humlang- values for that direction. 

   If there is a preference for denying the call when no languages match, 
   then it is not possible to indicate any preferred modality at the same time.

   It is OPTIONAL for the callee to honor the preference for denying the call at no match.
   For example, a PSAP is likely to attempt the call even without an
   indicated preference when there is no language in common, while a
   call center might choose to fail the call.

   The called party MAY ignore the indication for denying the call, e.g.,
   for the emergency services use case,
   regardless of the absence of an asterisk, a PSAP will likely not fail
   the call; some call centers might reject a call in case of no matching language
   even if the offer contains an asterisk. 

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

---Change in 5.5----

---Add this text as a separate example e.g. last in 5.5---
   An offer requesting the following media streams: audio for the caller
   to send using spoken English (most preferred modality) or American 
   Sign Language (less preferred modality),
   audio for the caller to receive spoken English (most preferred modality) or
   American Sign Language (less preferred modality), 
   supplemental text.  The offer also requests that the
   call proceed even if the callee does not support any of the
   languages. The offer is likely from a hearing person with knowledge in sign language:

      m=text 45020 RTP/AVP 103 104

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

     m=video 51372 RTP/AVP 31 32
     a=hlang-recv: ase 
     a=hlang-send: ase

 An answer for the above offer, indicating video in which the callee will send and receive American Sign Language, because that callee had no capability for spoken English. The text and audio streams are opened as supplementary streams.

      m=text 45020 RTP/AVP 103 104
      
      m=audio 49250 RTP/AVP 20


      m=video 51372 RTP/AVP 31 32
      a=hlang-send: ase
      a=hlang-recv: ase
---end of change---






-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288
--------------658743ECD68DC0B9772FA8E4-- From nobody Wed May 31 06:57:41 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EF0912762F for ; Wed, 31 May 2017 06:57:40 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wLxqP5oOzxC3 for ; Wed, 31 May 2017 06:57:37 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 69EED129C0C for ; Wed, 31 May 2017 06:57:37 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Wed, 31 May 2017 06:59:53 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <149609884905.14640.4714137651572553743@ietfa.amsl.com> <54839aba-7ac8-79e4-74f8-927eb455d8af@omnitor.se> X-Mailer: Eudora for Mac OS X Date: Wed, 31 May 2017 06:57:31 -0700 To: Gunnar =?iso-8859-1?Q?Hellstr=F6m?= , slim@ietf.org From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Slim] I-D Action: draft-ietf-slim-negotiating-human-language-10.txt X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 13:57:40 -0000 At 10:58 AM +0200 5/31/17, Gunnar Hellstr=F6m wrote: > Randall, > > Your response on change proposal 2 caused a=20 > more thorough review of weak points in the=20 > reasoning in section 5.2. > > So, change 2 expanded to a number of=20 > sub-proposals that, when accepted, should=20 > result in less risk for mis-interpretations. > > See also the other comments. > > Thanks, > > Gunnar > > > Den 2017-05-31 kl. 01:56, skrev Randall Gellens: > >> At 10:51 PM +0200 5/30/17, Gunnar Hellstr=F6m wrote: >> >>> Randall, >>> >>> good to see progress. >>> >>> I have a few edit proposals: >>> >>> ---Change 1--- >>> >>> Last two lines of 1. Introduction >>> >>> When the draft is ready, it is no draft=20 >>> anymore. Plus divide the aspects in two=20 >>> sentences. >>> >>> ----old text--- >>> >>> To reduce the complexity of the solution, this draft focuses on >>> negotiating language per media; routing is out of scope. >>> >>> ---New text--- >>> >>> To keep the complexity of the solution low, this document focuses on >>> negotiating language per media. Routing aspects are out of scope. >>> >>> -- end of change 1. ---- >>> >> >> The use of "draft" was an error, I'll change=20 >> it to "document." I prefer the semicolon to=20 >> maintain the two parts since it has closer=20 >> linkage between the two than would a period. >> > Accepted. > >> >>> >>> ---Change 2 -- >>> >>> Last lines of 5.2 >>> >>> We must be clear about that the result=20 >>> normally is alternative languages to use,=20 >>> normally not simultaneously. Without this=20 >>> clarification, we are not better than the old=20 >>> SDP lang attribute. >>> >>> ---Old text --- >>> Note that media and language negotiation might result in more media >>> streams being accepted than are needed by the users (e.g., if more >>> preferred and less preferred combinations of media and language are >>> all accepted). This is not a problem. >>> >>> ---New text ---- >>> Without any further indications of=20 >>> preferences or requirements for simultaneity,=20 >>> the language indications should be seen as=20 >>> alternatives to select from. Media and=20 >>> language negotiation might result in more=20 >>> media streams and languages being accepted=20 >>> than are needed by the users >>> (e.g., if more preferred and less preferred=20 >>> combinations of media and language are >>> all accepted). >>> >>> ---End of change 2 --- >>> >> >> I don't think it's true that we're no better=20 >> off than the old SDP lang attribute, for=20 >> multiple reasons, not least of which is that=20 >> 'lang' is not used for negotiating language in=20 >> interactive media. Further, I think the result=20 >> of extra streams is that there are extra=20 >> streams that probably won't be used. >> > I just mean that it must be absolutely=20 > clear that the language indications for the=20 > same direction are alternatives to select from,=20 > and not an indication that they will be used=20 > simultaneously. (not until we have the=20 > extension sorted out that will indicate=20 > simultaneous use in specific cases). > > The problem we had with 'Lang' was that the=20 > intention was not absolutely clear if it was=20 > about alternatives or simultaneous usage. You=20 > read it one way and I read it another way. > > In 5.2 we still have wording that can be read=20 > as if offering or answering with two languages=20 > in the same direction will imply that the user=20 > is prepared to use both simultaneously. We must=20 > be sure that the normal case means that the=20 > languages are alternatives to select from. > > Multiple reviewers indicated that they had=20 > problems understanding our attributes. Some=20 > read it as if we have some pairing specified=20 > and others saw other relations that we have not=20 > intended. I think we need to take these=20 > warnings from independent readers and sort out=20 > any risk for mis-interpretation of our=20 > intentions. > > Making a new effort to sort this out completely in 5.2 gives us: > > --Change 2.1-- > --Old text 2.1-- > This document defines two media-level attributes starting with > 'hlang' (short for "human interactive language") to negotiate which > human language is used in each interactive media stream. > --New text 2.1--- > This document defines two media-level attributes starting with > 'hlang' (short for "human interactive language") to negotiate which > human language alternative(s) the users are=20 > prepared to use in each interactive media=20 > stream. I think the editorial clarifications have=20 resolved any potential confusion noted by the=20 previous reviewers. Further, the current wording=20 only discusses language per media, while the text=20 in 5.2 explicitly says that it's possible that=20 some media might not be used. I think the=20 combination makes it clear that there is=20 absolutely no expectation that users use all=20 languages since it clearly says they might not=20 use all media. I do not think the wording=20 "language alternative(s)" is good; I think it=20 introduces more confusion. However, I can change=20 "language is used" to "language is selected for=20 use" for clarity. > > > > --End of change 2.1--- > > --Old text 2.2--- > Each can appear in an offer for a media > stream. > --New text 2.2--- > Each can appear in an offer and answer for a media > stream. > > > --End of change 2.2--- > > ---Old text 2.3 --- > > In an offer, the 'hlang-send' value is a list of one or more > language(s) the offerer is willing to use when sending using the > media, and the 'hlang-recv' value is a list of one or more > language(s) the offerer is willing to use when receiving using the > media. > ----New text 2.3--- > In an offer, the 'hlang-send' value is a list of one or more > alternative language(s) the offerer is=20 > willing to use when sending using the > media, and the 'hlang-recv' value is a list of one or more > alternative language(s) the offerer is=20 > willing to use when receiving using the > media. > > > ---End of change 2.3--- > > ---Old text 2.4 --- > The list of languages is in preference order (first is most > preferred). > ---New text 2.4--- > The list of alternative languages is in preference order (first is mos= t > preferred). > > > ---End of change 2.4--- > > ---Change 2.5----- > Requiring exactly one language per direction in=20 > the answer requires a tight coupling between=20 > the device and the user that we have avoided to=20 > specify. It would require either that the=20 > device takes the negotiation decision and=20 > dictates to the user e.g. "SPEAK GERMAN NOW !,=20 > or that there is a user interface interaction=20 > to decide which language to answer in, e.g.=20 > "The calling part may accept French or German,=20 > indicate here which one you will answer with". > > We do not want to dictate that kind of tight=20 > coupling, and therefore must allow a number of=20 > alternative languages in various media to=20 > appear in the answer. > > ---Old text 2.5--- > In an answer, 'hlang-send' is the language the answerer will send > when using the media (which in most cases is one of the languages in > the offer's 'hlang-recv'), and 'hlang-recv' is the language the > answerer expects to receive in the media (which in most cases is one > of the languages in the offer's 'hlang-send'). > ---New text 2.5--- > In an answer, 'hlang-send' may be one or a list of alternative languages= the > answerer will select from for sending if using the media for language > (which in most cases is one of the languages in the offer's 'hlang-recv')= , > and 'hlang-recv' may be one or a list of alternative languages the answer= er > can accept to receive if the media is used for=20 > language (which in most cases is one > of the languages in the offer's 'hlang-send'). Having one language per media in the answer has=20 been part of the draft all along. I don't recall=20 seeing an objection to this before. Further,=20 Section 3 has said all along that attempting to=20 negotiate multiple languages per media is out of=20 scope: (Negotiating multiple simultaneous languages within a media stream is out of scope of this document.) > > > ---End of change 2.5 > > ---Old text 2.6--- > > When placing an emergency call, and in any other case where the > language cannot be inferred from context, in an offer each media > stream primarily intended for human language communication SHOULD > specify both (or for asymmetrical language use, one of) the 'hlang- > send' and 'hlang-recv' attributes. > ---New text 2.6--- > When placing an emergency call, and in any other case where the > language cannot be inferred from context, in an offer each media > stream primarily intended as an alternative=20 > for human language communication SHOULD > specify both (or for asymmetrical language use, one of) the 'hlang- > send' and 'hlang-recv' attributes. I don't think this text is needed. A stream can=20 be negotiated as being intended for human=20 interactive communication but the text says the=20 stream might not be used. > > > --End of change 2.6--- > > > ---Old text 2.7--- > Clients acting on behalf of end users are expected to set one or both > 'hlang-send' and 'hlang-recv' attributes on each media stream > primarily intended for human communication in an offer when placing > an outgoing session, > ---New text 2.7--- > Clients acting on behalf of end users are expected to set one or both > 'hlang-send' and 'hlang-recv' attributes on each media stream > primarily intended as an alternative for=20 > human communication in an offer when placing > an outgoing session, I don't think this text is needed. A stream can=20 be negotiated as being intended for human=20 interactive communication but the text says the=20 stream might not be used. > > > ---End of change 2.7--- > > ---Old text 2.8--- > > Note that media and language negotiation might result in more media > streams being accepted than are needed by the users (e.g., if more > preferred and less preferred combinations of media and language are > all accepted). This is not a problem. > ---New text 2.8--- > Media and language negotiation might result in more media > streams and language alternatives being accepted than are needed by > the users (e.g., if more preferred and less preferred combinations > of media and language are all accepted). The users are expected to > sort out which media and language alternatives to really use in the > session, possibly supported by using refined indications. If you think such text is needed, I suggest=20 putting in a separate document containing advice=20 to implementers, where you can go into detail on=20 how the indications function. > > > ---End of change 2.8---- > >> >>> >>> ---Change 3--- >>> >>> In 5.3 >>> >>> sharpen up the description on how to use the=20 >>> asterisk. The current description confused=20 >>> most reviewers. >>> >>> ---old text---- >>> >>> The mechanism for indicating this preference is that, in an offer, if >>> the last value of either 'hlang-recv' or 'hlang-send' is an asterisk, >>> this indicates a request to not fail the call. >>> >>> ---new text--- >>> The mechanism for indicating this preference is that, in an offer, if >>> the last parameter of any 'hlang-recv' or=20 >>> 'hlang-send' value in the whole SDP >>> is an asterisk, this indicates a request to not fail the call. >>> >>> ---end of change 3--- >>> >> >> I think it's more clear to word it as so: >> >> The mechanism for indicating this preference is that, in an offer, if >> the last value of any 'hlang-recv' or 'hlang-send' for any media is >> an asterisk, this indicates a request to not fail the call. The >> called party MAY ignore the indication, e.g., for the emergency >> services use case, regardless of the absence of an asterisk, a PSAP >> will likely not fail the call; some call centers might reject a call >> even if the offer contains an asterisk. >> > The important part was to change from=20 > "either" to "any", so that is good. > > But we should also be strict about what we call=20 > the parts of the attribute values. > I prefer to call the whole string after=20 > 'hlang-recv:" or 'hlang-send:' the "value", and=20 > the separate language tags or asterisk then=20 > being "parameters" of that value. I think it is=20 > inconsistent to say that "the last value of the=20 > attribute value" may be an asterisk. Better to=20 > say that "the last parameter of the value" may=20 > be an asterisk. > > (I will return to the asterisk with a separate=20 > proposal for how to use its placement for=20 > something useful.) Such proposal should go in a separate document=20 containing advice to implementers. > >> >>> >>> ----Change 4--- >>> >>> In 5.5, >>> >>> Some example shows use of sign language one way and text the other. >>> >>> ---Old text---- >>> >>> Note that, even though the examples all show the same language >>> >>> --New text---- >>> Note that, even though most examples show the same language >>> >>> ---End of change 4---- >>> >> >> The text does say "(even when the modality=20 >> differs)" to cover this, but for=20 >> clarification, I can delete "all" and add "(or=20 >> essentially the same)": >> > I think of the case when a deaf-blind=20 > person prefers to send a sign language and=20 > receive a written language. These languages do=20 > not have the same language tags even if they=20 > are used in the same geographic region. Yes, the language tags are different between the=20 spoken/written form of a language and the signed=20 form. That's what the "essentially the same"=20 means. Can you suggest a better description of=20 the commonality between these forms? > > We also have the working cases when I accept to=20 > receive Norweigan but speak Swedish myself, or=20 > someone accepting to receive Italian, but want=20 > to speak Spanish themselves, and other similar=20 > language mixes. These cases will more likely be=20 > satisfied not by true language matching, but by=20 > never using the request to fail the call, and=20 > let the users sort out the communication with=20 > some guidance from the indications. (both=20 > seeing what the other party expects will=20 > prepare them for the a bit unusual language=20 > mix.) > > Your proposed change will work for these cases. Accepted. > >> >> Note that, even though the examples show the same (or essentially the >> same) language being used in both directions (even when the modality >> differs), there is no requirement that this be the case. However, in >> practice, doing so is likely to increase the chances of successful >> matching. >> > ---Change 5--- > >>> >>> In 6.1. >>> >>> SDP values are UTF-8 coded, not ASCII. >>> >>> ---Old text--- >>> >>> >>> >>> asterisk =3D "*" ; an asterisk (ASCII %2A) character >>> >>> sp =3D 1*" " ; one or more ASCII space (%20) characters >>> >>> ---New text--- >>> >>> >>> asterisk =3D "*" ; an asterisk (%x2A) character >>> >>> SP =3D 1*" " ; one or more space (%x20) characters >>> >>> --End of change 5 ---- >>> >> >> I'll change "ASCII %" to "0x" for clarity. >> > Note also the change from "sp" to "SP" Thanks, fixed. > >> >>> >>> -- >>> >>> Regards >>> Gunnar >>> >>> >>> Den 2017-05-30 kl. 01:00, skrev=20 >>> internet-drafts@ietf.org: >>> >>>> >>>> A New Internet-Draft is available from the=20 >>>> on-line Internet-Drafts directories. >>>> This draft is a work item of the Selection=20 >>>> of Language for Internet Media of the IETF. >>>> >>>> Title : Negotiating Human Language in Real-Time Communications >>>> Author : Randall Gellens >>>> Filename : draft-ietf-slim-negotiating-human-language-10.txt >>>> Pages : 17 >>>> Date : 2017-05-29 >>>> >>>> Abstract: >>>> Users have various human (natural) language needs, abilities, and >>>> preferences regarding spoken, written, and signed languages. This >>>> document adds new SDP media-level attributes so that when >>>> establishing interactive communication sessions ("calls"), it is >>>> possible to negotiate (communicate and match) the caller's language >>>> and media needs with the capabilities of the called party. This is >>>> especially important with emergency calls, where a call can be >>>> handled by a call taker capable of communicating with the user, or a >>>> translator or relay operator can be bridged into the call during >>>> setup, but this applies to non-emergency calls as well (as an >>>> example, when calling a company call center). >>>> >>>> This document describes the need and a solution using new SDP media >>>> attributes. >>>> >>>> >>>> The IETF datatracker status page for this draft is: >>>> >>>>=20 >>>> https://datatracker.ietf.org/doc/draft-ietf-slim-negotiating-huma= n-language/ >>>> >>>> There are also htmlized versions available at: >>>> >>>>=20 >>>> https://tools.ietf.org/html/draft-ietf-slim-negotiating-human-language-10 >>>> >>>>=20 >>>> https://datatracker.ietf.org/doc/html/draft-= ietf-slim-negotiating-human-language-10 >>>> >>>> A diff from the previous version is available at: >>>> >>>>=20 >>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sli= m-negotiating-human-language-10 >>>> >>>> >>>> Please note that it may take a couple of=20 >>>> minutes from the time of submission >>>> until the htmlized version and diff are available at tools.ietf.org. >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>>=20 >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> _______________________________________________ >>>> SLIM mailing list >>>>=20 >>>> SLIM@= ietf.org >>>> >>>>=20 >>>> https://www.iet= f.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/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: --------------- When bad men combine, the good must associate; else they will fall, one by one, an unpitied sacrifice in a contemptible struggle. --Edmund Burke (1729-1797) From nobody Wed May 31 06:58:40 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8DDD129B8C for ; Wed, 31 May 2017 06:58:37 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r88N5nt8p54I for ; Wed, 31 May 2017 06:58:36 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 3975C12762F for ; Wed, 31 May 2017 06:58:36 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Wed, 31 May 2017 07:00:52 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <149609884905.14640.4714137651572553743@ietfa.amsl.com> <54839aba-7ac8-79e4-74f8-927eb455d8af@omnitor.se> X-Mailer: Eudora for Mac OS X Date: Wed, 31 May 2017 06:58:30 -0700 To: Gunnar =?iso-8859-1?Q?Hellstr=F6m?= , slim@ietf.org From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Slim] New wording for the use of the asterisk in draft-ietf-slim-negotiating-human-language X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 13:58:38 -0000 This text should go in a separate document containing advice to implementers= =2E At 3:24 PM +0200 5/31/17, Gunnar Hellstr=F6m wrote: > Regarding the many review comments about the=20 > use of the asterisk parameter in=20 > draft-ietf-slim-negotiating-human-language, (=20 > e.g. by Adam Roach on 28/3/2017) I propose the=20 > following change that both gives a meaning to=20 > the position of the asterisk and satisfies=20 > issue #26 with media preferences. > > I propose to use this solution if there is a=20 > decision to not satisfy Issue #34, to use the=20 > Accept-Language syntax.: > > --Change proposal - to draft version -10--- > > --First change-- > > in section 5.2 > > --old text- > > In an offer, each value MAY have an asterisk appended as the final > value. An asterisk appended to either value in an offer indicates a > request by the caller to the callee to not fail the call if there is > no language in common. See Section 5.3 for more information and > discussion. > > -new text > > In an offer or answer, each value MAY have=20 > an asterisk appended as the final > parameter. An asterisk appended to a value in an offer indicates a > that the caller has higher preference for the corresponding modality > to be used in the specified direction than=20 > other modalities for the indicated > direction without an asterisk. If no such=20 > preference is indicated in any hlang- > attribute, it should be taken as a preference=20 > by the caller to get the call denied > if no languages are in common between the caller and the callee. > In an answer, the asterisk indicates a modality=20 > that is preferred by the callee to be used in=20 > the session. > > See Section 5.3 for more information and > discussion. > > --end of first change---- > > ---second change---- > In 5.3 > ----old text--- > > > 5.3. No Language in Common > > A consideration with the ability to negotiate language is if the call > proceeds or fails if the callee does not support any of the languages > requested by the caller. This document does not mandate either > behavior, although it does provide a way for the caller to indicate a > preference for the call succeeding when there is no language in > common. It is OPTIONAL for the callee to honor this preference. For > example, a PSAP is likely to attempt the call even without an > indicated preference when there is no language in common, while a > call center might choose to fail the call. > > The mechanism for indicating this preference is that, in an offer, if > the last value of either 'hlang-recv' or 'hlang-send' is an asterisk, > this indicates a request to not fail the call. The called party MAY > ignore the indication, e.g., for the emergency services use case, > regardless of the absence of an asterisk, a PSAP will likely not fail > the call; some call centers might reject a call even if the offer > contains an asterisk. > > ---New text ---- > > > 5.3. Preferred modality and action if no match > > A user may have a clear preference to use one specific modality in a > direction, while use of other modalities may be acceptable but lower i= n > preference. This condition MAY be indicated by appending an asterisk > as the last parameter in the corresponding humlang- value. This > indication should also be seen as a preference to not have the call > denied even if no indicated languages are in common. > > When negotiating language use for a direction, languages and modalitie= s > specified together with the asterisk should=20 > be given preference to be selected for use. > > No specific preference between modalities in the same direction should > be indicated by appending an asterisk on all=20 > or no humlang- values for that direction. > > If there is a preference for denying the call when no languages match, > then it is not possible to indicate any=20 > preferred modality at the same time. > > It is OPTIONAL for the callee to honor the=20 > preference for denying the call at no match. > For example, a PSAP is likely to attempt the call even without an > indicated preference when there is no language in common, while a > call center might choose to fail the call. > > The called party MAY ignore the indication for denying the call, e.g., > for the emergency services use case, > regardless of the absence of an asterisk, a PSAP will likely not fail > the call; some call centers might reject a=20 > call in case of no matching language > even if the offer contains an asterisk. > > -----end of change ------------------ > > ---Change in 5.5---- > > ---Add this text as a separate example e.g. last in 5.5--- > An offer requesting the following media streams: audio for the caller > to send using spoken English (most preferred modality) or American > Sign Language (less preferred modality), > audio for the caller to receive spoken=20 > English (most preferred modality) or > American Sign Language (less preferred modality), > supplemental text. The offer also requests that the > call proceed even if the callee does not support any of the > languages. The offer is likely from a=20 > hearing person with knowledge in sign language: > > m=3Dtext 45020 RTP/AVP 103 104 > > m=3Daudio 49250 RTP/AVP 20 > a=3Dhlang-recv:en * > a=3Dhlang-send:en * > > m=3Dvideo 51372 RTP/AVP 31 32 > a=3Dhlang-recv: ase > a=3Dhlang-send: ase > > An answer for the above offer, indicating=20 > video in which the callee will send and receive=20 > American Sign Language, because that callee had=20 > no capability for spoken English. The text and=20 > audio streams are opened as supplementary=20 > streams. > > m=3Dtext 45020 RTP/AVP 103 104 > > m=3Daudio 49250 RTP/AVP 20 > > > m=3Dvideo 51372 RTP/AVP 31 32 > a=3Dhlang-send: ase > a=3Dhlang-recv: ase > ---end of change--- > > > > > > -- > ----------------------------------------- > 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: --------------- He had that rare weird electricity about him -- that extremely wild and heavy presence that you only see in a person who has abandoned all hope of ever behaving "normally." --Hunter S. Thompson, "Fear and Loathing '72" From nobody Wed May 31 12:23:50 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9216812422F for ; Wed, 31 May 2017 12:23:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id giA4TWzepkaJ for ; Wed, 31 May 2017 12:23:42 -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 960E012943B for ; Wed, 31 May 2017 12:23:41 -0700 (PDT) X-Halon-ID: a2a8c71d-4636-11e7-bca7-0050569116f7 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [77.53.231.21]) by bin-vsp-out-03.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Wed, 31 May 2017 21:23:32 +0200 (CEST) To: Randall Gellens , slim@ietf.org References: <149609884905.14640.4714137651572553743@ietfa.amsl.com> <54839aba-7ac8-79e4-74f8-927eb455d8af@omnitor.se> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: Date: Wed, 31 May 2017 21:23:28 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------48B5D79EE6351D27E2DD18F6" Archived-At: Subject: Re: [Slim] I-D Action: draft-ietf-slim-negotiating-human-language-10.txt X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 19:23:49 -0000 This is a multi-part message in MIME format. --------------48B5D79EE6351D27E2DD18F6 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Den 2017-05-31 kl. 15:57, skrev Randall Gellens: > At 10:58 AM +0200 5/31/17, Gunnar Hellström wrote: > >> Randall, >> >> Your response on change proposal 2 caused a more thorough review of >> weak points in the reasoning in section 5.2. >> >> So, change 2 expanded to a number of sub-proposals that, when >> accepted, should result in less risk for mis-interpretations. >> >> See also the other comments. >> >> Thanks, >> >> Gunnar >> >> >> Den 2017-05-31 kl. 01:56, skrev Randall Gellens: >> >>> At 10:51 PM +0200 5/30/17, Gunnar Hellström wrote: >>> >>>> Randall, >>>> >>>> good to see progress. >>>> >>>> I have a few edit proposals: >>>> >>>> ---Change 1--- >>>> >>>> Last two lines of 1. Introduction >>>> >>>> When the draft is ready, it is no draft anymore. Plus divide the >>>> aspects in two sentences. >>>> >>>> ----old text--- >>>> >>>> To reduce the complexity of the solution, this draft focuses on >>>> negotiating language per media; routing is out of scope. >>>> >>>> ---New text--- >>>> >>>> To keep the complexity of the solution low, this document focuses on >>>> negotiating language per media. Routing aspects are out of scope. >>>> >>>> -- end of change 1. ---- >>>> >>> >>> The use of "draft" was an error, I'll change it to "document." I >>> prefer the semicolon to maintain the two parts since it has closer >>> linkage between the two than would a period. >>> >> Accepted. >> >>> >>>> >>>> ---Change 2 -- >>>> >>>> Last lines of 5.2 >>>> >>>> We must be clear about that the result normally is alternative >>>> languages to use, normally not simultaneously. Without this >>>> clarification, we are not better than the old SDP lang attribute. >>>> >>>> ---Old text --- >>>> Note that media and language negotiation might result in more media >>>> streams being accepted than are needed by the users (e.g., if more >>>> preferred and less preferred combinations of media and language are >>>> all accepted). This is not a problem. >>>> >>>> ---New text ---- >>>> Without any further indications of preferences or requirements for >>>> simultaneity, the language indications should be seen as >>>> alternatives to select from. Media and language negotiation might >>>> result in more media streams and languages being accepted than are >>>> needed by the users >>>> (e.g., if more preferred and less preferred combinations of media >>>> and language are >>>> all accepted). >>>> >>>> ---End of change 2 --- >>>> >>> >>> I don't think it's true that we're no better off than the old SDP >>> lang attribute, for multiple reasons, not least of which is that >>> 'lang' is not used for negotiating language in interactive media. >>> Further, I think the result of extra streams is that there are extra >>> streams that probably won't be used. >>> >> I just mean that it must be absolutely clear that the language >> indications for the same direction are alternatives to select from, >> and not an indication that they will be used simultaneously. (not >> until we have the extension sorted out that will indicate >> simultaneous use in specific cases). >> >> The problem we had with 'Lang' was that the intention was not >> absolutely clear if it was about alternatives or simultaneous usage. >> You read it one way and I read it another way. >> >> In 5.2 we still have wording that can be read as if offering or >> answering with two languages in the same direction will imply that >> the user is prepared to use both simultaneously. We must be sure that >> the normal case means that the languages are alternatives to select >> from. >> >> Multiple reviewers indicated that they had problems understanding >> our attributes. Some read it as if we have some pairing specified and >> others saw other relations that we have not intended. I think we need >> to take these warnings from independent readers and sort out any risk >> for mis-interpretation of our intentions. >> >> Making a new effort to sort this out completely in 5.2 gives us: >> >> --Change 2.1-- >> --Old text 2.1-- >> This document defines two media-level attributes starting with >> 'hlang' (short for "human interactive language") to negotiate which >> human language is used in each interactive media stream. >> --New text 2.1--- >> This document defines two media-level attributes starting with >> 'hlang' (short for "human interactive language") to negotiate which >> human language alternative(s) the users are prepared to use in >> each interactive media stream. > > I think the editorial clarifications have resolved any potential > confusion noted by the previous reviewers. Further, the current > wording only discusses language per media, while the text in 5.2 > explicitly says that it's possible that some media might not be used. > I think the combination makes it clear that there is absolutely no > expectation that users use all languages since it clearly says they > might not use all media. I do not think the wording "language > alternative(s)" is good; I think it introduces more confusion. > However, I can change "language is used" to "language is selected for > use" for clarity. Accepted > >> >> >> >> --End of change 2.1--- >> >> --Old text 2.2--- >> Each can appear in an offer for a media >> stream. >> --New text 2.2--- >> Each can appear in an offer and answer for a media >> stream. >> >> >> --End of change 2.2--- >> >> ---Old text 2.3 --- >> >> In an offer, the 'hlang-send' value is a list of one or more >> language(s) the offerer is willing to use when sending using the >> media, and the 'hlang-recv' value is a list of one or more >> language(s) the offerer is willing to use when receiving using the >> media. >> ----New text 2.3--- >> In an offer, the 'hlang-send' value is a list of one or more >> alternative language(s) the offerer is willing to use when >> sending using the >> media, and the 'hlang-recv' value is a list of one or more >> alternative language(s) the offerer is willing to use when >> receiving using the >> media. >> >> >> ---End of change 2.3--- >> >> ---Old text 2.4 --- >> The list of languages is in preference order (first is most >> preferred). >> ---New text 2.4--- >> The list of alternative languages is in preference order (first >> is most >> preferred). >> >> >> ---End of change 2.4--- Did you accept 2.2, 2.3, 2.4 ? >> >> ---Change 2.5----- >> Requiring exactly one language per direction in the answer requires >> a tight coupling between the device and the user that we have avoided >> to specify. It would require either that the device takes the >> negotiation decision and dictates to the user e.g. "SPEAK GERMAN NOW >> !, or that there is a user interface interaction to decide which >> language to answer in, e.g. "The calling part may accept French or >> German, indicate here which one you will answer with". >> >> We do not want to dictate that kind of tight coupling, and therefore >> must allow a number of alternative languages in various media to >> appear in the answer. >> >> ---Old text 2.5--- >> In an answer, 'hlang-send' is the language the answerer will send >> when using the media (which in most cases is one of the languages in >> the offer's 'hlang-recv'), and 'hlang-recv' is the language the >> answerer expects to receive in the media (which in most cases is one >> of the languages in the offer's 'hlang-send'). >> ---New text 2.5--- >> In an answer, 'hlang-send' may be one or a list of alternative >> languages the >> answerer will select from for sending if using the media for language >> (which in most cases is one of the languages in the offer's >> 'hlang-recv'), >> and 'hlang-recv' may be one or a list of alternative languages the >> answerer >> can accept to receive if the media is used for language (which in >> most cases is one >> of the languages in the offer's 'hlang-send'). > > Having one language per media in the answer has been part of the draft > all along. I don't recall seeing an objection to this before. > Further, Section 3 has said all along that attempting to negotiate > multiple languages per media is out of scope: > > (Negotiating multiple simultaneous languages within a media stream is > out of scope of this document.) Yes, the user will only use one language. But have you thought about the consequences for how to accomplish a negotiation result of just one language in a media, and just that language will also be used by the answering human? It will require tight coupling in the user interface of a kind that you do not want to discuss. If the UA decides that the answering part will send spoken german, then that needs to be conveyed to the user. If the UA instead lets the user decide, then there must be a question-answer exchange between the UA and the user to enable the UA to have just one language for the media in the answer. We have agreed that some kind of such coupling is needed, and we do not specify how. But the requirements on the operation will be much less strict if we allow a list of languages per media to be the result of the negotiation. The paranthesis " (Negotiating multiple simultaneous languages within a media stream is out of scope of this document.) " will then apply to the user. This is a quite new finding from when trying to think through a real negotiation, so I am prepared to discuss how strict we should be. > >> >> >> ---End of change 2.5 >> >> ---Old text 2.6--- >> >> When placing an emergency call, and in any other case where the >> language cannot be inferred from context, in an offer each media >> stream primarily intended for human language communication SHOULD >> specify both (or for asymmetrical language use, one of) the 'hlang- >> send' and 'hlang-recv' attributes. >> ---New text 2.6--- >> When placing an emergency call, and in any other case where the >> language cannot be inferred from context, in an offer each media >> stream primarily intended as an alternative for human language >> communication SHOULD >> specify both (or for asymmetrical language use, one of) the 'hlang- >> send' and 'hlang-recv' attributes. > > I don't think this text is needed. A stream can be negotiated as > being intended for human interactive communication but the text says > the stream might not be used. I think "primarily intended for human language communication" is a quite strong indication that the purpose is to use it. I wanted to reduce that impression by inserting the "as an alternative". > >> >> >> --End of change 2.6--- >> >> >> ---Old text 2.7--- >> Clients acting on behalf of end users are expected to set one or both >> 'hlang-send' and 'hlang-recv' attributes on each media stream >> primarily intended for human communication in an offer when placing >> an outgoing session, >> ---New text 2.7--- >> Clients acting on behalf of end users are expected to set one or both >> 'hlang-send' and 'hlang-recv' attributes on each media stream >> primarily intended as an alternative for human communication in >> an offer when placing >> an outgoing session, > > I don't think this text is needed. A stream can be negotiated as > being intended for human interactive communication but the text says > the stream might not be used. Again - "intended" is strong and may need to be weakened to indicate that it might not be used. > > >> >> >> ---End of change 2.7--- >> >> ---Old text 2.8--- >> >> Note that media and language negotiation might result in more media >> streams being accepted than are needed by the users (e.g., if more >> preferred and less preferred combinations of media and language are >> all accepted). This is not a problem. >> ---New text 2.8--- >> Media and language negotiation might result in more media >> streams and language alternatives being accepted than are needed by >> the users (e.g., if more preferred and less preferred combinations >> of media and language are all accepted). The users are expected to >> sort out which media and language alternatives to really use in the >> session, possibly supported by using refined indications. > > If you think such text is needed, I suggest putting in a separate > document containing advice to implementers, where you can go into > detail on how the indications function. You may delete the last phrase after the comma. The remaining part describes better the real situation than the current text. We take the discussion about refined indications separately. > >> >> >> ---End of change 2.8---- >> >>> >>>> >>>> ---Change 3--- >>>> >>>> In 5.3 >>>> >>>> sharpen up the description on how to use the asterisk. The current >>>> description confused most reviewers. >>>> >>>> ---old text---- >>>> >>>> The mechanism for indicating this preference is that, in an offer, if >>>> the last value of either 'hlang-recv' or 'hlang-send' is an asterisk, >>>> this indicates a request to not fail the call. >>>> >>>> ---new text--- >>>> The mechanism for indicating this preference is that, in an offer, if >>>> the last parameter of any 'hlang-recv' or 'hlang-send' value in >>>> the whole SDP >>>> is an asterisk, this indicates a request to not fail the call. >>>> >>>> ---end of change 3--- >>>> >>> >>> I think it's more clear to word it as so: >>> >>> The mechanism for indicating this preference is that, in an offer, if >>> the last value of any 'hlang-recv' or 'hlang-send' for any media is >>> an asterisk, this indicates a request to not fail the call. The >>> called party MAY ignore the indication, e.g., for the emergency >>> services use case, regardless of the absence of an asterisk, a PSAP >>> will likely not fail the call; some call centers might reject a call >>> even if the offer contains an asterisk. >>> >> The important part was to change from "either" to "any", so >> that is good. >> >> But we should also be strict about what we call the parts of the >> attribute values. >> I prefer to call the whole string after 'hlang-recv:" or >> 'hlang-send:' the "value", and the separate language tags or asterisk >> then being "parameters" of that value. I think it is inconsistent to >> say that "the last value of the attribute value" may be an asterisk. >> Better to say that "the last parameter of the value" may be an asterisk. Did you accept to call the language tags and the asterisk "parameters" of the value, instead of values in the value? >> >> (I will return to the asterisk with a separate proposal for how to >> use its placement for something useful.) > > Such proposal should go in a separate document containing advice to > implementers. > >> >>> >>>> >>>> ----Change 4--- >>>> >>>> In 5.5, >>>> >>>> Some example shows use of sign language one way and text the other. >>>> >>>> ---Old text---- >>>> >>>> Note that, even though the examples all show the same language >>>> >>>> --New text---- >>>> Note that, even though most examples show the same language >>>> >>>> ---End of change 4---- >>>> >>> >>> The text does say "(even when the modality differs)" to cover this, >>> but for clarification, I can delete "all" and add "(or essentially >>> the same)": >>> >> I think of the case when a deaf-blind person prefers to send a >> sign language and receive a written language. These languages do not >> have the same language tags even if they are used in the same >> geographic region. > > Yes, the language tags are different between the spoken/written form > of a language and the signed form. That's what the "essentially the > same" means. Can you suggest a better description of the commonality > between these forms? I think "essentially the same" will do. It can mean "in most cases the same" as well as "close to the same". > >> >> We also have the working cases when I accept to receive Norweigan >> but speak Swedish myself, or someone accepting to receive Italian, >> but want to speak Spanish themselves, and other similar language >> mixes. These cases will more likely be satisfied not by true language >> matching, but by never using the request to fail the call, and let >> the users sort out the communication with some guidance from the >> indications. (both seeing what the other party expects will prepare >> them for the a bit unusual language mix.) >> >> Your proposed change will work for these cases. Accepted. >> >>> >>> Note that, even though the examples show the same (or essentially the >>> same) language being used in both directions (even when the modality >>> differs), there is no requirement that this be the case. However, in >>> practice, doing so is likely to increase the chances of successful >>> matching. >>> >> ---Change 5--- >> >>>> >>>> In 6.1. >>>> >>>> SDP values are UTF-8 coded, not ASCII. >>>> >>>> ---Old text--- >>>> >>>> >>>> >>>> asterisk = "*" ; an asterisk (ASCII %2A) character >>>> >>>> sp = 1*" " ; one or more ASCII space (%20) characters >>>> >>>> ---New text--- >>>> >>>> >>>> asterisk = "*" ; an asterisk (%x2A) character >>>> >>>> SP = 1*" " ; one or more space (%x20) characters >>>> >>>> --End of change 5 ---- >>>> >>> >>> I'll change "ASCII %" to "0x" for clarity. >>> >> Note also the change from "sp" to "SP" > > Thanks, fixed. Thanks, Gunnar > >> >>> >>>> >>>> -- >>>> >>>> Regards >>>> Gunnar >>>> >>>> >>>> Den 2017-05-30 kl. 01:00, skrev >>>> internet-drafts@ietf.org: >>>> >>>>> >>>>> A New Internet-Draft is available from the on-line >>>>> Internet-Drafts directories. >>>>> This draft is a work item of the Selection of Language for >>>>> Internet Media of the IETF. >>>>> >>>>> Title : Negotiating Human Language in Real-Time Communications >>>>> Author : Randall Gellens >>>>> Filename : draft-ietf-slim-negotiating-human-language-10.txt >>>>> Pages : 17 >>>>> Date : 2017-05-29 >>>>> >>>>> Abstract: >>>>> Users have various human (natural) language needs, abilities, and >>>>> preferences regarding spoken, written, and signed languages. This >>>>> document adds new SDP media-level attributes so that when >>>>> establishing interactive communication sessions ("calls"), it is >>>>> possible to negotiate (communicate and match) the caller's language >>>>> and media needs with the capabilities of the called party. This is >>>>> especially important with emergency calls, where a call can be >>>>> handled by a call taker capable of communicating with the user, or a >>>>> translator or relay operator can be bridged into the call during >>>>> setup, but this applies to non-emergency calls as well (as an >>>>> example, when calling a company call center). >>>>> >>>>> This document describes the need and a solution using new SDP media >>>>> attributes. >>>>> >>>>> >>>>> The IETF datatracker status page for this draft is: >>>>> >>>>> >>>>> https://datatracker.ietf.org/doc/draft-ietf-slim-negotiating-human-language/ >>>>> >>>>> >>>>> There are also htmlized versions available at: >>>>> >>>>> >>>>> https://tools.ietf.org/html/draft-ietf-slim-negotiating-human-language-10 >>>>> >>>>> >>>>> >>>>> https://datatracker.ietf.org/doc/html/draft-ietf-slim-negotiating-human-language-10 >>>>> >>>>> >>>>> A diff from the previous version is available at: >>>>> >>>>> >>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-slim-negotiating-human-language-10 >>>>> >>>>> >>>>> >>>>> Please note that it may take a couple of minutes from the time of >>>>> submission >>>>> until the htmlized version and diff are available at tools.ietf.org. >>>>> >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>> >>>>> >>>>> _______________________________________________ >>>>> SLIM mailing list >>>>> >>>>> SLIM@ietf.org >>>>> >>>>> >>>>> >>>>> https://www.ietf.org/mailman/listinfo/slim >>>>> >>>>> >>>> >>>> -- >>>> ----------------------------------------- >>>> Gunnar Hellström >>>> Omnitor >>>> >>>> gunnar.hellstrom@omnitor.se >>>> >>>> +46 708 204 288 >>>> >>>> _______________________________________________ >>>> SLIM mailing list >>>> SLIM@ietf.org >>>> >>>> https://www.ietf.org/mailman/listinfo/slim >>>> >>>> >>> >>> >> >> -- >> ----------------------------------------- >> Gunnar Hellström >> Omnitor >> gunnar.hellstrom@omnitor.se >> +46 708 204 288 >> >> _______________________________________________ >> SLIM mailing list >> SLIM@ietf.org >> https://www.ietf.org/mailman/listinfo/slim > > -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 --------------48B5D79EE6351D27E2DD18F6 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Den 2017-05-31 kl. 15:57, skrev Randall Gellens:
At 10:58 AM +0200 5/31/17, Gunnar Hellström wrote:

 Randall,

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

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

 See also the other comments.

 Thanks,

 Gunnar


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

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

 Randall,

 good to see progress.

 I have a few edit proposals:

 ---Change 1---

 Last two lines of 1. Introduction

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

 ----old text---

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

 ---New text---

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

 -- end of change 1. ----


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

 <GH>Accepted.



 ---Change 2 --

 Last lines of 5.2

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

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

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

 ---End of change 2 ---


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

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

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

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

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

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

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

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




 --End of change 2.1---

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


 --End of change 2.2---

 ---Old text 2.3 ---

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


 ---End of change 2.3---

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


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

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

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

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

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

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

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

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

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


This is a quite new finding from when trying to think through a real negotiation, so I am prepared to discuss how strict we should be.

 



 ---End of change 2.5

 ---Old text 2.6---

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

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



 --End of change 2.6---


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

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




 ---End of change 2.7---

 ---Old text 2.8---

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

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

 



 ---End of change 2.8----



 ---Change 3---

 In 5.3

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

 ---old text----

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

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

 ---end of change 3---


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

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

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

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

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

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




 ----Change 4---

 In 5.5,

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

 ---Old text----

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

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

 ---End of change 4----


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

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

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


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

 Your proposed change will work for these cases. Accepted.


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

 ---Change 5---


 In 6.1.

 SDP values are UTF-8 coded, not ASCII.

 ---Old text---



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

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

 ---New text---


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

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

 --End of change 5 ----


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

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

Thanks, fixed.

Thanks,
Gunnar




 --

 Regards
 Gunnar


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


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

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

 Abstract:
 Users have various human (natural) language needs, abilities, and
 preferences regarding spoken, written, and signed languages. This
 document adds new SDP media-level attributes so that when
 establishing interactive communication sessions ("calls"), it is
 possible to negotiate (communicate and match) the caller's language
 and media needs with the capabilities of the called party. This is
 especially important with emergency calls, where a call can be
 handled by a call taker capable of communicating with the user, or a
 translator or relay operator can be bridged into the call during
 setup, but this applies to non-emergency calls as well (as an
 example, when calling a company call center).

 This document describes the need and a solution using new SDP media
 attributes.


 The IETF datatracker status page for this draft is:


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

 There are also htmlized versions available at:


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


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

 A diff from the previous version is available at:


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


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

 Internet-Drafts are also available by anonymous FTP at:

<ftp://ftp.ietf.org/internet-drafts/><ftp://ftp.ietf.org/internet-drafts/><ftp://ftp.ietf.org/internet-drafts/>ftp://ftp.ietf.org/internet-drafts/

 _______________________________________________
 SLIM mailing list

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


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


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

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

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

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




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

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



-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288
--------------48B5D79EE6351D27E2DD18F6-- From nobody Wed May 31 12:31:33 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEB8512711E for ; Wed, 31 May 2017 12:31:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ol_m6AM907nz for ; Wed, 31 May 2017 12:31:29 -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 55EA5124217 for ; Wed, 31 May 2017 12:31:29 -0700 (PDT) X-Halon-ID: bc67692c-4637-11e7-bcc3-005056917f90 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [77.53.231.21]) by bin-vsp-out-02.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Wed, 31 May 2017 21:31:25 +0200 (CEST) To: Randall Gellens , slim@ietf.org References: <149609884905.14640.4714137651572553743@ietfa.amsl.com> <54839aba-7ac8-79e4-74f8-927eb455d8af@omnitor.se> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <8ca64f00-b1d1-e4da-05cf-0e4663178d85@omnitor.se> Date: Wed, 31 May 2017 21:31:22 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Slim] New wording for the use of the asterisk in draft-ietf-slim-negotiating-human-language X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 19:31:32 -0000 Den 2017-05-31 kl. 15:58, skrev Randall Gellens: > This text should go in a separate document containing advice to > implementers. It adds an even better motivation than my earlier proposals for having the asterisk as a parameter on media level, and it adds a mild recommendation about the preference between media that we need to make the draft useful in reality. Therefore I suggest to accept it into the current draft. ( if issue #34 is rejected ) Without this change, the confusion about the placement of the asterisk and the question why the asterisk is a media parameter is still valid. Regards Gunnar > > At 3:24 PM +0200 5/31/17, Gunnar Hellström wrote: > >> Regarding the many review comments about the use of the asterisk >> parameter in draft-ietf-slim-negotiating-human-language, ( e.g. by >> Adam Roach on 28/3/2017) I propose the following change that both >> gives a meaning to the position of the asterisk and satisfies issue >> #26 with media preferences. >> >> I propose to use this solution if there is a decision to not satisfy >> Issue #34, to use the Accept-Language syntax.: >> >> --Change proposal - to draft version -10--- >> >> --First change-- >> >> in section 5.2 >> >> --old text- >> >> In an offer, each value MAY have an asterisk appended as the final >> value. An asterisk appended to either value in an offer indicates a >> request by the caller to the callee to not fail the call if there is >> no language in common. See Section 5.3 for more information and >> discussion. >> >> -new text >> >> In an offer or answer, each value MAY have an asterisk appended >> as the final >> parameter. An asterisk appended to a value in an offer indicates a >> that the caller has higher preference for the corresponding modality >> to be used in the specified direction than other modalities for the >> indicated >> direction without an asterisk. If no such preference is indicated in >> any hlang- >> attribute, it should be taken as a preference by the caller to get >> the call denied >> if no languages are in common between the caller and the callee. >> In an answer, the asterisk indicates a modality that is preferred by >> the callee to be used in the session. >> >> See Section 5.3 for more information and >> discussion. >> >> --end of first change---- >> >> ---second change---- >> In 5.3 >> ----old text--- >> >> >> 5.3. No Language in Common >> >> A consideration with the ability to negotiate language is if the >> call >> proceeds or fails if the callee does not support any of the >> languages >> requested by the caller. This document does not mandate either >> behavior, although it does provide a way for the caller to >> indicate a >> preference for the call succeeding when there is no language in >> common. It is OPTIONAL for the callee to honor this preference. >> For >> example, a PSAP is likely to attempt the call even without an >> indicated preference when there is no language in common, while a >> call center might choose to fail the call. >> >> The mechanism for indicating this preference is that, in an >> offer, if >> the last value of either 'hlang-recv' or 'hlang-send' is an >> asterisk, >> this indicates a request to not fail the call. The called party MAY >> ignore the indication, e.g., for the emergency services use case, >> regardless of the absence of an asterisk, a PSAP will likely not >> fail >> the call; some call centers might reject a call even if the offer >> contains an asterisk. >> >> ---New text ---- >> >> >> 5.3. Preferred modality and action if no match >> >> A user may have a clear preference to use one specific modality in a >> direction, while use of other modalities may be acceptable but >> lower in >> preference. This condition MAY be indicated by appending an asterisk >> as the last parameter in the corresponding humlang- value. This >> indication should also be seen as a preference to not have the call >> denied even if no indicated languages are in common. >> >> When negotiating language use for a direction, languages and >> modalities >> specified together with the asterisk should be given preference to >> be selected for use. >> No specific preference between modalities in the same direction >> should >> be indicated by appending an asterisk on all or no humlang- >> values for that direction. >> >> If there is a preference for denying the call when no languages >> match, >> then it is not possible to indicate any preferred modality at the >> same time. >> >> It is OPTIONAL for the callee to honor the preference for denying >> the call at no match. >> For example, a PSAP is likely to attempt the call even without an >> indicated preference when there is no language in common, while a >> call center might choose to fail the call. >> >> The called party MAY ignore the indication for denying the call, >> e.g., >> for the emergency services use case, >> regardless of the absence of an asterisk, a PSAP will likely not >> fail >> the call; some call centers might reject a call in case of no >> matching language >> even if the offer contains an asterisk. >> >> -----end of change ------------------ >> >> ---Change in 5.5---- >> >> ---Add this text as a separate example e.g. last in 5.5--- >> An offer requesting the following media streams: audio for the >> caller >> to send using spoken English (most preferred modality) or American >> Sign Language (less preferred modality), >> audio for the caller to receive spoken English (most preferred >> modality) or >> American Sign Language (less preferred modality), >> supplemental text. The offer also requests that the >> call proceed even if the callee does not support any of the >> languages. The offer is likely from a hearing person with >> knowledge in sign language: >> >> m=text 45020 RTP/AVP 103 104 >> >> m=audio 49250 RTP/AVP 20 >> a=hlang-recv:en * >> a=hlang-send:en * >> >> m=video 51372 RTP/AVP 31 32 >> a=hlang-recv: ase >> a=hlang-send: ase >> >> An answer for the above offer, indicating video in which the callee >> will send and receive American Sign Language, because that callee had >> no capability for spoken English. The text and audio streams are >> opened as supplementary streams. >> >> m=text 45020 RTP/AVP 103 104 >> m=audio 49250 RTP/AVP 20 >> >> >> m=video 51372 RTP/AVP 31 32 >> a=hlang-send: ase >> a=hlang-recv: ase >> ---end of change--- >> >> >> >> >> >> -- >> ----------------------------------------- >> Gunnar Hellström >> Omnitor >> gunnar.hellstrom@omnitor.se >> +46 708 204 288 >> >> _______________________________________________ >> SLIM mailing list >> SLIM@ietf.org >> https://www.ietf.org/mailman/listinfo/slim > > -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288