From nobody Sat Jul 1 02:32:31 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 2E3BF124BE8; Sat, 1 Jul 2017 02:32:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: slim@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149890154915.384.4700253299078257600@ietfa.amsl.com> Date: Sat, 01 Jul 2017 02:32:29 -0700 Archived-At: Subject: [Slim] I-D Action: draft-ietf-slim-negotiating-human-language-12.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: Sat, 01 Jul 2017 09:32:29 -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-12.txt Pages : 18 Date : 2017-07-01 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-12 https://datatracker.ietf.org/doc/html/draft-ietf-slim-negotiating-human-language-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-slim-negotiating-human-language-12 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 Sun Jul 2 13:35:20 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ECBF129ABE for ; Sun, 2 Jul 2017 13:35:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 b3MZ0F7cVKW3 for ; Sun, 2 Jul 2017 13:35:16 -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 47448127867 for ; Sun, 2 Jul 2017 13:35:16 -0700 (PDT) X-Halon-ID: f155d371-5f65-11e7-ba91-005056917f90 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [77.53.36.99]) by bin-vsp-out-02.atm.binero.net (Halon) with ESMTPSA id f155d371-5f65-11e7-ba91-005056917f90; Sun, 02 Jul 2017 22:35:10 +0200 (CEST) References: <149890154915.384.4700253299078257600@ietfa.amsl.com> Cc: slim@ietf.org To: Randall Gellens From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <875a0d11-150d-4d23-3e5b-2a327526f6de@omnitor.se> Date: Sun, 2 Jul 2017 22:35:08 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <149890154915.384.4700253299078257600@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Slim] I-D Action: draft-ietf-slim-negotiating-human-language-12.txt X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jul 2017 20:35:19 -0000 The draft looks good now. All issues reported by me under subject I-D Action: draft-ietf-slim-negotiating-human-language-11.txt are well resolved. Thanks, Gunnar Den 2017-07-01 kl. 11:32, 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-12.txt > Pages : 18 > Date : 2017-07-01 > > 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-12 > https://datatracker.ietf.org/doc/html/draft-ietf-slim-negotiating-human-language-12 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-slim-negotiating-human-language-12 > > > 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 From nobody Sun Jul 2 14:34:09 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D9BA129ACD for ; Sun, 2 Jul 2017 14:34:07 -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 SKKhwHQLLiA8 for ; Sun, 2 Jul 2017 14:34:05 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id A9CAE1275AB for ; Sun, 2 Jul 2017 14:34:05 -0700 (PDT) Received: from [10.20.3.156] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Sun, 2 Jul 2017 14:37:00 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <15BDE051-1F8A-434A-A87C-A9213057B500@gsma.com> References: <15BDE051-1F8A-434A-A87C-A9213057B500@gsma.com> X-Mailer: Eudora for Mac OS X Date: Sun, 2 Jul 2017 14:34:01 -0700 To: Natasha Rooney , slim@ietf.org From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Archived-At: Subject: Re: [Slim] IETf 99 and interim X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jul 2017 21:34:07 -0000 At 1:44 PM +0800 6/30/17, Natasha Rooney wrote: > On reflection, given many people will be absent from IETF99 and the > issues experienced when running a meeting with a large part of the > group being on the phone we have decided to cancel our IETF99 > meeting slot and hold a teleconference interim meeting in August. I concur. The real-time draft may not need any discussion time; I believe all open issues have been resolved. I propose we advance this draft now and free our discussion time for the email draft and Gunnar's drafts. > Editors (Randall, Nik, Gunnar): are you working during August? Any > block out dates? I am working and have no black out dates. > I'll make the request to cancel the meeting now. When the editors > respond with their ability for August we will work to find a time > suitable for as many people as possible for the interim meeting. Sounds good. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Very funny, Scotty. Now beam down my clothes. From nobody Mon Jul 3 11:23: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 BF85E12783A for ; Mon, 3 Jul 2017 11:23:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uhzNIuUgrbS3 for ; Mon, 3 Jul 2017 11:23:39 -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 A72BF1316F1 for ; Mon, 3 Jul 2017 11:23:38 -0700 (PDT) X-Halon-ID: b71e1889-601c-11e7-ba92-005056917f90 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [77.53.36.99]) by bin-vsp-out-02.atm.binero.net (Halon) with ESMTPSA id b71e1889-601c-11e7-ba92-005056917f90; Mon, 03 Jul 2017 20:23:31 +0200 (CEST) From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= To: "slim@ietf.org" Message-ID: Date: Mon, 3 Jul 2017 20: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 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Slim] I-D Action: draft-hellstrom-slim-modality-grouping-00.txt X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 18:23:44 -0000 A new draft is available, replacing draft-hellstrom-language-grouping-00 Just a few minor changes. They are: -A new file name indicating its relation to the SLIM wg. -A shorter abstract. -More polite IANA registration request. -A section about changes from earlier version. Regards Gunnar -------------------------------------------------------- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Human Language Modality Grouping Semantics in Session Description Protocol Author : Gunnar Hellstrom Filename : draft-hellstrom-slim-modality-grouping-00.txt Pages : 10 Date : 2017-07-03 Abstract: When setting up a real-time communication session, there may be a need to indicate priority for which media to use for language communications or a need to indicate preference for receiving the same language content simultaneously in two modalities. This document defines the semantics for grouping media for such purposes in the Session Description Protocol (SDP). The semantics defined in this document are based on the SDP Grouping Framework. Applications are for example negotiation the most suitable common modality or modalities for language communications in a real-time session. The indications are specified for the sending and receiving direction separately. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-hellstrom-slim-modality-grouping/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-hellstrom-slim-modality-grouping-00 https://datatracker.ietf.org/doc/html/draft-hellstrom-slim-modality-grouping-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Wed Jul 12 08:13:02 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 C422912F28E; Wed, 12 Jul 2017 08:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QUWcFoxBDT7J; Wed, 12 Jul 2017 08:12:59 -0700 (PDT) Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A29D12EE8D; Wed, 12 Jul 2017 08:12:59 -0700 (PDT) Received: by mail-ua0-x22d.google.com with SMTP id w19so16496350uac.0; Wed, 12 Jul 2017 08:12:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=XiQZF6wTh9vhw0WmtW+lW1dmmwX7JyvUz2qwcmg31V8=; b=b4tAne/NMG7K5JNoib+P/iLdoqEMHRyT5cJ7O1uTQnyoXB55tM9HnxuR3p9QSFPdsJ RRCXBvDkwl8VeQ3XJxyXC2wH1xvWpnsXWte132OpgbK+xAJKbQOkcuSzBNMWZmYROHlq ENu6aUqClFdkXUgm5qdHHom3AwPb7qh+aI3dV5KVoXL1TZq+wbcFu6j2sUCKcE7I5UQO aWBwmi7mqNW7eT4wh/sphBKPZR868z+T4s7sT5fLRM0wsQKHEE/FofGgyKW7jYnlZPIo rz85mrHP84PNXPonM5pfVbcPd99gB7eIBYQpcZHg5VoK4Dje96gWIk+R/mxYAdg7jKM6 jKaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=XiQZF6wTh9vhw0WmtW+lW1dmmwX7JyvUz2qwcmg31V8=; b=hLes0+IAYLR+L2rDI0vFvcnz3+5ax1ktJ1YfKQ1TUBtLdRox6vRkUEzh/FlaLlud59 JAIC4rf9ye6sARpjL4dfY2grnFv6gIFJgsAm7S2UYRJBMQNNO6idSsUYrAuF9ZESv4C1 zLX1DQsQrQiE7BevFbXhaj7UYOuYF0M19Q61YWQmcvkLp7BHLNq9HBsCJgNb3VdIOS/2 DVLi9FdcYTFTOISYA71TnbzYQgkgaivIJUz/zE36Ik/Tgtrcz+Ok5q230IUt7CIOoOMB 1UsobNAbZUuvG8+zSN65GXI9PYKmIVn9r8kM7k9TEHDZARBYUjZsPdOQ85oSm7X1HUaR 1OLA== X-Gm-Message-State: AIVw111jDH5fxWJpotVQ9mKfdztogymSLBcNifvpI6FVuohS9laiqz8e zON8Xt82ZWfEskBZKuVEaVzraoLZRg== X-Received: by 10.159.57.108 with SMTP id i44mr3143291uag.17.1499872378268; Wed, 12 Jul 2017 08:12:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.74.202 with HTTP; Wed, 12 Jul 2017 08:12:37 -0700 (PDT) From: Bernard Aboba Date: Wed, 12 Jul 2017 08:12:37 -0700 Message-ID: To: Alexey Melnikov Cc: Natasha Rooney , slim@ietf.org, draft-ietf-slim-multilangcontent@ietf.org Content-Type: multipart/mixed; boundary="f403043edb3050c84305542040e1" Archived-At: Subject: [Slim] Request for publication of draft-ietf-slim-multilangcontent-08 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, 12 Jul 2017 15:13:02 -0000 --f403043edb3050c84305542040e1 Content-Type: multipart/alternative; boundary="f403043edb3050c83f05542040df" --f403043edb3050c83f05542040df Content-Type: text/plain; charset="UTF-8" The SLIM WG requests that the IESG consider publication of draft-ietf-slim-multilangcontent-08 as a Proposed Standard RFC. The document shepherd writeup is enclosed. --f403043edb3050c83f05542040df Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The SLIM WG requests that the IESG consider publication of= draft-ietf-slim-multilangcontent-08 as a Proposed Standard RFC.=C2=A0 The = document shepherd writeup is enclosed.
--f403043edb3050c83f05542040df-- --f403043edb3050c84305542040e1 Content-Type: text/plain; charset="US-ASCII"; name="multi.txt" Content-Disposition: attachment; filename="multi.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_j5159ufn0 RG9jdW1lbnQgV3JpdGV1cCBmb3IgZHJhZnQtaWV0Zi1zbGltLW11bHRpbGFuZ2NvbnRlbnQtMDgK CkRvY3VtZW50IFNoZXBoZXJkOiBCZXJuYXJkIEFib2JhIChiZXJuYXJkLmFib2JhQGdtYWlsLmNv bSkKCigxKSBXaGF0IHR5cGUgb2YgUkZDIGlzIGJlaW5nIHJlcXVlc3RlZCAoQkNQLCBQcm9wb3Nl ZCBTdGFuZGFyZCwgSW50ZXJuZXQgU3RhbmRhcmQsIEluZm9ybWF0aW9uYWwsIEV4cGVyaW1lbnRh bCwgb3IgSGlzdG9yaWMpPyBXaHkgaXMgdGhpcyB0aGUgcHJvcGVyIHR5cGUgb2YgUkZDPyBJcyB0 aGlzIHR5cGUgb2YgUkZDIGluZGljYXRlZCBpbiB0aGUgdGl0bGUgcGFnZSBoZWFkZXI/CgpJdCBp cyByZXF1ZXN0ZWQgdGhhdCB0aGlzIGRvY3VtZW50IGJlIHB1Ymxpc2hlZCBhcyBhIFByb3Bvc2Vk IFN0YW5kYXJkLiBUaGUgaGVhZGVyIGluZGljYXRlcyB0aGF0IFN0YW5kYXJkcyBUcmFjayBwdWJs aWNhdGlvbiBpcyBkZXNpcmVkLgpUaGlzIGRvY3VtZW50IG5lZWRzIHRvIGJlIG9uIHRoZSBTdGFu ZGFyZHMgVHJhY2sgc2luY2UgYSBzdGFuZGFyZCB3YXkgdG8gaGFuZGxlIG11bHRpcGxlIGxhbmd1 YWdlIGNvbnRlbnQgaXMgbmVlZGVkIHRvIGVuc3VyZSBpbnRlcm9wZXJhYmlsaXR5LiAKCigyKSBU aGUgSUVTRyBhcHByb3ZhbCBhbm5vdW5jZW1lbnQgaW5jbHVkZXMgYSBEb2N1bWVudCBBbm5vdW5j ZW1lbnQgV3JpdGUtVXAuIFBsZWFzZSBwcm92aWRlIHN1Y2ggYSBEb2N1bWVudCBBbm5vdW5jZW1l bnQgV3JpdGUtVXAuIFJlY2VudCBleGFtcGxlcyBjYW4gYmUgZm91bmQgaW4gdGhlICJBY3Rpb24i IGFubm91bmNlbWVudHMgZm9yIGFwcHJvdmVkIGRvY3VtZW50cy4gVGhlIGFwcHJvdmFsIGFubm91 bmNlbWVudCBjb250YWlucyB0aGUgZm9sbG93aW5nIHNlY3Rpb25zOgoKVGVjaG5pY2FsIFN1bW1h cnk6CgogICBUaGUgb2JqZWN0aXZlIG9mIHRoaXMgZG9jdW1lbnQgaXMgdG8gZGVmaW5lIGFuIGFk ZGl0aW9uIHRvIHRoZQogICBNdWx0aXB1cnBvc2UgSW50ZXJuZXQgTWFpbCBFeHRlbnNpb25zIChN SU1FKSBzdGFuZGFyZCwgdG8gbWFrZSBpdAogICBwb3NzaWJsZSB0byBzZW5kIGEgc2luZ2xlIG1l c3NhZ2UgdG8gYSBncm91cCBvZiBwZW9wbGUgaW4gc3VjaCBhIHdheQogICB0aGF0IGFsbCBvZiB0 aGUgcmVjaXBpZW50cyBjYW4gcmVhZCB0aGUgZW1haWwgaW4gdGhlaXIgcHJlZmVycmVkCiAgIGxh bmd1YWdlLgoKV29ya2luZyBHcm91cCBTdW1tYXJ5OgoKV2FzIHRoZXJlIGFueXRoaW5nIGluIFdH IHByb2Nlc3MgdGhhdCBpcyB3b3J0aCBub3Rpbmc/IEZvciBleGFtcGxlLCB3YXMgdGhlcmUgY29u dHJvdmVyc3kgYWJvdXQgcGFydGljdWxhciBwb2ludHMgb3Igd2VyZSB0aGVyZSBkZWNpc2lvbnMg d2hlcmUgdGhlIGNvbnNlbnN1cyB3YXMgcGFydGljdWxhcmx5IHJvdWdoPwoKVGhpcyBkb2N1bWVu dCBoYXMgYmVlbiBub24tY29udHJvdmVyc2lhbC4KCkRvY3VtZW50IFF1YWxpdHk6CgpBcmUgdGhl cmUgZXhpc3RpbmcgaW1wbGVtZW50YXRpb25zIG9mIHRoZSBwcm90b2NvbD8gSGF2ZSBhIHNpZ25p ZmljYW50IG51bWJlciBvZiB2ZW5kb3JzIGluZGljYXRlZCB0aGVpciBwbGFuIHRvIGltcGxlbWVu dCB0aGUgc3BlY2lmaWNhdGlvbj8gQXJlIHRoZXJlIGFueSByZXZpZXdlcnMgdGhhdCBtZXJpdCBz cGVjaWFsIG1lbnRpb24gYXMgaGF2aW5nIGRvbmUgYSB0aG9yb3VnaCByZXZpZXcsIGUuZy4sIG9u ZSB0aGF0IHJlc3VsdGVkIGluIGltcG9ydGFudCBjaGFuZ2VzIG9yIGEgY29uY2x1c2lvbiB0aGF0 IHRoZSBkb2N1bWVudCBoYWQgbm8gc3Vic3RhbnRpdmUgaXNzdWVzPyBJZiB0aGVyZSB3YXMgYSBN SUIgRG9jdG9yLCBNZWRpYSBUeXBlIG9yIG90aGVyIGV4cGVydCByZXZpZXcsIHdoYXQgd2FzIGl0 cyBjb3Vyc2UgKGJyaWVmbHkpPyBJbiB0aGUgY2FzZSBvZiBhIE1lZGlhIFR5cGUgcmV2aWV3LCBv biB3aGF0IGRhdGUgd2FzIHRoZSByZXF1ZXN0IHBvc3RlZD8KClRoZXJlIGFyZSBubyBrbm93biBp bXBsZW1lbnRhdGlvbnMuCgpQZXJzb25uZWw6CgpXaG8gaXMgdGhlIERvY3VtZW50IFNoZXBoZXJk PyBXaG8gaXMgdGhlIFJlc3BvbnNpYmxlIEFyZWEgRGlyZWN0b3I/CgpCZXJuYXJkIEFib2JhIChT TElNIFdHIGNvLWNoYWlyKSBpcyB0aGUgRG9jdW1lbnQgU2hlcGhlcmQuICBUaGUgcmVzcG9uc2li bGUgYXJlYSBkaXJlY3RvciBpcyBBbGV4ZXkgTWVsbmlrb3YgKEFSVCBBRCkuCgooMykgQnJpZWZs eSBkZXNjcmliZSB0aGUgcmV2aWV3IG9mIHRoaXMgZG9jdW1lbnQgdGhhdCB3YXMgcGVyZm9ybWVk IGJ5IHRoZSBEb2N1bWVudCBTaGVwaGVyZC4gSWYgdGhpcyB2ZXJzaW9uIG9mIHRoZSBkb2N1bWVu dCBpcyBub3QgcmVhZHkgZm9yIHB1YmxpY2F0aW9uLCBwbGVhc2UgZXhwbGFpbiB3aHkgdGhlIGRv Y3VtZW50IGlzIGJlaW5nIGZvcndhcmRlZAogdG8gdGhlIElFU0cuCgpUaGUgU0xJTSBXRyBjby1j aGFpcnMgKEJlcm5hcmQgQWJvYmEgYW5kIE5hdGFzaGEgUm9vbmV5KSBoYXZlIHJldmlld2VkIHRo ZSBkb2N1bWVudC4gV2UgYmVsaWV2ZSBpdCBpcyByZWFkeSBmb3IgcHVibGljYXRpb24uCgooNCkg RG9lcyB0aGUgZG9jdW1lbnQgU2hlcGhlcmQgaGF2ZSBhbnkgY29uY2VybnMgYWJvdXQgdGhlIGRl cHRoIG9yIGJyZWFkdGggb2YgdGhlIHJldmlld3MgdGhhdCBoYXZlIGJlZW4gcGVyZm9ybWVkPwoK Tm8uCgooNSkgRG8gcG9ydGlvbnMgb2YgdGhlIGRvY3VtZW50IG5lZWQgcmV2aWV3IGZyb20gYSBw YXJ0aWN1bGFyIG9yIGZyb20gYnJvYWRlciBwZXJzcGVjdGl2ZSwgZS5nLiwgc2VjdXJpdHksIG9w ZXJhdGlvbmFsIGNvbXBsZXhpdHksIEFBQSwgRE5TLCBESENQLCBYTUwsIG9yIGludGVybmF0aW9u YWxpemF0aW9uPyAKSWYgc28sIGRlc2NyaWJlIHRoZSByZXZpZXcgdGhhdCB0b29rIHBsYWNlLgoK SW5kaXZpZHVhbHMga25vd2xlZGdlYWJsZSBhYm91dCBlbWFpbCBhbmQgbGFuZ3VhZ2UgbmVnb3Rp YXRpb24gaGF2ZSByZXZpZXdlZCB0aGUgZG9jdW1lbnQuCgooNikgRGVzY3JpYmUgYW55IHNwZWNp ZmljIGNvbmNlcm5zIG9yIGlzc3VlcyB0aGF0IHRoZSBEb2N1bWVudCBTaGVwaGVyZCBoYXMgd2l0 aCB0aGlzIGRvY3VtZW50IHRoYXQgdGhlIFJlc3BvbnNpYmxlIEFyZWEgRGlyZWN0b3IgYW5kL29y IHRoZSBJRVNHIHNob3VsZCBiZSBhd2FyZSBvZj8gCkZvciBleGFtcGxlLCBwZXJoYXBzICBoZSBv ciBzaGUgaXMgdW5jb21mb3J0YWJsZSB3aXRoIGNlcnRhaW4gcGFydHMgb2YgdGhlIGRvY3VtZW50 LCBvciBoYXMgY29uY2VybnMgd2hldGhlciB0aGVyZSByZWFsbHkgaXMgYSBuZWVkIGZvciBpdC4g SW4gYW55IGV2ZW50LCBpZiB0aGUgV0cgaGFzIGRpc2N1c3NlZCB0aG9zZSBpc3N1ZXMgYW5kIGhh cyBpbmRpY2F0ZWQgdGhhdCBpdCBzdGlsbCB3aXNoZXMgdG8gYWR2YW5jZSB0aGUKZG9jdW1lbnQs IGRldGFpbCB0aG9zZSBjb25jZXJucyBoZXJlLgoKTm8gc3BlY2lmaWMgY29uY2VybnMuCgooNykg SGFzIGVhY2ggYXV0aG9yIGNvbmZpcm1lZCB0aGF0IGFueSBhbmQgYWxsIGFwcHJvcHJpYXRlIElQ UiBkaXNjbG9zdXJlcyByZXF1aXJlZCBmb3IgZnVsbCBjb25mb3JtYW5jZSB3aXRoIHRoZSBwcm92 aXNpb25zIG9mIEJDUCA3OCBhbmQgQkNQIDc5IGhhdmUgYWxyZWFkeSBiZWVuIGZpbGVkLiBJZiBu b3QsIGV4cGxhaW4gd2h5PwoKWWVzLiAgQ29uZmlybWF0aW9uczoKTmF0aGFuaWVsIEJvcmVuc3Rl aW46IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvc2xpbS9jdXJyZW50L21z ZzAwOTYzLmh0bWwKTmlrIFRvbWtpbnNvbjogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNo aXZlL3dlYi9zbGltL2N1cnJlbnQvbXNnMDA5NjIuaHRtbAoKKDgpIEhhcyBhbiBJUFIgZGlzY2xv c3VyZSBiZWVuIGZpbGVkIHRoYXQgcmVmZXJlbmNlcyB0aGlzIGRvY3VtZW50PyBJZiBzbywgc3Vt bWFyaXplIGFueSBXRyBkaXNjdXNzaW9uIGFuZCBjb25jbHVzaW9uIHJlZ2FyZGluZyB0aGUgSVBS IGRpc2Nsb3N1cmVzLgoKTm8gSVBSIGRpc2Nsb3N1cmVzIGhhdmUgYmVlbiBmaWxlZC4KCig5KSBI b3cgc29saWQgaXMgdGhlIFdHIGNvbnNlbnN1cyBiZWhpbmQgdGhpcyBkb2N1bWVudD8gRG9lcyBp dCByZXByZXNlbnQgdGhlIHN0cm9uZyBjb25jdXJyZW5jZSBvZiBhIGZldyBpbmRpdmlkdWFscywg d2l0aCBvdGhlcnMgYmVpbmcgc2lsZW50LCBvciBkb2VzIHRoZSBXRyBhcyBhIHdob2xlIHVuZGVy c3RhbmQgYW5kIGFncmVlIHdpdGggaXQ/CgpXRyBjb25zZW5zdXMgcmVwcmVzZW50ZWQgdGhlIGNv bmN1cnJlbmNlIG9mIHRob3NlIFdHIHBhcnRpY2lwYW50cyB3aG8gd2VpZ2hlZCBpbiBvbiBpdCAo NC01KS4KCigxMCkgSGFzIGFueW9uZSB0aHJlYXRlbmVkIGFuIGFwcGVhbCBvciBvdGhlcndpc2Ug aW5kaWNhdGVkIGV4dHJlbWUgZGlzY29udGVudD8gSWYgc28sIHBsZWFzZSBzdW1tYXJpc2UgdGhl IGFyZWFzIG9mIGNvbmZsaWN0IGluIHNlcGFyYXRlIGVtYWlsIG1lc3NhZ2VzIHRvIHRoZSBSZXNw b25zaWJsZSBBcmVhIERpcmVjdG9yLiAoSXQgc2hvdWxkIGJlIGluIGEKc2VwYXJhdGUgZW1haWwg YmVjYXVzZSB0aGlzIHF1ZXN0aW9ubmFpcmUgaXMgcHVibGljbHkgYXZhaWxhYmxlLikKCk5vIGFw cGVhbHMgaGF2ZSBiZWVuIHRocmVhdGVuZWQuCgooMTEpIElkZW50aWZ5IGFueSBJRCBuaXRzIHRo ZSBEb2N1bWVudCBTaGVwaGVyZCBoYXMgZm91bmQgaW4gdGhpcyBkb2N1bWVudC4gKFNlZSBodHRw Oi8vd3d3LmlldGYub3JnL3Rvb2xzL2lkbml0cy8gYW5kIHRoZSBJbnRlcm5ldC1EcmFmdHMgQ2hl Y2tsaXN0KS4gCkJvaWxlcnBsYXRlIGNoZWNrcyBhcmUgbm90IGVub3VnaDsgdGhpcyBjaGVjayBu ZWVkcyB0byBiZSB0aG9yb3VnaC4KCkJlbG93IGlzIHRoZSBvdXRwdXQgZnJvbSBpZG5pdHMuICBP bmUgZXJyb3Igd2FzIGZvdW5kOiBsYWNrIG9mIGEgVGFibGUgb2YgQ29udGVudHMuCgppZG5pdHMg Mi4xNC4wMiAKCnRtcC9kcmFmdC1pZXRmLXNsaW0tbXVsdGlsYW5nY29udGVudC0wOC50eHQ6CnRt cC9kcmFmdC1pZXRmLXNsaW0tbXVsdGlsYW5nY29udGVudC0wOC50eHQoNjg4KTogUG9zc2libGUg Y29kZSBjb21tZW50IGluIGxpbmU6ICAgICAgICBtb3JlIG1lc3NhZ2UvKikgbWF5IGNvbnRhaW4g Ny1iaXQsIDgtYml0IG9yIGJpbmFyeSBlbmNvZGluZ3MuLgp0bXAvZHJhZnQtaWV0Zi1zbGltLW11 bHRpbGFuZ2NvbnRlbnQtMDgudHh0KDcxMik6IEZvdW5kIHBvc3NpYmxlIEZRRE4gJ3JmYy5uaWsu dG9ta2luc29uJyBpbiBwb3NpdGlvbiA3OyB0aGlzIGRvZXNuJ3QgbWF0Y2ggUkZDIDI2MDYncyBz dWdnZXN0ZWQgIi5leGFtcGxlIiBvciAiLmV4YW1wbGUuKGNvbXxvcmd8bmV0KSIuCgogLSBUaGUg ZHJhZnQtaWV0Zi1zbGltLW11bHRpbGFuZ2NvbnRlbnQgc3RhdGUgZmlsZSBpcyBub3QgZnJvbSB0 b2RheS4KICAgQXR0ZW1wdGluZyB0byBkb3dubG9hZCBhIG5ld2VyIG9uZS4uLgogLSBTdWNjZXNz IGZldGNoaW5nIGRyYWZ0LWlldGYtc2xpbS1tdWx0aWxhbmdjb250ZW50IHN0YXRlIGZpbGUuCgog LSBUaGUgZHJhZnQtaWV0Zi1zbGltLW5lZ290aWF0aW5nLWh1bWFuLWxhbmd1YWdlIHN0YXRlIGZp bGUgaXMgbm90IGZyb20gdG9kYXkuCiAgIEF0dGVtcHRpbmcgdG8gZG93bmxvYWQgYSBuZXdlciBv bmUuLi4KIC0gU3VjY2VzcyBmZXRjaGluZyBkcmFmdC1pZXRmLXNsaW0tbmVnb3RpYXRpbmctaHVt YW4tbGFuZ3VhZ2Ugc3RhdGUgZmlsZS4KCiAtIFRoZSBkcmFmdC10b21raW5zb24tbXVsdGlsYW5n Y29udGVudCBzdGF0ZSBmaWxlIGlzIG5vdCBmcm9tIHRvZGF5LgogICBBdHRlbXB0aW5nIHRvIGRv d25sb2FkIGEgbmV3ZXIgb25lLi4uCiAtIFN1Y2Nlc3MgZmV0Y2hpbmcgZHJhZnQtdG9ta2luc29u LW11bHRpbGFuZ2NvbnRlbnQgc3RhdGUgZmlsZS4KCiAtIFRoZSBkcmFmdC10b21raW5zb24tc2xp bS1tdWx0aWxhbmdjb250ZW50IHN0YXRlIGZpbGUgaXMgbm90IGZyb20gdG9kYXkuCiAgIEF0dGVt cHRpbmcgdG8gZG93bmxvYWQgYSBuZXdlciBvbmUuLi4KIC0gU3VjY2VzcyBmZXRjaGluZyBkcmFm dC10b21raW5zb24tc2xpbS1tdWx0aWxhbmdjb250ZW50IHN0YXRlIGZpbGUuCgogLSBUaGUgcmZj MTk5NiBzdGF0ZSBmaWxlIGlzIG5vdCBmcm9tIHRvZGF5LgogICBBdHRlbXB0aW5nIHRvIGRvd25s b2FkIGEgbmV3ZXIgb25lLi4uCiAtIFN1Y2Nlc3MgZmV0Y2hpbmcgcmZjMTk5NiBzdGF0ZSBmaWxl LgoKIC0gVGhlIHJmYzIwNDYgc3RhdGUgZmlsZSBpcyBub3QgZnJvbSB0b2RheS4KICAgQXR0ZW1w dGluZyB0byBkb3dubG9hZCBhIG5ld2VyIG9uZS4uLgogLSBTdWNjZXNzIGZldGNoaW5nIHJmYzIw NDYgc3RhdGUgZmlsZS4KCiAtIFRoZSByZmMyMDQ3IHN0YXRlIGZpbGUgaXMgbm90IGZyb20gdG9k YXkuCiAgIEF0dGVtcHRpbmcgdG8gZG93bmxvYWQgYSBuZXdlciBvbmUuLi4KIC0gU3VjY2VzcyBm ZXRjaGluZyByZmMyMDQ3IHN0YXRlIGZpbGUuCgogLSBUaGUgcmZjMjE4MyBzdGF0ZSBmaWxlIGlz IG5vdCBmcm9tIHRvZGF5LgogICBBdHRlbXB0aW5nIHRvIGRvd25sb2FkIGEgbmV3ZXIgb25lLi4u CiAtIFN1Y2Nlc3MgZmV0Y2hpbmcgcmZjMjE4MyBzdGF0ZSBmaWxlLgoKIC0gVGhlIHJmYzMyODIg c3RhdGUgZmlsZSBpcyBub3QgZnJvbSB0b2RheS4KICAgQXR0ZW1wdGluZyB0byBkb3dubG9hZCBh IG5ld2VyIG9uZS4uLgogLSBTdWNjZXNzIGZldGNoaW5nIHJmYzMyODIgc3RhdGUgZmlsZS4KCiAt IFRoZSByZmM0NjQ3IHN0YXRlIGZpbGUgaXMgbm90IGZyb20gdG9kYXkuCiAgIEF0dGVtcHRpbmcg dG8gZG93bmxvYWQgYSBuZXdlciBvbmUuLi4KIC0gU3VjY2VzcyBmZXRjaGluZyByZmM0NjQ3IHN0 YXRlIGZpbGUuCgogLSBUaGUgcmZjNDgwIHN0YXRlIGZpbGUgaXMgbm90IGZyb20gdG9kYXkuCiAg IEF0dGVtcHRpbmcgdG8gZG93bmxvYWQgYSBuZXdlciBvbmUuLi4KIC0gU3VjY2VzcyBmZXRjaGlu ZyByZmM0ODAgc3RhdGUgZmlsZS4KCiAtIFRoZSByZmM1NjQ2IHN0YXRlIGZpbGUgaXMgbm90IGZy b20gdG9kYXkuCiAgIEF0dGVtcHRpbmcgdG8gZG93bmxvYWQgYSBuZXdlciBvbmUuLi4KIC0gU3Vj Y2VzcyBmZXRjaGluZyByZmM1NjQ2IHN0YXRlIGZpbGUuCgogLSBUaGUgcmZjNjUzMiBzdGF0ZSBm aWxlIGlzIG5vdCBmcm9tIHRvZGF5LgogICBBdHRlbXB0aW5nIHRvIGRvd25sb2FkIGEgbmV3ZXIg b25lLi4uCiAtIFN1Y2Nlc3MgZmV0Y2hpbmcgcmZjNjUzMiBzdGF0ZSBmaWxlLgoKIC0gVGhlIHJm YzgyMiBzdGF0ZSBmaWxlIGlzIG5vdCBmcm9tIHRvZGF5LgogICBBdHRlbXB0aW5nIHRvIGRvd25s b2FkIGEgbmV3ZXIgb25lLi4uCiAtIFN1Y2Nlc3MgZmV0Y2hpbmcgcmZjODIyIHN0YXRlIGZpbGUu CgogLSBUaGUgcmZjOTk3IHN0YXRlIGZpbGUgaXMgbm90IGZyb20gdG9kYXkuCiAgIEF0dGVtcHRp bmcgdG8gZG93bmxvYWQgYSBuZXdlciBvbmUuLi4KIC0gU3VjY2VzcyBmZXRjaGluZyByZmM5OTcg c3RhdGUgZmlsZS4KCiAgQ2hlY2tpbmcgYm9pbGVycGxhdGUgcmVxdWlyZWQgYnkgUkZDIDUzNzgg YW5kIHRoZSBJRVRGIFRydXN0IChzZWUKICBodHRwOi8vdHJ1c3RlZS5pZXRmLm9yZy9saWNlbnNl LWluZm8pOgogIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KCiAgICAgTm8gaXNzdWVzIGZvdW5kIGhlcmUu CgogIENoZWNraW5nIG5pdHMgYWNjb3JkaW5nIHRvIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaWQtaW5m by8xaWQtZ3VpZGVsaW5lcy50eHQ6CiAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQoKICAqKiBUaGUgZG9j dW1lbnQgaXMgbW9yZSB0aGFuIDE1IHBhZ2VzIGFuZCBzZWVtcyB0byBsYWNrIGEgVGFibGUgb2Yg Q29udGVudHMuCgoKICBDaGVja2luZyBuaXRzIGFjY29yZGluZyB0byBodHRwOi8vd3d3LmlldGYu b3JnL2lkLWluZm8vY2hlY2tsaXN0IDoKICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCgogID09IFRoZXJl IGFyZSAxIGluc3RhbmNlIG9mIGxpbmVzIHdpdGggbm9uLVJGQzI2MDYtY29tcGxpYW50IEZRRE5z IGluIHRoZQogICAgIGRvY3VtZW50LgoKCiAgTWlzY2VsbGFuZW91cyB3YXJuaW5nczoKICAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tCgogIC0tIFRoZSBkb2N1bWVudCBkYXRlIChKdW5lIDEyLCAyMDE3KSBp cyAyOSBkYXlzIGluIHRoZSBwYXN0LiAgSXMgdGhpcwogICAgIGludGVudGlvbmFsPwoKICAtLSBG b3VuZCBzb21ldGhpbmcgd2hpY2ggbG9va3MgbGlrZSBhIGNvZGUgY29tbWVudCAtLSBpZiB5b3Ug aGF2ZSBjb2RlCiAgICAgc2VjdGlvbnMgaW4gdGhlIGRvY3VtZW50LCBwbGVhc2Ugc3Vycm91bmQg dGhlbSB3aXRoICc8Q09ERSBCRUdJTlM+JyBhbmQKICAgICAnPENPREUgRU5EUz4nIGxpbmVzLgoK CiAgQ2hlY2tpbmcgcmVmZXJlbmNlcyBmb3IgaW50ZW5kZWQgc3RhdHVzOiBQcm9wb3NlZCBTdGFu ZGFyZAogIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KCiAgICAgKFNlZSBSRkNzIDM5NjcgYW5kIDQ4OTcg Zm9yIGluZm9ybWF0aW9uIGFib3V0IHVzaW5nIG5vcm1hdGl2ZSByZWZlcmVuY2VzCiAgICAgdG8g bG93ZXItbWF0dXJpdHkgZG9jdW1lbnRzIGluIFJGQ3MpCgogID09IE91dGRhdGVkIHJlZmVyZW5j ZTogQSBsYXRlciB2ZXJzaW9uICgtMTIpIGV4aXN0cyBvZgogICAgIGRyYWZ0LWlldGYtc2xpbS1u ZWdvdGlhdGluZy1odW1hbi1sYW5ndWFnZS0xMAoKCiAgICAgU3VtbWFyeTogMSBlcnJvciAoKiop LCAwIGZsYXdzICh+fiksIDIgd2FybmluZ3MgKD09KSwgMiBjb21tZW50cyAoLS0pLgoKLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0KCigxMikgRGVzY3JpYmUgaG93IHRoZSBkb2N1bWVudCBtZWV0cyBh bnkgcmVxdWlyZWQgZm9ybWFsIHJldmlldyBjcml0ZXJpYSwgc3VjaCBhcyB0aGUgTUlCIERvY3Rv ciwgbWVkaWEgdHlwZSwgYW5kIFVSSSB0eXBlIHJldmlld3MuCiAgIApUaGlzIGRvY3VtZW50IGRv ZXMgbm90IHJlcXVpcmUgTUlCIERvY3RvciwgbWVkaWEgdHlwZSBvciBVUkkgdHlwZSByZXZpZXdz LgoKKDEzKSBIYXZlIGFsbCByZWZlcmVuY2VzIHdpdGhpbiB0aGlzIGRvY3VtZW50IGJlZW4gaWRl bnRpZmllZCBhcyBlaXRoZXIgbm9ybWF0aXZlIG9yIGluZm9ybWF0aXZlPwoKWWVzLgoKKDE0KSBB cmUgdGhlcmUgbm9ybWF0aXZlIHJlZmVyZW5jZXMgdG8gZG9jdW1lbnRzIHRoYXQgYXJlIG5vdCBy ZWFkeSBmb3IgYWR2YW5jZW1lbnQgb3IgYXJlIG90aGVyd2lzZSBpbiBhbiB1bmNsZWFyIHN0YXRl PyBJZiBzdWNoIG5vcm1hdGl2ZSByZWZlcmVuY2VzIGV4aXN0LCB3aGF0IGlzIHRoZSBwbGFuIGZv ciB0aGVpciBjb21wbGV0aW9uPwoKVGhlcmUgYXJlIG5vIG5vcm1hdGl2ZSByZWZlcmVuY2VzIHRv IGRyYWZ0cywgb25seSBSRkNzLgoKKDE1KSBBcmUgdGhlcmUgZG93bndhcmQgbm9ybWF0aXZlIHJl ZmVyZW5jZXMgcmVmZXJlbmNlcyAoc2VlIFJGQyAzOTY3KT8gSWYgc28sIGxpc3QgdGhlc2UgZG93 bndhcmQgcmVmZXJlbmNlcyB0byBzdXBwb3J0IHRoZSBBcmVhIERpcmVjdG9yIGluIHRoZSBMYXN0 IENhbGwgcHJvY2VkdXJlLgoKTm8uCgooMTYpIFdpbGwgcHVibGljYXRpb24gb2YgdGhpcyBkb2N1 bWVudCBjaGFuZ2UgdGhlIHN0YXR1cyBvZiBhbnkgZXhpc3RpbmcgUkZDcz8gQXJlIHRob3NlIFJG Q3MgbGlzdGVkIG9uIHRoZSB0aXRsZSBwYWdlIGhlYWRlciwgbGlzdGVkIGluIHRoZSBhYnN0cmFj dCwgYW5kIGRpc2N1c3NlZCBpbiB0aGUgaW50cm9kdWN0aW9uPyBJZiB0aGUgUkZDcyBhcmUgbm90 IApsaXN0ZWQgaW4gdGhlIEFic3RyYWN0IGFuZCBJbnRyb2R1Y3Rpb24sIGV4cGxhaW4gd2h5LCBh bmQgcG9pbnQgdG8gdGhlIHBhcnQgb2YgdGhlIGRvY3VtZW50IHdoZXJlIHRoZSByZWxhdGlvbnNo aXAgb2YgdGhpcyBkb2N1bWVudCB0byB0aGUgb3RoZXIgUkZDcyBpcyBkaXNjdXNzZWQuIElmIHRo aXMgaW5mb3JtYXRpb24gaXMgbm90IGluIHRoZSBkb2N1bWVudCwgZXhwbGFpbiB3aHkgdGhlIFdH IGNvbnNpZGVycyBpdCB1bm5lY2Vzc2FyeS4KCk5vLgoKKDE3KSBEZXNjcmliZSB0aGUgRG9jdW1l bnQgU2hlcGhlcmQncyByZXZpZXcgb2YgdGhlIElBTkEgY29uc2lkZXJhdGlvbnMgc2VjdGlvbiwg ZXNwZWNpYWxseSB3aXRoIHJlZ2FyZCB0byBpdHMgY29uc2lzdGVuY3kgd2l0aCB0aGUgYm9keSBv ZiB0aGUgZG9jdW1lbnQuIENvbmZpcm0gdGhhdCBhbGwgcHJvdG9jb2wgZXh0ZW5zaW9ucyB0aGF0 CnRoZSBkb2N1bWVudCBtYWtlcyBhcmUgYXNzb2NpYXRlZCB3aXRoIHRoZSBhcHByb3ByaWF0ZSBy ZXNlcnZhdGlvbnMgaW4gSUFOQSByZWdpc3RyaWVzLiBDb25maXJtIHRoYXQgYW55IHJlZmVyZW5j ZWQgSUFOQSByZWdpc3RyaWVzIGhhdmUgYmVlbiBjbGVhcmx5IGlkZW50aWZpZWQuIApDb25maXJt IHRoYXQgbmV3bHkgY3JlYXRlZCBJQU5BIHJlZ2lzdHJpZXMgaW5jbHVkZSBhIGRldGFpbGVkIHNw ZWNpZmljYXRpb24gb2YgdGhlIGluaXRpYWwgY29udGVudHMgZm9yIHRoZSByZWdpc3RyeSwKdGhh dCBhbGxvY2F0aW9ucyBwcm9jZWR1cmVzIGZvciBmdXR1cmUgcmVnaXN0cmF0aW9ucyBhcmUgZGVm aW5lZCwgYW5kIGEgcmVhc29uYWJsZSBuYW1lIGZvciB0aGUgbmV3IHJlZ2lzdHJ5IGhhcyBiZWVu IHN1Z2dlc3RlZCAoc2VlIFJGQyA1MjI2KS4KClRoZXJlIGlzIGEgcmVxdWVzdCB0byByZWdpc3Rl ciB0aGUgbXVsdGlwYXJ0L211bHRpbGluZ3VhbCBNSU1FIHR5cGUgYXMgd2VsbCBhcyB0aGUgVHJh bnNsYXRpb24tVHlwZSBmaWVsZC4KCigxOCkgTGlzdCBhbnkgbmV3IElBTkEgcmVnaXN0cmllcyB0 aGF0IHJlcXVpcmUgRXhwZXJ0IFJldmlldyBmb3IgZnV0dXJlIGFsbG9jYXRpb25zLiAKUHJvdmlk ZSBhbnkgcHVibGljIGd1aWRhbmNlIHRoYXQgdGhlIElFU0cgd291bGQgZmluZCB1c2VmdWwgaW4g c2VsZWN0aW5nIHRoZSBJQU5BIEV4cGVydHMgZm9yIHRoZXNlIG5ldyByZWdpc3RyaWVzLgoKVGhl cmUgYXJlIG5vIG5ldyBJQU5BIHJlZ2lzdHJpZXMgY3JlYXRlZCBieSB0aGlzIGRvY3VtZW50LgoK KDE5KSBEZXNjcmliZSByZXZpZXdzIGFuZCBhdXRvbWF0ZWQgY2hlY2tzIHBlcmZvcm1lZCBieSB0 aGUgRG9jdW1lbnQgU2hlcGhlcmQgdG8gdmFsaWRhdGUgc2VjdGlvbnMgb2YgdGhlIGRvY3VtZW50 IHdyaXR0ZW4gaW4gYSBmb3JtYWwgbGFuZ3VhZ2UsIHN1Y2ggYXMgWE1MIGNvZGUsIEJORiBydWxl cywgTUlCIGRlZmluaXRpb25zLCBldGMuCgpUaGlzIGRvY3VtZW50IGRvZXMgbm90IHV0aWxpemUg YW55IGZvcm1hbCBsYW5ndWFnZXMuCg== --f403043edb3050c84305542040e1-- From nobody Wed Jul 12 10:11:36 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CECD71316DB for ; Wed, 12 Jul 2017 10:11:34 -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 7zigwPHo66pc for ; Wed, 12 Jul 2017 10:11:33 -0700 (PDT) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::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 38FDF131737 for ; Wed, 12 Jul 2017 10:11:33 -0700 (PDT) Received: by mail-vk0-x22c.google.com with SMTP id f68so13005157vkg.2 for ; Wed, 12 Jul 2017 10:11:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Z6UNbr0EGrFDU/TjO/hDcmt6D+nRNSW217daMXZ94wo=; b=WQGdlLdLABI5JH9GE6vs7mCaYOC+YFGbKM2k8gzC5mK9IikVoZJd+Sda1vetv1SjGD nZ4UilyW/+gIIzuWiyh//CrYLvjUS4r9SZGzMHQ+BzEPFpZ2H8p2QMNkhyZYM3UsXVR5 +IsYHWSjjES2+hyf/tR4wv/wdQtcZXw7baZEuxo2ZD6XHWR/33IKujwqoUEeD4a3hhpb 85qSHXEbbkUUi8W6QrnSGScf3HrVncHsMV7FscJOgeNl/m3L9vc8Cld7tPsc5VrbKW8Z knZTyIT+KOTeopMpebYb1Iy4j5EtIJe0Md1+INT91XBnvgM9YCuryD7K9jBU1GLMVNM7 ln7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Z6UNbr0EGrFDU/TjO/hDcmt6D+nRNSW217daMXZ94wo=; b=Hxh8QdYzPYaskfQQtFYxGIvQJIhSxyGZXapRcVGv+4tF3/npU8ZbLKHKdOpT9d3x6/ IExbZm4Ak7iWZmBsvUic49yAYdnxRz7n7JUPLiNqgd5r4bvU/eBNJ3/V8EkuPXB24zeO AIaz6EZ9yHJ4hmfNU4FsNahZSZixtEW88jT/YS2r2+/uNcGf/lJVbJbPyomdVI5EPYbd 95tIUHd+GsH1FhzDxXHeNVLOZiMIUa4FAvD4iuPOyX4MuRnRsWEJ47ifHYMvYh0mGvMr dFpS+WXwv0CPmn3th0zU+mL41SvEVTe1R1HE+UNFENsVzV20qxq1z2IErGZ5C8YzSELE Evnw== X-Gm-Message-State: AIVw111ESZ0P0uFARYIImo/NXYZPc08nEIoNHi8uwkONcl+4RVMs6hf9 /ZD4jPVAw7ZADC2n2WTAnQXeTkNuTVhWDnY= X-Received: by 10.31.4.19 with SMTP id 19mr2223799vke.54.1499879492041; Wed, 12 Jul 2017 10:11:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.74.202 with HTTP; Wed, 12 Jul 2017 10:11:11 -0700 (PDT) From: Bernard Aboba Date: Wed, 12 Jul 2017 10:11:11 -0700 Message-ID: To: slim@ietf.org Content-Type: multipart/alternative; boundary="001a1142a29a543f08055421e883" Archived-At: Subject: [Slim] draft-ietf-slim-negotiating-human-language: Issue 38 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, 12 Jul 2017 17:11:35 -0000 --001a1142a29a543f08055421e883 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable In reviewing open tickets against draft-ietf-slim-negotiating-human-language, it appears to me that Issue 38 remains unresolved. This issue was raised by ART AD Adam Roach in his review: =E2=80=8B https://mailarchive.ietf.org/arch/msg/slim/fZmbXKtwn1771DoZhh1Kt_kUWf4 " Aside -- I have a concern that negotiating language in SDP rather than SIP makes it necessary for proxies to look into SDP to make routing decisions, which is a pretty substantial layer violation (keep in mind, for example, that SIP was originally envisioned to contain S/MIME encrypted bodies, which would render the SDP unreadable by proxies). However, I note that section 5.1 indicates that this has issue been litigated in the working group already, and that it chose to do things in the way documented in the current draft." --001a1142a29a543f08055421e883 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In reviewing open tickets against=C2=A0draft-ietf-slim-neg= otiating-human-language, it appears to me that Issue 38 remains unresolved.= =C2=A0

This issue was raised by ART AD Adam Roac= h in his review:=C2=A0=E2=80=8Bhttps://mailarchive.iet= f.org/arch/msg/slim/fZmbXKtwn1771DoZhh1Kt_kUWf4

" A= side -- I have a concern that negotiating language in SDP rather

than SIP makes it necessary for proxies to look into SDP t= o make
routing decisions, which is a pretty substantial layer violation<= br>(keep in mind, for example, that SIP was originally envisioned to
con= tain S/MIME encrypted bodies, which would render the SDP
unreadable by p= roxies). However, I note that section 5.1 indicates
that this has issue = been litigated in the working group already, and
that it chose to do thi= ngs in the way documented in the current draft."

--001a1142a29a543f08055421e883-- From nobody Wed Jul 12 10:13:03 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CFB0127B73 for ; Wed, 12 Jul 2017 10:13:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oQKSaC2Elex4 for ; Wed, 12 Jul 2017 10:12:58 -0700 (PDT) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97CD812785F for ; Wed, 12 Jul 2017 10:12:58 -0700 (PDT) Received: by mail-vk0-x234.google.com with SMTP id y70so16433099vky.3 for ; Wed, 12 Jul 2017 10:12:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DbEb515r3ufOs1323BZ7+1hSGv14eUUbeSAS0glYFk0=; b=j2bYcQuzqYgbsbHaaBlJzA6ddfoheWQPdeRWbM9zeH8Fo4QITRoSEBvwVakELsyMuU 2g6W4oi4wHMLcG5LJb8s4on7322sD+5q2GizZg3UHeHe6WE53OuRx3vriYEQAIuJ1eVD aOx/90qP4AiBiLY8v+4z624bB0au6VEvWmqyX/G8wqK9axFbJfHXgvV0AoW61ItBY6r4 8gTA4anBDnrcNIDCHg2PEZ/oq3I+ce2QcT18CybqscWeZw4qEe/d0Lm3Z7qClfWaScUG 53Ge+rHkOOmC3xUX9nGZ1i9o1ZTEwfrDv6HCzFd/xXeerg/G+J1LYG7eRne4I8WpIeIw jAXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DbEb515r3ufOs1323BZ7+1hSGv14eUUbeSAS0glYFk0=; b=ENuHY4TM+Qme+V16DtuajOVcRyDQh3K4xJA5mke/PqyZiAfgyIJJ4GXVe1L1JL+WD+ iwHeuGR8bhyo5XWEUD3fYwJSmnVQWr5Ivg3aaZCCzWjq+m4PLuo1HB+nC4DMsh2//VZI tWgCCRSCYigSwezpu/xpvnGpnWAosRWZvY+ZIHebUJPmegZhb2AlhFAqxJDBTPrrhtKD 6aMkF+2xlpeou27RDwZaGYvxa5X6LgejTPRfGeOkcrv6xbn2k8b7tp/9LJwlmPRlQ4nk JZA7pqWK6FdDVbUe67mS19MTX1FcK9EIcgumATd9cPHxAINn0MCBiZsETwNSdiL94pdx 2ffg== X-Gm-Message-State: AIVw110EHFnkHaM1NAnseEdHEg565FVvpztyWcADRIDgnyoeeN6xUzU+ U7rFINcVX3nTYLRDAs2QiO5FXWmcZ30INx0= X-Received: by 10.31.64.135 with SMTP id n129mr1802763vka.64.1499879577332; Wed, 12 Jul 2017 10:12:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.74.202 with HTTP; Wed, 12 Jul 2017 10:12:36 -0700 (PDT) In-Reply-To: References: From: Bernard Aboba Date: Wed, 12 Jul 2017 10:12:36 -0700 Message-ID: To: slim@ietf.org Cc: Adam Roach Content-Type: multipart/alternative; boundary="001a1144743869b27d055421ed47" Archived-At: Subject: Re: [Slim] draft-ietf-slim-negotiating-human-language: Issue 38 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, 12 Jul 2017 17:13:02 -0000 --001a1144743869b27d055421ed47 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable To resolve Issue 38 which arose from Adam Roach's review, I would like to suggest the following revision for Section 1 and introduction of a new applicability section 1.1 as follows: 1. Introduction A mutually comprehensive language is helpful for human communication. This document addresses the negotiation of human (natural) language and media modality (spoken, signed, written) in real-time communications. A companion document [I-D.ietf-slim-multilangcontent] addresses language selection in email. Unless the caller and callee know each other or there is contextual or out-of- band information from which the language(s) and media modalities can be determined, there is a need for spoken, signed, or written languages to be negotiated based on the caller's needs and the callee's capabilities. This need applies to both emergency and non-emergency calls. For example, it is helpful for a caller to a company call center or a Public Safety Answering Point (PSAP) to be able to indicate preferred signed, written, and/or spoken languages, and for the callee to be able to indicate its capabilities in this area, allowing the call to proceed using the language(s) and media forms supported by both= . For various reasons, including the ability to establish multiple streams using different media (e.g., voice, text, video), it makes sense to use a per-stream negotiation mechanism known as the Session Description Protocol (SDP). Utilizing SDP enables the solution described in this document to be applied to all interactive communications negotiated using SDP, in emergency as well as non-emergency scenarios. By treating language as another SDP attribute that is negotiated along with other aspects of a media stream, it becomes possible to accommodate a range of users' needs and called party facilities. For example, some users may be able to speak several languages, but have a preference. Some called parties may support some of those languages internally but require the use of a translation service for others, or may have a limited number of call takers able to use certain languages. Another example would be a user who is able to speak but is deaf or hard-of-hearing and requires a voice stream plus a text stream. Making language a media attribute allows the standard session negotiation mechanism to handle this by providing the information and mechanism for the endpoints to make appropriate decisions. The term "negotiation" is used here rather than "indication" because human language (spoken/written/signed) can be negotiated in the same manner as media (audio/text/video) and codecs. For example, if we think of a user calling an airline reservation center, the user may have a set of languages he or she speaks, with perhaps preferences for one or a few, while the airline reservation center will support a fixed set of languages. Negotiation should select the user's most preferred language that is supported by the call center. Both sides should be aware of which language was negotiated. This is conceptually similar to the way other aspects of each media stream are negotiated using SDP (e.g., media type and codecs). Since this is a protocol mechanism, the user equipment (UE client) needs to know the user's preferred languages; a reasonable technique could include a configuration mechanism with a default of the language of the user interface. In some cases, a UE could tie language and media preferences, such as a preference for a video stream using a signed language and/or a text or audio stream using a written/spoken language. 1.1 Applicability Within this document, it is assumed that the negotiating endpoints have already been determined, so that a per-stream negotiation based on the Session Description Protocol (SDP) can proceed. However, when setting up interactive communications sessions it is first necessary to route signaling messages to the appropriate endpoint(s). This document does not address the problem of language-based routing. In order to enable intermediaries to make make routing decisions based on language and media capabilities, future documents may define extensions to the Session Initiation Protocol (SIP). On Wed, Jul 12, 2017 at 10:11 AM, Bernard Aboba wrote: > In reviewing open tickets against draft-ietf-slim-negotiating-human-langu= age, > it appears to me that Issue 38 remains unresolved. > > This issue was raised by ART AD Adam Roach in his review: =E2=80=8B > https://mailarchive.ietf.org/arch/msg/slim/fZmbXKtwn1771DoZhh1Kt_kUWf4 > > " Aside -- I have a concern that negotiating language in SDP rather > > than SIP makes it necessary for proxies to look into SDP to make > routing decisions, which is a pretty substantial layer violation > (keep in mind, for example, that SIP was originally envisioned to > contain S/MIME encrypted bodies, which would render the SDP > unreadable by proxies). However, I note that section 5.1 indicates > that this has issue been litigated in the working group already, and > that it chose to do things in the way documented in the current draft." > > --001a1144743869b27d055421ed47 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

To resolv= e Issue 38 which arose from Adam Roach's review, I would like to sugges= t the following revision for Section 1 and introduction of a new applicabil= ity section 1.1 as follows:=C2=A0

  1. Introduction

A mutually comprehensive language is helpful fo= r human communication.
This document addresses the negotiation of human = (natural) language
and media modality (spoken, signed, written) in real-= time communications.
A companion document [I-D.ietf-slim-multilangconten= t] addresses
language selection in email.

Unless the caller and ca= llee know each other or there is contextual or out-of-
band information = from which the language(s) and media modalities can
be determined, there= is a need for spoken, signed, or written languages
to be negotiated bas= ed on the caller's needs and the callee's capabilities.
This nee= d applies to both emergency and non-emergency calls.
For example, it is = helpful for a caller to a company call center
or a Public Safety Answeri= ng Point (PSAP) to be able to indicate
preferred signed, written, and/or= spoken languages, and for the callee
to be able to indicate its capabil= ities in this area, allowing
the call to proceed using the language(s) a= nd media forms supported by both.

For various reasons, including the = ability to
establish multiple streams using different media (e.g., voice= , text,
video), it makes sense to use a per-stream negotiation mechanism= known
as the Session Description Protocol (SDP). Utilizing SDP enables<= br>the solution described in this document to be applied to all
interact= ive communications negotiated using SDP, in emergency as well
as non-eme= rgency scenarios.

By treating language as another SDP attribute that = is negotiated along
with other aspects of a media stream, it becomes pos= sible to
accommodate a range of users' needs and called party facili= ties. For
example, some users may be able to speak several languages, bu= t have
a preference. Some called parties may support some of those
la= nguages internally but require the use of a translation service for
othe= rs, or may have a limited number of call takers able to use
certain lang= uages. Another example would be a user who is able to
speak but is deaf = or hard-of-hearing and requires a voice stream plus
a text stream. Makin= g language a media attribute allows the standard
session negotiation mec= hanism to handle this by providing the
information and mechanism for the= endpoints to make appropriate
decisions.

The term "negotiati= on" is used here rather than "indication" because
human l= anguage (spoken/written/signed) can be negotiated in the same
manner as = media (audio/text/video) and codecs. For example, if we think
of a user = calling an airline reservation center, the user may
have a set of langua= ges he or she speaks, with perhaps preferences
for one or a few, while t= he airline reservation center will support a
fixed set of languages. Neg= otiation should select the user's most
preferred language that is su= pported by the call center. Both sides
should be aware of which language= was negotiated. This is
conceptually similar to the way other aspects o= f each media stream
are negotiated using SDP (e.g., media type and codec= s).

Since this is a protocol mechanism, the user equipment (UE client= )
needs to know the user's preferred languages; a reasonable techniq= ue
could include a configuration mechanism with a default of the
lang= uage of the user interface. In some cases, a UE could tie
language and m= edia preferences, such as a preference for a video
stream using a signed= language and/or a text or audio stream using a
written/spoken language.=

1.1 A= pplicability

Within this document, it is assumed that the negotiating endpointshave already been determined, so that a per-stream negotiation
based on= the Session Description Protocol (SDP) can proceed.

However, when se= tting up interactive communications sessions it
is first necessary to ro= ute signaling messages to the appropriate
endpoint(s). This document doe= s not address the problem of
language-based routing. In order to enable = intermediaries to make
make routing decisions based on language and medi= a capabilities,
future documents may define extensions to the Session In= itiation
Protocol (SIP).


On Wed, Jul 12, 2017 at 10:11 AM, Bernard = Aboba <bernard.aboba@gmail.com> wrote:
In reviewing open tickets against=C2=A0= draft-ietf-slim-negotiating-human-language, it appears to me that Issu= e 38 remains unresolved.=C2=A0


--001a1144743869b27d055421ed47-- From nobody Wed Jul 12 10:21:36 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 935DA1296C6 for ; Wed, 12 Jul 2017 10:21:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MQlI5NFrHtgX for ; Wed, 12 Jul 2017 10:21:32 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B723126B7E for ; Wed, 12 Jul 2017 10:21:32 -0700 (PDT) Received: from Orochi.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v6CHLTxK037332 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 12 Jul 2017 12:21:30 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Orochi.local To: Bernard Aboba , slim@ietf.org References: From: Adam Roach Message-ID: Date: Wed, 12 Jul 2017 12:21:24 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------41AFD54B0C6F4622FD180AE7" Content-Language: en-US Archived-At: Subject: Re: [Slim] draft-ietf-slim-negotiating-human-language: Issue 38 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, 12 Jul 2017 17:21:35 -0000 This is a multi-part message in MIME format. --------------41AFD54B0C6F4622FD180AE7 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Thanks. The text in 1.1, in particular, addresses my concern. The rest of the revisions look good as well. /a On 7/12/17 12:12, Bernard Aboba wrote: > > To resolve Issue 38 which arose from Adam Roach's review, I would like > to suggest the following revision for Section 1 and introduction of a > new applicability section 1.1 as follows: > > 1. Introduction > > A mutually comprehensive language is helpful for human communication. > This document addresses the negotiation of human (natural) language > and media modality (spoken, signed, written) in real-time > communications. > A companion document [I-D.ietf-slim-multilangcontent] addresses > language selection in email. > > Unless the caller and callee know each other or there is > contextual or out-of- > band information from which the language(s) and media modalities can > be determined, there is a need for spoken, signed, or written > languages > to be negotiated based on the caller's needs and the callee's > capabilities. > This need applies to both emergency and non-emergency calls. > For example, it is helpful for a caller to a company call center > or a Public Safety Answering Point (PSAP) to be able to indicate > preferred signed, written, and/or spoken languages, and for the callee > to be able to indicate its capabilities in this area, allowing > the call to proceed using the language(s) and media forms > supported by both. > > For various reasons, including the ability to > establish multiple streams using different media (e.g., voice, text, > video), it makes sense to use a per-stream negotiation mechanism known > as the Session Description Protocol (SDP). Utilizing SDP enables > the solution described in this document to be applied to all > interactive communications negotiated using SDP, in emergency as well > as non-emergency scenarios. > > By treating language as another SDP attribute that is negotiated along > with other aspects of a media stream, it becomes possible to > accommodate a range of users' needs and called party facilities. For > example, some users may be able to speak several languages, but have > a preference. Some called parties may support some of those > languages internally but require the use of a translation service for > others, or may have a limited number of call takers able to use > certain languages. Another example would be a user who is able to > speak but is deaf or hard-of-hearing and requires a voice stream plus > a text stream. Making language a media attribute allows the standard > session negotiation mechanism to handle this by providing the > information and mechanism for the endpoints to make appropriate > decisions. > > The term "negotiation" is used here rather than "indication" because > human language (spoken/written/signed) can be negotiated in the same > manner as media (audio/text/video) and codecs. For example, if we > think > of a user calling an airline reservation center, the user may > have a set of languages he or she speaks, with perhaps preferences > for one or a few, while the airline reservation center will support a > fixed set of languages. Negotiation should select the user's most > preferred language that is supported by the call center. Both sides > should be aware of which language was negotiated. This is > conceptually similar to the way other aspects of each media stream > are negotiated using SDP (e.g., media type and codecs). > > Since this is a protocol mechanism, the user equipment (UE client) > needs to know the user's preferred languages; a reasonable technique > could include a configuration mechanism with a default of the > language of the user interface. In some cases, a UE could tie > language and media preferences, such as a preference for a video > stream using a signed language and/or a text or audio stream using a > written/spoken language. > > 1.1 Applicability > > Within this document, it is assumed that the negotiating endpoints > have already been determined, so that a per-stream negotiation > based on the Session Description Protocol (SDP) can proceed. > > However, when setting up interactive communications sessions it > is first necessary to route signaling messages to the appropriate > endpoint(s). This document does not address the problem of > language-based routing. In order to enable intermediaries to make > make routing decisions based on language and media capabilities, > future documents may define extensions to the Session Initiation > Protocol (SIP). > > > On Wed, Jul 12, 2017 at 10:11 AM, Bernard Aboba > > wrote: > > In reviewing open tickets > against draft-ietf-slim-negotiating-human-language, it appears to > me that Issue 38 remains unresolved. > > This issue was raised by ART AD Adam Roach in his review: > ​https://mailarchive.ietf.org/arch/msg/slim/fZmbXKtwn1771DoZhh1Kt_kUWf4 > > > " Aside -- I have a concern that negotiating language in SDP rather > > than SIP makes it necessary for proxies to look into SDP to make > routing decisions, which is a pretty substantial layer violation > (keep in mind, for example, that SIP was originally envisioned to > contain S/MIME encrypted bodies, which would render the SDP > unreadable by proxies). However, I note that section 5.1 indicates > that this has issue been litigated in the working group > already, and > that it chose to do things in the way documented in the > current draft." > > --------------41AFD54B0C6F4622FD180AE7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Thanks. The text in 1.1, in particular, addresses my concern. The rest of the revisions look good as well.

/a

On 7/12/17 12:12, Bernard Aboba wrote:

To resolve Issue 38 which arose from Adam Roach's review, I would like to suggest the following revision for Section 1 and introduction of a new applicability section 1.1 as follows: 

  1. Introduction

A mutually comprehensive language is helpful for human communication.
This document addresses the negotiation of human (natural) language
and media modality (spoken, signed, written) in real-time communications.
A companion document [I-D.ietf-slim-multilangcontent] addresses
language selection in email.

Unless the caller and callee know each other or there is contextual or out-of-
band information from which the language(s) and media modalities can
be determined, there is a need for spoken, signed, or written languages
to be negotiated based on the caller's needs and the callee's capabilities.
This need applies to both emergency and non-emergency calls.
For example, it is helpful for a caller to a company call center
or a Public Safety Answering Point (PSAP) to be able to indicate
preferred signed, written, and/or spoken languages, and for the callee
to be able to indicate its capabilities in this area, allowing
the call to proceed using the language(s) and media forms supported by both.

For various reasons, including the ability to
establish multiple streams using different media (e.g., voice, text,
video), it makes sense to use a per-stream negotiation mechanism known
as the Session Description Protocol (SDP). Utilizing SDP enables
the solution described in this document to be applied to all
interactive communications negotiated using SDP, in emergency as well
as non-emergency scenarios.

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

The term "negotiation" is used here rather than "indication" because
human language (spoken/written/signed) can be negotiated in the same
manner as media (audio/text/video) and codecs. For example, if we think
of a user calling an airline reservation center, the user may
have a set of languages he or she speaks, with perhaps preferences
for one or a few, while the airline reservation center will support a
fixed set of languages. Negotiation should select the user's most
preferred language that is supported by the call center. Both sides
should be aware of which language was negotiated. This is
conceptually similar to the way other aspects of each media stream
are negotiated using SDP (e.g., media type and codecs).

Since this is a protocol mechanism, the user equipment (UE client)
needs to know the user's preferred languages; a reasonable technique
could include a configuration mechanism with a default of the
language of the user interface. In some cases, a UE could tie
language and media preferences, such as a preference for a video
stream using a signed language and/or a text or audio stream using a
written/spoken language.

1.1 Applicability

Within this document, it is assumed that the negotiating endpoints
have already been determined, so that a per-stream negotiation
based on the Session Description Protocol (SDP) can proceed.

However, when setting up interactive communications sessions it
is first necessary to route signaling messages to the appropriate
endpoint(s). This document does not address the problem of
language-based routing. In order to enable intermediaries to make
make routing decisions based on language and media capabilities,
future documents may define extensions to the Session Initiation
Protocol (SIP).


On Wed, Jul 12, 2017 at 10:11 AM, Bernard Aboba <bernard.aboba@gmail.com> wrote:
In reviewing open tickets against draft-ietf-slim-negotiating-human-language, it appears to me that Issue 38 remains unresolved. 

This issue was raised by ART AD Adam Roach in his review: ​https://mailarchive.ietf.org/arch/msg/slim/fZmbXKtwn1771DoZhh1Kt_kUWf4

" Aside -- I have a concern that negotiating language in SDP rather

than SIP makes it necessary for proxies to look into SDP to make
routing decisions, which is a pretty substantial layer violation
(keep in mind, for example, that SIP was originally envisioned to
contain S/MIME encrypted bodies, which would render the SDP
unreadable by proxies). However, I note that section 5.1 indicates
that this has issue been litigated in the working group already, and
that it chose to do things in the way documented in the current draft."



--------------41AFD54B0C6F4622FD180AE7-- From nobody Thu Jul 13 00:42:07 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD324126C83 for ; Thu, 13 Jul 2017 00:42:06 -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 vUKjQbK4M36E for ; Thu, 13 Jul 2017 00:42:03 -0700 (PDT) Received: from bin-vsp-out-01.atm.binero.net (vsp-unauthed02.binero.net [195.74.38.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CED1130134 for ; Thu, 13 Jul 2017 00:42:03 -0700 (PDT) X-Halon-ID: bdf78308-679e-11e7-b24e-005056917a89 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [85.238.220.142]) by bin-vsp-out-01.atm.binero.net (Halon) with ESMTPSA id bdf78308-679e-11e7-b24e-005056917a89; Thu, 13 Jul 2017 09:41:55 +0200 (CEST) To: Adam Roach , Bernard Aboba , slim@ietf.org References: From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <275d4884-274e-8006-e46a-9abe52337df5@omnitor.se> Date: Thu, 13 Jul 2017 09:41:51 +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="------------81AE5B4683A3D2620B2D7CE6" Archived-At: Subject: Re: [Slim] draft-ietf-slim-negotiating-human-language: Issue 38 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, 13 Jul 2017 07:42:07 -0000 This is a multi-part message in MIME format. --------------81AE5B4683A3D2620B2D7CE6 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Bernard, I do not like the last sentence of 1.1. A long time ago, I stopped arguing for a SIP based solution when I realized that SDP is more often used than SIP in the WebRTC environment. Basing it on SDP makes it easier to convey the language and modality needs across the SIP / WebRTC border. (There is a complication that real-time text is an RTP stream on the SIP side and a multiplexed data channel on the WebRTC side, but there are solutions defined for handling SDP attribute conveyance for such situations. ) Indicating that a SIP solution may follow kind of invalidates the whole work we have done. I prefer to just leave out the last sentence in 1.1. Saying that routing is out-of-scope for this document is sufficient. Gunnar Den 2017-07-12 kl. 19:21, skrev Adam Roach: > Thanks. The text in 1.1, in particular, addresses my concern. The rest > of the revisions look good as well. > > /a > > On 7/12/17 12:12, Bernard Aboba wrote: >> >> To resolve Issue 38 which arose from Adam Roach's review, I would >> like to suggest the following revision for Section 1 and introduction >> of a new applicability section 1.1 as follows: >> >> 1. Introduction >> >> A mutually comprehensive language is helpful for human >> communication. >> This document addresses the negotiation of human (natural) language >> and media modality (spoken, signed, written) in real-time >> communications. >> A companion document [I-D.ietf-slim-multilangcontent] addresses >> language selection in email. >> >> Unless the caller and callee know each other or there is >> contextual or out-of- >> band information from which the language(s) and media modalities can >> be determined, there is a need for spoken, signed, or written >> languages >> to be negotiated based on the caller's needs and the callee's >> capabilities. >> This need applies to both emergency and non-emergency calls. >> For example, it is helpful for a caller to a company call center >> or a Public Safety Answering Point (PSAP) to be able to indicate >> preferred signed, written, and/or spoken languages, and for the >> callee >> to be able to indicate its capabilities in this area, allowing >> the call to proceed using the language(s) and media forms >> supported by both. >> >> For various reasons, including the ability to >> establish multiple streams using different media (e.g., voice, text, >> video), it makes sense to use a per-stream negotiation mechanism >> known >> as the Session Description Protocol (SDP). Utilizing SDP enables >> the solution described in this document to be applied to all >> interactive communications negotiated using SDP, in emergency as >> well >> as non-emergency scenarios. >> >> By treating language as another SDP attribute that is negotiated >> along >> with other aspects of a media stream, it becomes possible to >> accommodate a range of users' needs and called party facilities. For >> example, some users may be able to speak several languages, but have >> a preference. Some called parties may support some of those >> languages internally but require the use of a translation service >> for >> others, or may have a limited number of call takers able to use >> certain languages. Another example would be a user who is able to >> speak but is deaf or hard-of-hearing and requires a voice stream >> plus >> a text stream. Making language a media attribute allows the standard >> session negotiation mechanism to handle this by providing the >> information and mechanism for the endpoints to make appropriate >> decisions. >> >> The term "negotiation" is used here rather than "indication" because >> human language (spoken/written/signed) can be negotiated in the same >> manner as media (audio/text/video) and codecs. For example, if we >> think >> of a user calling an airline reservation center, the user may >> have a set of languages he or she speaks, with perhaps preferences >> for one or a few, while the airline reservation center will >> support a >> fixed set of languages. Negotiation should select the user's most >> preferred language that is supported by the call center. Both sides >> should be aware of which language was negotiated. This is >> conceptually similar to the way other aspects of each media stream >> are negotiated using SDP (e.g., media type and codecs). >> >> Since this is a protocol mechanism, the user equipment (UE client) >> needs to know the user's preferred languages; a reasonable technique >> could include a configuration mechanism with a default of the >> language of the user interface. In some cases, a UE could tie >> language and media preferences, such as a preference for a video >> stream using a signed language and/or a text or audio stream using a >> written/spoken language. >> >> 1.1 Applicability >> >> Within this document, it is assumed that the negotiating endpoints >> have already been determined, so that a per-stream negotiation >> based on the Session Description Protocol (SDP) can proceed. >> >> However, when setting up interactive communications sessions it >> is first necessary to route signaling messages to the appropriate >> endpoint(s). This document does not address the problem of >> language-based routing. In order to enable intermediaries to make >> make routing decisions based on language and media capabilities, >> future documents may define extensions to the Session Initiation >> Protocol (SIP). >> >> >> On Wed, Jul 12, 2017 at 10:11 AM, Bernard Aboba >> > wrote: >> >> In reviewing open tickets >> against draft-ietf-slim-negotiating-human-language, it appears to >> me that Issue 38 remains unresolved. >> >> This issue was raised by ART AD Adam Roach in his review: >> ​https://mailarchive.ietf.org/arch/msg/slim/fZmbXKtwn1771DoZhh1Kt_kUWf4 >> >> >> " Aside -- I have a concern that negotiating language in SDP rather >> >> than SIP makes it necessary for proxies to look into SDP to make >> routing decisions, which is a pretty substantial layer violation >> (keep in mind, for example, that SIP was originally >> envisioned to >> contain S/MIME encrypted bodies, which would render the SDP >> unreadable by proxies). However, I note that section 5.1 >> indicates >> that this has issue been litigated in the working group >> already, and >> that it chose to do things in the way documented in the >> current draft." >> >> > > > > > _______________________________________________ > 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 --------------81AE5B4683A3D2620B2D7CE6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

Bernard,

I do not like the last sentence of 1.1. A long time ago, I stopped arguing for a SIP based solution when I realized that SDP is more often used than SIP in the WebRTC environment. Basing it on SDP makes it easier to convey the language and modality needs across the SIP / WebRTC border. (There is a complication that real-time text is an RTP stream on the SIP side and a multiplexed data channel on the WebRTC side, but there are solutions defined for handling SDP attribute conveyance for such situations. )

Indicating that a SIP solution may follow kind of invalidates the whole work we have done. I prefer to just leave out the last sentence in 1.1. Saying that routing is out-of-scope for this document is sufficient.

Gunnar



Den 2017-07-12 kl. 19:21, skrev Adam Roach:
Thanks. The text in 1.1, in particular, addresses my concern. The rest of the revisions look good as well.

/a

On 7/12/17 12:12, Bernard Aboba wrote:

To resolve Issue 38 which arose from Adam Roach's review, I would like to suggest the following revision for Section 1 and introduction of a new applicability section 1.1 as follows:

 1. Introduction

    A mutually comprehensive language is helpful for human communication.
    This document addresses the negotiation of human (natural) language
    and media modality (spoken, signed, written) in real-time
    communications.
    A companion document [I-D.ietf-slim-multilangcontent] addresses
    language selection in email.

    Unless the caller and callee know each other or there is
    contextual or out-of-
    band information from which the language(s) and media modalities can
    be determined, there is a need for spoken, signed, or written
    languages
    to be negotiated based on the caller's needs and the callee's
    capabilities.
    This need applies to both emergency and non-emergency calls.
    For example, it is helpful for a caller to a company call center
    or a Public Safety Answering Point (PSAP) to be able to indicate
    preferred signed, written, and/or spoken languages, and for the callee
    to be able to indicate its capabilities in this area, allowing
    the call to proceed using the language(s) and media forms
    supported by both.

    For various reasons, including the ability to
    establish multiple streams using different media (e.g., voice, text,
    video), it makes sense to use a per-stream negotiation mechanism known
    as the Session Description Protocol (SDP). Utilizing SDP enables
    the solution described in this document to be applied to all
    interactive communications negotiated using SDP, in emergency as well
    as non-emergency scenarios.

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

    The term "negotiation" is used here rather than "indication" because
    human language (spoken/written/signed) can be negotiated in the same
    manner as media (audio/text/video) and codecs. For example, if we
    think
    of a user calling an airline reservation center, the user may
    have a set of languages he or she speaks, with perhaps preferences
    for one or a few, while the airline reservation center will support a
    fixed set of languages. Negotiation should select the user's most
    preferred language that is supported by the call center. Both sides
    should be aware of which language was negotiated. This is
    conceptually similar to the way other aspects of each media stream
    are negotiated using SDP (e.g., media type and codecs).

    Since this is a protocol mechanism, the user equipment (UE client)
    needs to know the user's preferred languages; a reasonable technique
    could include a configuration mechanism with a default of the
    language of the user interface. In some cases, a UE could tie
    language and media preferences, such as a preference for a video
    stream using a signed language and/or a text or audio stream using a
    written/spoken language.

1.1 Applicability

    Within this document, it is assumed that the negotiating endpoints
    have already been determined, so that a per-stream negotiation
    based on the Session Description Protocol (SDP) can proceed.

    However, when setting up interactive communications sessions it
    is first necessary to route signaling messages to the appropriate
    endpoint(s). This document does not address the problem of
    language-based routing. In order to enable intermediaries to make
    make routing decisions based on language and media capabilities,
    future documents may define extensions to the Session Initiation
    Protocol (SIP).


On Wed, Jul 12, 2017 at 10:11 AM, Bernard Aboba <bernard.aboba@gmail.com <mailto:bernard.aboba@gmail.com>> wrote:

    In reviewing open tickets
    against draft-ietf-slim-negotiating-human-language, it appears to
    me that Issue 38 remains unresolved.

    This issue was raised by ART AD Adam Roach in his review:
    ​https://mailarchive.ietf.org/arch/msg/slim/fZmbXKtwn1771DoZhh1Kt_kUWf4
    <https://mailarchive.ietf.org/arch/msg/slim/fZmbXKtwn1771DoZhh1Kt_kUWf4>

    " Aside -- I have a concern that negotiating language in SDP rather

        than SIP makes it necessary for proxies to look into SDP to make
        routing decisions, which is a pretty substantial layer violation
        (keep in mind, for example, that SIP was originally envisioned to
        contain S/MIME encrypted bodies, which would render the SDP
        unreadable by proxies). However, I note that section 5.1 indicates
        that this has issue been litigated in the working group
        already, and
        that it chose to do things in the way documented in the
        current draft." 






_______________________________________________
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
--------------81AE5B4683A3D2620B2D7CE6-- From nobody Thu Jul 13 09:12: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 A4C9C131475 for ; Thu, 13 Jul 2017 09:12:24 -0700 (PDT) X-Quarantine-ID: <4Yq9wURTG8br> 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 4Yq9wURTG8br for ; Thu, 13 Jul 2017 09:12:23 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 54C4713146A for ; Thu, 13 Jul 2017 09:12:23 -0700 (PDT) Received: from [10.197.191.116] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Thu, 13 Jul 2017 09:15:24 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Mailer: Eudora for Mac OS X Date: Thu, 13 Jul 2017 09:12:08 -0700 To: 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] draft-ietf-slim-negotiating-human-language: Issue 38 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, 13 Jul 2017 16:12:24 -0000 At 10:11 AM -0700 7/12/17, Bernard Aboba wrote: > In reviewing open tickets=20 > against draft-ietf-slim-negotiating-human-language,=20 > it appears to me that Issue 38 remains=20 > unresolved. > > This issue was raised by ART AD Adam Roach in=20 > his=20 > review: =D0https://mailarchive.ietf.org/arch/msg/slim/fZmbXKtwn1771DoZhh1Kt_kU= Wf4 > > " Aside -- I have a concern that negotiating language in SDP rather > > than SIP makes it necessary for proxies to look into SDP to make > routing decisions, which is a pretty substantial layer violation > (keep in mind, for example, that SIP was originally envisioned to > contain S/MIME encrypted bodies, which would render the SDP > unreadable by proxies). However, I note that section 5.1 indicates > that this has issue been litigated in the working group already, and > that it chose to do things in the way documented in the current draft." The group explicitly decided to keep routing out=20 of scope of this draft. Section 1 says: To reduce the complexity of the solution, this document focuses on negotiating language per media; routing is out of scope. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- When I was younger, I could remember anything, whether it had happened or not. --Mark Twain From nobody Thu Jul 13 09:25:28 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D046B13147F for ; Thu, 13 Jul 2017 09:25:27 -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 aogJEeJ7cFge for ; Thu, 13 Jul 2017 09:25:26 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id EE1BC1270A0 for ; Thu, 13 Jul 2017 09:25:25 -0700 (PDT) Received: from [10.197.191.116] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Thu, 13 Jul 2017 09:28:28 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Mailer: Eudora for Mac OS X Date: Thu, 13 Jul 2017 09:25:18 -0700 To: Bernard Aboba , slim@ietf.org From: Randall Gellens Cc: Adam Roach Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Slim] draft-ietf-slim-negotiating-human-language: Issue 38 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, 13 Jul 2017 16:25:28 -0000 At 10:12 AM -0700 7/12/17, Bernard Aboba wrote: > To resolve Issue 38 which arose from Adam Roach's review, I am not clear on why we need to say more than=20 what we already say, which is that routing is out=20 of scope. > I would like to suggest the following revision=20 > for Section 1 and introduction of a new=20 > applicability section 1.1 as follows: > > 1. Introduction > > A mutually comprehensive language is helpful for human communication. Why do you want to change "comprehensible" to "comprehensive"? > This document addresses the negotiation of human (natural) language > and media modality (spoken, signed, written) in real-time communications. > A companion document [I-D.ietf-slim-multilangcontent] addresses > language selection in email. > > Unless the caller and callee know each other or=20 > there is contextual or out-of- > band information from which the language(s) and media modalities can > be determined, there is a need for spoken, signed, or written languages > to be negotiated based on the caller's needs and the callee's capabilitie= s. > This need applies to both emergency and non-emergency calls. > For example, it is helpful for a caller to a company call center > or a Public Safety Answering Point (PSAP) to be able to indicate > preferred signed, written, and/or spoken languages, and for the callee > to be able to indicate its capabilities in this area, allowing > the call to proceed using the language(s) and media forms supported by bo= th. > > For various reasons, including the ability to > establish multiple streams using different media (e.g., voice, text, > video), it makes sense to use a per-stream negotiation mechanism known > as the Session Description Protocol (SDP). Utilizing SDP enables > the solution described in this document to be applied to all > interactive communications negotiated using SDP, in emergency as well > as non-emergency scenarios. > > By treating language as another SDP attribute that is negotiated along > with other aspects of a media stream, it becomes possible to > accommodate a range of users' needs and called party facilities. For > example, some users may be able to speak several languages, but have > a preference. Some called parties may support some of those > languages internally but require the use of a translation service for > others, or may have a limited number of call takers able to use > certain languages. Another example would be a user who is able to > speak but is deaf or hard-of-hearing and requires a voice stream plus > a text stream. Making language a media attribute allows the standard > session negotiation mechanism to handle this by providing the > information and mechanism for the endpoints to make appropriate > decisions. > > The term "negotiation" is used here rather than "indication" because > human language (spoken/written/signed) can be negotiated in the same > manner as media (audio/text/video) and codecs. For example, if we think > of a user calling an airline reservation center, the user may > have a set of languages he or she speaks, with perhaps preferences > for one or a few, while the airline reservation center will support a > fixed set of languages. Negotiation should select the user's most > preferred language that is supported by the call center. Both sides > should be aware of which language was negotiated. This is > conceptually similar to the way other aspects of each media stream > are negotiated using SDP (e.g., media type and codecs). > > Since this is a protocol mechanism, the user equipment (UE client) > needs to know the user's preferred languages; a reasonable technique > could include a configuration mechanism with a default of the > language of the user interface. In some cases, a UE could tie > language and media preferences, such as a preference for a video > stream using a signed language and/or a text or audio stream using a > written/spoken language. Aside from "comprehensive," the rest of this text looks fine. > > 1.1 Applicability > > Within this document, it is assumed that the negotiating endpoints > have already been determined, so that a per-stream negotiation > based on the Session Description Protocol (SDP) can proceed. > > However, when setting up interactive communications sessions it > is first necessary to route signaling messages to the appropriate > endpoint(s). This document does not address the problem of > language-based routing. In order to enable intermediaries to make > make routing decisions based on language and media capabilities, > future documents may define extensions to the Session Initiation > Protocol (SIP). I'd suggest deleting the last sentence, as I=20 don't see the benefit of speculating in this=20 draft on what future drafts might do. --Randy > > > On Wed, Jul 12, 2017 at 10:11 AM, Bernard Aboba=20 > <bernard.aboba@gmail.com>=20 > wrote: > > In reviewing open tickets=20 > against draft-ietf-slim-negotiating-human-language,=20 > it appears to me that Issue 38 remains=20 > unresolved. > > This issue was raised by ART AD Adam Roach in=20 > his=20 > review: =D0https://mailarchive.ietf.org/arch/msg/slim/fZmbXKtwn1771DoZhh1Kt_kU= Wf4 > > " Aside -- I have a concern that negotiating language in SDP rather > > than SIP makes it necessary for proxies to look into SDP to make > routing decisions, which is a pretty substantial layer violation > (keep in mind, for example, that SIP was originally envisioned to > contain S/MIME encrypted bodies, which would render the SDP > unreadable by proxies). However, I note that section 5.1 indicates > that this has issue been litigated in the working group already, and > that it chose to do things in the way documented in the current draft." > > > > _______________________________________________ > 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: --------------- Beware of programmers who carry screwdrivers. --Leonard Brandwein From nobody Thu Jul 13 10:09:51 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 25A7212F257 for ; Thu, 13 Jul 2017 10:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7cra71GXs7XC for ; Thu, 13 Jul 2017 10:09:47 -0700 (PDT) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 447B51298BA for ; Thu, 13 Jul 2017 10:09:47 -0700 (PDT) Received: by mail-ua0-x236.google.com with SMTP id g13so19011646uaj.0 for ; Thu, 13 Jul 2017 10:09:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=yOIsKeYIGg59OX71oVUnHmUcSU4eoNqqoV5obGHH7cE=; b=C9uOz8sG9Q6/w9wgkC+660kMmZ9JsfUFl13c+B71LLl9+1rrIU5tiM7EY09FlaqPzx +l1BdVD3uY2MrSaz62ykwoTnclcPe2x7RUFZ73Lz9lDOxjonys2GcYAU8RVdcl4xExqG vYFdH/NnX8YJm8KdWDfi6miagaPqFssrdWew9o5cYgxkRBXdl+gBtmdAz9744o4YTzwe xlzYqxjXTMlnT29aRXsu0OAbOmwy4256cU027odcHKN9o/HON/TSevP7tpJ2jEBfH8Kz dYXjN3r8petWJ/w1Yk2qUZgGKOGeE3i0cJBZ/eDkwbaSwaeND0wASvRMgzDTGlcsjWh4 5vug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=yOIsKeYIGg59OX71oVUnHmUcSU4eoNqqoV5obGHH7cE=; b=FFWJjMtbL2jWEUMue8cwwlcxT6NWCyVIeikCcuW2IDGuDsB8UzEYZ7Tvdk2BdqcQZU YR9RxdasxakD1E3iPBsqtNziHP/Z2cOIMkwPItOU9nXvujFgqAGYcgbtFi1Qe28vymWS xIBKB75WxbFdh0VVe+1fyZaUaWXTiZmmeomdTiFx+E8T8uJzL0i8XMlD0IQlzgtCKaLC 1qKuJyw4nPWKVHlHiWiazM8HwFBCzCz1tKmayOMXANTNwrFLfN1lNlQWi00hGN4zhXgd ZjCF5UTGPN1OmhC1mKgnh1SiJOPKBPoGJtE+tSeM6ocTmhbwK1rqqqtT/FylIVtx4J1/ qJzQ== X-Gm-Message-State: AIVw1100jJiKTyr7FToNCMNuMSVGnL4tFMkSWh9vZuvlILMf2BbI06yw 7UvbRu7A2+yAMpix4nqexciEGvmzXu52gpA= X-Received: by 10.176.2.22 with SMTP id 22mr2605043uas.0.1499965786016; Thu, 13 Jul 2017 10:09:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.35.80 with HTTP; Thu, 13 Jul 2017 10:09:25 -0700 (PDT) In-Reply-To: <275d4884-274e-8006-e46a-9abe52337df5@omnitor.se> References: <275d4884-274e-8006-e46a-9abe52337df5@omnitor.se> From: Bernard Aboba Date: Thu, 13 Jul 2017 10:09:25 -0700 Message-ID: To: =?UTF-8?Q?Gunnar_Hellstr=C3=B6m?= Cc: Adam Roach , slim@ietf.org Content-Type: multipart/alternative; boundary="001a113fa1e6d9d0b4055435ffc4" Archived-At: Subject: Re: [Slim] draft-ietf-slim-negotiating-human-language: Issue 38 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, 13 Jul 2017 17:09:50 -0000 --001a113fa1e6d9d0b4055435ffc4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Gunnar said: " A long time ago, I stopped arguing for a SIP based solution when I realized that SDP is more often used than SIP in the WebRTC environment. Basing it on SDP makes it easier to convey the language and modality needs across the SIP / WebRTC border. (There is a complication that real-time text is an RTP stream on the SIP side and a multiplexed data channel on the WebRTC side, but there are solutions defined for handling SDP attribute conveyance for such situations. ). Indicating that a SIP solution may follow kind of invalidates the whole work we have done." [BA] The group did indeed converge on SDP as the mechanism to negotiate language and media modality (the subject of the draft). As I read it, the SDP Directorate review is not a request to reconsider that decision, but rather a request for the document to more clearly indicate that SDP is not being proposed as a solution to the routing problem. "I prefer to just leave out the last sentence in 1.1. Saying that routing is out-of-scope for this document is sufficient." [BA] Adam and Gunnar - Would the following work? 1.1 Applicability Within this document, it is assumed that the negotiating endpoints have already been determined, so that a per-stream negotiation based on the Session Description Protocol (SDP) can proceed. However, when setting up interactive communications sessions it is first necessary to route signaling messages to the appropriate endpoint(s). This document does not address the problem of routing based on language and media capabilities. On Thu, Jul 13, 2017 at 12:41 AM, Gunnar Hellstr=C3=B6m < gunnar.hellstrom@omnitor.se> wrote: > Bernard, > > I do not like the last sentence of 1.1. A long time ago, I stopped arguin= g > for a SIP based solution when I realized that SDP is more often used than > SIP in the WebRTC environment. Basing it on SDP makes it easier to convey > the language and modality needs across the SIP / WebRTC border. (There is= a > complication that real-time text is an RTP stream on the SIP side and a > multiplexed data channel on the WebRTC side, but there are solutions > defined for handling SDP attribute conveyance for such situations. ) > > Indicating that a SIP solution may follow kind of invalidates the whole > work we have done. I prefer to just leave out the last sentence in 1.1. > Saying that routing is out-of-scope for this document is sufficient. > Gunnar > > > > Den 2017-07-12 kl. 19:21, skrev Adam Roach: > > Thanks. The text in 1.1, in particular, addresses my concern. The rest of > the revisions look good as well. > > /a > > On 7/12/17 12:12, Bernard Aboba wrote: > > > To resolve Issue 38 which arose from Adam Roach's review, I would like to > suggest the following revision for Section 1 and introduction of a new > applicability section 1.1 as follows: > > 1. Introduction > > A mutually comprehensive language is helpful for human communication. > This document addresses the negotiation of human (natural) language > and media modality (spoken, signed, written) in real-time > communications. > A companion document [I-D.ietf-slim-multilangcontent] addresses > language selection in email. > > Unless the caller and callee know each other or there is > contextual or out-of- > band information from which the language(s) and media modalities can > be determined, there is a need for spoken, signed, or written > languages > to be negotiated based on the caller's needs and the callee's > capabilities. > This need applies to both emergency and non-emergency calls. > For example, it is helpful for a caller to a company call center > or a Public Safety Answering Point (PSAP) to be able to indicate > preferred signed, written, and/or spoken languages, and for the calle= e > to be able to indicate its capabilities in this area, allowing > the call to proceed using the language(s) and media forms > supported by both. > > For various reasons, including the ability to > establish multiple streams using different media (e.g., voice, text, > video), it makes sense to use a per-stream negotiation mechanism know= n > as the Session Description Protocol (SDP). Utilizing SDP enables > the solution described in this document to be applied to all > interactive communications negotiated using SDP, in emergency as well > as non-emergency scenarios. > > By treating language as another SDP attribute that is negotiated alon= g > with other aspects of a media stream, it becomes possible to > accommodate a range of users' needs and called party facilities. For > example, some users may be able to speak several languages, but have > a preference. Some called parties may support some of those > languages internally but require the use of a translation service for > others, or may have a limited number of call takers able to use > certain languages. Another example would be a user who is able to > speak but is deaf or hard-of-hearing and requires a voice stream plus > a text stream. Making language a media attribute allows the standard > session negotiation mechanism to handle this by providing the > information and mechanism for the endpoints to make appropriate > decisions. > > The term "negotiation" is used here rather than "indication" because > human language (spoken/written/signed) can be negotiated in the same > manner as media (audio/text/video) and codecs. For example, if we > think > of a user calling an airline reservation center, the user may > have a set of languages he or she speaks, with perhaps preferences > for one or a few, while the airline reservation center will support a > fixed set of languages. Negotiation should select the user's most > preferred language that is supported by the call center. Both sides > should be aware of which language was negotiated. This is > conceptually similar to the way other aspects of each media stream > are negotiated using SDP (e.g., media type and codecs). > > Since this is a protocol mechanism, the user equipment (UE client) > needs to know the user's preferred languages; a reasonable technique > could include a configuration mechanism with a default of the > language of the user interface. In some cases, a UE could tie > language and media preferences, such as a preference for a video > stream using a signed language and/or a text or audio stream using a > written/spoken language. > > 1.1 Applicability > > Within this document, it is assumed that the negotiating endpoints > have already been determined, so that a per-stream negotiation > based on the Session Description Protocol (SDP) can proceed. > > However, when setting up interactive communications sessions it > is first necessary to route signaling messages to the appropriate > endpoint(s). This document does not address the problem of > language-based routing. In order to enable intermediaries to make > make routing decisions based on language and media capabilities, > future documents may define extensions to the Session Initiation > Protocol (SIP). > > > On Wed, Jul 12, 2017 at 10:11 AM, Bernard Aboba > wrote: > > In reviewing open tickets > against draft-ietf-slim-negotiating-human-language, it appears to > me that Issue 38 remains unresolved. > > This issue was raised by ART AD Adam Roach in his review: > =E2=80=8Bhttps://mailarchive.ietf.org/arch/msg/slim/ > fZmbXKtwn1771DoZhh1Kt_kUWf4 > fZmbXKtwn1771DoZhh1Kt_kUWf4> > > > " Aside -- I have a concern that negotiating language in SDP rather > > than SIP makes it necessary for proxies to look into SDP to make > routing decisions, which is a pretty substantial layer violation > (keep in mind, for example, that SIP was originally envisioned to > contain S/MIME encrypted bodies, which would render the SDP > unreadable by proxies). However, I note that section 5.1 indicate= s > that this has issue been litigated in the working group > already, and > that it chose to do things in the way documented in the > current draft." > > > > > > > _______________________________________________ > SLIM mailing listSLIM@ietf.orghttps://www.ietf.org/mailman/listinfo/slim > > > -- > ----------------------------------------- > Gunnar Hellstr=C3=B6m > Omnitorgunnar.hellstrom@omnitor.se > +46 708 204 288 > > --001a113fa1e6d9d0b4055435ffc4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Gunnar said:=C2=A0

"=C2=A0A long tim= e ago, I stopped arguing for a SIP based solution when I realized that SDP = is more often used than SIP in the WebRTC environment. Basing it on SDP mak= es it easier to convey the language and modality needs across the SIP / Web= RTC border. (There is a complication that real-time text is an RTP stream o= n the SIP side and a multiplexed data channel on the WebRTC side, but there= are solutions defined for handling SDP attribute conveyance for such situa= tions. ).=C2=A0Indicating that a SI= P solution may follow kind of invalidates the whole work we have done."

[BA= ] =C2=A0The group did indeed converge on SDP as the mechanism to negotiate = language and media modality (the subject of the draft).=C2=A0 As I read it,= the SDP Directorate review is not a request to reconsider that decision, b= ut rather a request for the document to more clearly indicate that SDP is n= ot being proposed as a solution to the routing problem.=C2=A0
<= div>
"I prefer to = just leave out the last sentence in 1.1. Saying that routing is out-of-scop= e for this document is sufficient."

[BA]= =C2=A0Adam and Gunnar - Would the following work?=C2=A0
<= span style=3D"font-size:12.8px">
1.1 Applicability

Within this document, it is assumed that the negotiating endpoints
have already been determined, so that a per-stream negotiation
based on the Session Description Protocol (SDP) can proceed.

However, when setting up interactive communications sessions it
is first necessary to route signaling messages to the appropriate
endpoint(s). This document does not address the problem of
routing based on language and media capabilities.



On Thu, Jul 13, 2017 at 12:41 = AM, Gunnar Hellstr=C3=B6m <gunnar.hellstrom@omnitor.se> wrote:
=20 =20 =20

Bernard,

I do not like the last sentence of 1.1. A long time ago, I stopped arguing for a SIP based solution when I realized that SDP is more often used than SIP in the WebRTC environment. Basing it on SDP makes it easier to convey the language and modality needs across the SIP / WebRTC border. (There is a complication that real-time text is an RTP stream on the SIP side and a multiplexed data channel on the WebRTC side, but there are solutions defined for handling SDP attribute conveyance for such situations. )

Indicating that a SIP solution may follow kind of invalidates the whole work we have done. I prefer to just leave out the last sentence in 1.1. Saying that routing is out-of-scope for this document is sufficient.

Gunnar



Den 2017-07-12 kl. 19= :21, skrev Adam Roach:
Thanks. The text in 1= .1, in particular, addresses my concern. The rest of the revisions look good as well.

/a

On 7/12/17 12:12, Bernard Aboba wrote:

To resolve Issue 38 which arose from Adam Roach's review, I would like to suggest the following revision for Section 1 and introduction of a new applicability section 1.1 as follows:

=C2=A01. Introduction

=C2=A0=C2=A0=C2=A0 A mutually comprehensive language is helpful for= human communication.
=C2=A0=C2=A0=C2=A0 This document addresses the negotiation of human= (natural) language
=C2=A0=C2=A0=C2=A0 and media modality (spoken, signed, written) in = real-time
=C2=A0=C2=A0=C2=A0 communications.
=C2=A0=C2=A0=C2=A0 A companion document [I-D.ietf-slim-multila= ngcontent] addresses
=C2=A0=C2=A0=C2=A0 language selection in email.

=C2=A0=C2=A0=C2=A0 Unless the caller and callee know each other or = there is
=C2=A0=C2=A0=C2=A0 contextual or out-of-
=C2=A0=C2=A0=C2=A0 band information from which the language(s) and = media modalities can
=C2=A0=C2=A0=C2=A0 be determined, there is a need for spoken, signe= d, or written
=C2=A0=C2=A0=C2=A0 languages
=C2=A0=C2=A0=C2=A0 to be negotiated based on the caller's needs= and the callee's
=C2=A0=C2=A0=C2=A0 capabilities.
=C2=A0=C2=A0=C2=A0 This need applies to both emergency and non-emer= gency calls.
=C2=A0=C2=A0=C2=A0 For example, it is helpful for a caller to a com= pany call center
=C2=A0=C2=A0=C2=A0 or a Public Safety Answering Point (PSAP) to be = able to indicate
=C2=A0=C2=A0=C2=A0 preferred signed, written, and/or spoken languag= es, and for the callee
=C2=A0=C2=A0=C2=A0 to be able to indicate its capabilities in this = area, allowing
=C2=A0=C2=A0=C2=A0 the call to proceed using the language(s) and me= dia forms
=C2=A0=C2=A0=C2=A0 supported by both.

=C2=A0=C2=A0=C2=A0 For various reasons, including the ability to
=C2=A0=C2=A0=C2=A0 establish multiple streams using different media= (e.g., voice, text,
=C2=A0=C2=A0=C2=A0 video), it makes sense to use a per-stream negot= iation mechanism known
=C2=A0=C2=A0=C2=A0 as the Session Description Protocol (SDP). Utili= zing SDP enables
=C2=A0=C2=A0=C2=A0 the solution described in this document to be ap= plied to all
=C2=A0=C2=A0=C2=A0 interactive communications negotiated using SDP,= in emergency as well
=C2=A0=C2=A0=C2=A0 as non-emergency scenarios.

=C2=A0=C2=A0=C2=A0 By treating language as another SDP attribute th= at is negotiated along
=C2=A0=C2=A0=C2=A0 with other aspects of a media stream, it becomes= possible to
=C2=A0=C2=A0=C2=A0 accommodate a range of users' needs and call= ed party facilities. For
=C2=A0=C2=A0=C2=A0 example, some users may be able to speak several= languages, but have
=C2=A0=C2=A0=C2=A0 a preference. Some called parties may support so= me of those
=C2=A0=C2=A0=C2=A0 languages internally but require the use of a tr= anslation service for
=C2=A0=C2=A0=C2=A0 others, or may have a limited number of call tak= ers able to use
=C2=A0=C2=A0=C2=A0 certain languages. Another example would be a us= er who is able to
=C2=A0=C2=A0=C2=A0 speak but is deaf or hard-of-hearing and require= s a voice stream plus
=C2=A0=C2=A0=C2=A0 a text stream. Making language a media attribute= allows the standard
=C2=A0=C2=A0=C2=A0 session negotiation mechanism to handle this by = providing the
=C2=A0=C2=A0=C2=A0 information and mechanism for the endpoints to m= ake appropriate
=C2=A0=C2=A0=C2=A0 decisions.

=C2=A0=C2=A0=C2=A0 The term "negotiation" is used here ra= ther than "indication" because
=C2=A0=C2=A0=C2=A0 human language (spoken/written/signed) can be ne= gotiated in the same
=C2=A0=C2=A0=C2=A0 manner as media (audio/text/video) and codecs. F= or example, if we
=C2=A0=C2=A0=C2=A0 think
=C2=A0=C2=A0=C2=A0 of a user calling an airline reservation center,= the user may
=C2=A0=C2=A0=C2=A0 have a set of languages he or she speaks, with p= erhaps preferences
=C2=A0=C2=A0=C2=A0 for one or a few, while the airline reservation = center will support a
=C2=A0=C2=A0=C2=A0 fixed set of languages. Negotiation should selec= t the user's most
=C2=A0=C2=A0=C2=A0 preferred language that is supported by the call= center. Both sides
=C2=A0=C2=A0=C2=A0 should be aware of which language was negotiated= . This is
=C2=A0=C2=A0=C2=A0 conceptually similar to the way other aspects of= each media stream
=C2=A0=C2=A0=C2=A0 are negotiated using SDP (e.g., media type and c= odecs).

=C2=A0=C2=A0=C2=A0 Since this is a protocol mechanism, the user equ= ipment (UE client)
=C2=A0=C2=A0=C2=A0 needs to know the user's preferred languages= ; a reasonable technique
=C2=A0=C2=A0=C2=A0 could include a configuration mechanism with a d= efault of the
=C2=A0=C2=A0=C2=A0 language of the user interface. In some cases, a= UE could tie
=C2=A0=C2=A0=C2=A0 language and media preferences, such as a prefer= ence for a video
=C2=A0=C2=A0=C2=A0 stream using a signed language and/or a text or = audio stream using a
=C2=A0=C2=A0=C2=A0 written/spoken language.

1.1 Applicability

=C2=A0=C2=A0=C2=A0 Within this document, it is assumed that the neg= otiating endpoints
=C2=A0=C2=A0=C2=A0 have already been determined, so that a per-stre= am negotiation
=C2=A0=C2=A0=C2=A0 based on the Session Description Protocol (SDP) = can proceed.

=C2=A0=C2=A0=C2=A0 However, when setting up interactive communicati= ons sessions it
=C2=A0=C2=A0=C2=A0 is first necessary to route signaling messages t= o the appropriate
=C2=A0=C2=A0=C2=A0 endpoint(s). This document does not address the = problem of
=C2=A0=C2=A0=C2=A0 language-based routing. In order to enable inter= mediaries to make
=C2=A0=C2=A0=C2=A0 make routing decisions based on language and med= ia capabilities,
=C2=A0=C2=A0=C2=A0 future documents may define extensions to the Se= ssion Initiation
=C2=A0=C2=A0=C2=A0 Protocol (SIP).


On Wed, Jul 12, 2017 at 10:11 AM, Bernard Aboba <bernard.aboba@gmail.c= om <mailto:bernard.aboba@gmail= .com>> wrote:

=C2=A0=C2=A0=C2=A0 In reviewing open tickets
=C2=A0=C2=A0=C2=A0 against draft-ietf-slim-negotiating-human-l= anguage, it appears to
=C2=A0=C2=A0=C2=A0 me that Issue 38 remains unresolved.

=C2=A0=C2=A0=C2=A0 This issue was raised by ART AD Adam Roach in hi= s review:
=C2=A0=C2=A0=C2=A0 =E2=80=8Bhttps://mailarchive.ietf.org/arch/msg/slim/fZm= bXKtwn1771DoZhh1Kt_kUWf4
=C2=A0=C2=A0=C2=A0 <https://mailarchive.ietf.org/arch/msg/slim/fZmbXKtwn1771DoZ= hh1Kt_kUWf4>

=C2=A0=C2=A0=C2=A0 " Aside -- I have a concern that negotiatin= g language in SDP rather

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 than SIP makes it necess= ary for proxies to look into SDP to make
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 routing decisions, which= is a pretty substantial layer violation
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (keep in mind, for examp= le, that SIP was originally envisioned to
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 contain S/MIME encrypted= bodies, which would render the SDP
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 unreadable by proxies). = However, I note that section 5.1 indicates
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 that this has issue been= litigated in the working group
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 already, and
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 that it chose to do thin= gs in the way documented in the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 current draft." 






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


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

--001a113fa1e6d9d0b4055435ffc4-- From nobody Thu Jul 13 13:34:08 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59DE712EC22 for ; Thu, 13 Jul 2017 13:34:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 RqZ1XyTzWmTi for ; Thu, 13 Jul 2017 13:34:03 -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 2A6DC12009C for ; Thu, 13 Jul 2017 13:34:02 -0700 (PDT) X-Halon-ID: 9599dba6-680a-11e7-ba98-005056917f90 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.43.70] (unknown [2.67.67.106]) by bin-vsp-out-02.atm.binero.net (Halon) with ESMTPSA id 9599dba6-680a-11e7-ba98-005056917f90; Thu, 13 Jul 2017 22:33:53 +0200 (CEST) To: Bernard Aboba References: <275d4884-274e-8006-e46a-9abe52337df5@omnitor.se> Cc: slim@ietf.org, Adam Roach From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: Date: Thu, 13 Jul 2017 22:33:55 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------7B91A0EA9FE1CBACEF2A39D5" Archived-At: Subject: Re: [Slim] draft-ietf-slim-negotiating-human-language: Issue 38 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, 13 Jul 2017 20:34:07 -0000 This is a multi-part message in MIME format. --------------7B91A0EA9FE1CBACEF2A39D5 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Den 2017-07-13 kl. 19:09, skrev Bernard Aboba: > Gunnar said: > > " A long time ago, I stopped arguing for a SIP based solution when I > realized that SDP is more often used than SIP in the WebRTC environment. > Basing it on SDP makes it easier to convey the language and modality needs > across the SIP / WebRTC border. (There is a complication that real-time > text is an RTP stream on the SIP side and a multiplexed data channel on the > WebRTC side, but there are solutions defined for handling SDP attribute > conveyance for such situations. ). Indicating that a SIP solution may > follow kind of invalidates the whole work we have done." > > [BA] The group did indeed converge on SDP as the mechanism to negotiate > language and media modality (the subject of the draft). As I read it, the > SDP Directorate review is not a request to reconsider that decision, but > rather a request for the document to more clearly indicate that SDP is not > being proposed as a solution to the routing problem. > > "I prefer to just leave out the last sentence in 1.1. Saying that routing > is out-of-scope for this document is sufficient." > > [BA] Adam and Gunnar - Would the following work? Yes it works, and it is better than the wording in version 0.12 /Gunnar > > 1.1 Applicability > > Within this document, it is assumed that the negotiating endpoints > have already been determined, so that a per-stream negotiation > based on the Session Description Protocol (SDP) can proceed. > > However, when setting up interactive communications sessions it > is first necessary to route signaling messages to the appropriate > endpoint(s). This document does not address the problem of > routing based on language and media capabilities. > > > > > On Thu, Jul 13, 2017 at 12:41 AM, Gunnar Hellström < > gunnar.hellstrom@omnitor.se> wrote: > >> Bernard, >> >> I do not like the last sentence of 1.1. A long time ago, I stopped arguing >> for a SIP based solution when I realized that SDP is more often used than >> SIP in the WebRTC environment. Basing it on SDP makes it easier to convey >> the language and modality needs across the SIP / WebRTC border. (There is a >> complication that real-time text is an RTP stream on the SIP side and a >> multiplexed data channel on the WebRTC side, but there are solutions >> defined for handling SDP attribute conveyance for such situations. ) >> >> Indicating that a SIP solution may follow kind of invalidates the whole >> work we have done. I prefer to just leave out the last sentence in 1.1. >> Saying that routing is out-of-scope for this document is sufficient. >> Gunnar >> >> >> >> Den 2017-07-12 kl. 19:21, skrev Adam Roach: >> >> Thanks. The text in 1.1, in particular, addresses my concern. The rest of >> the revisions look good as well. >> >> /a >> >> On 7/12/17 12:12, Bernard Aboba wrote: >> >> >> To resolve Issue 38 which arose from Adam Roach's review, I would like to >> suggest the following revision for Section 1 and introduction of a new >> applicability section 1.1 as follows: >> >> 1. Introduction >> >> A mutually comprehensive language is helpful for human communication. >> This document addresses the negotiation of human (natural) language >> and media modality (spoken, signed, written) in real-time >> communications. >> A companion document [I-D.ietf-slim-multilangcontent] addresses >> language selection in email. >> >> Unless the caller and callee know each other or there is >> contextual or out-of- >> band information from which the language(s) and media modalities can >> be determined, there is a need for spoken, signed, or written >> languages >> to be negotiated based on the caller's needs and the callee's >> capabilities. >> This need applies to both emergency and non-emergency calls. >> For example, it is helpful for a caller to a company call center >> or a Public Safety Answering Point (PSAP) to be able to indicate >> preferred signed, written, and/or spoken languages, and for the callee >> to be able to indicate its capabilities in this area, allowing >> the call to proceed using the language(s) and media forms >> supported by both. >> >> For various reasons, including the ability to >> establish multiple streams using different media (e.g., voice, text, >> video), it makes sense to use a per-stream negotiation mechanism known >> as the Session Description Protocol (SDP). Utilizing SDP enables >> the solution described in this document to be applied to all >> interactive communications negotiated using SDP, in emergency as well >> as non-emergency scenarios. >> >> By treating language as another SDP attribute that is negotiated along >> with other aspects of a media stream, it becomes possible to >> accommodate a range of users' needs and called party facilities. For >> example, some users may be able to speak several languages, but have >> a preference. Some called parties may support some of those >> languages internally but require the use of a translation service for >> others, or may have a limited number of call takers able to use >> certain languages. Another example would be a user who is able to >> speak but is deaf or hard-of-hearing and requires a voice stream plus >> a text stream. Making language a media attribute allows the standard >> session negotiation mechanism to handle this by providing the >> information and mechanism for the endpoints to make appropriate >> decisions. >> >> The term "negotiation" is used here rather than "indication" because >> human language (spoken/written/signed) can be negotiated in the same >> manner as media (audio/text/video) and codecs. For example, if we >> think >> of a user calling an airline reservation center, the user may >> have a set of languages he or she speaks, with perhaps preferences >> for one or a few, while the airline reservation center will support a >> fixed set of languages. Negotiation should select the user's most >> preferred language that is supported by the call center. Both sides >> should be aware of which language was negotiated. This is >> conceptually similar to the way other aspects of each media stream >> are negotiated using SDP (e.g., media type and codecs). >> >> Since this is a protocol mechanism, the user equipment (UE client) >> needs to know the user's preferred languages; a reasonable technique >> could include a configuration mechanism with a default of the >> language of the user interface. In some cases, a UE could tie >> language and media preferences, such as a preference for a video >> stream using a signed language and/or a text or audio stream using a >> written/spoken language. >> >> 1.1 Applicability >> >> Within this document, it is assumed that the negotiating endpoints >> have already been determined, so that a per-stream negotiation >> based on the Session Description Protocol (SDP) can proceed. >> >> However, when setting up interactive communications sessions it >> is first necessary to route signaling messages to the appropriate >> endpoint(s). This document does not address the problem of >> language-based routing. In order to enable intermediaries to make >> make routing decisions based on language and media capabilities, >> future documents may define extensions to the Session Initiation >> Protocol (SIP). >> >> >> On Wed, Jul 12, 2017 at 10:11 AM, Bernard Aboba > > wrote: >> >> In reviewing open tickets >> against draft-ietf-slim-negotiating-human-language, it appears to >> me that Issue 38 remains unresolved. >> >> This issue was raised by ART AD Adam Roach in his review: >> ​https://mailarchive.ietf.org/arch/msg/slim/ >> fZmbXKtwn1771DoZhh1Kt_kUWf4 >> > fZmbXKtwn1771DoZhh1Kt_kUWf4> >> >> >> " Aside -- I have a concern that negotiating language in SDP rather >> >> than SIP makes it necessary for proxies to look into SDP to make >> routing decisions, which is a pretty substantial layer violation >> (keep in mind, for example, that SIP was originally envisioned to >> contain S/MIME encrypted bodies, which would render the SDP >> unreadable by proxies). However, I note that section 5.1 indicates >> that this has issue been litigated in the working group >> already, and >> that it chose to do things in the way documented in the >> current draft." >> >> >> >> >> >> >> _______________________________________________ >> SLIM mailing listSLIM@ietf.orghttps://www.ietf.org/mailman/listinfo/slim >> >> >> -- >> ----------------------------------------- >> Gunnar Hellström >> Omnitorgunnar.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 --------------7B91A0EA9FE1CBACEF2A39D5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Den 2017-07-13 kl. 19:09, skrev Bernard Aboba:
Gunnar said:

" A long time ago, I stopped arguing for a SIP based solution when I
realized that SDP is more often used than SIP in the WebRTC environment.
Basing it on SDP makes it easier to convey the language and modality needs
across the SIP / WebRTC border. (There is a complication that real-time
text is an RTP stream on the SIP side and a multiplexed data channel on the
WebRTC side, but there are solutions defined for handling SDP attribute
conveyance for such situations. ). Indicating that a SIP solution may
follow kind of invalidates the whole work we have done."

[BA]  The group did indeed converge on SDP as the mechanism to negotiate
language and media modality (the subject of the draft).  As I read it, the
SDP Directorate review is not a request to reconsider that decision, but
rather a request for the document to more clearly indicate that SDP is not
being proposed as a solution to the routing problem.

"I prefer to just leave out the last sentence in 1.1. Saying that routing
is out-of-scope for this document is sufficient."

[BA]  Adam and Gunnar - Would the following work?
Yes it works, and it is better than the wording in version 0.12

/Gunnar 

1.1 Applicability

Within this document, it is assumed that the negotiating endpoints
have already been determined, so that a per-stream negotiation
based on the Session Description Protocol (SDP) can proceed.

However, when setting up interactive communications sessions it
is first necessary to route signaling messages to the appropriate
endpoint(s). This document does not address the problem of
routing based on language and media capabilities.




On Thu, Jul 13, 2017 at 12:41 AM, Gunnar Hellström <
gunnar.hellstrom@omnitor.se> wrote:


Bernard,

I do not like the last sentence of 1.1. A long time ago, I stopped arguing
for a SIP based solution when I realized that SDP is more often used than
SIP in the WebRTC environment. Basing it on SDP makes it easier to convey
the language and modality needs across the SIP / WebRTC border. (There is a
complication that real-time text is an RTP stream on the SIP side and a
multiplexed data channel on the WebRTC side, but there are solutions
defined for handling SDP attribute conveyance for such situations. )

Indicating that a SIP solution may follow kind of invalidates the whole
work we have done. I prefer to just leave out the last sentence in 1.1.
Saying that routing is out-of-scope for this document is sufficient.
Gunnar



Den 2017-07-12 kl. 19:21, skrev Adam Roach:

Thanks. The text in 1.1, in particular, addresses my concern. The rest of
the revisions look good as well.

/a

On 7/12/17 12:12, Bernard Aboba wrote:


To resolve Issue 38 which arose from Adam Roach's review, I would like to
suggest the following revision for Section 1 and introduction of a new
applicability section 1.1 as follows:

 1. Introduction

    A mutually comprehensive language is helpful for human communication.
    This document addresses the negotiation of human (natural) language
    and media modality (spoken, signed, written) in real-time
    communications.
    A companion document [I-D.ietf-slim-multilangcontent] addresses
    language selection in email.

    Unless the caller and callee know each other or there is
    contextual or out-of-
    band information from which the language(s) and media modalities can
    be determined, there is a need for spoken, signed, or written
    languages
    to be negotiated based on the caller's needs and the callee's
    capabilities.
    This need applies to both emergency and non-emergency calls.
    For example, it is helpful for a caller to a company call center
    or a Public Safety Answering Point (PSAP) to be able to indicate
    preferred signed, written, and/or spoken languages, and for the callee
    to be able to indicate its capabilities in this area, allowing
    the call to proceed using the language(s) and media forms
    supported by both.

    For various reasons, including the ability to
    establish multiple streams using different media (e.g., voice, text,
    video), it makes sense to use a per-stream negotiation mechanism known
    as the Session Description Protocol (SDP). Utilizing SDP enables
    the solution described in this document to be applied to all
    interactive communications negotiated using SDP, in emergency as well
    as non-emergency scenarios.

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

    The term "negotiation" is used here rather than "indication" because
    human language (spoken/written/signed) can be negotiated in the same
    manner as media (audio/text/video) and codecs. For example, if we
    think
    of a user calling an airline reservation center, the user may
    have a set of languages he or she speaks, with perhaps preferences
    for one or a few, while the airline reservation center will support a
    fixed set of languages. Negotiation should select the user's most
    preferred language that is supported by the call center. Both sides
    should be aware of which language was negotiated. This is
    conceptually similar to the way other aspects of each media stream
    are negotiated using SDP (e.g., media type and codecs).

    Since this is a protocol mechanism, the user equipment (UE client)
    needs to know the user's preferred languages; a reasonable technique
    could include a configuration mechanism with a default of the
    language of the user interface. In some cases, a UE could tie
    language and media preferences, such as a preference for a video
    stream using a signed language and/or a text or audio stream using a
    written/spoken language.

1.1 Applicability

    Within this document, it is assumed that the negotiating endpoints
    have already been determined, so that a per-stream negotiation
    based on the Session Description Protocol (SDP) can proceed.

    However, when setting up interactive communications sessions it
    is first necessary to route signaling messages to the appropriate
    endpoint(s). This document does not address the problem of
    language-based routing. In order to enable intermediaries to make
    make routing decisions based on language and media capabilities,
    future documents may define extensions to the Session Initiation
    Protocol (SIP).


On Wed, Jul 12, 2017 at 10:11 AM, Bernard Aboba <bernard.aboba@gmail.com
<mailto:bernard.aboba@gmail.com> <bernard.aboba@gmail.com>> wrote:

    In reviewing open tickets
    against draft-ietf-slim-negotiating-human-language, it appears to
    me that Issue 38 remains unresolved.

    This issue was raised by ART AD Adam Roach in his review:
    ​https://mailarchive.ietf.org/arch/msg/slim/
fZmbXKtwn1771DoZhh1Kt_kUWf4
    <https://mailarchive.ietf.org/arch/msg/slim/
fZmbXKtwn1771DoZhh1Kt_kUWf4>
<https://mailarchive.ietf.org/arch/msg/slim/fZmbXKtwn1771DoZhh1Kt_kUWf4>

    " Aside -- I have a concern that negotiating language in SDP rather

        than SIP makes it necessary for proxies to look into SDP to make
        routing decisions, which is a pretty substantial layer violation
        (keep in mind, for example, that SIP was originally envisioned to
        contain S/MIME encrypted bodies, which would render the SDP
        unreadable by proxies). However, I note that section 5.1 indicates
        that this has issue been litigated in the working group
        already, and
        that it chose to do things in the way documented in the
        current draft."






_______________________________________________
SLIM mailing listSLIM@ietf.orghttps://www.ietf.org/mailman/listinfo/slim


--
-----------------------------------------
Gunnar Hellström
Omnitorgunnar.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

  


--------------7B91A0EA9FE1CBACEF2A39D5--


From nobody Thu Jul 13 14:44:13 2017
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5406A131784 for ; Thu, 13 Jul 2017 14:44:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.878
X-Spam-Level: 
X-Spam-Status: No, score=-1.878 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, 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 s5dF8Ih4DaHb for ; Thu, 13 Jul 2017 14:44:03 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 924B312ECED for ; Thu, 13 Jul 2017 14:44:03 -0700 (PDT)
Received: from [33.247.152.45] ([172.56.6.64]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v6DLehF5019128 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 13 Jul 2017 16:41:42 -0500 (CDT) (envelope-from adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host [172.56.6.64] claimed to be [33.247.152.45]
Content-Type: multipart/alternative; boundary=Apple-Mail-1A7EC8B8-65BB-4C4F-82C4-24BF1F4DD2EF
Content-Transfer-Encoding: 7bit
References:    <275d4884-274e-8006-e46a-9abe52337df5@omnitor.se> 
From: Adam Roach 
In-Reply-To: 
Message-Id: <1DDA69D4-52B3-4E4B-8920-67EB6F2C4B84@nostrum.com>
Date: Thu, 13 Jul 2017 16:34:39 -0500
Cc: =?utf-8?Q?Gunnar_Hellstr=C3=B6m?= , slim@ietf.org
To: Bernard Aboba 
Mime-Version: 1.0 (1.0)
X-Mailer: iPhone Mail (14E304)
Archived-At: 
Subject: Re: [Slim] draft-ietf-slim-negotiating-human-language: Issue 38
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, 13 Jul 2017 21:44:11 -0000

--Apple-Mail-1A7EC8B8-65BB-4C4F-82C4-24BF1F4DD2EF
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

I'm okay with this formulation.=20

/a

> On Jul 13, 2017, at 12:09, Bernard Aboba  wrote:
>=20
> Gunnar said:=20
>=20
> " A long time ago, I stopped arguing for a SIP based solution when I reali=
zed that SDP is more often used than SIP in the WebRTC environment. Basing i=
t on SDP makes it easier to convey the language and modality needs across th=
e SIP / WebRTC border. (There is a complication that real-time text is an RT=
P stream on the SIP side and a multiplexed data channel on the WebRTC side, b=
ut there are solutions defined for handling SDP attribute conveyance for suc=
h situations. ). Indicating that a SIP solution may follow kind of invalidat=
es the whole work we have done."
>=20
> [BA]  The group did indeed converge on SDP as the mechanism to negotiate l=
anguage and media modality (the subject of the draft).  As I read it, the SD=
P Directorate review is not a request to reconsider that decision, but rathe=
r a request for the document to more clearly indicate that SDP is not being p=
roposed as a solution to the routing problem.=20
>=20
> "I prefer to just leave out the last sentence in 1.1. Saying that routing i=
s out-of-scope for this document is sufficient."
>=20
> [BA]  Adam and Gunnar - Would the following work?=20
>=20
> 1.1 Applicability
>=20
> Within this document, it is assumed that the negotiating endpoints
> have already been determined, so that a per-stream negotiation
> based on the Session Description Protocol (SDP) can proceed.
>=20
> However, when setting up interactive communications sessions it
> is first necessary to route signaling messages to the appropriate
> endpoint(s). This document does not address the problem of
> routing based on language and media capabilities.
>=20
>=20
>=20
>> On Thu, Jul 13, 2017 at 12:41 AM, Gunnar Hellstr=C3=B6m  wrote:
>> Bernard,
>>=20
>> I do not like the last sentence of 1.1. A long time ago, I stopped arguin=
g for a SIP based solution when I realized that SDP is more often used than S=
IP in the WebRTC environment. Basing it on SDP makes it easier to convey the=
 language and modality needs across the SIP / WebRTC border. (There is a com=
plication that real-time text is an RTP stream on the SIP side and a multipl=
exed data channel on the WebRTC side, but there are solutions defined for ha=
ndling SDP attribute conveyance for such situations. )
>> Indicating that a SIP solution may follow kind of invalidates the whole w=
ork we have done. I prefer to just leave out the last sentence in 1.1. Sayin=
g that routing is out-of-scope for this document is sufficient.
>>=20
>> Gunnar
>>=20
>>=20
>>> Den 2017-07-12 kl. 19:21, skrev Adam Roach:
>>> Thanks. The text in 1.1, in particular, addresses my concern. The rest o=
f the revisions look good as well.=20
>>>=20
>>> /a=20
>>>=20
>>>> On 7/12/17 12:12, Bernard Aboba wrote:=20
>>>>=20
>>>> To resolve Issue 38 which arose from Adam Roach's review, I would like t=
o suggest the following revision for Section 1 and introduction of a new app=
licability section 1.1 as follows:=20
>>>>=20
>>>>  1. Introduction=20
>>>>=20
>>>>     A mutually comprehensive language is helpful for human communicatio=
n.=20
>>>>     This document addresses the negotiation of human (natural) language=
=20
>>>>     and media modality (spoken, signed, written) in real-time=20
>>>>     communications.=20
>>>>     A companion document [I-D.ietf-slim-multilangcontent] addresses=20
>>>>     language selection in email.=20
>>>>=20
>>>>     Unless the caller and callee know each other or there is=20
>>>>     contextual or out-of-=20
>>>>     band information from which the language(s) and media modalities ca=
n=20
>>>>     be determined, there is a need for spoken, signed, or written=20
>>>>     languages=20
>>>>     to be negotiated based on the caller's needs and the callee's=20
>>>>     capabilities.=20
>>>>     This need applies to both emergency and non-emergency calls.=20
>>>>     For example, it is helpful for a caller to a company call center=20=

>>>>     or a Public Safety Answering Point (PSAP) to be able to indicate   =
     =20
>>>>     preferred signed, written, and/or spoken languages, and for the cal=
lee=20
>>>>     to be able to indicate its capabilities in this area, allowing=20
>>>>     the call to proceed using the language(s) and media forms=20
>>>>     supported by both.=20
>>>>=20
>>>>     For various reasons, including the ability to=20
>>>>     establish multiple streams using different media (e.g., voice, text=
,=20
>>>>     video), it makes sense to use a per-stream negotiation mechanism kn=
own=20
>>>>     as the Session Description Protocol (SDP). Utilizing SDP enables=20=

>>>>     the solution described in this document to be applied to all=20
>>>>     interactive communications negotiated using SDP, in emergency as we=
ll=20
>>>>     as non-emergency scenarios.=20
>>>>=20
>>>>     By treating language as another SDP attribute that is negotiated al=
ong=20
>>>>     with other aspects of a media stream, it becomes possible to=20
>>>>     accommodate a range of users' needs and called party facilities. Fo=
r=20
>>>>     example, some users may be able to speak several languages, but hav=
e=20
>>>>     a preference. Some called parties may support some of those=20
>>>>     languages internally but require the use of a translation service f=
or        =20
>>>>     others, or may have a limited number of call takers able to use=20
>>>>     certain languages. Another example would be a user who is able to=20=

>>>>     speak but is deaf or hard-of-hearing and requires a voice stream pl=
us=20
>>>>     a text stream. Making language a media attribute allows the standar=
d=20
>>>>     session negotiation mechanism to handle this by providing the=20
>>>>     information and mechanism for the endpoints to make appropriate    =
    =20
>>>>     decisions.=20
>>>>=20
>>>>     The term "negotiation" is used here rather than "indication" becaus=
e=20
>>>>     human language (spoken/written/signed) can be negotiated in the sam=
e=20
>>>>     manner as media (audio/text/video) and codecs. For example, if we=20=

>>>>     think=20
>>>>     of a user calling an airline reservation center, the user may=20
>>>>     have a set of languages he or she speaks, with perhaps preferences=20=

>>>>     for one or a few, while the airline reservation center will support=
 a=20
>>>>     fixed set of languages. Negotiation should select the user's most=20=

>>>>     preferred language that is supported by the call center. Both sides=
=20
>>>>     should be aware of which language was negotiated. This is=20
>>>>     conceptually similar to the way other aspects of each media stream=20=

>>>>     are negotiated using SDP (e.g., media type and codecs).=20
>>>>=20
>>>>     Since this is a protocol mechanism, the user equipment (UE client)=20=

>>>>     needs to know the user's preferred languages; a reasonable         t=
echnique=20
>>>>     could include a configuration mechanism with a default of the=20
>>>>     language of the user interface. In some cases, a UE could tie=20
>>>>     language and media preferences, such as a preference for a video=20=

>>>>     stream using a signed language and/or a text or audio stream using a=
=20
>>>>     written/spoken language.=20
>>>>=20
>>>> 1.1 Applicability=20
>>>>=20
>>>>     Within this document, it is assumed that the negotiating endpoints=20=

>>>>     have already been determined, so that a per-stream negotiation=20
>>>>     based on the Session Description Protocol (SDP) can proceed.=20
>>>>=20
>>>>     However, when setting up interactive communications sessions it=20
>>>>     is first necessary to route signaling messages to the appropriate=20=

>>>>     endpoint(s). This document does not address the problem of=20
>>>>     language-based routing. In order to enable intermediaries to make=20=

>>>>     make routing decisions based on language and media capabilities,=20=

>>>>     future documents may define extensions to the Session Initiation=20=

>>>>     Protocol (SIP).=20
>>>>=20
>>>>=20
>>>> On Wed, Jul 12, 2017 at 10:11 AM, Bernard Aboba > wrote:=20
>>>>=20
>>>>     In reviewing open tickets=20
>>>>     against draft-ietf-slim-negotiating-human-language, it appears to=20=

>>>>     me that Issue 38 remains unresolved.=20
>>>>=20
>>>>     This issue was raised by ART AD Adam Roach in his review:=20
>>>>     =E2=80=8Bhttps://mailarchive.ietf.org/arch/msg/slim/fZmbXKtwn1771Do=
Zhh1Kt_kUWf4=20
>>>>     
>>>>=20
>>>>     " Aside -- I have a concern that negotiating language in SDP rather=
=20
>>>>=20
>>>>         than SIP makes it necessary for proxies to look into SDP to mak=
e=20
>>>>         routing decisions, which is a pretty substantial layer violatio=
n=20
>>>>         (keep in mind, for example, that SIP was originally envisioned t=
o=20
>>>>         contain S/MIME encrypted bodies, which would render the SDP=20
>>>>         unreadable by proxies). However, I note that section 5.1 indica=
tes=20
>>>>         that this has issue been litigated in the working group=20
>>>>         already, and=20
>>>>         that it chose to do things in the way documented in the=20
>>>>         current draft."=20
>>>>=20
>>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>> _______________________________________________
>>> SLIM mailing list
>>> SLIM@ietf.org
>>> https://www.ietf.org/mailman/listinfo/slim
>>=20
>> --=20
>> -----------------------------------------
>> Gunnar Hellstr=C3=B6m
>> Omnitor
>> gunnar.hellstrom@omnitor.se
>> +46 708 204 288
>=20

--Apple-Mail-1A7EC8B8-65BB-4C4F-82C4-24BF1F4DD2EF
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


I'm okay with this formulat=
ion. 

/a

On Jul 13, 2017, at 12:=
09, Bernard Aboba <bernard.abo=
ba@gmail.com> wrote:

Gunnar said: 

" A long time ago, I st=
opped arguing for a SIP based solution when I realized that SDP is more ofte=
n used than SIP in the WebRTC environment. Basing it on SDP makes it easier t=
o convey the language and modality needs across the SIP / WebRTC border. (Th=
ere is a complication that real-time text is an RTP stream on the SIP side a=
nd a multiplexed data channel on the WebRTC side, but there are solutions de=
fined for handling SDP attribute conveyance for such situations. ). Indicating that a SIP solution may foll=
ow kind of invalidates the whole work we have done."

[BA]  The group did indee=
d converge on SDP as the mechanism to negotiate language and media modality (=
the subject of the draft).  As I read it, the SDP Directorate review is=
 not a request to reconsider that decision, but rather a request for the doc=
ument to more clearly indicate that SDP is not being proposed as a solution t=
o the routing problem. 

"I prefer to just leave out the last sentence in 1.1. S=
aying that routing is out-of-scope for this document is sufficient."<=
/div>

[BA]  Adam and Gunnar - Would the following work?=
 

1.1 Applicability

Within this document, it is assumed that the negotiating endpoints
have already been determined, so that a per-stream negotiation
based on the Session Description Protocol (SDP) can proceed.

However, when setting up interactive communications sessions it
is first necessary to route signaling messages to the appropriate
endpoint(s). This document does not address the problem of
routing based on language and media capabilities.



On Thu, Jul 13, 2017 at 12:41 AM,=
 Gunnar Hellstr=C3=B6m <gunnar.hellstrom@omnitor.se>=
 wrote:

 =20
   =20
 =20
  

    
Bernard,

    
I do not like the last sentence of 1.1. A long time ago, I
      stopped arguing for a SIP based solution when I realized that SDP
      is more often used than SIP in the WebRTC environment. Basing it
      on SDP makes it easier to convey the language and modality needs
      across the SIP / WebRTC border. (There is a complication that
      real-time text is an RTP stream on the SIP side and a multiplexed
      data channel on the WebRTC side, but there are solutions defined
      for handling SDP attribute conveyance for such situations. )

    

    
Indicating that a SIP solution may follow kind of invalidates the
      whole work we have done. I prefer to just leave out the last
      sentence in 1.1. Saying that routing is out-of-scope for this
      document is sufficient.

    Gunnar

    


    

    

    
Den 2017-07-12 kl. 19:=
21, skrev Adam
      Roach:

    

    
Thanks. The text in 1.=
1, in particular, addresses my
      concern. The rest of the revisions look good as well.
      

      

      /a
      

      

      On 7/12/17 12:12, Bernard Aboba wrote:
      

      

        

        To resolve Issue 38 which arose from Adam Roach's review, I
        would like to suggest the following revision for Section 1 and
        introduction of a new applicability section 1.1 as follows:
        

        

         1. Introduction
        

        

            A mutually comprehensive language is helpful for h=
uman
        communication.
        

            This document addresses the negotiation of human (=
natural)
        language
        

            and media modality (spoken, signed, written) in r=
eal-time
        

            communications.
        

            A companion document [I-D.ietf-slim-multilan=
gcontent]
        addresses
        

            language selection in email.
        

        

            Unless the caller and callee know each other or t=
here is
        

            contextual or out-of-
        

            band information from which the language(s) and m=
edia
        modalities can
        

            be determined, there is a need for spoken, signed=
, or
        written
        

            languages
        

            to be negotiated based on the caller's needs and t=
he
        callee's
        

            capabilities.
        

            This need applies to both emergency and non-emerg=
ency calls.
        

            For example, it is helpful for a caller to a comp=
any call
        center
        

            or a Public Safety Answering Point (PSAP) to be a=
ble to
        indicate
        

            preferred signed, written, and/or spoken language=
s, and for
        the callee
        

            to be able to indicate its capabilities in this a=
rea,
        allowing
        

            the call to proceed using the language(s) and med=
ia forms
        

            supported by both.
        

        

            For various reasons, including the ability to
        

            establish multiple streams using different media (=
e.g.,
        voice, text,
        

            video), it makes sense to use a per-stream negoti=
ation
        mechanism known
        

            as the Session Description Protocol (SDP). Utiliz=
ing SDP
        enables
        

            the solution described in this document to be app=
lied to all
        

            interactive communications negotiated using SDP, i=
n
        emergency as well
        

            as non-emergency scenarios.
        

        

            By treating language as another SDP attribute tha=
t is
        negotiated along
        

            with other aspects of a media stream, it becomes p=
ossible to
        

            accommodate a range of users' needs and called pa=
rty
        facilities. For
        

            example, some users may be able to speak several l=
anguages,
        but have
        

            a preference. Some called parties may support som=
e of those
        

            languages internally but require the use of a tra=
nslation
        service for
        

            others, or may have a limited number of call take=
rs able to
        use
        

            certain languages. Another example would be a use=
r who is
        able to
        

            speak but is deaf or hard-of-hearing and requires=
 a voice
        stream plus
        

            a text stream. Making language a media attribute a=
llows the
        standard
        

            session negotiation mechanism to handle this by p=
roviding
        the
        

            information and mechanism for the endpoints to ma=
ke
        appropriate
        

            decisions.
        

        

            The term "negotiation" is used here rather than "=
indication"
        because
        

            human language (spoken/written/signed) can be neg=
otiated in
        the same
        

            manner as media (audio/text/video) and codecs. Fo=
r example,
        if we
        

            think
        

            of a user calling an airline reservation center, t=
he user
        may
        

            have a set of languages he or she speaks, with pe=
rhaps
        preferences
        

            for one or a few, while the airline reservation c=
enter will
        support a
        

            fixed set of languages. Negotiation should select=
 the user's
        most
        

            preferred language that is supported by the call c=
enter.
        Both sides
        

            should be aware of which language was negotiated.=
 This is
        

            conceptually similar to the way other aspects of e=
ach media
        stream
        

            are negotiated using SDP (e.g., media type and co=
decs).
        

        

            Since this is a protocol mechanism, the user equi=
pment (UE
        client)
        

            needs to know the user's preferred languages; a r=
easonable
        technique
        

            could include a configuration mechanism with a de=
fault of
        the
        

            language of the user interface. In some cases, a U=
E could
        tie
        

            language and media preferences, such as a prefere=
nce for a
        video
        

            stream using a signed language and/or a text or a=
udio stream
        using a
        

            written/spoken language.
        

        

        1.1 Applicability
        

        

            Within this document, it is assumed that the nego=
tiating
        endpoints
        

            have already been determined, so that a per-strea=
m
        negotiation
        

            based on the Session Description Protocol (SDP) c=
an proceed.
        

        

            However, when setting up interactive communicatio=
ns sessions
        it
        

            is first necessary to route signaling messages to=
 the
        appropriate
        

            endpoint(s). This document does not address the p=
roblem of
        

            language-based routing. In order to enable interm=
ediaries to
        make
        

            make routing decisions based on language and medi=
a
        capabilities,
        

            future documents may define extensions to the Ses=
sion
        Initiation
        

            Protocol (SIP).
        

        

        

        On Wed, Jul 12, 2017 at 10:11 AM, Bernard Aboba
        <bernard.aboba@gmail.com
        <mailto:bernard.aboba@gmail.<=
wbr>com>> wrote:
        

        

            In reviewing open tickets
        

            against draft-ietf-slim-negotiating-human-la=
nguage, it
        appears to
        

            me that Issue 38 remains unresolved.
        

        

            This issue was raised by ART AD Adam Roach in his=
 review:
        

           
        =E2=80=8Bhttps://mailarchive.ietf.org/arch/msg/slim/fZmbXKtw=
n1771DoZhh1Kt_kUWf4
        

           
=
<https://mailarchive.ietf.org/arch/msg/slim/fZmbXKtwn1771DoZhh1=
Kt_kUWf4>

        

            " Aside -- I have a concern that negotiating lang=
uage in SDP
        rather
        

        

                than SIP makes it necessa=
ry for proxies to look into SDP
        to make
        

                routing decisions, which i=
s a pretty substantial layer
        violation
        

                (keep in mind, for exampl=
e, that SIP was originally
        envisioned to
        

                contain S/MIME encrypted b=
odies, which would render the
        SDP
        

                unreadable by proxies). H=
owever, I note that section 5.1
        indicates
        

                that this has issue been l=
itigated in the working group
        

                already, and
        

                that it chose to do thing=
s in the way documented in the
        

                current draft."
        

        

        

      

      

      

      

      

      

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


    

    

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

  






=

--Apple-Mail-1A7EC8B8-65BB-4C4F-82C4-24BF1F4DD2EF--


From nobody Thu Jul 13 23:37:28 2017
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9FA8131805 for ; Thu, 13 Jul 2017 23:37:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.336
X-Spam-Level: 
X-Spam-Status: No, score=-0.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0WkdAh1eHZtN for ; Thu, 13 Jul 2017 23:37:25 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A548131761 for ; Thu, 13 Jul 2017 23:37:25 -0700 (PDT)
Received: from [100.90.249.79] ([172.56.13.5]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v6E6b4qx005085 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 14 Jul 2017 01:37:17 -0500 (CDT) (envelope-from adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host [172.56.13.5] claimed to be [100.90.249.79]
Content-Type: multipart/alternative; boundary=Apple-Mail-1A7EC8B8-65BB-4C4F-82C4-24BF1F4DD2EF
Content-Transfer-Encoding: 7bit
References:    <275d4884-274e-8006-e46a-9abe52337df5@omnitor.se> 
From: Adam Roach 
In-Reply-To: 
Message-Id: <1DDA69D4-52B3-4E4B-8920-67EB6F2C4B84@nostrum.com>
Date: Thu, 13 Jul 2017 16:34:39 -0500
Cc: =?utf-8?Q?Gunnar_Hellstr=C3=B6m?= , slim@ietf.org
To: Bernard Aboba 
Mime-Version: 1.0 (1.0)
X-Mailer: iPhone Mail (14E304)
Archived-At: 
Subject: Re: [Slim] draft-ietf-slim-negotiating-human-language: Issue 38
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 14 Jul 2017 06:37:27 -0000

--Apple-Mail-1A7EC8B8-65BB-4C4F-82C4-24BF1F4DD2EF
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

I'm okay with this formulation.=20

/a

> On Jul 13, 2017, at 12:09, Bernard Aboba  wrote:
>=20
> Gunnar said:=20
>=20
> " A long time ago, I stopped arguing for a SIP based solution when I reali=
zed that SDP is more often used than SIP in the WebRTC environment. Basing i=
t on SDP makes it easier to convey the language and modality needs across th=
e SIP / WebRTC border. (There is a complication that real-time text is an RT=
P stream on the SIP side and a multiplexed data channel on the WebRTC side, b=
ut there are solutions defined for handling SDP attribute conveyance for suc=
h situations. ). Indicating that a SIP solution may follow kind of invalidat=
es the whole work we have done."
>=20
> [BA]  The group did indeed converge on SDP as the mechanism to negotiate l=
anguage and media modality (the subject of the draft).  As I read it, the SD=
P Directorate review is not a request to reconsider that decision, but rathe=
r a request for the document to more clearly indicate that SDP is not being p=
roposed as a solution to the routing problem.=20
>=20
> "I prefer to just leave out the last sentence in 1.1. Saying that routing i=
s out-of-scope for this document is sufficient."
>=20
> [BA]  Adam and Gunnar - Would the following work?=20
>=20
> 1.1 Applicability
>=20
> Within this document, it is assumed that the negotiating endpoints
> have already been determined, so that a per-stream negotiation
> based on the Session Description Protocol (SDP) can proceed.
>=20
> However, when setting up interactive communications sessions it
> is first necessary to route signaling messages to the appropriate
> endpoint(s). This document does not address the problem of
> routing based on language and media capabilities.
>=20
>=20
>=20
>> On Thu, Jul 13, 2017 at 12:41 AM, Gunnar Hellstr=C3=B6m  wrote:
>> Bernard,
>>=20
>> I do not like the last sentence of 1.1. A long time ago, I stopped arguin=
g for a SIP based solution when I realized that SDP is more often used than S=
IP in the WebRTC environment. Basing it on SDP makes it easier to convey the=
 language and modality needs across the SIP / WebRTC border. (There is a com=
plication that real-time text is an RTP stream on the SIP side and a multipl=
exed data channel on the WebRTC side, but there are solutions defined for ha=
ndling SDP attribute conveyance for such situations. )
>> Indicating that a SIP solution may follow kind of invalidates the whole w=
ork we have done. I prefer to just leave out the last sentence in 1.1. Sayin=
g that routing is out-of-scope for this document is sufficient.
>>=20
>> Gunnar
>>=20
>>=20
>>> Den 2017-07-12 kl. 19:21, skrev Adam Roach:
>>> Thanks. The text in 1.1, in particular, addresses my concern. The rest o=
f the revisions look good as well.=20
>>>=20
>>> /a=20
>>>=20
>>>> On 7/12/17 12:12, Bernard Aboba wrote:=20
>>>>=20
>>>> To resolve Issue 38 which arose from Adam Roach's review, I would like t=
o suggest the following revision for Section 1 and introduction of a new app=
licability section 1.1 as follows:=20
>>>>=20
>>>>  1. Introduction=20
>>>>=20
>>>>     A mutually comprehensive language is helpful for human communicatio=
n.=20
>>>>     This document addresses the negotiation of human (natural) language=
=20
>>>>     and media modality (spoken, signed, written) in real-time=20
>>>>     communications.=20
>>>>     A companion document [I-D.ietf-slim-multilangcontent] addresses=20
>>>>     language selection in email.=20
>>>>=20
>>>>     Unless the caller and callee know each other or there is=20
>>>>     contextual or out-of-=20
>>>>     band information from which the language(s) and media modalities ca=
n=20
>>>>     be determined, there is a need for spoken, signed, or written=20
>>>>     languages=20
>>>>     to be negotiated based on the caller's needs and the callee's=20
>>>>     capabilities.=20
>>>>     This need applies to both emergency and non-emergency calls.=20
>>>>     For example, it is helpful for a caller to a company call center=20=

>>>>     or a Public Safety Answering Point (PSAP) to be able to indicate   =
     =20
>>>>     preferred signed, written, and/or spoken languages, and for the cal=
lee=20
>>>>     to be able to indicate its capabilities in this area, allowing=20
>>>>     the call to proceed using the language(s) and media forms=20
>>>>     supported by both.=20
>>>>=20
>>>>     For various reasons, including the ability to=20
>>>>     establish multiple streams using different media (e.g., voice, text=
,=20
>>>>     video), it makes sense to use a per-stream negotiation mechanism kn=
own=20
>>>>     as the Session Description Protocol (SDP). Utilizing SDP enables=20=

>>>>     the solution described in this document to be applied to all=20
>>>>     interactive communications negotiated using SDP, in emergency as we=
ll=20
>>>>     as non-emergency scenarios.=20
>>>>=20
>>>>     By treating language as another SDP attribute that is negotiated al=
ong=20
>>>>     with other aspects of a media stream, it becomes possible to=20
>>>>     accommodate a range of users' needs and called party facilities. Fo=
r=20
>>>>     example, some users may be able to speak several languages, but hav=
e=20
>>>>     a preference. Some called parties may support some of those=20
>>>>     languages internally but require the use of a translation service f=
or        =20
>>>>     others, or may have a limited number of call takers able to use=20
>>>>     certain languages. Another example would be a user who is able to=20=

>>>>     speak but is deaf or hard-of-hearing and requires a voice stream pl=
us=20
>>>>     a text stream. Making language a media attribute allows the standar=
d=20
>>>>     session negotiation mechanism to handle this by providing the=20
>>>>     information and mechanism for the endpoints to make appropriate    =
    =20
>>>>     decisions.=20
>>>>=20
>>>>     The term "negotiation" is used here rather than "indication" becaus=
e=20
>>>>     human language (spoken/written/signed) can be negotiated in the sam=
e=20
>>>>     manner as media (audio/text/video) and codecs. For example, if we=20=

>>>>     think=20
>>>>     of a user calling an airline reservation center, the user may=20
>>>>     have a set of languages he or she speaks, with perhaps preferences=20=

>>>>     for one or a few, while the airline reservation center will support=
 a=20
>>>>     fixed set of languages. Negotiation should select the user's most=20=

>>>>     preferred language that is supported by the call center. Both sides=
=20
>>>>     should be aware of which language was negotiated. This is=20
>>>>     conceptually similar to the way other aspects of each media stream=20=

>>>>     are negotiated using SDP (e.g., media type and codecs).=20
>>>>=20
>>>>     Since this is a protocol mechanism, the user equipment (UE client)=20=

>>>>     needs to know the user's preferred languages; a reasonable         t=
echnique=20
>>>>     could include a configuration mechanism with a default of the=20
>>>>     language of the user interface. In some cases, a UE could tie=20
>>>>     language and media preferences, such as a preference for a video=20=

>>>>     stream using a signed language and/or a text or audio stream using a=
=20
>>>>     written/spoken language.=20
>>>>=20
>>>> 1.1 Applicability=20
>>>>=20
>>>>     Within this document, it is assumed that the negotiating endpoints=20=

>>>>     have already been determined, so that a per-stream negotiation=20
>>>>     based on the Session Description Protocol (SDP) can proceed.=20
>>>>=20
>>>>     However, when setting up interactive communications sessions it=20
>>>>     is first necessary to route signaling messages to the appropriate=20=

>>>>     endpoint(s). This document does not address the problem of=20
>>>>     language-based routing. In order to enable intermediaries to make=20=

>>>>     make routing decisions based on language and media capabilities,=20=

>>>>     future documents may define extensions to the Session Initiation=20=

>>>>     Protocol (SIP).=20
>>>>=20
>>>>=20
>>>> On Wed, Jul 12, 2017 at 10:11 AM, Bernard Aboba > wrote:=20
>>>>=20
>>>>     In reviewing open tickets=20
>>>>     against draft-ietf-slim-negotiating-human-language, it appears to=20=

>>>>     me that Issue 38 remains unresolved.=20
>>>>=20
>>>>     This issue was raised by ART AD Adam Roach in his review:=20
>>>>     =E2=80=8Bhttps://mailarchive.ietf.org/arch/msg/slim/fZmbXKtwn1771Do=
Zhh1Kt_kUWf4=20
>>>>     
>>>>=20
>>>>     " Aside -- I have a concern that negotiating language in SDP rather=
=20
>>>>=20
>>>>         than SIP makes it necessary for proxies to look into SDP to mak=
e=20
>>>>         routing decisions, which is a pretty substantial layer violatio=
n=20
>>>>         (keep in mind, for example, that SIP was originally envisioned t=
o=20
>>>>         contain S/MIME encrypted bodies, which would render the SDP=20
>>>>         unreadable by proxies). However, I note that section 5.1 indica=
tes=20
>>>>         that this has issue been litigated in the working group=20
>>>>         already, and=20
>>>>         that it chose to do things in the way documented in the=20
>>>>         current draft."=20
>>>>=20
>>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>> _______________________________________________
>>> SLIM mailing list
>>> SLIM@ietf.org
>>> https://www.ietf.org/mailman/listinfo/slim
>>=20
>> --=20
>> -----------------------------------------
>> Gunnar Hellstr=C3=B6m
>> Omnitor
>> gunnar.hellstrom@omnitor.se
>> +46 708 204 288
>=20

--Apple-Mail-1A7EC8B8-65BB-4C4F-82C4-24BF1F4DD2EF
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


I'm okay with this formulat=
ion. 

/a

On Jul 13, 2017, at 12:=
09, Bernard Aboba <bernard.abo=
ba@gmail.com> wrote:

Gunnar said: 

" A long time ago, I st=
opped arguing for a SIP based solution when I realized that SDP is more ofte=
n used than SIP in the WebRTC environment. Basing it on SDP makes it easier t=
o convey the language and modality needs across the SIP / WebRTC border. (Th=
ere is a complication that real-time text is an RTP stream on the SIP side a=
nd a multiplexed data channel on the WebRTC side, but there are solutions de=
fined for handling SDP attribute conveyance for such situations. ). Indicating that a SIP solution may foll=
ow kind of invalidates the whole work we have done."

[BA]  The group did indee=
d converge on SDP as the mechanism to negotiate language and media modality (=
the subject of the draft).  As I read it, the SDP Directorate review is=
 not a request to reconsider that decision, but rather a request for the doc=
ument to more clearly indicate that SDP is not being proposed as a solution t=
o the routing problem. 

"I prefer to just leave out the last sentence in 1.1. S=
aying that routing is out-of-scope for this document is sufficient."<=
/div>

[BA]  Adam and Gunnar - Would the following work?=
 

1.1 Applicability

Within this document, it is assumed that the negotiating endpoints
have already been determined, so that a per-stream negotiation
based on the Session Description Protocol (SDP) can proceed.

However, when setting up interactive communications sessions it
is first necessary to route signaling messages to the appropriate
endpoint(s). This document does not address the problem of
routing based on language and media capabilities.



On Thu, Jul 13, 2017 at 12:41 AM,=
 Gunnar Hellstr=C3=B6m <gunnar.hellstrom@omnitor.se>=
 wrote:

 =20
   =20
 =20
  

    
Bernard,

    
I do not like the last sentence of 1.1. A long time ago, I
      stopped arguing for a SIP based solution when I realized that SDP
      is more often used than SIP in the WebRTC environment. Basing it
      on SDP makes it easier to convey the language and modality needs
      across the SIP / WebRTC border. (There is a complication that
      real-time text is an RTP stream on the SIP side and a multiplexed
      data channel on the WebRTC side, but there are solutions defined
      for handling SDP attribute conveyance for such situations. )

    

    
Indicating that a SIP solution may follow kind of invalidates the
      whole work we have done. I prefer to just leave out the last
      sentence in 1.1. Saying that routing is out-of-scope for this
      document is sufficient.

    Gunnar

    


    

    

    
Den 2017-07-12 kl. 19:=
21, skrev Adam
      Roach:

    

    
Thanks. The text in 1.=
1, in particular, addresses my
      concern. The rest of the revisions look good as well.
      

      

      /a
      

      

      On 7/12/17 12:12, Bernard Aboba wrote:
      

      

        

        To resolve Issue 38 which arose from Adam Roach's review, I
        would like to suggest the following revision for Section 1 and
        introduction of a new applicability section 1.1 as follows:
        

        

         1. Introduction
        

        

            A mutually comprehensive language is helpful for h=
uman
        communication.
        

            This document addresses the negotiation of human (=
natural)
        language
        

            and media modality (spoken, signed, written) in r=
eal-time
        

            communications.
        

            A companion document [I-D.ietf-slim-multilan=
gcontent]
        addresses
        

            language selection in email.
        

        

            Unless the caller and callee know each other or t=
here is
        

            contextual or out-of-
        

            band information from which the language(s) and m=
edia
        modalities can
        

            be determined, there is a need for spoken, signed=
, or
        written
        

            languages
        

            to be negotiated based on the caller's needs and t=
he
        callee's
        

            capabilities.
        

            This need applies to both emergency and non-emerg=
ency calls.
        

            For example, it is helpful for a caller to a comp=
any call
        center
        

            or a Public Safety Answering Point (PSAP) to be a=
ble to
        indicate
        

            preferred signed, written, and/or spoken language=
s, and for
        the callee
        

            to be able to indicate its capabilities in this a=
rea,
        allowing
        

            the call to proceed using the language(s) and med=
ia forms
        

            supported by both.
        

        

            For various reasons, including the ability to
        

            establish multiple streams using different media (=
e.g.,
        voice, text,
        

            video), it makes sense to use a per-stream negoti=
ation
        mechanism known
        

            as the Session Description Protocol (SDP). Utiliz=
ing SDP
        enables
        

            the solution described in this document to be app=
lied to all
        

            interactive communications negotiated using SDP, i=
n
        emergency as well
        

            as non-emergency scenarios.
        

        

            By treating language as another SDP attribute tha=
t is
        negotiated along
        

            with other aspects of a media stream, it becomes p=
ossible to
        

            accommodate a range of users' needs and called pa=
rty
        facilities. For
        

            example, some users may be able to speak several l=
anguages,
        but have
        

            a preference. Some called parties may support som=
e of those
        

            languages internally but require the use of a tra=
nslation
        service for
        

            others, or may have a limited number of call take=
rs able to
        use
        

            certain languages. Another example would be a use=
r who is
        able to
        

            speak but is deaf or hard-of-hearing and requires=
 a voice
        stream plus
        

            a text stream. Making language a media attribute a=
llows the
        standard
        

            session negotiation mechanism to handle this by p=
roviding
        the
        

            information and mechanism for the endpoints to ma=
ke
        appropriate
        

            decisions.
        

        

            The term "negotiation" is used here rather than "=
indication"
        because
        

            human language (spoken/written/signed) can be neg=
otiated in
        the same
        

            manner as media (audio/text/video) and codecs. Fo=
r example,
        if we
        

            think
        

            of a user calling an airline reservation center, t=
he user
        may
        

            have a set of languages he or she speaks, with pe=
rhaps
        preferences
        

            for one or a few, while the airline reservation c=
enter will
        support a
        

            fixed set of languages. Negotiation should select=
 the user's
        most
        

            preferred language that is supported by the call c=
enter.
        Both sides
        

            should be aware of which language was negotiated.=
 This is
        

            conceptually similar to the way other aspects of e=
ach media
        stream
        

            are negotiated using SDP (e.g., media type and co=
decs).
        

        

            Since this is a protocol mechanism, the user equi=
pment (UE
        client)
        

            needs to know the user's preferred languages; a r=
easonable
        technique
        

            could include a configuration mechanism with a de=
fault of
        the
        

            language of the user interface. In some cases, a U=
E could
        tie
        

            language and media preferences, such as a prefere=
nce for a
        video
        

            stream using a signed language and/or a text or a=
udio stream
        using a
        

            written/spoken language.
        

        

        1.1 Applicability
        

        

            Within this document, it is assumed that the nego=
tiating
        endpoints
        

            have already been determined, so that a per-strea=
m
        negotiation
        

            based on the Session Description Protocol (SDP) c=
an proceed.
        

        

            However, when setting up interactive communicatio=
ns sessions
        it
        

            is first necessary to route signaling messages to=
 the
        appropriate
        

            endpoint(s). This document does not address the p=
roblem of
        

            language-based routing. In order to enable interm=
ediaries to
        make
        

            make routing decisions based on language and medi=
a
        capabilities,
        

            future documents may define extensions to the Ses=
sion
        Initiation
        

            Protocol (SIP).
        

        

        

        On Wed, Jul 12, 2017 at 10:11 AM, Bernard Aboba
        <bernard.aboba@gmail.com
        <mailto:bernard.aboba@gmail.<=
wbr>com>> wrote:
        

        

            In reviewing open tickets
        

            against draft-ietf-slim-negotiating-human-la=
nguage, it
        appears to
        

            me that Issue 38 remains unresolved.
        

        

            This issue was raised by ART AD Adam Roach in his=
 review:
        

           
        =E2=80=8Bhttps://mailarchive.ietf.org/arch/msg/slim/fZmbXKtw=
n1771DoZhh1Kt_kUWf4
        

           
=
<https://mailarchive.ietf.org/arch/msg/slim/fZmbXKtwn1771DoZhh1=
Kt_kUWf4>

        

            " Aside -- I have a concern that negotiating lang=
uage in SDP
        rather
        

        

                than SIP makes it necessa=
ry for proxies to look into SDP
        to make
        

                routing decisions, which i=
s a pretty substantial layer
        violation
        

                (keep in mind, for exampl=
e, that SIP was originally
        envisioned to
        

                contain S/MIME encrypted b=
odies, which would render the
        SDP
        

                unreadable by proxies). H=
owever, I note that section 5.1
        indicates
        

                that this has issue been l=
itigated in the working group
        

                already, and
        

                that it chose to do thing=
s in the way documented in the
        

                current draft."
        

        

        

      

      

      

      

      

      

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


    

    

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

  






=

--Apple-Mail-1A7EC8B8-65BB-4C4F-82C4-24BF1F4DD2EF--


From nobody Mon Jul 17 01:08:54 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 298291317A1; Mon, 17 Jul 2017 01:08:53 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: slim@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.56.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150027893310.303.7087858254460163821@ietfa.amsl.com>
Date: Mon, 17 Jul 2017 01:08:53 -0700
Archived-At: 
Subject: [Slim] I-D Action: draft-ietf-slim-negotiating-human-language-13.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, 17 Jul 2017 08:08:53 -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-13.txt
	Pages           : 17
	Date            : 2017-07-17

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

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


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 Jul 17 08:45:15 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 9D0F8131C71 for ; Mon, 17 Jul 2017 08:45:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.7
X-Spam-Level: 
X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gsmasso.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PeqH7rvs5S-D for ; Mon, 17 Jul 2017 08:45:11 -0700 (PDT)
Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50052.outbound.protection.outlook.com [40.107.5.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B2A5131C73 for ; Mon, 17 Jul 2017 08:45:08 -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=CBY7TADOjtQ7rAxeouOyy++w677x4cQ9rqa8wHbtvis=; b=UM3E+oIiQQrjNvJymea8RuZ1czqb5Lx0UQrc4aG0N00iD9YvY2iLLDZB7C/pMycen8X/BB/BKMHscDt8LVi4kJ6Ma8Nw46BxBHgvc6tVzAUOkcZoosZGyFzhixWfUjhS+E3oFDw1dcu1WDUaTnSEys9IlZZX2bx1ChiyXyAUIaI=
Received: from AM2PR04MB0802.eurprd04.prod.outlook.com (10.160.56.28) by AM2PR04MB0802.eurprd04.prod.outlook.com (10.160.56.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.13; Mon, 17 Jul 2017 15:45:06 +0000
Received: from AM2PR04MB0802.eurprd04.prod.outlook.com ([fe80::6471:41e1:367d:ca67]) by AM2PR04MB0802.eurprd04.prod.outlook.com ([fe80::6471:41e1:367d:ca67%13]) with mapi id 15.01.1261.022; Mon, 17 Jul 2017 15:45:06 +0000
From: Natasha Rooney 
To: "slim@ietf.org" 
Thread-Topic: A reminder 
Thread-Index: AQHS/xOpSAmCrufneUKTwYK9cR2Z9g==
Date: Mon, 17 Jul 2017 15:45:06 +0000
Message-ID: <162B32E0-22EB-4E75-B59E-1A57CF8E6ADD@gsma.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=gsma.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [31.101.126.247]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM2PR04MB0802; 7:GN9K/3AoZAqafvvjQSPP4CKhn+SuFhuIURjckPpjXxYS32kei4WTUBeZsUfFpa/6d2hWYlHxr7sG0WjREZkFqzyN7tfq4YjGlZN1ey95Gqf+7QOXX72mKagA/U0oH7fEyye43m6IKfVZSdOIzXUpaOkf1H2H7hTnK3kbvUXbLU2wpT2J64/cvRcxlVYKp/lhH8KD11TJDBQcNC4YJtgiH2q0g9xTrdbSmF/eqHJXS0hSghtDGycigOwUAwSN4XLFLdXs60rt0+IhAuK1XyWYtMszXCbYlfQmRcP0KPfrAKgYK/gWjz0WRfcmBy2qMCUNp2wNikGHiw0onoCYMuBL9UtPH7gOiCUm3aAHoqlCyavCGJ4K1Cjj6MsF6s+wMgZu+tjJd2jUyx6FHEdG0eGvN0rE6sBG5UlinWoT8q3244MzjbhmQ5R9Z2mnKahLnqYLCDCVI/IN2iBwKT2Hs9jItqhB4gRSEVmmquC6DGjIwaLCnWRADMzN5Ji+rMzzzYi+NoFiKA9urWXhaS+b1jOnAR1U1v6oVMlaW/VfqxXln2fhZ6ST/jjez58pd9ui5m/3bOv/3gLik1/aKPF8nDnkphqjoKG/UxJ0Unu+GR75I4rJMTpSn/sKKWEmz0E/s/W130vVUXKEY3lJ2A03daHqOUth/Z4V6TYN8iT7oQ1zvUvWMrPvZqiBoHsgoC9Mj2q8p6qEjsbU0jK3eG0ikm0FXleob+iyKpavu1sY+n/lRwlE7++BBHtFDNzin1hMZ9Z4r6o+kiint1cAZfWsUix8pBpnJimZtISDmFRX1ZmbKjs=
x-ms-office365-filtering-correlation-id: 16fbe38a-2863-4550-19c0-08d4cd2acc3b
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM2PR04MB0802; 
x-ms-traffictypediagnostic: AM2PR04MB0802:
x-exchange-antispam-report-test: UriScan:(236129657087228)(92093043455673)(50300203121483); 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(2017060910075)(5005006)(8121501046)(3002001)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(6041248)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123564025)(20161123555025)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM2PR04MB0802; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM2PR04MB0802; 
x-forefront-prvs: 0371762FE7
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39410400002)(39850400002)(39840400002)(39400400002)(39450400003)(12213003)(6436002)(6506006)(36756003)(478600001)(8676002)(8936002)(5640700003)(25786009)(33656002)(5250100002)(81166006)(50986999)(54356999)(3280700002)(1730700003)(5660300001)(4743002)(3846002)(189998001)(6486002)(3480700004)(66066001)(102836003)(14454004)(6116002)(54896002)(7736002)(86362001)(236005)(82746002)(5890100001)(6916009)(53936002)(2501003)(110136004)(2351001)(6512007)(99286003)(38730400002)(83716003)(2900100001)(2906002)(3660700001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM2PR04MB0802; H:AM2PR04MB0802.eurprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_162B32E022EB4E75B59E1A57CF8E6ADDgsmacom_"
MIME-Version: 1.0
X-OriginatorOrg: gsma.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jul 2017 15:45:06.3578 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72a4ff82-fec3-469d-aafb-ac8276216699
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR04MB0802
X-MS-Exchange-CrossPremises-AuthAs: Internal
X-MS-Exchange-CrossPremises-AuthMechanism: 04
X-MS-Exchange-CrossPremises-AuthSource: AM2PR04MB0802.eurprd04.prod.outlook.com
X-MS-Exchange-CrossPremises-TransportTrafficType: Email
X-MS-Exchange-CrossPremises-TransportTrafficSubType: 
X-MS-Exchange-CrossPremises-SCL: 1
X-MS-Exchange-CrossPremises-messagesource: StoreDriver
X-MS-Exchange-CrossPremises-BCC: 
X-MS-Exchange-CrossPremises-originalclientipaddress: 31.101.126.247
X-MS-Exchange-CrossPremises-transporttraffictype: Email
X-MS-Exchange-CrossPremises-transporttrafficsubtype: 
X-MS-Exchange-CrossPremises-disclaimer-hash: 78ca8040c6722e32c2f5b0a45bf37e74b9409d645a53be96aa19958e0cee0f00
X-MS-Exchange-CrossPremises-antispam-scancontext: DIR:Originating; SFV:NSPM; SKIP:0; 
X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent
X-OrganizationHeadersPreserved: AM2PR04MB0802.eurprd04.prod.outlook.com
Archived-At: 
Subject: [Slim] A reminder
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, 17 Jul 2017 15:45:14 -0000

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

QSByZW1pbmRlciB0aGF0IG91ciBtZWV0aW5nIGF0IElFVEY5OSBpcyBjYW5jZWxsZWQuIEludGVy
aW0gbWVldGluZyBwbGFubmluZyB3aWxsIGNvbW1lbmNlIHNvb24hDQoNCk5hdGFzaGEgUm9vbmV5
IHwgSW50ZXJuZXQgRW5naW5lZXJpbmcgRGlyZWN0b3IgfCBHU01BIHwgbnJvb25leUBnc21hLmNv
bTxtYWlsdG86bnJvb25leUBnc21hLmNvbT4gfCArNDQgKDApIDc3MzAgMjE5IDc2NTx0ZWw6KzQ0
JTIwNzczMCVDMiVBMDIxOSUyMDc2NT4gfCBAdGhpc05hdGFzaGEgfCBTa3lwZTogbnJvb25leUBn
c20ub3JnPG1haWx0bzpucm9vbmV5QGdzbS5vcmc+DQoNClRoaXMgZW1haWwgYW5kIGl0cyBhdHRh
Y2htZW50cyBhcmUgaW50ZW5kZWQgZm9yIHRoZSBhYm92ZSBuYW1lZCBvbmx5IGFuZCBtYXkgYmUg
Y29uZmlkZW50aWFsLiBJZiB0aGV5IGhhdmUgY29tZSB0byB5b3UgaW4gZXJyb3IgeW91IG11c3Qg
dGFrZSBubyBhY3Rpb24gYmFzZWQgb24gdGhlbSwgbm9yIG11c3QgeW91IGNvcHkgb3Igc2hvdyB0
aGVtIHRvIGFueW9uZTsgcGxlYXNlIHJlcGx5IHRvIHRoaXMgZW1haWwgb3IgY2FsbCArNDQgMjA3
IDM1NiAwNjAwIGFuZCBoaWdobGlnaHQgdGhlIGVycm9yLg0K

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

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8
ZGl2PkEgcmVtaW5kZXIgdGhhdCBvdXIgbWVldGluZyBhdCBJRVRGOTkgaXMgY2FuY2VsbGVkLiBJ
bnRlcmltIG1lZXRpbmcgcGxhbm5pbmcgd2lsbCBjb21tZW5jZSBzb29uISZuYnNwOzxicj4NCjxi
cj4NCjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiByZ2JhKDI1NSwgMjU1LCAyNTUsIDAp
OyI+TmF0YXNoYSBSb29uZXkgfCBJbnRlcm5ldCBFbmdpbmVlcmluZyBEaXJlY3RvciB8IEdTTUEg
fCZuYnNwOzxhIGhyZWY9Im1haWx0bzpucm9vbmV5QGdzbWEuY29tIj5ucm9vbmV5QGdzbWEuY29t
PC9hPiZuYnNwO3wmbmJzcDs8YSBkaXI9Imx0ciIgaHJlZj0idGVsOiYjNDM7NDQlMjA3NzMwJUMy
JUEwMjE5JTIwNzY1IiB4LWFwcGxlLWRhdGEtZGV0ZWN0b3JzPSJ0cnVlIiB4LWFwcGxlLWRhdGEt
ZGV0ZWN0b3JzLXR5cGU9InRlbGVwaG9uZSIgeC1hcHBsZS1kYXRhLWRldGVjdG9ycy1yZXN1bHQ9
IjEwIj4mIzQzOzQ0DQogKDApIDc3MzAmbmJzcDsyMTkgNzY1PC9hPiZuYnNwO3wgQHRoaXNOYXRh
c2hhIHwgU2t5cGU6Jm5ic3A7PGEgaHJlZj0ibWFpbHRvOm5yb29uZXlAZ3NtLm9yZyI+bnJvb25l
eUBnc20ub3JnPC9hPjwvc3Bhbj48L2Rpdj4NCjxwIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWws
c2Fucy1zZXJpZjtmb250LXNpemU6MTFweDtjb2xvcjojOTk5OTk5OyI+PHNwYW4gbGFuZz0iRU4t
VVMiIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsc2Fucy1zZXJpZjtjb2xvcjojOTk5OTk5OyBt
c28tZmFyZWFzdC1mb250LWZhbWlseTogQXJpYWw7IG1zby1mYXJlYXN0LXRoZW1lLWZvbnQ6IG1p
bm9yLWxhdGluOyBtc28tYmlkaS1mb250LWZhbWlseTogJnF1b3Q7QXJpYWwmcXVvdDs7IG1zby1h
bnNpLWxhbmd1YWdlOiBFTi1VUzsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEVOLUdCOyBtc28tYmlk
aS1sYW5ndWFnZTogQVItU0EiPlRoaXMNCiBlbWFpbCBhbmQgaXRzIGF0dGFjaG1lbnRzIGFyZSBp
bnRlbmRlZCBmb3IgdGhlIGFib3ZlIG5hbWVkIG9ubHkgYW5kIG1heSBiZSBjb25maWRlbnRpYWwu
IElmIHRoZXkgaGF2ZSBjb21lIHRvIHlvdSBpbiBlcnJvciB5b3UgbXVzdCB0YWtlIG5vIGFjdGlv
biBiYXNlZCBvbiB0aGVtLCBub3IgbXVzdCB5b3UgY29weSBvciBzaG93IHRoZW0gdG8gYW55b25l
OyBwbGVhc2UgcmVwbHkgdG8gdGhpcyBlbWFpbCBvciBjYWxsICYjNDM7NDQgMjA3IDM1NiAwNjAw
DQogYW5kIGhpZ2hsaWdodCB0aGUgZXJyb3IuIDwvc3Bhbj48L3A+DQo8L2JvZHk+DQo8L2h0bWw+
DQo=

--_000_162B32E022EB4E75B59E1A57CF8E6ADDgsmacom_--


From nobody Mon Jul 17 09:54:26 2017
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56B27127867 for ; Mon, 17 Jul 2017 09:54:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UsBRCtfi3smN for ; Mon, 17 Jul 2017 09:54:22 -0700 (PDT)
Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBF07131B48 for ; Mon, 17 Jul 2017 09:54:22 -0700 (PDT)
Received: by mail-ua0-x22f.google.com with SMTP id 35so55562281uax.3 for ; Mon, 17 Jul 2017 09:54:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to; bh=YcxY3J8QXZ3cs/a24FER/67nuQn11PYF0tmsQ0yxew8=; b=fs/fYp0+DUc3t6PmLc3T3j1mJU5lxubZSWPFIj5TqjACxpS8yaWPmHEVUV2yHg8alm PMg1WzIT9g91xNL7Jcar9ypz20uzq5R0yMm5Xu9z/dYmxfsYJTPUWUIF6ZupqrRjVgW+ Qo+p5RiD+/4BmosQ08EJCGihjQW7a/NtOJAmenyN3mvfOTLQHv9TvZpwwPyo5QqLOF6s M7YTnXeqE+96vK4r2cVJqPnWzBW8AH7r8m3po0U4T3ISRmQhS+ZdTH9TgctN12Slf/YC 6LwE6TSQOmrWjN4dIRyQ0f2ZJpYdxhZlPTdk6pVQsxGJjRj5LMaTng/wIWSnLXcLrvKF qkXw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=YcxY3J8QXZ3cs/a24FER/67nuQn11PYF0tmsQ0yxew8=; b=dDOpG/KkTWGnbguE+NEG76VId5smCwXk82fiQXoXp1N7oFYgWfZPvYjY9bJLxQwlTY nxy9e1AddEa5qNM6Z6gakOEdPXkssc74EhAwZgXwOFza20ZyLkc1WCCo6m3tp/iA1Q87 Irzl5sfWU97xaWywaJxrigwGszlfb1xWU4zWBMjYXNUslOxNhBeDhY13DrZuy8c4YiHv 8OROFIEyUYLwwdtfEHAXRnqz0F8AM5jETZ+4D+CFcB5gUR5Wv+Klkb6Ze/KLEZexvjIY wLPnd8+HmBBbQy6hOtAWd9bffDr7HZcWCrJtndt9Ls0vKXArwkebXLJHQ0x1DpbfyWiE qfeQ==
X-Gm-Message-State: AIVw110E6NW8AHLcCOUYYFdWTc+N9CAfzNaXulbOs6mtkJMYqEJ7FqNN 9iKaE0SZIX4QHN0QN/rtDUvAJEQbZqDRprE=
X-Received: by 10.159.48.69 with SMTP id i5mr14157201uab.106.1500310461471; Mon, 17 Jul 2017 09:54:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.159.35.80 with HTTP; Mon, 17 Jul 2017 09:54:00 -0700 (PDT)
From: Bernard Aboba 
Date: Mon, 17 Jul 2017 09:54:00 -0700
Message-ID: 
To: slim@ietf.org
Content-Type: multipart/alternative; boundary="f403045e34b41be28a0554864091"
Archived-At: 
Subject: [Slim] Human-language Issue 26: Asterisk modifier scope
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, 17 Jul 2017 16:54:25 -0000

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

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

The remaining open aspect of Issue 26 relates to the scope of  the "*".

Paul Kyzivat summarized the problem in his post on February 13, 2017 (see:
  https://www.ietf.org/mail-archive/web/slim/current/msg00737.html)


   - The text needs to be improved simply to properly explain and define
   the syntax related to the "*" as you intend to use it.


   - the use of the "*" to indicate what it does is confusing. It is using
   a media level attribute "parameter" to signify a session level property.
   This has been brought up before, but simply rejected without (IMO) adequate
   justification. There seems to be some love for this particular syntax. ISTM
   that in part Gunnar is trying to adapt this syntax so that it both makes
   sense as a media-level attribute and simultaneously can satisfy the session
   level need that has been identified.

These concerns do not appear to have been addressed in
https://tools.ietf.org/html/draft-ietf-slim-negotiating-human-language-13

Section 5.2 states:

   In an offer, a list of language tags MAY have an asterisk appended at
   the end.  An asterisk appended to any value in any media in an offer
   indicates a request by the caller to the callee to not fail the call
   if there is no language in common.  See Section 5.3

for more
   information and discussion.


Section 5.3 states:

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

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


Some questions that come to mind:

1. Does the inclusion of an * represent a request for the callee to not
fail the call based on an inability to negotiate a common language only for
the particular hlang-recv or hlang-send line that contains the "*"?

That is, if an "*" is included on some hlang-recv/send lines but not other
ones, would it tell the callee that it can fail the call if a
common-language can't be negotiated for the lines without an "*"?

-OR-

2. Does the inclusion of an "*" on any hlang-recv/send line imply the
inclusion of an "*" on other hlang-recv/send lines, either within a given
m-line or on other m-lines?


-OR-


3. To provide clarity, should the "*" merely be considered an indication
that the offerer will accept "any language"?  If so, should it be valid
only for hlang-recv lines and can an Answer respond with a * in its
hlang-recv line?

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


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

The rem=
aining open aspect of Issue 26 relates to the scope of =C2=A0the "*&qu=
ot;.=C2=A0

Paul Kyzivat summarized the problem in =
his post on February 13, 2017 (see: =C2=A0 https://www.ietf.org/mail-arch=
ive/web/slim/current/msg00737.html)

  • The text needs to be improved =
simply to properly explain and define the syntax related to the "*&quo=
t; as you intend to use it.
  • the use of the "*" to indicate what it does is co=
nfusing. It is using a media level attribute "parameter" to signi=
fy a session level property. This has been brought up before, but simply re=
jected without (IMO) adequate justification. There seems to be some love fo=
r this particular syntax. ISTM that in part Gunnar is trying to adapt this =
syntax so that it both makes sense as a media-level attribute and simultane=
ously can satisfy the session level need that has been identified.
These concerns do not appear to have been addressed in https://tools.ietf.org/html/draft-ietf-slim-negotiating-human-language-=
13

Section 5.2 states:=C2=A0

   In an offer, a list of languag=
e tags MAY have an asterisk appended at
   the end.  An asterisk appended to any value in any media in an offer
   indicates a request by the caller to the callee to not fail the call
   if there is no language in common.  See Section 5=
.3 for more
   information and discussion.

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

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

S=
ome questions that come to mind:=C2=A0

1. Does the=
 inclusion of an * represent a request for the callee to not fail the call =
based on an inability to negotiate a common language only for the particula=
r hlang-recv or hlang-send line that contains the "*"?=C2=A0

That is, if an "*" is included on some hlang=
-recv/send lines but not other ones, would it tell the callee that it can f=
ail the call if a common-language can't be negotiated for the lines wit=
hout an "*"?=C2=A0

-OR-
2. Does the inclusion of an "*" on any hlang-recv/se=
nd line imply the inclusion of an "*" on other hlang-recv/send li=
nes, either within a given m-line or on other m-lines? =C2=A0


-OR-


3. To provide clarity, should the "*" merely be consi=
dered an indication that the offerer will accept "any language"?=
=C2=A0 If so, should it be valid only for hlang-recv lines and can an Answe=
r respond with a * in its hlang-recv line?=C2=A0

=






--f403045e34b41be28a0554864091--


From nobody Sat Jul 22 15:06: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 511B9129B6A for ; Sat, 22 Jul 2017 15:06:29 -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 WdjY8WgPdD5j for ; Sat, 22 Jul 2017 15:06:26 -0700 (PDT)
Received: from bin-vsp-out-01.atm.binero.net (bin-mail-out-05.binero.net [195.74.38.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F447129B25 for ; Sat, 22 Jul 2017 15:06:26 -0700 (PDT)
X-Halon-ID: fca21651-6f29-11e7-b257-005056917a89
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.43.70] (unknown [2.64.88.32]) by bin-vsp-out-01.atm.binero.net (Halon) with ESMTPSA id fca21651-6f29-11e7-b257-005056917a89; Sun, 23 Jul 2017 00:06:18 +0200 (CEST)
To: Bernard Aboba , slim@ietf.org
References: 
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: 
Date: Sun, 23 Jul 2017 00:06:17 +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="------------D2B9D320B6F9B1CF8BE24DF5"
Archived-At: 
Subject: Re: [Slim] Human-language Issue 26: Asterisk modifier scope
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 22 Jul 2017 22:06:29 -0000

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

Den 2017-07-17 kl. 18:54, skrev Bernard Aboba:
> Issue: https://trac.ietf.org/trac/slim/ticket/26
>
> The remaining open aspect of Issue 26 relates to the scope of  the "*".
>
> Paul Kyzivat summarized the problem in his post on February 13, 2017 (see:
>    https://www.ietf.org/mail-archive/web/slim/current/msg00737.html)
>
>
>     - The text needs to be improved simply to properly explain and define
>     the syntax related to the "*" as you intend to use it.
>
>
>     - the use of the "*" to indicate what it does is confusing. It is using
>     a media level attribute "parameter" to signify a session level property.
>     This has been brought up before, but simply rejected without (IMO) adequate
>     justification. There seems to be some love for this particular syntax. ISTM
>     that in part Gunnar is trying to adapt this syntax so that it both makes
>     sense as a media-level attribute and simultaneously can satisfy the session
>     level need that has been identified.
>
> These concerns do not appear to have been addressed in
> https://tools.ietf.org/html/draft-ietf-slim-negotiating-human-language-13
>
> Section 5.2 states:
>
>     In an offer, a list of language tags MAY have an asterisk appended at
>     the end.  An asterisk appended to any value in any media in an offer
>     indicates a request by the caller to the callee to not fail the call
>     if there is no language in common.  See Section 5.3
> 
> for more
>     information and discussion.
>
>
> Section 5.3 states:
>
>     A consideration with the ability to negotiate language is if the call
>     proceeds or fails if the callee does not support any of the languages
>     requested by the caller.  This document does not mandate either
>     behavior, although it does provide a way for the caller to indicate a
>     preference for the call succeeding when there is no language in
>     common.  It is OPTIONAL for the callee to honor this preference.  For
>     example, a PSAP is likely to attempt the call even without an
>     indicated preference when there is no language in common, while a
>     call center might choose to fail the call.
>
>     The mechanism for indicating this preference is that, in an offer, if
>     the last token of any 'hlang-recv' or 'hlang-send' value for any
>     media is an asterisk, this indicates a request to not fail the call.
>     The called party MAY ignore the indication, e.g., for the emergency
>     services use case, regardless of the absence of an asterisk, a PSAP
>     will likely not fail the call; some call centers might reject a call
>     even if the offer contains an asterisk.
>
>
> Some questions that come to mind:
>
> 1. Does the inclusion of an * represent a request for the callee to not
> fail the call based on an inability to negotiate a common language only for
> the particular hlang-recv or hlang-send line that contains the "*"?
>
> That is, if an "*" is included on some hlang-recv/send lines but not other
> ones, would it tell the callee that it can fail the call if a
> common-language can't be negotiated for the lines without an "*"?
>
> -OR-
>
> 2. Does the inclusion of an "*" on any hlang-recv/send line imply the
> inclusion of an "*" on other hlang-recv/send lines, either within a given
> m-line or on other m-lines?
>
>
> -OR-
>
>
> 3. To provide clarity, should the "*" merely be considered an indication
> that the offerer will accept "any language"?  If so, should it be valid
> only for hlang-recv lines and can an Answer respond with a * in its
> hlang-recv line?
I think the intention is quite clearly stated in 5.2 by this statement: "

An asterisk appended to any value in any media in an offer
    indicates a request by the caller to the callee to not fail the call
    if there is no language in common."

The idea is apparently that the position of the asterisk, and even the 
number of asterisks has no influence on the interpretation. As soon as 
there is an asterisk anywhere among the hlang-attributes in the whole 
SDP, the call should not fail because of lack of common languages.

It is a bit easier to understand the effect of the asterisk if we look 
at the logic the opposite way. "The total lack of asterisks at the end 
of all hlang-attributes in the whole SDP indicates a request by the 
offeror to the answering party to fail the call if no language match is 
found."

An interesting side effect is that if there is a language match in one 
direction, but not in the other, and no asterisk, then the call will be 
connected,  even if there will be opportunities for human language 
communication just one way.
I wonder if that was the intention by the author.

It seems not possible to invent any suitable interpretation on a true 
media level of the asterisk controlling call failure, so the comment 
from the review that it seems to be a session level parameter placed on 
a media level attribute. I think that is not good IETF quality, and 
should be corrected. I see four possible solutions:

1. Drop the idea to control if the call shall be denied.

2. Make a separate session level attribute for this purpose. e.g. 
a=hlang-disposition:keep / fail

3. Use the asterisk also for a session level purpose already in the 
current draft.

4. Accept that we propose a draft that does not fulfill good IETF 
quality standards and keep the wording as is.

Gunnar




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

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


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


  
    
  
  
    Den 2017-07-17 kl. 18:54, skrev Bernard Aboba:

    

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

The remaining open aspect of Issue 26 relates to the scope of  the "*".

Paul Kyzivat summarized the problem in his post on February 13, 2017 (see:
  https://www.ietf.org/mail-archive/web/slim/current/msg00737.html)


   - The text needs to be improved simply to properly explain and define
   the syntax related to the "*" as you intend to use it.


   - the use of the "*" to indicate what it does is confusing. It is using
   a media level attribute "parameter" to signify a session level property.
   This has been brought up before, but simply rejected without (IMO) adequate
   justification. There seems to be some love for this particular syntax. ISTM
   that in part Gunnar is trying to adapt this syntax so that it both makes
   sense as a media-level attribute and simultaneously can satisfy the session
   level need that has been identified.

These concerns do not appear to have been addressed in
https://tools.ietf.org/html/draft-ietf-slim-negotiating-human-language-13

Section 5.2 states:

   In an offer, a list of language tags MAY have an asterisk appended at
   the end.  An asterisk appended to any value in any media in an offer
   indicates a request by the caller to the callee to not fail the call
   if there is no language in common.  See Section 5.3
<https://tools.ietf.org/html/draft-ietf-slim-negotiating-human-language-13#section-5.3>
for more
   information and discussion.


Section 5.3 states:

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

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


Some questions that come to mind:

1. Does the inclusion of an * represent a request for the callee to not
fail the call based on an inability to negotiate a common language only for
the particular hlang-recv or hlang-send line that contains the "*"?

That is, if an "*" is included on some hlang-recv/send lines but not other
ones, would it tell the callee that it can fail the call if a
common-language can't be negotiated for the lines without an "*"?

    

    

      

-OR-

2. Does the inclusion of an "*" on any hlang-recv/send line imply the
inclusion of an "*" on other hlang-recv/send lines, either within a given
m-line or on other m-lines?


-OR-


3. To provide clarity, should the "*" merely be considered an indication
that the offerer will accept "any language"?  If so, should it be valid
only for hlang-recv lines and can an Answer respond with a * in its
hlang-recv line?

    

    I think the intention is quite clearly stated in 5.2 by this
    statement: "
    
An asterisk appended to any value in any media in an offer
   indicates a request by the caller to the callee to not fail the call
   if there is no language in common."


    The idea is apparently that the position of the asterisk, and even
    the number of asterisks has no influence on the interpretation. As
    soon as there is an asterisk anywhere among the hlang-attributes in
    the whole SDP, the call should not fail because of lack of common
    languages.

    

    It is a bit easier to understand the effect of the asterisk if we
    look at the logic the opposite way. "The total lack of asterisks at
    the end of all hlang-attributes in the whole SDP indicates a request
    by the offeror to the answering party to fail the call if no
    language match is found."

    

    An interesting side effect is that if there is a language match in
    one direction, but not in the other, and no asterisk, then the call
    will be connected,  even if there will be opportunities for human
    language communication just one way.  

    I wonder if that was the intention by the author.

    

    It seems not possible to invent any suitable interpretation on a
    true media level of the asterisk controlling call failure, so the
    comment from the review that it seems to be a session level
    parameter placed on a media level attribute. I think that is not
    good IETF quality, and should be corrected. I see four possible
    solutions:

    

    1. Drop the idea to control if the call shall be denied. 

    

    2. Make a separate session level attribute for this purpose. e.g.
    a=hlang-disposition:keep / fail

    

    3. Use the asterisk also for a session level purpose already in the
    current draft.

    

    4. Accept that we propose a draft that does not fulfill good IETF
    quality standards and keep the wording as is.

    

    Gunnar

    

    

    

      

    

      



      

      

      

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


    

    

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

  


--------------D2B9D320B6F9B1CF8BE24DF5--


From nobody Mon Jul 24 05:42:39 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 C390E131C33; Mon, 24 Jul 2017 05:42:37 -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.57.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150090015775.32033.15676847431103990839@ietfa.amsl.com>
Date: Mon, 24 Jul 2017 05:42:37 -0700
Archived-At: 
Subject: [Slim] I-D Action: draft-ietf-slim-multilangcontent-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, 24 Jul 2017 12:42:38 -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 WG of the IETF.

        Title           : Multiple Language Content Type
        Authors         : Nik Tomkinson
                          Nathaniel Borenstein
	Filename        : draft-ietf-slim-multilangcontent-09.txt
	Pages           : 19
	Date            : 2017-07-24

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-09
https://datatracker.ietf.org/doc/html/draft-ietf-slim-multilangcontent-09

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-slim-multilangcontent-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 Tue Jul 25 08:42:39 2017
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AD62131D10 for ; Tue, 25 Jul 2017 08:42:39 -0700 (PDT)
X-Quarantine-ID: 
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pNVNMIIrFQ2O for ; Tue, 25 Jul 2017 08:42:36 -0700 (PDT)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 9EDDC131D03 for ; Tue, 25 Jul 2017 08:42:36 -0700 (PDT)
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Tue, 25 Jul 2017 08:45:47 -0700
Mime-Version: 1.0
Message-Id: 
In-Reply-To: 
References: 
X-Mailer: Eudora for Mac OS X
Date: Tue, 25 Jul 2017 08:42:33 -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] Human-language Issue 26: Asterisk modifier scope
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, 25 Jul 2017 15:42:39 -0000

I don't think there is any particular love for the asterisk.  It's 
worth keeping in mind that it is a very mild mechanism, able at most 
to express a desire by the caller to not fail a call, but either the 
presence or absence of an asterisk may be ignored by the caller.

At 9:54 AM -0700 7/17/17, Bernard Aboba wrote:

>  Issue: 
> https://trac.ietf.org/trac/slim/ticket/26
>
>  The remaining open aspect of Issue 26 relates to the scope of  the "*".
>
>  Paul Kyzivat summarized the problem in his post on February 13, 
> 2017 (see: 
> https://www.ietf.org/mail-archive/web/slim/current/msg00737.html)
>
>  The text needs to be improved simply to properly explain and define 
> the syntax related to the "*" as you intend to use it.
>  the use of the "*" to indicate what it does is confusing. It is 
> using a media level attribute "parameter" to signify a session 
> level property. This has been brought up before, but simply 
> rejected without (IMO) adequate justification. There seems to be 
> some love for this particular syntax. ISTM that in part Gunnar is 
> trying to adapt this syntax so that it both makes sense as a 
> media-level attribute and simultaneously can satisfy the session 
> level need that has been identified.
>  These concerns do not appear to have been addressed in 
> https://tools.ietf.org/html/draft-ietf-slim-negotiating-human-language-13
>
>  Section 5.2 states:
>
>     In an offer, a list of language tags MAY have an asterisk appended at
>     the end.  An asterisk appended to any value in any media in an offer
>     indicates a request by the caller to the callee to not fail the call
>     if there is no language in common.  See 
> Section 
> 5.3 for more
>     information and discussion.
>
>  Section 5.3 states:
>     A consideration with the ability to negotiate language is if the call
>     proceeds or fails if the callee does not support any of the languages
>     requested by the caller.  This document does not mandate either
>     behavior, although it does provide a way for the caller to indicate a
>     preference for the call succeeding when there is no language in
>     common.  It is OPTIONAL for the callee to honor this preference.  For
>     example, a PSAP is likely to attempt the call even without an
>     indicated preference when there is no language in common, while a
>     call center might choose to fail the call.
>
>     The mechanism for indicating this preference is that, in an offer, if
>     the last token of any 'hlang-recv' or 'hlang-send' value for any
>     media is an asterisk, this indicates a request to not fail the call.
>     The called party MAY ignore the indication, e.g., for the emergency
>     services use case, regardless of the absence of an asterisk, a PSAP
>     will likely not fail the call; some call centers might reject a call
>     even if the offer contains an asterisk.
>
>  Some questions that come to mind:
>
>  1. Does the inclusion of an * represent a request for the callee to 
> not fail the call based on an inability to negotiate a common 
> language only for the particular hlang-recv or hlang-send line that 
> contains the "*"?
>
>  That is, if an "*" is included on some hlang-recv/send lines but 
> not other ones, would it tell the callee that it can fail the call 
> if a common-language can't be negotiated for the lines without an 
> "*"?
>
>  -OR-
>
>
>  2. Does the inclusion of an "*" on any hlang-recv/send line imply 
> the inclusion of an "*" on other hlang-recv/send lines, either 
> within a given m-line or on other m-lines?
>
>
>  -OR-
>
>
>
>  3. To provide clarity, should the "*" merely be considered an 
> indication that the offerer will accept "any language"?  If so, 
> should it be valid only for hlang-recv lines and can an Answer 
> respond with a * in its hlang-recv line?
>
>
>
>
>
>  _______________________________________________
>  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: ---------------
Creditors have better memories than debtors.
                                    --Benjamin Franklin


From nobody Tue Jul 25 09:04:51 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 AED82131D1B for ; Tue, 25 Jul 2017 09:04:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.935
X-Spam-Level: 
X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WM7iPDXLiIBG for ; Tue, 25 Jul 2017 09:04:48 -0700 (PDT)
Received: from resqmta-ch2-03v.sys.comcast.net (resqmta-ch2-03v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E9E8129AD1 for ; Tue, 25 Jul 2017 09:04:48 -0700 (PDT)
Received: from resomta-ch2-03v.sys.comcast.net ([69.252.207.99]) by resqmta-ch2-03v.sys.comcast.net with ESMTP id a2Hod32YcOZSqa2KFda2Eg; Tue, 25 Jul 2017 16:04:47 +0000
Received: from [192.168.1.110] ([24.62.227.142]) by resomta-ch2-03v.sys.comcast.net with SMTP id a2KEdMWNnTnV3a2KFd9jNt; Tue, 25 Jul 2017 16:04:47 +0000
To: slim@ietf.org
References:  
From: Paul Kyzivat 
Message-ID: 
Date: Tue, 25 Jul 2017 12:04:46 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-CMAE-Envelope: MS4wfIMlSG1+fhZ6nyxh1+0n/hvNnqJBC35WHezE9eAnKF1wcgVcg+DdZgpRteGeS1pH2K7xdNxdACSain8+N6BIO+C2ayZ6A7ejK8BRAcrlzPnR5ng3aepw bQbixpW2EYNaCLPhK5wTd3PTlFGPnM0HOKZYEr/H8ADpctV3ANp5t01o
Archived-At: 
Subject: Re: [Slim] Human-language Issue 26: Asterisk modifier scope
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, 25 Jul 2017 16:04:50 -0000

On 7/22/17 6:06 PM, Gunnar Hellström wrote:

> It seems not possible to invent any suitable interpretation on a true 
> media level of the asterisk controlling call failure, so the comment 
> from the review that it seems to be a session level parameter placed on 
> a media level attribute. I think that is not good IETF quality, and 
> should be corrected. I see four possible solutions:
> 
> 1. Drop the idea to control if the call shall be denied.
> 
> 2. Make a separate session level attribute for this purpose. e.g. 
> a=hlang-disposition:keep / fail
> 
> 3. Use the asterisk also for a session level purpose already in the 
> current draft.
> 
> 4. Accept that we propose a draft that does not fulfill good IETF 
> quality standards and keep the wording as is.

+1

(And I don't find #4 to be a reasonable choice.)

	Thanks,
	Paul


From nobody Tue Jul 25 10:10:10 2017
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 775F6131E2A for ; Tue, 25 Jul 2017 10:10:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level: 
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nZF7S-ju9p1I for ; Tue, 25 Jul 2017 10:10:06 -0700 (PDT)
Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6BA1131E0C for ; Tue, 25 Jul 2017 10:10:05 -0700 (PDT)
Received: by mail-vk0-x232.google.com with SMTP id n125so9401984vke.1 for ; Tue, 25 Jul 2017 10:10:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KByz5QVoz9ShJ9XWR7eg6UGfVLHLQ5NslEyF7z9Y20c=; b=Ahnwe2q7qZ96mMrKxwqfk69q42cx0fs/cA7hmCoZCjz8fKkOq22BaF/TkGBVz1H1Mn vJvpPnQCmzhykNDXDMgNtU2HugQamqgRYVKvQMT0W/PB2c1jwL/ZQ1AARmw+g/DgSzmL PcvWfyEY9m8dgLRS+ebRgmyheJwQrORU39uRzk01eCpFF+TWKbaXvEjW8FLHtfMXetbl 2NCRmGsEq1DnJR/IYx/w+2oNMau8U5fLVbJWT4pdgSrlbxiHirfMeB9vXxaU+PoNJTgN Ayha1OBYfdpgqQHUjXeRqFr7fWlSaNRyL6imyD32IzmT0UfEQFsoa73wuO4ckSMmk4vV 3/zA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KByz5QVoz9ShJ9XWR7eg6UGfVLHLQ5NslEyF7z9Y20c=; b=rVZk5E/3nVowVmSh9MzOqkhtZbiLeZ1rW3HQ4bC1GcORn2JM3AWMk1KmFTxw307oIC Ee5Z7Tj8EPEbeC2hX4OMHJkm4ZU4z2Jy0yACvmw7QCyWQx7zUIrvKBilCWh4Th4reNK7 yIddvgErP3BrMoVShGKlv7OfEJZWOTgUgX7erOXgi0CpGrdBiCGue2LNieJ+DqeTgAkz OtF1WdV9eMMXg+RNZJxWMNjDSWJUq0ivK7qGBOX/rW3g5Rk227rTSBQEU/U5Wd6vlnN7 akr+g7K6I00xx/Fqs34I20xSBFNL9SNODdFIZhFtasSsh5yDESU6DQ/GKzdfHNYQgTiB 20zQ==
X-Gm-Message-State: AIVw113QptGNsxzHQqZZy9Q/Mu+1EvltpIIb7FksOYkKo8aBm0YaGYYv nQ4yTeeNNaOvik0rU1rMfbcqWAC58A==
X-Received: by 10.31.107.66 with SMTP id g63mr11266357vkc.76.1501002604675; Tue, 25 Jul 2017 10:10:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.159.36.111 with HTTP; Tue, 25 Jul 2017 10:09:44 -0700 (PDT)
In-Reply-To: 
References:   
From: Bernard Aboba 
Date: Tue, 25 Jul 2017 10:09:44 -0700
Message-ID: 
To: Paul Kyzivat 
Cc: slim@ietf.org
Content-Type: multipart/alternative; boundary="001a11478fea0f06520555276758"
Archived-At: 
Subject: Re: [Slim] Human-language Issue 26: Asterisk modifier scope
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, 25 Jul 2017 17:10:08 -0000

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

Paul Kyzivat said:

"(And I don't find #4 to be a reasonable choice.)"

[BA] Is there another choice/solution that you would prefer?

On Tue, Jul 25, 2017 at 9:04 AM, Paul Kyzivat  wrote=
:

> On 7/22/17 6:06 PM, Gunnar Hellstr=C3=B6m wrote:
>
> It seems not possible to invent any suitable interpretation on a true
>> media level of the asterisk controlling call failure, so the comment fro=
m
>> the review that it seems to be a session level parameter placed on a med=
ia
>> level attribute. I think that is not good IETF quality, and should be
>> corrected. I see four possible solutions:
>>
>> 1. Drop the idea to control if the call shall be denied.
>>
>> 2. Make a separate session level attribute for this purpose. e.g.
>> a=3Dhlang-disposition:keep / fail
>>
>> 3. Use the asterisk also for a session level purpose already in the
>> current draft.
>>
>> 4. Accept that we propose a draft that does not fulfill good IETF qualit=
y
>> standards and keep the wording as is.
>>
>
> +1
>
> (And I don't find #4 to be a reasonable choice.)
>
>         Thanks,
>         Paul
>
>
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim
>

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


Paul Kyzivat said:=C2=A0

"(And I don't find #4 to be a reasonable choice=
.)"

[BA] Is there another choice/solut=
ion that you would prefer?=C2=A0

=

On Tue, Jul 25, 2017 at 9:04 AM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
On 7/22/17 6:06 PM, Gunnar Hellstr=C3=B6m wrote:




It seems not possible to invent any suitable interpretation on a true media=
 level of the asterisk controlling call failure, so the comment from the re=
view that it seems to be a session level parameter placed on a media level =
attribute. I think that is not good IETF quality, and should be corrected. =
I see four possible solutions:



1. Drop the idea to control if the call shall be denied.



2. Make a separate session level attribute for this purpose. e.g. a=3Dhlang=
-disposition:keep / fail



3. Use the asterisk also for a session level purpose already in the current=
 draft.



4. Accept that we propose a draft that does not fulfill good IETF quality s=
tandards and keep the wording as is.





+1



(And I don't find #4 to be a reasonable choice.)



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

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Paul



_______________________________________________

SLIM mailing list

SLIM@ietf.org

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





--001a11478fea0f06520555276758--


From nobody Tue Jul 25 10:18:10 2017
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8870D131E5C for ; Tue, 25 Jul 2017 10:18:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.72
X-Spam-Level: 
X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=rb+8dkXl; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=nP1/B5CO
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 dsbOCvz3pirf for ; Tue, 25 Jul 2017 10:18:07 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1396131D03 for ; Tue, 25 Jul 2017 10:18:06 -0700 (PDT)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 56349213AD for ; Tue, 25 Jul 2017 13:18:06 -0400 (EDT)
Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Tue, 25 Jul 2017 13:18:06 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=FGPSBz1Uye9K32FYgFXkzPbTjTAohxufzYMAcnLyFiw=; b=rb+8dkXl jXUOFHQvGul5NUBgC2IynuDvlhNXr2JksMWQEDReIDDF9VPQzKNg6738FvjuDCeH ckuH4HiAnqxSPlfbc6+CfvCKUzQPfAK8iVSjruJdIbFFyI0QxMFiElhJl3woo9X1 fzQZA6C10j1eB5aLY0L02DzVYdprIoeuqc++yr/x/UWSS7imM2MGc8hY0hG/0TNK kpkZG4CMvaI6qVPuqWHk/3AsK3VMy6gRS6pGdpWu2tb81tWVGmQoLSgOtwU6mcNv XyzdTCVAFT+QEFFFBpvwEndf+cQZ4cpyYRIpU2Ch4rmQUIVCmWCsiVFjctz9tt0f bJTJhukFIa23lQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=FGPSBz1Uye9K32FYgFXkzPbTjTAoh xufzYMAcnLyFiw=; b=nP1/B5COH+JNkULMbeYMNeG8XGURS+RlWGAmCwYjtMhzN YNFcE0UNGCQk9wOasJj54AIwimhrdTonP1jkj9GWjRJBk+ZgiM7YF+fADzNh8LqL Y7x2HqoFwLAP+VdZzv4MF/KIMitYV6kYRRcursIivO0xpHYtWjJ+0nHMifTDQOMZ kaLJUWaO9Cpvm1DLtKsBhm/q48bzhdj8a/gphU1d9Scz9K+NJO1QA7I5XAJnYUZZ gt1zXMFDnC4Ya5AAKWrVQLBxFENVe2LF2ClAQTaXv+Omuq6gABz/SKEHDNzdkBgQ MkSapHfn8PZnsgSrTr15IDxOc6I5k8ynk3dn37q0Q==
X-ME-Sender: 
Received: by mailuser.nyi.internal (Postfix, from userid 99) id 36BA99E28E; Tue, 25 Jul 2017 13:18:06 -0400 (EDT)
Message-Id: <1501003086.384245.1052229912.05CB8CEF@webmail.messagingengine.com>
From: Alexey Melnikov 
To: slim@ietf.org
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="utf-8"
X-Mailer: MessagingEngine.com Webmail Interface - ajax-c8af44bc
Date: Tue, 25 Jul 2017 18:18:06 +0100
Archived-At: 
Subject: [Slim] AD review of draft-ietf-slim-multilangcontent-08
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, 25 Jul 2017 17:18:08 -0000

Hi,
I've started IETF LC on the document. Please respond and address the
following comments after IETF LC. Most of my comments are nits or minor.


The first mention of UTF-8 needs a Normative Reference to RFC 3629.

In order to avoid confusion, I suggest you say "UTF-8 charset" instead
of "UTF-8 encoding". "Encoding" means something else in MIME.

In Section 4, 2nd para:

   Firstly, if the email client does not understand multipart/
   multilingual then it should treat the message as if it was multipart/

s/should/will and add a reference to the relevant MIME RFC that requires
this behaviour.

   mixed and render message parts accordingly.

4th para in the same section:

   If there is no match for the user's preferred language (or there is
   no preferred language information available) the email client SHOULD
   select the language independent part (if one exists) or the first
   language part (directly after the multilingual preface) if a language
   independent part does not exist.

I think asking user (as per MAY below in the same section) might be a
better choice than showing a random part in a language the user might
not understand. But I don't feel strongly about this.

In Section 6: This document should add ABNF for the Translation-Type
header field in order to avoid doubt. For example, CFWS shouldn't be
allowed in it, but optional FWS probably needs to be allowed before the
value. Without seeing the ABNF I have to make guesses when implementing
parser for this header field.


In Section 8.2: multipart/mixed with a single image part is not really
the best example. While it is legal, you should probably just use
image/png directly.

In Section 10.1:

Interoperability Considerations: I keep believing that such
implementations are non compliant with MIME, so it would be better to
say so.

"Published Specification" should say "RFC XXXX", so that RFC Editor
would know to replace XXXX with the document RFC # before publication.
IANA templates are cut & pasted to IANA website, so saying "this
document" is not going to be useful.

I think "Change Controller" field is missing from the registration
template.

Best Regards,
Alexey


From nobody Tue Jul 25 10:41: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 5F088131E81; Tue, 25 Jul 2017 10:41:34 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: The IESG 
To: "IETF-Announce" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.57.0
Auto-Submitted: auto-generated
Precedence: bulk
CC: slim@ietf.org, draft-ietf-slim-multilangcontent@ietf.org, slim-chairs@ietf.org, alexey.melnikov@isode.com, Bernard Aboba , bernard.aboba@gmail.com
Reply-To: ietf@ietf.org
Sender: 
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-ID: <150100449429.26131.11150968929985316822.idtracker@ietfa.amsl.com>
Date: Tue, 25 Jul 2017 10:41:34 -0700
Archived-At: 
Subject: [Slim] Last Call:  (Multiple Language Content Type) to Proposed Standard
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: Tue, 25 Jul 2017 17:41:34 -0000

The IESG has received a request from the Selection of Language for Internet
Media WG (slim) to consider the following document: - 'Multiple Language
Content Type'
   as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2017-08-08. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

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 file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-slim-multilangcontent/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-slim-multilangcontent/ballot/


No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information: 
    draft-tomkinson-multilangcontent: Multiple Language Content Type (None - )
    draft-tomkinson-slim-multilangcontent: Multiple Language Content Type (None - )




From nobody Tue Jul 25 10:42:45 2017
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81FAB131E8A for ; Tue, 25 Jul 2017 10:42:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 PQXOWtGkUUKG for ; Tue, 25 Jul 2017 10:42:42 -0700 (PDT)
Received: from alum-mailsec-scanner-1.mit.edu (alum-mailsec-scanner-1.mit.edu [18.7.68.12]) by ietfa.amsl.com (Postfix) with ESMTP id C3F43131A50 for ; Tue, 25 Jul 2017 10:42:40 -0700 (PDT)
X-AuditID: 1207440c-c4bff70000000b4f-da-5977830f07db
Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 67.DA.02895.F0387795; Tue, 25 Jul 2017 13:42:39 -0400 (EDT)
Received: from [192.168.1.110] (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id v6PHgcif020969 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 25 Jul 2017 13:42:39 -0400
To: slim@ietf.org
References:    
From: Paul Kyzivat 
Message-ID: <518f72c7-da4f-120e-f77f-cd61719410f3@alum.mit.edu>
Date: Tue, 25 Jul 2017 13:42:38 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHIsWRmVeSWpSXmKPExsUixO6iqMvfXB5p0DjJ3GLmh042B0aPJUt+ MgUwRnHZpKTmZJalFunbJXBlnG1ezV5whK/i4K8+tgbGA1xdjJwcEgImEjceTGHsYuTiEBLY wSSxYeo6ZgjnJZPEvLmLWLsYOTiEBVwk/u8IAGkQERCU+N4zgwnEFhJoZJLovu8DYrMJaEnM OfSfBcTmFbCXuHpwJjuIzSKgKrHkxC4wW1QgTWLG9+vMEDWCEidnPgGr5xQIlGhu3A5mMwuY Sczb/JAZwhaXuPVkPhOELS/RvHU28wRG/llI2mchaZmFpGUWkpYFjCyrGOUSc0pzdXMTM3OK U5N1i5MT8/JSi3QN9XIzS/RSU0o3MUKCkmcH47d1MocYBTgYlXh4DbzKI4VYE8uKK3MPMUpy MCmJ8n7TBQrxJeWnVGYkFmfEF5XmpBYfYpTgYFYS4S2rAMrxpiRWVqUW5cOkpDlYlMR5VZeo +wkJpCeWpGanphakFsFkZTg4lCR4tzYCNQoWpaanVqRl5pQgpJk4OEGG8wAN12oCGV5ckJhb nJkOkT/FqMvxa+bWL0xCLHn5ealS4rx3G4CKBECKMkrz4ObAkskrRnGgt4R5s0FG8QATEdyk V0BLmICWzJlRCrKkJBEhJdXAGO2c0S3wdrl666v56qckfiz5JZm/jmN28dup9cLrLi99XfPu 1ETN2KsdHU8KxOqFzj+wqTc8p3F2HsvhPCv1jcFWlj9b3VjYnu79+uga/72tM2Svz9qdNPOT 3InrIhsXSy61KjsR+u+t6cxvbF2m7wNLTh6cccHsbFbVs6thCbemzPVTaPn3eqoSS3FGoqEW c1FxIgAOt7qRAQMAAA==
Archived-At: 
Subject: Re: [Slim] Human-language Issue 26: Asterisk modifier scope
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, 25 Jul 2017 17:42:44 -0000

On 7/25/17 1:09 PM, Bernard Aboba wrote:
> Paul Kyzivat said:
> 
> "(And I don't find #4 to be a reasonable choice.)"
> 
> [BA] Is there another choice/solution that you would prefer?

Since this is really a session-level feature I would prefer to see it 
controlled by a session-level attribute.

	Thanks,
	Paul

> On Tue, Jul 25, 2017 at 9:04 AM, Paul Kyzivat  > wrote:
> 
>     On 7/22/17 6:06 PM, Gunnar Hellström wrote:
> 
>         It seems not possible to invent any suitable interpretation on a
>         true media level of the asterisk controlling call failure, so
>         the comment from the review that it seems to be a session level
>         parameter placed on a media level attribute. I think that is not
>         good IETF quality, and should be corrected. I see four possible
>         solutions:
> 
>         1. Drop the idea to control if the call shall be denied.
> 
>         2. Make a separate session level attribute for this purpose.
>         e.g. a=hlang-disposition:keep / fail
> 
>         3. Use the asterisk also for a session level purpose already in
>         the current draft.
> 
>         4. Accept that we propose a draft that does not fulfill good
>         IETF quality standards and keep the wording as is.
> 
> 
>     +1
> 
>     (And I don't find #4 to be a reasonable choice.)
> 
>              Thanks,
>              Paul
> 
> 
>     _______________________________________________
>     SLIM mailing list
>     SLIM@ietf.org 
>     https://www.ietf.org/mailman/listinfo/slim
>     
> 
> 
> 
> 
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim
> 


From nobody Wed Jul 26 05:14:43 2017
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA07C131C83 for ; Wed, 26 Jul 2017 05:14:42 -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 7JhBtuutOJwB for ; Wed, 26 Jul 2017 05:14:40 -0700 (PDT)
Received: from bin-vsp-out-01.atm.binero.net (bin-mail-out-05.binero.net [195.74.38.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DA16131C6C for ; Wed, 26 Jul 2017 05:14:40 -0700 (PDT)
X-Halon-ID: fbdcf9b5-71fb-11e7-b257-005056917a89
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.43.70] (unknown [79.138.214.169]) by bin-vsp-out-01.atm.binero.net (Halon) with ESMTPSA id fbdcf9b5-71fb-11e7-b257-005056917a89; Wed, 26 Jul 2017 14:14:34 +0200 (CEST)
To: Paul Kyzivat , slim@ietf.org
References:     <518f72c7-da4f-120e-f77f-cd61719410f3@alum.mit.edu>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: <7f6b44ad-8b90-0c21-b841-763be03c32af@omnitor.se>
Date: Wed, 26 Jul 2017 14:14:33 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <518f72c7-da4f-120e-f77f-cd61719410f3@alum.mit.edu>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [Slim] Human-language Issue 26: Asterisk modifier scope
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, 26 Jul 2017 12:14:43 -0000

I see now that I made a mistake in formulating alternative 3 - see below.


Den 2017-07-25 kl. 19:42, skrev Paul Kyzivat:
> On 7/25/17 1:09 PM, Bernard Aboba wrote:
>> Paul Kyzivat said:
>>
>> "(And I don't find #4 to be a reasonable choice.)"
>>
>> [BA] Is there another choice/solution that you would prefer?
>
> Since this is really a session-level feature I would prefer to see it 
> controlled by a session-level attribute.
 That would mean alternative 2. I also find that most appropriate.
>
>     Thanks,
>     Paul
>
>> On Tue, Jul 25, 2017 at 9:04 AM, Paul Kyzivat > > wrote:
>>
>>     On 7/22/17 6:06 PM, Gunnar Hellström wrote:
>>
>>         It seems not possible to invent any suitable interpretation on a
>>         true media level of the asterisk controlling call failure, so
>>         the comment from the review that it seems to be a session level
>>         parameter placed on a media level attribute. I think that is not
>>         good IETF quality, and should be corrected. I see four possible
>>         solutions:
>>
>>         1. Drop the idea to control if the call shall be denied.
>>
>>         2. Make a separate session level attribute for this purpose.
>>         e.g. a=hlang-disposition:keep / fail
>>
>>         3. Use the asterisk also for a session level purpose already in
>>         the current draft.
 Mistake, it should read:
3. "Use the asterisk also for a media level purpose already in the 
current draft."
     This alternative of course aims at my earlier efforts to specify 
also relative modality preference with the asterisk.
    But it has problems. 1) It is not logically clean to merge two 
meanings of the asterisk, even if it looks possible. 2) In order to not 
create interop problems, this meaning should be specified in the same 
draft, and not be done as a separate addition. The wg has opposed to do so.
The decision would be easier to take if we got some comments on the 
draft about using sdp grouping for modality preference and simultaneous 
modality indication. draft-hellstrom-slim-modality-grouping


>>
>>         4. Accept that we propose a draft that does not fulfill good
>>         IETF quality standards and keep the wording as is.
>>
>>
>>     +1
>>
>>     (And I don't find #4 to be a reasonable choice.)
>>
>>              Thanks,
>>              Paul
  #2 seems to be the right way.
Gunnar
>>
>>
>>     _______________________________________________
>>     SLIM mailing list
>>     SLIM@ietf.org 
>>     https://www.ietf.org/mailman/listinfo/slim
>>     
>>
>>
>>
>>
>> _______________________________________________
>> SLIM mailing list
>> SLIM@ietf.org
>> https://www.ietf.org/mailman/listinfo/slim
>>
>
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim

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


From nobody Wed Jul 26 11:35:10 2017
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C143C131D18 for ; Wed, 26 Jul 2017 11:35:09 -0700 (PDT)
X-Quarantine-ID: 
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -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 fHv-mu4EMUbZ for ; Wed, 26 Jul 2017 11:35:08 -0700 (PDT)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 393A4131E0F for ; Wed, 26 Jul 2017 11:35:08 -0700 (PDT)
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Wed, 26 Jul 2017 11:38:19 -0700
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <7f6b44ad-8b90-0c21-b841-763be03c32af@omnitor.se>
References:     <518f72c7-da4f-120e-f77f-cd61719410f3@alum.mit.edu> <7f6b44ad-8b90-0c21-b841-763be03c32af@omnitor.se>
X-Mailer: Eudora for Mac OS X
Date: Wed, 26 Jul 2017 11:35:05 -0700
To: Gunnar =?iso-8859-1?Q?Hellstr=F6m?=  , Paul Kyzivat , slim@ietf.org
From: Randall Gellens 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Archived-At: 
Subject: Re: [Slim] Human-language Issue 26: Asterisk modifier scope
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, 26 Jul 2017 18:35:10 -0000

Why don't we just take out of the current draft the asterisk and the 
ability to indicate a caller preference to not fail the call?  Then 
Gunnar's draft(s) are free to use the asterisk.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Law of Probability Dispersal:  Whatever it is that hits the fan will
not be evenly distributed.


From nobody Wed Jul 26 13:46: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 EE69712EB99 for ; Wed, 26 Jul 2017 13:46:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6U3b2Xy-zzSB for ; Wed, 26 Jul 2017 13:46:18 -0700 (PDT)
Received: from resqmta-ch2-10v.sys.comcast.net (resqmta-ch2-10v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF03B129A9F for ; Wed, 26 Jul 2017 13:46:17 -0700 (PDT)
Received: from resomta-ch2-03v.sys.comcast.net ([69.252.207.99]) by resqmta-ch2-10v.sys.comcast.net with ESMTP id aTBvd7T2fpjExaTCCd3sG1; Wed, 26 Jul 2017 20:46:16 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1501101976; bh=fc3EUDBoEqQiZW9EG4/fzs2e2RSxc4oaLNjQcsiXzNM=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=Rgl7gQBDpQMVwXaka+rBuWZscdNXWR/w8ie59CGTJ4lOdvbtf4+AcN5vHcj3hFwlN SpznLTeICZCmFkwIaeNhBgC8Kw7e5n13spEnZIhbtSt3GvoZnV6RQ6srWb23WGOqTE Y+0Fex4RBCqEaXLhixHkTXUZHSlCboY/+DUPXN0liWatfmgJ99kmgqirRwQK6clQIc 8FwtADWNahcVBQNP+AC62DZNzR6xiTAKlnlpTDOzefVE00b1GaaGfX3vm0oxM6G+BE tV5mA/ZVKtpxYVVM49xxfukclTr2sXPuXdagAM4PqlKDBy6OHepZJlcDyFXzaB/73f RUvlYVEUTe5/g==
Received: from [192.168.1.110] ([24.62.227.142]) by resomta-ch2-03v.sys.comcast.net with SMTP id aTCCdT8ZXTnV3aTCCdD2Oo; Wed, 26 Jul 2017 20:46:16 +0000
To: slim@ietf.org
References:     <518f72c7-da4f-120e-f77f-cd61719410f3@alum.mit.edu> <7f6b44ad-8b90-0c21-b841-763be03c32af@omnitor.se> 
From: Paul Kyzivat 
Message-ID: <5f73c02c-801e-bf33-c41d-1809dd9dc25b@comcast.net>
Date: Wed, 26 Jul 2017 16:46:16 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-CMAE-Envelope: MS4wfBqrgrp1/5l6Uhu4e9z3jGKf0i8Zff/f2gKWDvLHPtju564RJZR7lNePg8o/sHj8+D0lgTNsT2s4DtK63NiIb3zo5cilUOUU5cqFI0eEennd+0Zb7kyy Ln8Cns54abFrzhy1/PYqJNcNmm9LPy4diyV5uGkxjULlkmJ8Ls7L69hm
Archived-At: 
Subject: Re: [Slim] Human-language Issue 26: Asterisk modifier scope
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, 26 Jul 2017 20:46:23 -0000

On 7/26/17 2:35 PM, Randall Gellens wrote:
> Why don't we just take out of the current draft the asterisk and the 
> ability to indicate a caller preference to not fail the call?  Then 
> Gunnar's draft(s) are free to use the asterisk.

Then what is the expectation regarding whether to accept a call with no 
matching language?

I guess it would make the most sense for the callee to accept the call 
unless he doesn't want a call without matching language. Then if the 
callee does accept the call without the matching language the caller can 
still terminate the call once he realizes that is the situation.

That seems reasonable to me.

	Thanks,
	Paul


From nobody Wed Jul 26 14:14:52 2017
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59D1413178D for ; Wed, 26 Jul 2017 14:14:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.89
X-Spam-Level: 
X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uXPfv8eEpLgq for ; Wed, 26 Jul 2017 14:14:49 -0700 (PDT)
Received: from mail-qk0-x242.google.com (mail-qk0-x242.google.com [IPv6:2607:f8b0:400d:c09::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44EAC131461 for ; Wed, 26 Jul 2017 14:14:49 -0700 (PDT)
Received: by mail-qk0-x242.google.com with SMTP id v76so5002014qka.5 for ; Wed, 26 Jul 2017 14:14:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=sJVIUy5z6CvA2Pzaz4QfKEXshn1S9TrT4GDsS6jGp5k=; b=PnkT2HuV09kiB/2wPW7bwSPzciCW3l/e0fVWH4VcZozsIQFAhnzd/DNNWTv7mhLMBN 71P3ucF1inO3z4AiIBZw03UdGXt8zcJlmlwbNgAUH73mZH6ZJ+MMF8zG698Uw7ZEvcXV YDGFYOxl59xkMc6tO5cufSBFHnsT8JS6h6PKnEY//iQOWRTDu8Tgfjj184drtLMIOcZ1 VioxRo9rg5vQIwoacTwBQepYNfK8MrqetsdV8h+S8Qvs57nYRKmjXMlHOfGelyRA9FCZ 5s+oAQ7OWuC9wYOg1s1zUJKIZXOqnUqxZ6GS4eD3TfyYLOcc2m9o8YXLglylsK8i28VB o57A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=sJVIUy5z6CvA2Pzaz4QfKEXshn1S9TrT4GDsS6jGp5k=; b=EGQCsfX7Z+lGjfFrIaHXAlVTMzsgIFMXn/57qojr/paS5ZsXCR387uuY0FzSfaI6mo e323T61hb/b8P1cwz8dkVMj9slydEgGHuc3yEnj9meFOjeiyElDSnjQhCae/Wx4cOyO9 Awx1vyTANwWwNviDOm5ID3kw567y5BjGpXhA0QzL5JCz1k/rKbdMKdNURVgAh/nhs7uY 7cpNYPj/ICtBosHhVf8rljrlPNIrToeY/u3ayW+FOD9FKiP8+fz/N8n71RPtXNMc1zAE taek9+VWxw8eIFbqSFq7J/8ZRpBXENS0T6DI7fO8UwdP2HOlKXCoY1Rbhu496GMgtxFX ZHow==
X-Gm-Message-State: AIVw112tqP4QH0QBdzYCs0WuWHz2IyMSCj8mzIFZ0NggFnimLZuDcVey DfDDsMrb0pB6AQU2
X-Received: by 10.233.237.132 with SMTP id c126mr3214777qkg.215.1501103688287;  Wed, 26 Jul 2017 14:14:48 -0700 (PDT)
Received: from [10.96.9.193] (neustar-sthide-nat1.neustar.biz. [156.154.81.54]) by smtp.gmail.com with ESMTPSA id m64sm3304892qte.53.2017.07.26.14.14.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Jul 2017 14:14:47 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Brian Rosen 
In-Reply-To: <5f73c02c-801e-bf33-c41d-1809dd9dc25b@comcast.net>
Date: Wed, 26 Jul 2017 14:14:44 -0700
Cc: slim@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <1CFADB4C-4B0F-4EEA-A189-1DB6D1F7D0EF@brianrosen.net>
References:     <518f72c7-da4f-120e-f77f-cd61719410f3@alum.mit.edu> <7f6b44ad-8b90-0c21-b841-763be03c32af@omnitor.se>  <5f73c02c-801e-bf33-c41d-1809dd9dc25b@comcast.net>
To: Paul Kyzivat 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [Slim] Human-language Issue 26: Asterisk modifier scope
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, 26 Jul 2017 21:14:51 -0000

I think it=E2=80=99s up to the called party, right?  =E2=80=9CReject=E2=80=
=9D a call after you have an offer has to be done by the UAS.  So the =
asterisk is advice to the UAS on whether to accept the call or reject =
it.
The callee, after it gets the answer, can always send BYE, of course but =
that=E2=80=99s not a =E2=80=9Creject=E2=80=9D.=20

The asterisk was just a way to indicated the caller=E2=80=99s preference =
on the matter.

I really think we=E2=80=99ve blown this up way, way beyond what we =
intended, which was to send an advisory note from the UAC to the UAS =
that suggests what the caller would prefer.  It wasn=E2=80=99t supposed =
to be media specific - it=E2=80=99s just a suggestion as to what to do =
when faced with no common language.  It=E2=80=99s advisory.  It =
doesn=E2=80=99t suggest what media or language that will be used.  =
It=E2=80=99s just a notion of what the caller would like the called =
party to do in this case.

Brian


> On Jul 26, 2017, at 1:46 PM, Paul Kyzivat  =
wrote:
>=20
> On 7/26/17 2:35 PM, Randall Gellens wrote:
>> Why don't we just take out of the current draft the asterisk and the =
ability to indicate a caller preference to not fail the call?  Then =
Gunnar's draft(s) are free to use the asterisk.
>=20
> Then what is the expectation regarding whether to accept a call with =
no matching language?
>=20
> I guess it would make the most sense for the callee to accept the call =
unless he doesn't want a call without matching language. Then if the =
callee does accept the call without the matching language the caller can =
still terminate the call once he realizes that is the situation.
>=20
> That seems reasonable to me.
>=20
> 	Thanks,
> 	Paul
>=20
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim


From nobody Wed Jul 26 14:26:45 2017
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26E66131CFF for ; Wed, 26 Jul 2017 14:26:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level: 
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b9bXKVBhbnpc for ; Wed, 26 Jul 2017 14:26:42 -0700 (PDT)
Received: from alum-mailsec-scanner-4.mit.edu (alum-mailsec-scanner-4.mit.edu [18.7.68.15]) by ietfa.amsl.com (Postfix) with ESMTP id 1A90412420B for ; Wed, 26 Jul 2017 14:26:42 -0700 (PDT)
X-AuditID: 1207440f-343ff70000000b50-68-59790910f610
Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 7D.B5.02896.11909795; Wed, 26 Jul 2017 17:26:41 -0400 (EDT)
Received: from [192.168.1.110] (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id v6QLQdXf006434 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 26 Jul 2017 17:26:40 -0400
To: Brian Rosen 
Cc: slim@ietf.org
References:     <518f72c7-da4f-120e-f77f-cd61719410f3@alum.mit.edu> <7f6b44ad-8b90-0c21-b841-763be03c32af@omnitor.se>  <5f73c02c-801e-bf33-c41d-1809dd9dc25b@comcast.net> <1CFADB4C-4B0F-4EEA-A189-1DB6D1F7D0EF@brianrosen.net>
From: Paul Kyzivat 
Message-ID: <10119f34-c214-4585-532c-0a3588403426@alum.mit.edu>
Date: Wed, 26 Jul 2017 17:26:39 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <1CFADB4C-4B0F-4EEA-A189-1DB6D1F7D0EF@brianrosen.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphleLIzCtJLcpLzFFi42IRYndR1BXkrIw06FsoZvH0/jQ2i5kfOtkc mDzuf/vL7rFkyU+mAKYoLpuU1JzMstQifbsErozn8yYwFlwSqJh+dwZzA+Nk3i5GTg4JAROJ CcsWsncxcnEICexgkli44hYLhHOVSWLJvw9AGQ4OYQEXif87AkAaRASUJXbe6mQHsZkFBCX2 dN5jgqhvYpG4tquLESTBJqAlMefQfxYQm1fAXmL6hWVgDSwCqhJn1/eygtiiAmkSM75fZ4ao EZQ4OfMJC8guTgEniR8bvSHmm0nM2/yQGcIWl7j1ZD4ThC0v0bx1NvMERoFZSLpnIWmZhaRl FpKWBYwsqxjlEnNKc3VzEzNzilOTdYuTE/PyUot0TfRyM0v0UlNKNzFCAph/B2PXeplDjAIc jEo8vCumVEQKsSaWFVfmHmKU5GBSEuWdZAoU4kvKT6nMSCzOiC8qzUktPsQowcGsJMKbz14Z KcSbklhZlVqUD5OS5mBREudVX6LuJySQnliSmp2aWpBaBJOV4eBQkuBt5wBqFCxKTU+tSMvM KUFIM3FwggznARpeAFLDW1yQmFucmQ6RP8Woy/Fr5tYvTEIsefl5qVLivKogRQIgRRmleXBz YInnFaM40FvCvDIgVTzApAU36RXQEiagJXNmlIIsKUlESEk1MK6+e7Cyc56VhIzZd/PtETri jFuZuHe1TWGcefeA/Sb+6keJrZNX/zqq23U4oztIRO7MjI8vvthnL+15lqe5//v2J29Y3oRt rE8vPOLxUqaRK/q4qMMBHr1Vwf/f9xYHLVn59tJfw8iDl5Q5ZBdJFbOXewh82h0Vbaw+g6t1 PXNHjW1vYob6BCWW4oxEQy3mouJEAKCVxS0XAwAA
Archived-At: 
Subject: Re: [Slim] Human-language Issue 26: Asterisk modifier scope
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, 26 Jul 2017 21:26:44 -0000

On 7/26/17 5:14 PM, Brian Rosen wrote:
> I think it’s up to the called party, right?  “Reject†a call after you have an offer has to be done by the UAS.  So the asterisk is advice to the UAS on whether to accept the call or reject it.
> The callee, after it gets the answer, can always send BYE, of course but that’s not a “rejectâ€.
> 
> The asterisk was just a way to indicated the caller’s preference on the matter.
> 
> I really think we’ve blown this up way, way beyond what we intended, which was to send an advisory note from the UAC to the UAS that suggests what the caller would prefer.  It wasn’t supposed to be media specific - it’s just a suggestion as to what to do when faced with no common language.  It’s advisory.  It doesn’t suggest what media or language that will be used.  It’s just a notion of what the caller would like the called party to do in this case.

Sure, I get that. It is effectively a callerpref. Maybe the right thing 
to do is to define it as such.

If we want to keep it, and if it must be in SDP, then I think it ought 
to be a session-level attribute. The easiest way out is just to drop it.

	Thanks,
	Paul

> Brian
> 
> 
>> On Jul 26, 2017, at 1:46 PM, Paul Kyzivat  wrote:
>>
>> On 7/26/17 2:35 PM, Randall Gellens wrote:
>>> Why don't we just take out of the current draft the asterisk and the ability to indicate a caller preference to not fail the call?  Then Gunnar's draft(s) are free to use the asterisk.
>>
>> Then what is the expectation regarding whether to accept a call with no matching language?
>>
>> I guess it would make the most sense for the callee to accept the call unless he doesn't want a call without matching language. Then if the callee does accept the call without the matching language the caller can still terminate the call once he realizes that is the situation.
>>
>> That seems reasonable to me.
>>
>> 	Thanks,
>> 	Paul
>>
>> _______________________________________________
>> SLIM mailing list
>> SLIM@ietf.org
>> https://www.ietf.org/mailman/listinfo/slim
> 
> 


From nobody Wed Jul 26 14:35:51 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 2A9F6131D0A for ; Wed, 26 Jul 2017 14:35:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mw0Dsm36jx2x for ; Wed, 26 Jul 2017 14:35:48 -0700 (PDT)
Received: from mail-ua0-x242.google.com (mail-ua0-x242.google.com [IPv6:2607:f8b0:400c:c08::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41B0E131471 for ; Wed, 26 Jul 2017 14:35:48 -0700 (PDT)
Received: by mail-ua0-x242.google.com with SMTP id x24so15117540uah.5 for ; Wed, 26 Jul 2017 14:35:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+vfa+ioBTHlcAXw6lyXfezwe0RXaxwGibhENN8uY1VA=; b=HP6rsHCbo1/xjKxIib2x47NR1BBBW6d4MEPQwZmdAceLU01e8Mg/1j8tBgnp0qS0vt txL3+DEmgApKKtYtv4Y6E+5acTkLTvP9UtrROrE1BS1W6fizg5n7dSSRzegcAOpSphft 2Naa33mwBAnVuyOgSSsIHuiKfgWFsvuu9bdPI8e6aXkFvDH4hl/UBZZbFW9Zx5qY0FlV aDH2G/aeU+YlNhJ5j/dAxZXU1T4CIuXJsLy+EICFzdKo+6+HsmLJnxnb9mgSyrvU4jtR TAsWSxRdTAGHNEv4uj2g40li6D9Mm5HomsSH3G57KFh4Cmbx+MmzscoGWICb06ham8/p Ux9w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+vfa+ioBTHlcAXw6lyXfezwe0RXaxwGibhENN8uY1VA=; b=c1hg0mQKGjYZJpBTCJMkK4W3i/q56yEwkHLM8UTz+oyipQL26X/8zm0Q9KQXiZ48Tz a/ATEvN3+zQ2cXlJCTYM5EPK37UDfXDUb2s6E+vg9LnOv+6DR0QlX7ViUsrE49chnXv9 VdU2/8xLRth8lYh+sh0Loks4wHdfD00hEYFkUDU/BXyR/VwbMn0QvoLwXD/sFFrqEWCl jb7lA8PAXA0rtP39hiq+EMuMH+pHP6buSR4fE6GzFo9SdUp7RJ68ND4e7ArCul0GIZeE oUE8CDXeM+LrQaFBxNpM4tLmcAfQOV7TGY3y06QvNHCOwTR3uYfcar4Y8ZBJ5i176Mlb TUEg==
X-Gm-Message-State: AIVw112Ovjulk7YFx8s/GCHA0sqJkPlkVpY8kPdNxN/WGnrGMBpvRVnE ZJbFmYDT7Kd8qHAArTHLPwDZcfxBKBxSsgU=
X-Received: by 10.176.3.162 with SMTP id 31mr1533231uau.149.1501104947002; Wed, 26 Jul 2017 14:35:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.159.36.111 with HTTP; Wed, 26 Jul 2017 14:35:26 -0700 (PDT)
In-Reply-To: <5f73c02c-801e-bf33-c41d-1809dd9dc25b@comcast.net>
References:     <518f72c7-da4f-120e-f77f-cd61719410f3@alum.mit.edu> <7f6b44ad-8b90-0c21-b841-763be03c32af@omnitor.se>  <5f73c02c-801e-bf33-c41d-1809dd9dc25b@comcast.net>
From: Bernard Aboba 
Date: Wed, 26 Jul 2017 14:35:26 -0700
Message-ID: 
To: Paul Kyzivat 
Cc: slim@ietf.org
Content-Type: multipart/alternative; boundary="94eb2c05ae0223013805553f3be0"
Archived-At: 
Subject: Re: [Slim] Human-language Issue 26: Asterisk modifier scope
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, 26 Jul 2017 21:35:50 -0000

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

Paul said:

"Then what is the expectation regarding whether to accept a call with no
matching language?"

I guess it would make the most sense for the callee to accept the call
unless he doesn't want a call without matching language. Then if the callee
does accept the call without the matching language the caller can still
terminate the call once he realizes that is the situation.

That seems reasonable to me."

[BA] The inability to negotiate a matching language is different from other
SDP negotiation failures such as the inability to negotiate a matching
codec, since even without a matching language, it still may be useful to
successfully negotiate media characteristics and bring up the call.
Therefore it is not clear to me how much value the "*" has in the current
draft, regardless of how it is defined.

For example, if the callee has policy that dictates that it will always
accept the call (e.g. a PSAP), the callee might always ignore the "*".
This might be frustrating to the caller, but the caller may still choose
not to terminate the call.

Even if the callee cares deeply about a matching language (e.g. a voice
recognition or chat bot system that is only supports a subset of
languages), the callee might still choose to ignore the "*".

For example, the callee might accept the call in order to provide
information to the caller (e.g. a pre-recorded voice or text message
indicating that the caller's languages are not supported).

On Wed, Jul 26, 2017 at 1:46 PM, Paul Kyzivat 
wrote:

> On 7/26/17 2:35 PM, Randall Gellens wrote:
>
>> Why don't we just take out of the current draft the asterisk and the
>> ability to indicate a caller preference to not fail the call?  Then
>> Gunnar's draft(s) are free to use the asterisk.
>>
>
> Then what is the expectation regarding whether to accept a call with no
> matching language?
>
> I guess it would make the most sense for the callee to accept the call
> unless he doesn't want a call without matching language. Then if the callee
> does accept the call without the matching language the caller can still
> terminate the call once he realizes that is the situation.
>
> That seems reasonable to me.
>
>         Thanks,
>         Paul
>
>
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim
>

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


Paul said:=C2=A0

"Then what is the expectation regarding whether to accept a=
 call with no matching language?"

I guess it would make the most sense for the callee=
 to accept the call unless he doesn't want a call without matching lang=
uage. Then if the callee does accept the call without the matching language=
 the caller can still terminate the call once he realizes that is the situa=
tion.

<=
div>That seems reasonable to me.&qu=
ot;

[BA] The inability to negotiate a matching lan=
guage is different from other SDP negotiation failures such as the inabilit=
y to negotiate a matching codec, since even without a matching language, it=
 still may be useful to successfully negotiate media characteristics and br=
ing up the call.=C2=A0 Therefore it is not clear to me how much value the &=
quot;*" has in the current draft, regardless of how it is defined.

For example, if the callee has policy that dictates t=
hat it will always accept the call (e.g. a PSAP), the callee might always i=
gnore the "*".=C2=A0 This might be frustrating to the caller, but=
 the caller may still choose not to terminate the call.

Even if the callee cares deeply about a matching language (e.g. a voi=
ce recognition or chat bot system that is only supports a subset of languag=
es), the callee might still choose to ignore the "*". =C2=A0

For example, the callee might accept the call in order=
 to provide information to the caller (e.g. a pre-recorded voice or text me=
ssage indicating that the caller's languages are not supported).=C2=A0<=
/div>

On Wed=
, Jul 26, 2017 at 1:46 PM, Paul Kyzivat <paul.kyzivat@comcast.net> wrote:
On =
7/26/17 2:35 PM, Randall Gellens wrote:



Why don't we just take out of the current draft the asterisk and the ab=
ility to indicate a caller preference to not fail the call?=C2=A0 Then Gunn=
ar's draft(s) are free to use the asterisk.





Then what is the expectation regarding whether to accept a call with no mat=
ching language?



I guess it would make the most sense for the callee to accept the call unle=
ss he doesn't want a call without matching language. Then if the callee=
 does accept the call without the matching language the caller can still te=
rminate the call once he realizes that is the situation.



That seems reasonable to me.



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

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Paul



_______________________________________________

SLIM mailing list

SLIM@ietf.org

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





--94eb2c05ae0223013805553f3be0--


From nobody Wed Jul 26 15:12: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 A30BA131E82 for ; Wed, 26 Jul 2017 15:12:21 -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 pV3gbU8VfcSm for ; Wed, 26 Jul 2017 15:12:19 -0700 (PDT)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 85CCC131E77 for ; Wed, 26 Jul 2017 15:12:15 -0700 (PDT)
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Wed, 26 Jul 2017 15:15:25 -0700
Mime-Version: 1.0
Message-Id: 
In-Reply-To: 
References:     <518f72c7-da4f-120e-f77f-cd61719410f3@alum.mit.edu> <7f6b44ad-8b90-0c21-b841-763be03c32af@omnitor.se>  <5f73c02c-801e-bf33-c41d-1809dd9dc25b@comcast.net> 
X-Mailer: Eudora for Mac OS X
Date: Wed, 26 Jul 2017 15:12:09 -0700
To: Bernard Aboba , Paul Kyzivat 
From: Randall Gellens 
Cc: slim@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Archived-At: 
Subject: Re: [Slim] Human-language Issue 26: Asterisk modifier scope
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, 26 Jul 2017 22:12:22 -0000

At 2:35 PM -0700 7/26/17, Bernard Aboba wrote:

>  Paul said:
>
>  "Then what is the expectation regarding whether to accept a call 
> with no matching language?"
>
>  I guess it would make the most sense for the callee to accept the 
> call unless he doesn't want a call without matching language. Then 
> if the callee does accept the call without the matching language 
> the caller can still terminate the call once he realizes that is 
> the situation.
>
>  That seems reasonable to me."
>
>  [BA] The inability to negotiate a matching language is different 
> from other SDP negotiation failures such as the inability to 
> negotiate a matching codec, since even without a matching language, 
> it still may be useful to successfully negotiate media 
> characteristics and bring up the call.  Therefore it is not clear 
> to me how much value the "*" has in the current draft, regardless 
> of how it is defined.
>
>  For example, if the callee has policy that dictates that it will 
> always accept the call (e.g. a PSAP), the callee might always 
> ignore the "*".  This might be frustrating to the caller, but the 
> caller may still choose not to terminate the call.
>
>  Even if the callee cares deeply about a matching language (e.g. a 
> voice recognition or chat bot system that is only supports a subset 
> of languages), the callee might still choose to ignore the "*".
>
>  For example, the callee might accept the call in order to provide 
> information to the caller (e.g. a pre-recorded voice or text 
> message indicating that the caller's languages are not supported).

The draft has said for some time that the asterisk is nothing more 
than advisory, and has explicitly said that the callee is free to 
ignore either the presence or absence of an asterisk:

    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.

Therefore, if the asterisk is causing heartburn, we can remove it 
without technical impact.

--Randy

>
>  On Wed, Jul 26, 2017 at 1:46 PM, Paul Kyzivat 
> <paul.kyzivat@comcast.net> wrote:
>
>  On 7/26/17 2:35 PM, Randall Gellens wrote:
>
>  Why don't we just take out of the current draft the asterisk and 
> the ability to indicate a caller preference to not fail the call? 
> Then Gunnar's draft(s) are free to use the asterisk.
>
>
>  Then what is the expectation regarding whether to accept a call 
> with no matching language?
>
>  I guess it would make the most sense for the callee to accept the 
> call unless he doesn't want a call without matching language. Then 
> if the callee does accept the call without the matching language 
> the caller can still terminate the call once he realizes that is 
> the situation.
>
>  That seems reasonable to me.
>
>          Thanks,
>          Paul
>
>
>  _______________________________________________
>  SLIM mailing list
>  SLIM@ietf.org
> 
> https://www.ietf.org/mailman/listinfo/slim
>
>
>
>  _______________________________________________
>  SLIM mailing list
>  SLIM@ietf.org
>  https://www.ietf.org/mailman/listinfo/slim


-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
It isn't pollution that's harming the environment.  It's the
impurities in our air and water that are doing it.
                 --Dan Quayle (then-U.S. Vice-President)


From nobody Wed Jul 26 15:21: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 4CF6F131E96 for ; Wed, 26 Jul 2017 15:21:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sxScyqUxKFoL for ; Wed, 26 Jul 2017 15:21:18 -0700 (PDT)
Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::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 3A373131E92 for ; Wed, 26 Jul 2017 15:21:18 -0700 (PDT)
Received: by mail-ua0-x22c.google.com with SMTP id f9so127920785uaf.4 for ; Wed, 26 Jul 2017 15:21:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NICkmfWBDpqygKB8JInM63UcOgMmIZM0NmwTDmpl37E=; b=Nri+qzcUzH0nFbyFY8Va8YpuXloK10/V1WzlRrP0a5yaDjmwb8lwjvcs4R8xF4zaNH 6mfcRg3PV9/A95anqmq5mwfIjH6WCEX7rWHOyP8CudNxbWgbQowyU70qec1C59nK/JDZ hzBBtAfzQg7o8PuJDt/Dugu8BAv+MUiOQtYi/56PhWtOJeJpBVGlEF/RaykAC3cHr2Gs EU9AyJL8Eg4O78sOzRvjbPs9h3HJxWcCs8rXJe1ryUuzv0Psd77ZZw6bmT0dLjbRshlE /3x1NXKR9+LmYxn9iZHSfbrERJBWDFYqy6l9RbDNSy5Sba54aqkhO+KbQkYVprkho6z9 lyKw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NICkmfWBDpqygKB8JInM63UcOgMmIZM0NmwTDmpl37E=; b=BIqsm9lOKvDiMKTBQMzA9o/v3ZSL5+SROT/DwOIDXuJgNs12F2L4sGHKzAVnKKjKKh mtN9+7A4Zqa9jt1wH5IEnJXK74aU9c2S94tXE4M6aSU3xcgc3JpE6vNrmWqUmIAku/1a wrpmgowLhr2eo3/bXbkKLCFO3tbS+mJlSlY6vN7+brl88i16u7zwHWu59QyP8MFzzLsN NNQyzyLohpb5ShYE/R+G9uJG4D12cWrlX/g8ThPjfa5pXLOmAmwARQNwZxxcNpSGS+cV cv+31JvgL63u+YN65OvX3h98PtRny2eWmxMeH2+zSId1v9HMrF3B9DEesicJmcBq7uAB 3wOw==
X-Gm-Message-State: AIVw110XH6fO24PKfKofV5wwtdg/ZE2hUJWcg51iREMB40Y8wOzqI/0s 62lEIwu9FcB/wZv7SuoxyFWbXEr9ug==
X-Received: by 10.159.51.231 with SMTP id y39mr1622458uab.130.1501107677070; Wed, 26 Jul 2017 15:21:17 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.159.36.111 with HTTP; Wed, 26 Jul 2017 15:20:56 -0700 (PDT)
In-Reply-To: 
References:     <518f72c7-da4f-120e-f77f-cd61719410f3@alum.mit.edu> <7f6b44ad-8b90-0c21-b841-763be03c32af@omnitor.se>  <5f73c02c-801e-bf33-c41d-1809dd9dc25b@comcast.net>  
From: Bernard Aboba 
Date: Wed, 26 Jul 2017 15:20:56 -0700
Message-ID: 
To: Randall Gellens 
Cc: Paul Kyzivat , slim@ietf.org
Content-Type: multipart/alternative; boundary="f403043ee2f0dc8ad105553fdd28"
Archived-At: 
Subject: Re: [Slim] Human-language Issue 26: Asterisk modifier scope
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, 26 Jul 2017 22:21:23 -0000

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

Randy said:

"Therefore, if the asterisk is causing heartburn, we can remove it without
technical impact."

[BA] Unless there is some compelling reason to keep it, removing the "*"
might be the simplest way to resolve Issue 26.

On Wed, Jul 26, 2017 at 3:12 PM, Randall Gellens 
wrote:

> At 2:35 PM -0700 7/26/17, Bernard Aboba wrote:
>
>  Paul said:
>>
>>  "Then what is the expectation regarding whether to accept a call with no
>> matching language?"
>>
>>  I guess it would make the most sense for the callee to accept the call
>> unless he doesn't want a call without matching language. Then if the callee
>> does accept the call without the matching language the caller can still
>> terminate the call once he realizes that is the situation.
>>
>>  That seems reasonable to me."
>>
>>  [BA] The inability to negotiate a matching language is different from
>> other SDP negotiation failures such as the inability to negotiate a
>> matching codec, since even without a matching language, it still may be
>> useful to successfully negotiate media characteristics and bring up the
>> call.  Therefore it is not clear to me how much value the "*" has in the
>> current draft, regardless of how it is defined.
>>
>>  For example, if the callee has policy that dictates that it will always
>> accept the call (e.g. a PSAP), the callee might always ignore the "*".
>> This might be frustrating to the caller, but the caller may still choose
>> not to terminate the call.
>>
>>  Even if the callee cares deeply about a matching language (e.g. a voice
>> recognition or chat bot system that is only supports a subset of
>> languages), the callee might still choose to ignore the "*".
>>
>>  For example, the callee might accept the call in order to provide
>> information to the caller (e.g. a pre-recorded voice or text message
>> indicating that the caller's languages are not supported).
>>
>
> The draft has said for some time that the asterisk is nothing more than
> advisory, and has explicitly said that the callee is free to ignore either
> the presence or absence of an asterisk:
>
>    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.
>
> Therefore, if the asterisk is causing heartburn, we can remove it without
> technical impact.
>
> --Randy
>
>
>>  On Wed, Jul 26, 2017 at 1:46 PM, Paul Kyzivat <> paul.kyzivat@comcast.net>paul.kyzivat@comcast.net> wrote:
>>
>>  On 7/26/17 2:35 PM, Randall Gellens wrote:
>>
>>  Why don't we just take out of the current draft the asterisk and the
>> ability to indicate a caller preference to not fail the call? Then Gunnar's
>> draft(s) are free to use the asterisk.
>>
>>
>>  Then what is the expectation regarding whether to accept a call with no
>> matching language?
>>
>>  I guess it would make the most sense for the callee to accept the call
>> unless he doesn't want a call without matching language. Then if the callee
>> does accept the call without the matching language the caller can still
>> terminate the call once he realizes that is the situation.
>>
>>  That seems reasonable to me.
>>
>>          Thanks,
>>          Paul
>>
>>
>>  _______________________________________________
>>  SLIM mailing list
>>  SLIM@ietf.org
>>
>> https://www.ietf
>> .org/mailman/listinfo/slim
>>
>>
>>
>>  _______________________________________________
>>  SLIM mailing list
>>  SLIM@ietf.org
>>  https://www.ietf.org/mailman/listinfo/slim
>>
>
>
> --
> Randall Gellens
> Opinions are personal;    facts are suspect;    I speak for myself only
> -------------- Randomly selected tag: ---------------
> It isn't pollution that's harming the environment.  It's the
> impurities in our air and water that are doing it.
>                 --Dan Quayle (then-U.S. Vice-President)
>

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


Randy said:=C2=A0

"Therefore, if the asterisk is causing heartburn, we can r=
emove it without technical impact."

[B=
A] Unless there is some compelling reason to keep it, removing the "*&=
quot; might be the simplest way to resolve Issue 26.=C2=A0

On Wed, Jul 26, 2017 a=
t 3:12 PM, Randall Gellens <rg+ietf@randy.pensive.org> wrote:
At 2:35 PM -07=
00 7/26/17, Bernard Aboba wrote:





=C2=A0Paul said:



=C2=A0"Then what is the expectation regarding whether to accept a call=
 with no matching language?"



=C2=A0I guess it would make the most sense for the callee to accept the cal=
l unless he doesn't want a call without matching language. Then if the =
callee does accept the call without the matching language the caller can st=
ill terminate the call once he realizes that is the situation.



=C2=A0That seems reasonable to me."



=C2=A0[BA] The inability to negotiate a matching language is different from=
 other SDP negotiation failures such as the inability to negotiate a matchi=
ng codec, since even without a matching language, it still may be useful to=
 successfully negotiate media characteristics and bring up the call.=C2=A0 =
Therefore it is not clear to me how much value the "*" has in the=
 current draft, regardless of how it is defined.



=C2=A0For example, if the callee has policy that dictates that it will alwa=
ys accept the call (e.g. a PSAP), the callee might always ignore the "=
*".=C2=A0 This might be frustrating to the caller, but the caller may =
still choose not to terminate the call.



=C2=A0Even if the callee cares deeply about a matching language (e.g. a voi=
ce recognition or chat bot system that is only supports a subset of languag=
es), the callee might still choose to ignore the "*".



=C2=A0For example, the callee might accept the call in order to provide inf=
ormation to the caller (e.g. a pre-recorded voice or text message indicatin=
g that the caller's languages are not supported).





The draft has said for some time that the asterisk is nothing more than adv=
isory, and has explicitly said that the callee is free to ignore either the=
 presence or absence of an asterisk:



=C2=A0 =C2=A0The called party MAY ignore the indication, e.g., for the emer=
gency

=C2=A0 =C2=A0services use case, regardless of the absence of an asterisk, a=
 PSAP

=C2=A0 =C2=A0will likely not fail the call; some call centers might reject =
a call

=C2=A0 =C2=A0even if the offer contains an asterisk.



Therefore, if the asterisk is causing heartburn, we can remove it without t=
echnical impact.



--Randy







=C2=A0On Wed, Jul 26, 2017 at 1:46 PM, Paul Kyzivat <<mailto:paul.kyzivat@comcast=
.net>paul.kyzivat@comcast.net> wrote:



=C2=A0On 7/26/17 2:35 PM, Randall Gellens wrote:



=C2=A0Why don't we just take out of the current draft the asterisk and =
the ability to indicate a caller preference to not fail the call? Then Gunn=
ar's draft(s) are free to use the asterisk.





=C2=A0Then what is the expectation regarding whether to accept a call with =
no matching language?



=C2=A0I guess it would make the most sense for the callee to accept the cal=
l unless he doesn't want a call without matching language. Then if the =
callee does accept the call without the matching language the caller can st=
ill terminate the call once he realizes that is the situation.



=C2=A0That seems reasonable to me.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Thanks,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Paul





=C2=A0_______________________________________________

=C2=A0SLIM mailing list

=C2=A0<mailto:SLIM@ie=
tf.org>SLIM@ietf.org



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







=C2=A0_______________________________________________

=C2=A0SLIM mailing list

=C2=A0SLIM@ietf.org<=
br>
=C2=A0https://www.ietf.org/mailman/listinfo/slim<=
br>






-- 

Randall Gellens

Opinions are personal;=C2=A0 =C2=A0 facts are suspect;=C2=A0 =C2=A0 I speak=
 for myself only

-------------- Randomly selected tag: ---------------

It isn't pollution that's harming the environment.=C2=A0 It's t=
he

impurities in our air and water that are doing it.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --Dan Quayle (then-=
U.S. Vice-President)





--f403043ee2f0dc8ad105553fdd28--


From nobody Wed Jul 26 16:11: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 1012F131EC1 for ; Wed, 26 Jul 2017 16:11:11 -0700 (PDT)
X-Quarantine-ID: 
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -1.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 Rh8c8jiYJ4Rt for ; Wed, 26 Jul 2017 16:11:09 -0700 (PDT)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id D67BF131EB4 for ; Wed, 26 Jul 2017 16:11:08 -0700 (PDT)
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Wed, 26 Jul 2017 16:14:20 -0700
Mime-Version: 1.0
Message-Id: 
In-Reply-To: 
References:     <518f72c7-da4f-120e-f77f-cd61719410f3@alum.mit.edu> <7f6b44ad-8b90-0c21-b841-763be03c32af@omnitor.se>  <5f73c02c-801e-bf33-c41d-1809dd9dc25b@comcast.net>   
X-Mailer: Eudora for Mac OS X
Date: Wed, 26 Jul 2017 16:11:05 -0700
To: Bernard Aboba , Randall Gellens 
From: Randall Gellens 
Cc: slim@ietf.org, Paul Kyzivat 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Archived-At: 
Subject: Re: [Slim] Human-language Issue 26: Asterisk modifier scope
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, 26 Jul 2017 23:11:11 -0000

At 3:20 PM -0700 7/26/17, Bernard Aboba wrote:

>  Randy said:
>
>  "Therefore, if the asterisk is causing heartburn, we can remove it 
> without technical impact."
>
>  [BA] Unless there is some compelling reason to keep it, removing 
> the "*" might be the simplest way to resolve Issue 26.

There is no compelling reason to keep it, especially since it's 
purely advisory.

I suggest we delete it, revise the draft, and advance it.  In my 
view, we've spent far too much time on the asterisk, which is a 
supremely trivial aspect of the draft.

--Randy

>
>  On Wed, Jul 26, 2017 at 3:12 PM, Randall Gellens 
> <rg+ietf@randy.pensive.org> wrote:
>
>  At 2:35 PM -0700 7/26/17, Bernard Aboba wrote:
>
>   Paul said:
>
>   "Then what is the expectation regarding whether to accept a call 
> with no matching language?"
>
>   I guess it would make the most sense for the callee to accept the 
> call unless he doesn't want a call without matching language. Then 
> if the callee does accept the call without the matching language 
> the caller can still terminate the call once he realizes that is 
> the situation.
>
>   That seems reasonable to me."
>
>   [BA] The inability to negotiate a matching language is different 
> from other SDP negotiation failures such as the inability to 
> negotiate a matching codec, since even without a matching language, 
> it still may be useful to successfully negotiate media 
> characteristics and bring up the call.  Therefore it is not clear 
> to me how much value the "*" has in the current draft, regardless 
> of how it is defined.
>
>   For example, if the callee has policy that dictates that it will 
> always accept the call (e.g. a PSAP), the callee might always 
> ignore the "*".  This might be frustrating to the caller, but the 
> caller may still choose not to terminate the call.
>
>   Even if the callee cares deeply about a matching language (e.g. a 
> voice recognition or chat bot system that is only supports a subset 
> of languages), the callee might still choose to ignore the "*".
>
>   For example, the callee might accept the call in order to provide 
> information to the caller (e.g. a pre-recorded voice or text 
> message indicating that the caller's languages are not supported).
>
>
>  The draft has said for some time that the asterisk is nothing more 
> than advisory, and has explicitly said that the callee is free to 
> ignore either the presence or absence of an asterisk:
>
>     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.
>
>  Therefore, if the asterisk is causing heartburn, we can remove it 
> without technical impact.
>
>  --Randy
>
>
>   On Wed, Jul 26, 2017 at 1:46 PM, Paul Kyzivat 
> <paul.kyzivat@comcast.net>paul.kyzivat@comcast.net> 
> wrote:
>
>   On 7/26/17 2:35 PM, Randall Gellens wrote:
>
>   Why don't we just take out of the current draft the asterisk and 
> the ability to indicate a caller preference to not fail the call? 
> Then Gunnar's draft(s) are free to use the asterisk.
>
>
>   Then what is the expectation regarding whether to accept a call 
> with no matching language?
>
>   I guess it would make the most sense for the callee to accept the 
> call unless he doesn't want a call without matching language. Then 
> if the callee does accept the call without the matching language 
> the caller can still terminate the call once he realizes that is 
> the situation.
>
>   That seems reasonable to me.
>
>           Thanks,
>           Paul
>
>
>   _______________________________________________
>   SLIM mailing list
> 
> SLIM@ietf.org>SLIM@ietf.org
>
> 
> <https://www.ietf.org/mailman/listinfo/slim>https://www.ietf.org/mailman/listinfo/slim
>
>
>
>   _______________________________________________
>   SLIM mailing list
>   SLIM@ietf.org
> 
> https://www.ietf.org/mailman/listinfo/slim
>
>
>
>  --
>  Randall Gellens
>  Opinions are personal;    facts are suspect;    I speak for myself only
>  -------------- Randomly selected tag: ---------------
>  It isn't pollution that's harming the environment.  It's the
>  impurities in our air and water that are doing it.
>                  --Dan Quayle (then-U.S. Vice-President)
>
>
>
>  _______________________________________________
>  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: ---------------
I base my fashion taste on what doesn't itch.
    --Gilda Radner


From nobody Wed Jul 26 16:51:15 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 815D7131EEE for ; Wed, 26 Jul 2017 16:51:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ByYnuNQwdFuN for ; Wed, 26 Jul 2017 16:51:12 -0700 (PDT)
Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F900131EE9 for ; Wed, 26 Jul 2017 16:51:12 -0700 (PDT)
Received: by mail-ua0-x229.google.com with SMTP id f9so129043365uaf.4 for ; Wed, 26 Jul 2017 16:51:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to; bh=cRS2CX+x9o/Y520YodBd9Tv7hp6zYPKThh5nOZg9WkI=; b=gdAq1VPAYaXnENoEQyxx+eBKOA0TnYHj17Cvn4Z7RkUw9iCFbHhWSe0QFeW7+LF5Ft Z9buhdqSgtQImdrXoOTFhgbLwVWoGPed+fOtatHr7HqJpD77KDmOsur8f4WhQmDYpUHl fi0cw72ckwEQc+3GkCUG80oIfITiBcTmuwXt/GWjOL8M1H564OIX6sUjGiMlzScPS/p3 q49vTlRU2C63ZTXGWbu1Lc2RxPciB6/JAw46TsCbEhraZvVMzfy8u9els4rETznhIAlu 9YOeuzw4CWYGdrhJyQGXPw3TEtVmpBHM1Y/vFJ7n38215wo100M1L9Fw/aBPm14nWqr5 ch6w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=cRS2CX+x9o/Y520YodBd9Tv7hp6zYPKThh5nOZg9WkI=; b=MLVQSB4uTrt2V0ioQr/cX55+hD1fpiacxlfhen88fhzL3HmJ2+s/lo1fi8Gw7saz47 AALE0TDjYAkMxG9SZXoi7mdXsClLDn3LdXdJ67YttYJcbja5oMuPdZaleSzOJDPlLPTr F/bU5YLNt2rM7/m2FcpIdesM6dGlS0BpQM5VJ4pWx7/J0SIu1VzEyK8eb/ro3dHeBNsL IMOrk6jsnLCZhBIQA9TswOAdWHTlZRtDDoqShpwqGdiJhiWOHrXEd51B232J0dLEYRvv JTtNcq0XwfSxF5shFZ0uD9dgoZUdTFkaxYK0dFb3bZibXEl6Qr4JbCsJthE8eoFAceJC 7uPQ==
X-Gm-Message-State: AIVw113mtxmb3/32TLk1zR5RvFqd09EHOtJFUu5VQj6S6L7b5FWEgmSi bGPHhr1ml8uMANCfwydFQMVR9lxy4OMhffw=
X-Received: by 10.176.3.162 with SMTP id 31mr1754541uau.149.1501113071206; Wed, 26 Jul 2017 16:51:11 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.159.36.111 with HTTP; Wed, 26 Jul 2017 16:50:50 -0700 (PDT)
From: Bernard Aboba 
Date: Wed, 26 Jul 2017 16:50:50 -0700
Message-ID: 
To: slim@ietf.org
Content-Type: multipart/alternative; boundary="94eb2c05ae026085030555411f24"
Archived-At: 
Subject: [Slim] draft-ietf-slim-negotiating-human-language: Proposed Disposition of Issues 34, 35 and 40
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, 26 Jul 2017 23:51:14 -0000

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

With respect to draft-ietf-slim-negotiating-human-language-13, the Issue
Tracker (see:   https://trac.ietf.org/trac/slim/report/1) indicates that
Issues 34, 35 and 40 are still open:

Ticket 
Summary 
Component

Version 
Milestone
Type
Owner
Status
Created

#34  Use the Accept-Language
syntax 
negotiating-human-language 2.0 milestone1
 defect
rg+ietf@randy.pensive.org assigned Mar 22, 2017
#35  Have an attribute to
abbreviate the bidirectionally-symmetric case
 negotiating-human-language 2.0
milestone1  defect
rg+ietf@randy.pensive.org assigned Mar 22, 2017
#40  Syntax Extensibility
 negotiating-human-language 2.0
milestone1  defect
draft-ietf-slim-negotiating-human-language@ietf.org new Jun 7, 2017


I would like to propose that we close these issues.  Are there any
objections?

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


With respect to draft-ietf-slim-negotiating-human-language=
-13, the Issue Tracker (see: =C2=A0=C2=A0https://tra=
c.ietf.org/trac/slim/report/1) indicates that Issues 34, 35 and 40=
 are still open:=C2=A0

Type=
<=
tr class=3D"gmail-color3-even" style=3D"font-stretch:normal;line-height:nor=
mal;border-bottom:1px solid rgb(204,204,204);border-top:1px solid rgb(204,2=
04,204);background:rgb(246,246,246);border-right-color:rgb(204,204,204);bor=
der-left-color:rgb(204,204,204);color:rgb(51,51,51)">
TicketSumm=
aryComponentVersionMilestoneOwnerStatusCreated
#34Use the Acce=
pt-Language syntaxnegotiati=
ng-human-language2.0milestone1defectrg+ietf@randy.pensive.orgassignedMar 22, 2017
#35Have an attribute to abbreviate the bidirectionally-sym=
metric casenegotiating-huma=
n-language2.0milestone1defectrg+ietf@randy.pensive.orgassignedMar 22, 2017
#40Syntax Extensibilitynegotiating-human-language2.=
0milestone1defectdraft-ietf-slim-negotiating-human-language@ietf.orgnewJun 7,=
 2017


I would like to propose that we close these issues.=C2=A0 Are there any ob=
jections?=C2=A0


--94eb2c05ae026085030555411f24--


From nobody Wed Jul 26 16:54:59 2017
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7EE5131EF2 for ; Wed, 26 Jul 2017 16:54:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wiJszhW5AKhA for ; Wed, 26 Jul 2017 16:54:56 -0700 (PDT)
Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49BDC131EE9 for ; Wed, 26 Jul 2017 16:54:56 -0700 (PDT)
Received: by mail-ua0-x22d.google.com with SMTP id w45so128834935uac.5 for ; Wed, 26 Jul 2017 16:54:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to; bh=1HBBgAn61WBLjiLy6F/D1x4oR9jRNFZeN7fk/O5zqFg=; b=nBX5DA4gqjtOXNgtEsav7lMthRXKN43JQfl4Yb/cDmpjjYjbkufTMD7xdaG48cDtHC ud9ps4OSBq2XU9rYz0BIWrmkXy8fgDXXtbZSljJ719W/LMQ36dcIK0UU5nmzLfEj9xKm ANurp+SJfVLKQDl6ZEBuA/SOe8pe1caKcVcAD8GByU6EtEEEU58m26U/43Enff3EEI/R 8QsRwNH6Gjhigm+ykL0T3A4/Ce44WjrNIWhEaWF23Skl8Kssl6iyYLWSFPoL+dhxMb6H mT9yjlg3RNisMawAoq9EWgq9jNDw0Si6A5kw95g10r3arX2F0DxHnTXRl398jn67UW7Z gj0g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=1HBBgAn61WBLjiLy6F/D1x4oR9jRNFZeN7fk/O5zqFg=; b=dOuG43qJO7i3fw2HFsl1cgpbdf0C1ZvCGzb77e1U3OaV7LGJN7bp3M3nF54WOi/3+n 61/EgL+DjooZ9i5uFqqx+K7H4EzDyS1CLMOJIlDqVSCgw1adk6etc3SpUfeZB/K6B08K d3nWw33oDaq5yP6TU4rVrkOuU6iAvmyWCwSq5KwgZCRnaXQRCdhzkUqA/zl2EuvyHMXd w0I6oLGiAiuwjh24VkzS2Dg08WNcRlJbjnFcjq5/2ory5LId2tvrqk1S/+3BtJASvR6T yfSV7DelViRIRkF1h35EfKcbePZPI1gRukl363by930r1dv4SCjiU8WzLZJ95TfumU3O Swug==
X-Gm-Message-State: AIVw1116IMPHi/8c7qylExABPooqfaYYCFiynkZ0MK3hL9VVMOtjq5Ku TwReQbkU70ECGWpbIXFSujP0XkJdfgew49M=
X-Received: by 10.176.78.219 with SMTP id x27mr1553742uah.144.1501113295000; Wed, 26 Jul 2017 16:54:55 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.159.36.111 with HTTP; Wed, 26 Jul 2017 16:54:34 -0700 (PDT)
From: Bernard Aboba 
Date: Wed, 26 Jul 2017 16:54:34 -0700
Message-ID: 
To: slim@ietf.org
Content-Type: multipart/alternative; boundary="f403045ea5ceb75a640555412c5f"
Archived-At: 
Subject: [Slim] draft-ietf-slim-negotiating-human-language-13: Status of Issue 41?
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, 26 Jul 2017 23:54:58 -0000

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

The Issue tracker indicates that Issue 41 (Allow sign languages in the text
stream for text notations of sign language) is still open:
https://trac.ietf.org/trac/slim/ticket/41

However, there was some discussion on this Issue that points to a potential
resolution:
https://mailarchive.ietf.org/arch/msg/slim/ppql0tolo3SCphsitXa98Ppmc7w

Is Issue 41 still open?

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


The Issue tracker indicates that Issue 41 (Allow sign lang=
uages in the text stream for text notations of sign language)=C2=A0is still=
 open:=C2=A0

Howe=
ver, there was some discussion on this Issue that points to a potential res=
olution:

Is Issue 41 still o=
pen?




--f403045ea5ceb75a640555412c5f--


From nobody Thu Jul 27 02:57:22 2017
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C1CC12441E for ; Thu, 27 Jul 2017 02:57:18 -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 yBOqnR2aOcou for ; Thu, 27 Jul 2017 02:57:16 -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 308AD1200ED for ; Thu, 27 Jul 2017 02:57:16 -0700 (PDT)
X-Halon-ID: f5a58b6d-72b1-11e7-ba9c-005056917f90
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.13.217] (unknown [185.122.190.7]) by bin-vsp-out-02.atm.binero.net (Halon) with ESMTPSA id f5a58b6d-72b1-11e7-ba9c-005056917f90; Thu, 27 Jul 2017 11:57:11 +0200 (CEST)
To: Bernard Aboba , slim@ietf.org
References: 
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: 
Date: Thu, 27 Jul 2017 11:57:11 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------7B1431DFA280715F550065EE"
Archived-At: 
Subject: Re: [Slim] draft-ietf-slim-negotiating-human-language: Proposed Disposition of Issues 34, 35 and 40
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, 27 Jul 2017 09:57:18 -0000

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

Right, I agree that issues 34, 35 and 40 can be closed as rejected.

/Gunnar


Den 2017-07-27 kl. 01:50, skrev Bernard Aboba:
> With respect to draft-ietf-slim-negotiating-human-language-13, the Issue
> Tracker (see:   https://trac.ietf.org/trac/slim/report/1) indicates that
> Issues 34, 35 and 40 are still open:
>
> Ticket 
> Summary 
> Component
> 
> Version 
> Milestone
> Type
> Owner
> Status
> Created
> 
> #34  Use the Accept-Language
> syntax 
> negotiating-human-language 2.0 milestone1
>  defect
> rg+ietf@randy.pensive.org assigned Mar 22, 2017
> #35  Have an attribute to
> abbreviate the bidirectionally-symmetric case
>  negotiating-human-language 2.0
> milestone1  defect
> rg+ietf@randy.pensive.org assigned Mar 22, 2017
> #40  Syntax Extensibility
>  negotiating-human-language 2.0
> milestone1  defect
> draft-ietf-slim-negotiating-human-language@ietf.org new Jun 7, 2017
>
>
> I would like to propose that we close these issues.  Are there any
> objections?
>
>
>
> _______________________________________________
> 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


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


  
    
  
  
    
Right, I agree that issues 34, 35 and 40 can be closed as
      rejected.

    
/Gunnar

    

    

    
Den 2017-07-27 kl. 01:50, skrev Bernard
      Aboba:

    

    

      
With respect to draft-ietf-slim-negotiating-human-language-13, the Issue
Tracker (see:   https://trac.ietf.org/trac/slim/report/1) indicates that
Issues 34, 35 and 40 are still open:

Ticket <https://trac.ietf.org/trac/slim/report/1?sort=ticket&asc=1&page=1>
Summary <https://trac.ietf.org/trac/slim/report/1?sort=summary&asc=1&page=1>
Component
<https://trac.ietf.org/trac/slim/report/1?sort=component&asc=1&page=1>
Version <https://trac.ietf.org/trac/slim/report/1?sort=version&asc=1&page=1>
Milestone
<https://trac.ietf.org/trac/slim/report/1?sort=milestone&asc=1&page=1>Type
<https://trac.ietf.org/trac/slim/report/1?sort=type&asc=1&page=1>Owner
<https://trac.ietf.org/trac/slim/report/1?sort=owner&asc=1&page=1>Status
<https://trac.ietf.org/trac/slim/report/1?sort=status&asc=1&page=1>Created
<https://trac.ietf.org/trac/slim/report/1?sort=created&asc=1&page=1>
#34 <https://trac.ietf.org/trac/slim/ticket/34> Use the Accept-Language
syntax <https://trac.ietf.org/trac/slim/ticket/34>
negotiating-human-language 2.0 milestone1
<https://trac.ietf.org/trac/slim/milestone/milestone1> defect
rg+ietf@randy.pensive.org assigned Mar 22, 2017
#35 <https://trac.ietf.org/trac/slim/ticket/35> Have an attribute to
abbreviate the bidirectionally-symmetric case
<https://trac.ietf.org/trac/slim/ticket/35> negotiating-human-language 2.0
milestone1 <https://trac.ietf.org/trac/slim/milestone/milestone1> defect
rg+ietf@randy.pensive.org assigned Mar 22, 2017
#40 <https://trac.ietf.org/trac/slim/ticket/40> Syntax Extensibility
<https://trac.ietf.org/trac/slim/ticket/40> negotiating-human-language 2.0
milestone1 <https://trac.ietf.org/trac/slim/milestone/milestone1> defect
draft-ietf-slim-negotiating-human-language@ietf.org new Jun 7, 2017


I would like to propose that we close these issues.  Are there any
objections?



      

      

      

      
_______________________________________________
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

  


--------------7B1431DFA280715F550065EE--


From nobody Thu Jul 27 03:07:43 2017
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54A241300BB for ; Thu, 27 Jul 2017 03:07:43 -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 iy4mkR5DUOaX for ; Thu, 27 Jul 2017 03:07:40 -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 21E4E12441E for ; Thu, 27 Jul 2017 03:07:39 -0700 (PDT)
X-Halon-ID: 665ac932-72b3-11e7-8607-0050569116f7
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.13.217] (unknown [185.122.190.7]) by bin-vsp-out-03.atm.binero.net (Halon) with ESMTPSA id 665ac932-72b3-11e7-8607-0050569116f7; Thu, 27 Jul 2017 12:07:30 +0200 (CEST)
To: Bernard Aboba , slim@ietf.org
References: 
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: <86248e13-984c-6d08-eeb3-0cd3860eb61e@omnitor.se>
Date: Thu, 27 Jul 2017 12:07:35 +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="------------9743FC9DFD788714137FBF7F"
Archived-At: 
Subject: Re: [Slim] draft-ietf-slim-negotiating-human-language-13: Status of Issue 41?
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, 27 Jul 2017 10:07:43 -0000

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

I recommend to make the change declared as change 1 in the ticket.

I notice that the sentence has the expression "spoken/written language 
tag". I remember Addison did not like our use of that term in another 
place. Maybe we need to modify it here also.

Gunnar


Den 2017-07-27 kl. 01:54, skrev Bernard Aboba:
> The Issue tracker indicates that Issue 41 (Allow sign languages in the text
> stream for text notations of sign language) is still open:
> https://trac.ietf.org/trac/slim/ticket/41
>
> However, there was some discussion on this Issue that points to a potential
> resolution:
> https://mailarchive.ietf.org/arch/msg/slim/ppql0tolo3SCphsitXa98Ppmc7w
>
> Is Issue 41 still open?
>
>
>
> _______________________________________________
> 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


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


  
    
  
  
    
I recommend to make the change declared as change 1 in the
      ticket.

    
I notice that the sentence has the expression "spoken/written
      language tag". I remember Addison did not like our use of that
      term in another place. Maybe we need to modify it here also.

    
Gunnar

    

    

    
Den 2017-07-27 kl. 01:54, skrev Bernard
      Aboba:

    

    

      
The Issue tracker indicates that Issue 41 (Allow sign languages in the text
stream for text notations of sign language) is still open:
https://trac.ietf.org/trac/slim/ticket/41

However, there was some discussion on this Issue that points to a potential
resolution:
https://mailarchive.ietf.org/arch/msg/slim/ppql0tolo3SCphsitXa98Ppmc7w

Is Issue 41 still open?



      

      

      

      
_______________________________________________
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

  


--------------9743FC9DFD788714137FBF7F--


From nobody Fri Jul 28 04:55:43 2017
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A531E131FC7 for ; Fri, 28 Jul 2017 04:55:42 -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 Grv7mX5fFjSH for ; Fri, 28 Jul 2017 04:55:41 -0700 (PDT)
Received: from bin-vsp-out-01.atm.binero.net (bin-mail-out-05.binero.net [195.74.38.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD2A7126DEE for ; Fri, 28 Jul 2017 04:55:40 -0700 (PDT)
X-Halon-ID: a788b7ec-738b-11e7-b257-005056917a89
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [172.20.7.164] (unknown [65.216.242.51]) by bin-vsp-out-01.atm.binero.net (Halon) with ESMTPSA id a788b7ec-738b-11e7-b257-005056917a89; Fri, 28 Jul 2017 13:55:32 +0200 (CEST)
To: "slim@ietf.org" 
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: <5833ea9b-c7fe-1cfa-2015-21e42b5c3d55@omnitor.se>
Date: Fri, 28 Jul 2017 13:55:32 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: [Slim] Simultaneity requirement in draft-ietf-slim-negotiating-human-language
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Jul 2017 11:55:42 -0000

Rereading draft-ietf-slim-negotiating-human-language-13, I found a 
couple of minor issues. I bring them up in separate mails.

1. The introduction says that we support request of simultaneous text 
and voice, but that is excluded from the protocol.

This is the sentence:

"Another example would be a user who is able to
    speak but is deaf or hard-of-hearing and requires a voice stream plus
    a text stream."

This looks as a need to specify that the user wants to receive both 
voice and captions at the same time, but that is one of the requirements 
I have tried to convince the group that we need, but it has not been 
accepted. We have said that specifying language in the same direction in 
two media means that they are alternatives to select from.

I suggest that the sentence is reworded to a case that is supported by 
this change:
"Another example would be a user who is able to
    speak but is deaf or hard-of-hearing and requires to send spoken 
language in a voice stream and receive
    written language in a text stream."

/Gunnar


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


From nobody Fri Jul 28 05:13:01 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 C9FCB131C29 for ; Fri, 28 Jul 2017 05:12:59 -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 mRDGiYtUFv_o for ; Fri, 28 Jul 2017 05:12:56 -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 41A85131FE4 for ; Fri, 28 Jul 2017 05:12:48 -0700 (PDT)
X-Halon-ID: 0e72f6f5-738e-11e7-ba9c-005056917f90
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [172.20.7.164] (unknown [65.216.242.51]) by bin-vsp-out-02.atm.binero.net (Halon) with ESMTPSA id 0e72f6f5-738e-11e7-ba9c-005056917f90; Fri, 28 Jul 2017 14:12:43 +0200 (CEST)
To: "slim@ietf.org" 
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: <376ade2a-be29-33a6-b539-5cab2b847fcd@omnitor.se>
Date: Fri, 28 Jul 2017 14:12:42 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: [Slim] How to know modality in draft-ietf-slim-negotiating-human-language
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Jul 2017 12:13:00 -0000

I remember a comment in one of the reviews (maybe from Adam ?) mentioning that it would be good if there was a simple way to decide if a language tag is a sign language or a written or spoken language.
We have not responded to that comment.

I know one application scanning the IANA language registry at startup for that purpose and scanning for the word "sign" in the tag description. But that might be seen as an inappropriate way to use IANA registers if it get used by every phone in the future.

What can we say about this review comment? Do we need to add a modality indication parameter in the syntax? Or shall we strictly limit audio to have spoken languages, video to have signed languages and text and webrtc data channels to have written languages? Or shall we leave this problem to implementation?

/Gunnar


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


From nobody Fri Jul 28 05:24:53 2017
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C17FB132004 for ; Fri, 28 Jul 2017 05:24:50 -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 IE3pUS1VrDJq for ; Fri, 28 Jul 2017 05:24:49 -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 659FD132129 for ; Fri, 28 Jul 2017 05:24:34 -0700 (PDT)
X-Halon-ID: afa5bfa4-738f-11e7-8607-0050569116f7
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [172.20.7.164] (unknown [65.216.242.51]) by bin-vsp-out-03.atm.binero.net (Halon) with ESMTPSA id afa5bfa4-738f-11e7-8607-0050569116f7; Fri, 28 Jul 2017 14:24:24 +0200 (CEST)
To: "slim@ietf.org" , "Phillips, Addison" 
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: <82c9d45e-9a00-3ecd-e8ba-7f48ffaa9e1b@omnitor.se>
Date: Fri, 28 Jul 2017 14:24:28 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: [Slim] Is the use of spoken/written language tag appropriate in draft-ietf-negotiating-human-language
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Jul 2017 12:24:51 -0000

We got a comment from Addison Phillips that use of the term 
"spoken/written language tag" would not be appropriate to use. It was 
reworded at the place where it was used.

Later, the same wording reappeared in section 5.4:

"the behavior when specifying a spoken/
  written language tag for a video media stream"

This use of the term may also be inappropriate and should be reworded.

I have not understood the reasoning why it was inappropriate in the 
first case, so I cannot judge.

/Gunnar


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


From nobody Fri Jul 28 10:41:13 2017
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0B2C1322EB for ; Fri, 28 Jul 2017 10:41:11 -0700 (PDT)
X-Quarantine-ID: 
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -1.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 h7RYOABelfaT for ; Fri, 28 Jul 2017 10:41:10 -0700 (PDT)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 41802131CF0 for ; Fri, 28 Jul 2017 10:41:10 -0700 (PDT)
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Fri, 28 Jul 2017 10:44:23 -0700
Mime-Version: 1.0
Message-Id: 
In-Reply-To: 
References: 
X-Mailer: Eudora for Mac OS X
Date: Fri, 28 Jul 2017 10:41:06 -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] draft-ietf-slim-negotiating-human-language-13: Status of Issue 41?
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Jul 2017 17:41:12 -0000

At 4:54 PM -0700 7/26/17, Bernard Aboba wrote:

>  The Issue tracker indicates that Issue 41 (Allow sign languages in 
> the text stream for text notations of sign language) is still open:
> 
> https://trac.ietf.org/trac/slim/ticket/41
>
>
>  However, there was some discussion on this Issue that points to a 
> potential resolution:
> 
> https://mailarchive.ietf.org/arch/msg/slim/ppql0tolo3SCphsitXa98Ppmc7w
>
>
>  Is Issue 41 still open?

My understanding is that there was email discussion with no consensus 
to change the text, which states:

5.4.  Undefined Combinations

    With the exception of the case mentioned in Section 5.2 (a spoken
    language tag for a video stream in parallel with an audio stream with
    the same spoken language tag), the behavior when specifying a spoken/
    written language tag for a video media stream, or a signed language
    tag for an audio or text media stream, is not defined.

I do not think there is a compelling reason to change the text. 
Leaving such combinations as undefined allows them to be specified in 
the future, if such use becomes clear.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
We don't see things as they are; we see things as we are.
                                            --Anais Nin


From nobody Fri Jul 28 14:30:31 2017
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 310D61315FF for ; Fri, 28 Jul 2017 14:30:29 -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 pvqpw1muRX91 for ; Fri, 28 Jul 2017 14:30:25 -0700 (PDT)
Received: from bin-vsp-out-01.atm.binero.net (vsp-unauthed02.binero.net [195.74.38.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8151F12FEE2 for ; Fri, 28 Jul 2017 14:30:25 -0700 (PDT)
X-Halon-ID: ed1cd597-73db-11e7-b257-005056917a89
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [172.20.7.164] (unknown [65.216.242.51]) by bin-vsp-out-01.atm.binero.net (Halon) with ESMTPSA id ed1cd597-73db-11e7-b257-005056917a89; Fri, 28 Jul 2017 23:30:11 +0200 (CEST)
To: Randall Gellens , Bernard Aboba , slim@ietf.org
References:  
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: 
Date: Fri, 28 Jul 2017 23:30:08 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [Slim] draft-ietf-slim-negotiating-human-language-13: Status of Issue 41?
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Jul 2017 21:30:29 -0000

Den 2017-07-28 kl. 19:41, skrev Randall Gellens:
> At 4:54 PM -0700 7/26/17, Bernard Aboba wrote:
>
>>  The Issue tracker indicates that Issue 41 (Allow sign languages in 
>> the text stream for text notations of sign language) is still open:
>>
>> https://trac.ietf.org/trac/slim/ticket/41 
>>
>>
>>
>>  However, there was some discussion on this Issue that points to a 
>> potential resolution:
>>
>> https://mailarchive.ietf.org/arch/msg/slim/ppql0tolo3SCphsitXa98Ppmc7w 
>>
>>
>>
>>  Is Issue 41 still open?
>
> My understanding is that there was email discussion with no consensus 
> to change the text, which states:
>
> 5.4.  Undefined Combinations
>
>    With the exception of the case mentioned in Section 5.2 (a spoken
>    language tag for a video stream in parallel with an audio stream with
>    the same spoken language tag), the behavior when specifying a spoken/
>    written language tag for a video media stream, or a signed language
>    tag for an audio or text media stream, is not defined.
>
> I do not think there is a compelling reason to change the text. 
> Leaving such combinations as undefined allows them to be specified in 
> the future, if such use becomes clear.
But why would we undefine a usage that we know is defined? I propose 
to delete the words "or text" on the last line of 5.4.

However, this interacts with one of the solution options for an issue I 
brought up today under subject "[Slim] How to know modality in 
draft-ietf-slim-negotiating-human-language". I said that we could return 
to just defining one modality per media type. Coordinated decisions are 
needed on these issues.

/Gunnar



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


From nobody Fri Jul 28 15:07:58 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 10D5C13178D for ; Fri, 28 Jul 2017 15:07:57 -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 SGIqQdatJNM2 for ; Fri, 28 Jul 2017 15:07:55 -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 EF13B131771 for ; Fri, 28 Jul 2017 15:07:54 -0700 (PDT)
X-Halon-ID: 0e056c2e-73e1-11e7-8607-0050569116f7
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [172.20.7.164] (unknown [65.216.242.51]) by bin-vsp-out-03.atm.binero.net (Halon) with ESMTPSA id 0e056c2e-73e1-11e7-8607-0050569116f7; Sat, 29 Jul 2017 00:06:51 +0200 (CEST)
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
To: "slim@ietf.org" 
Message-ID: <3e945827-8310-56aa-b2e5-7a9405ff85c4@omnitor.se>
Date: Sat, 29 Jul 2017 00:06:55 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: [Slim] Indication of modality alternatives in draft-ietf-slim-negotiating-human-language
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Jul 2017 22:07:57 -0000

We have dealt with this topic before, but rereading the draft indicates 
to me that we still need some tuning of the wording so that it is clear 
that the language indications for the same direction for different media 
are alternatives with no requirements that they need to be provided 
together, so that it is allowed to answer with just one media in each 
direction having language indication.

Suggested wording changes to make this clear:

---Change 1 in 5.2, first paragraph----------------
------old text---------
This document defines two media-level attributes starting with
    'hlang' (short for "human interactive language") to negotiate which
    human language is selected for use in each interactive media stream.
------------new text--------------------
This document defines two media-level attributes starting with
    'hlang' (short for "human interactive language") to negotiate which
    human language is selected for use in each media stream used for 
interactive language communication.
-------end of change 1-------

----Change 2 in 5.2, third paragraph ------
----old text------
   In an answer, 'hlang-send' is the language the answerer will send if
    using the media for language (which in most cases is one of the
    languages in the offer's 'hlang-recv'), and 'hlang-recv' is the
    language the answerer expects to receive in the media (which in most
    cases is one of the languages in the offer's 'hlang-send').
-----new text----
   In an answer, 'hlang-send' is the language the answerer will send if
    using the media for language (which in most cases is one of the
    languages in the offer's 'hlang-recv'), and 'hlang-recv' is the
    language the answerer expects to receive in the media if
    using the media for language (which in most
    cases is one of the languages in the offer's 'hlang-send').
----end of change 2-------------------------------


/Gunnar

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


From nobody Sat Jul 29 15:35:07 2017
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5230C12942F for ; Sat, 29 Jul 2017 15:35:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.7
X-Spam-Level: 
X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[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 gGxNzmgxLHG7 for ; Sat, 29 Jul 2017 15:35:04 -0700 (PDT)
Received: from bin-vsp-out-01.atm.binero.net (vsp-unauthed02.binero.net [195.74.38.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A28412EACD for ; Sat, 29 Jul 2017 15:35:03 -0700 (PDT)
X-Halon-ID: 23a0bce3-74ae-11e7-b257-005056917a89
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [172.20.7.164] (unknown [65.216.242.51]) by bin-vsp-out-01.atm.binero.net (Halon) with ESMTPSA id 23a0bce3-74ae-11e7-b257-005056917a89; Sun, 30 Jul 2017 00:34:55 +0200 (CEST)
To: "slim@ietf.org" , "Phillips, Addison" 
References: <82c9d45e-9a00-3ecd-e8ba-7f48ffaa9e1b@omnitor.se>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: 
Date: Sun, 30 Jul 2017 00:34:51 +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: <82c9d45e-9a00-3ecd-e8ba-7f48ffaa9e1b@omnitor.se>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [Slim] Is the use of spoken/written language tag appropriate in draft-ietf-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: Sat, 29 Jul 2017 22:35:06 -0000

The earlier discussion of this topic is found in:

https://www.ietf.org/mail-archive/web/slim/current/msg00757.html


Den 2017-07-28 kl. 14:24, skrev Gunnar Hellström:
> We got a comment from Addison Phillips that use of the term 
> "spoken/written language tag" would not be appropriate to use. It was 
> reworded at the place where it was used.
>
> Later, the same wording reappeared in section 5.4:
>
> "the behavior when specifying a spoken/
>  written language tag for a video media stream"
>
> This use of the term may also be inappropriate and should be reworded.
>
> I have not understood the reasoning why it was inappropriate in the 
> first case, so I cannot judge.
>
> /Gunnar
>
>

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


From nobody Sat Jul 29 15:46:51 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 4E2AA12EB99 for ; Sat, 29 Jul 2017 15:46:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.699
X-Spam-Level: 
X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5 tests=[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 1ohxPfwJ6AdD for ; Sat, 29 Jul 2017 15:46:48 -0700 (PDT)
Received: from bin-vsp-out-02.atm.binero.net (vsp-unauthed02.binero.net [195.74.38.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EDFD12942F for ; Sat, 29 Jul 2017 15:46:47 -0700 (PDT)
X-Halon-ID: caa91bff-74af-11e7-ba9c-005056917f90
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [172.20.7.164] (unknown [65.216.242.51]) by bin-vsp-out-02.atm.binero.net (Halon) with ESMTPSA id caa91bff-74af-11e7-ba9c-005056917f90; Sun, 30 Jul 2017 00:46:43 +0200 (CEST)
To: "slim@ietf.org" 
References: <376ade2a-be29-33a6-b539-5cab2b847fcd@omnitor.se>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: <8233c526-f66d-041e-e4eb-cad6c22b8a73@omnitor.se>
Date: Sun, 30 Jul 2017 00:46:41 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <376ade2a-be29-33a6-b539-5cab2b847fcd@omnitor.se>
Content-Type: multipart/alternative; boundary="------------CE7FE43DA74C0ADC5CF6763D"
Archived-At: 
Subject: Re: [Slim] How to know modality 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: Sat, 29 Jul 2017 22:46:50 -0000

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

The review comment on this topic was from Dale Worley and is found in 
section B of:

https://www.ietf.org/mail-archive/web/slim/current/msg00766.html

by the sentence about specifying a view of the speaker in video: "

I think this mechanism needs to be described more exactly, and in
particular, it should not depend on the UA understanding which
language tags are spoken language tags."

It is this part we have not handled: " it should not depend on the UA understanding which language tags are spoken language tags"
That is a general issue, not really linked to the issue of the view of a speaker in the video stream.


Den 2017-07-28 kl. 14:12, skrev Gunnar Hellström:
> I remember a comment in one of the reviews (maybe from Adam ?) 
> mentioning that it would be good if there was a simple way to decide 
> if a language tag is a sign language or a written or spoken language.
> We have not responded to that comment.
>
> I know one application scanning the IANA language registry at startup 
> for that purpose and scanning for the word "sign" in the tag 
> description. But that might be seen as an inappropriate way to use 
> IANA registers if it get used by every phone in the future.
>
> What can we say about this review comment? Do we need to add a 
> modality indication parameter in the syntax? Or shall we strictly 
> limit audio to have spoken languages, video to have signed languages 
> and text and webrtc data channels to have written languages? Or shall 
> we leave this problem to implementation?
>
> /Gunnar
>
>

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


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


  
    
  
  
    
The review comment on this topic was from Dale Worley and is
      found in section B of:

    
https://www.ietf.org/mail-archive/web/slim/current/msg00766.html

    
by the sentence about specifying a view of the speaker in video:
      "

    

    
I think this mechanism needs to be described more exactly, and in
particular, it should not depend on the UA understanding which
language tags are spoken language tags."

It is this part we have not handled: " it should not depend on the UA understanding which language tags are spoken language tags" 
That is a general issue, not really linked to the issue of the view of a speaker in the video stream.


    

    
Den 2017-07-28 kl. 14:12, skrev Gunnar
      Hellström:

    

    
I remember a comment in one of the reviews (maybe from
      Adam ?) mentioning that it would be good if there was a simple way
      to decide if a language tag is a sign language or a written or
      spoken language.
      

      We have not responded to that comment.
      

      

      I know one application scanning the IANA language registry at
      startup for that purpose and scanning for the word "sign" in the
      tag description. But that might be seen as an inappropriate way to
      use IANA registers if it get used by every phone in the future.
      

      

      What can we say about this review comment? Do we need to add a
      modality indication parameter in the syntax? Or shall we strictly
      limit audio to have spoken languages, video to have signed
      languages and text and webrtc data channels to have written
      languages? Or shall we leave this problem to implementation?
      

      

      /Gunnar
      

      

      

    

    

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

  


--------------CE7FE43DA74C0ADC5CF6763D--