From nobody Wed Feb 1 15:21:55 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 5C2E01295EB; Wed, 1 Feb 2017 15:21:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.42.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148599131437.18680.9777611954473801850.idtracker@ietfa.amsl.com> Date: Wed, 01 Feb 2017 15:21:54 -0800 Archived-At: Cc: slim@ietf.org Subject: [Slim] I-D Action: draft-ietf-slim-negotiating-human-language-05.txt X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 23:21:54 -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-05.txt Pages : 18 Date : 2017-02-01 Abstract: Users have various human (natural) language needs, abilities, and preferences regarding spoken, written, and signed languages. When establishing interactive communication ("calls") there needs to be a way to negotiate (communicate and match) the caller's language and media needs with the capabilities of the called party. This is especially important with emergency calls, where a call can be handled by a call taker capable of communicating with the user, or a translator or relay operator can be bridged into the call during setup, but this applies to non-emergency calls as well (as an example, when calling a company call center). This document describes the need and a solution using new SDP stream attributes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-slim-negotiating-human-language/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-slim-negotiating-human-language-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-slim-negotiating-human-language-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Feb 2 10:17:59 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 3B23412940B; Thu, 2 Feb 2017 10:17:58 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.42.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148605947823.13893.99763238254146987.idtracker@ietfa.amsl.com> Date: Thu, 02 Feb 2017 10:17:58 -0800 Archived-At: Cc: slim@ietf.org Subject: [Slim] I-D Action: draft-ietf-slim-negotiating-human-language-06.txt X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 18:17:58 -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-06.txt Pages : 19 Date : 2017-02-02 Abstract: Users have various human (natural) language needs, abilities, and preferences regarding spoken, written, and signed languages. When establishing interactive communication ("calls") there needs to be a way to negotiate (communicate and match) the caller's language and media needs with the capabilities of the called party. This is especially important with emergency calls, where a call can be handled by a call taker capable of communicating with the user, or a translator or relay operator can be bridged into the call during setup, but this applies to non-emergency calls as well (as an example, when calling a company call center). This document describes the need and a solution using new SDP stream attributes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-slim-negotiating-human-language/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-slim-negotiating-human-language-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-slim-negotiating-human-language-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Feb 2 10:21: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 546111294EE for ; Thu, 2 Feb 2017 10:21:01 -0800 (PST) X-Quarantine-ID: <0EN51eE20lOj> 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: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199] 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 0EN51eE20lOj for ; Thu, 2 Feb 2017 10:21:00 -0800 (PST) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 64C1B12940B for ; Thu, 2 Feb 2017 10:21:00 -0800 (PST) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Thu, 2 Feb 2017 10:15:11 -0800 Mime-Version: 1.0 Message-Id: In-Reply-To: <148599131437.18680.9777611954473801850.idtracker@ietfa.amsl.com> References: <148599131437.18680.9777611954473801850.idtracker@ietfa.amsl.com> X-Mailer: Eudora for Mac OS X Date: Thu, 2 Feb 2017 10:20:56 -0800 To: slim@ietf.org From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 Archived-At: Cc: Natasha Rooney , Bernard Aboba Subject: [Slim] draft-ietf-slim-negotiating-human-language-06.txt X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 18:21:01 -0000 Version -06 of the human language negotiation draft is uploaded. It addresses all open issues. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Citizens for corrupt government, unclean water, higher taxes, unsafe streets, and poor schools. From nobody Thu Feb 2 10:59: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 D075012951A for ; Thu, 2 Feb 2017 10:59:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 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=-3.199, 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 meVpFv91jEFh for ; Thu, 2 Feb 2017 10:59:40 -0800 (PST) Received: from resqmta-po-09v.sys.comcast.net (resqmta-po-09v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:168]) (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 59FE4129511 for ; Thu, 2 Feb 2017 10:59:40 -0800 (PST) Received: from resomta-po-15v.sys.comcast.net ([96.114.154.239]) by resqmta-po-09v.sys.comcast.net with SMTP id ZMbHc1JGn3kZMZMbbcemPQ; Thu, 02 Feb 2017 18:59:39 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1486061979; bh=lfxVw/eu+5c4JzPu+i+6BYw8zOk5Dz2xG+H4t46wesg=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=nXa+uJr331QEA0fvH8Jn2d0l4wsIti9nSQBTc+hYN6lYHpfTobWmhJl+b19wX9ziH LDPTMSQh8LOlAa8nZjm+0I9G/iZhKRhc0uYFMYNvUXQmwFCjMeeZreVfB2qnuVAoUg Fx6a7gp8tiLJt8eu6Ggz8MTDK16t5Y7ERkdIcWKgS+Vx61JCqF5f2VtQ1bM53KS8nq Mi24ZeGNqr1808lmCxOFV4MMvv+d1jSrCrJ3Q61dDf93Gx85Gu8zM2L7wUydkazmot r9UXJjAvX0cm2OKuNoEgVdabv8qjB0caOr1aJcftFhaJ/k5Y26f9mVsZUOGDTpvIQZ jo1UwCWbMaegA== Received: from [192.168.1.110] ([73.186.127.100]) by resomta-po-15v.sys.comcast.net with SMTP id ZMbac4nwW04HZZMbacJhKH; Thu, 02 Feb 2017 18:59:39 +0000 To: slim@ietf.org References: <148605947823.13893.99763238254146987.idtracker@ietfa.amsl.com> From: Paul Kyzivat Message-ID: <8e229648-a96f-394b-1e3c-911d90ad5855@comcast.net> Date: Thu, 2 Feb 2017 13:59:38 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <148605947823.13893.99763238254146987.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfDP6/2aSQ/WixOybHlf0udsYEun+/6gtxQxSvU8kjUxzTpi5+LEJZBXJZ5T6BE5ZmFaLUn4BfMIeoYX6IZpocnNfSGL5J1lxHBCSJCRTUlmVAqnlQplM ThFg2hfD0V0cVLWZfbecaijMPwqjblSh42NOloEsDYRzjhvTuybUItLC Archived-At: Subject: Re: [Slim] I-D Action: draft-ietf-slim-negotiating-human-language-06.txt X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 18:59:42 -0000 There is a lot of repeated material in section 6. It looks like an editing error. Thanks, Paul On 2/2/17 1:17 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Selection of Language for Internet Media of the IETF. > > Title : Negotiating Human Language in Real-Time Communications > Author : Randall Gellens > Filename : draft-ietf-slim-negotiating-human-language-06.txt > Pages : 19 > Date : 2017-02-02 > > Abstract: > Users have various human (natural) language needs, abilities, and > preferences regarding spoken, written, and signed languages. When > establishing interactive communication ("calls") there needs to be a > way to negotiate (communicate and match) the caller's language and > media needs with the capabilities of the called party. This is > especially important with emergency calls, where a call can be > handled by a call taker capable of communicating with the user, or a > translator or relay operator can be bridged into the call during > setup, but this applies to non-emergency calls as well (as an > example, when calling a company call center). > > This document describes the need and a solution using new SDP stream > attributes. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-slim-negotiating-human-language/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-slim-negotiating-human-language-06 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-slim-negotiating-human-language-06 > > > 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 > From nobody Thu Feb 2 16:20:21 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 94FB91295FE for ; Thu, 2 Feb 2017 16:20:15 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199] 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 XwJ6mxXnl7o2 for ; Thu, 2 Feb 2017 16:20:14 -0800 (PST) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 1C7D11299F6 for ; Thu, 2 Feb 2017 16:20:14 -0800 (PST) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Thu, 2 Feb 2017 16:14:22 -0800 Mime-Version: 1.0 Message-Id: In-Reply-To: <8e229648-a96f-394b-1e3c-911d90ad5855@comcast.net> References: <148605947823.13893.99763238254146987.idtracker@ietfa.amsl.com> <8e229648-a96f-394b-1e3c-911d90ad5855@comcast.net> X-Mailer: Eudora for Mac OS X Date: Thu, 2 Feb 2017 16:20:10 -0800 To: Paul Kyzivat , slim@ietf.org From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 Archived-At: Subject: Re: [Slim] I-D Action: draft-ietf-slim-negotiating-human-language-06.txt X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 00:20:15 -0000 At 1:59 PM -0500 2/2/17, Paul Kyzivat wrote: > There is a lot of repeated material in section 6. It looks like an > editing error. Are you talking about the two tables, one per attribute? I think that's a consequence of switching to the larger table template. > On 2/2/17 1:17 PM, internet-drafts@ietf.org wrote: >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Selection of Language for >> Internet Media of the IETF. >> >> Title : Negotiating Human Language in Real-Time >> Communications >> Author : Randall Gellens >> Filename : draft-ietf-slim-negotiating-human-language-06.txt >> Pages : 19 >> Date : 2017-02-02 >> >> Abstract: >> Users have various human (natural) language needs, abilities, and >> preferences regarding spoken, written, and signed languages. When >> establishing interactive communication ("calls") there needs to be a >> way to negotiate (communicate and match) the caller's language and >> media needs with the capabilities of the called party. This is >> especially important with emergency calls, where a call can be >> handled by a call taker capable of communicating with the user, or a >> translator or relay operator can be bridged into the call during >> setup, but this applies to non-emergency calls as well (as an >> example, when calling a company call center). >> >> This document describes the need and a solution using new SDP stream >> attributes. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-slim-negotiating-human-language/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-slim-negotiating-human-language-06 >> >> A diff from the previous version is available at: >> >> https://www.ietf.org/rfcdiff?url2=draft-ietf-slim-negotiating-human-language-06 >> >> >> 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 >> > > _______________________________________________ > 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: --------------- Don't accept your dog's admiration as conclusive evidence that you are wonderful. --Ann Landers From nobody Fri Feb 3 00:13: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 03C1A12951F for ; Fri, 3 Feb 2017 00:13:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.91 X-Spam-Level: X-Spam-Status: No, score=-2.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 NmC_qZ1eAlZT for ; Fri, 3 Feb 2017 00:13:48 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0045.outbound.protection.outlook.com [104.47.1.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D65CC129BC9 for ; Fri, 3 Feb 2017 00:13:47 -0800 (PST) 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=ERrxP8DnuV2fxhR5XcSVYmV+vXK+f8zLxszLhEW0HME=; b=AmFMuHRGXMaNKDcIfN11q73ZIOH6KaNBZ07XRLC0BGnbdGp8QWwIrrmDs7NO5dfBkj1/I9+o+QGNOXdgXjxZqUH+XO9Fo4FztOZSc0lw5ecKvp9E3I15h4FrBGsHo2Wlm5E1VcPDM0jpg2k7z04KNbSiaMgLXov+5Lq1dVW1N3A= Received: from VI1PR0401MB2064.eurprd04.prod.outlook.com (10.166.141.138) by VI1PR0401MB2064.eurprd04.prod.outlook.com (10.166.141.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.874.12; Fri, 3 Feb 2017 08:13:43 +0000 Received: from VI1PR0401MB2064.eurprd04.prod.outlook.com ([10.166.141.138]) by VI1PR0401MB2064.eurprd04.prod.outlook.com ([10.166.141.138]) with mapi id 15.01.0874.021; Fri, 3 Feb 2017 08:13:43 +0000 From: Natasha Rooney To: Randall Gellens Thread-Topic: [Slim] draft-ietf-slim-negotiating-human-language-06.txt Thread-Index: AQHSfYEfPhYJjXlZ6UST03J11Fr1g6FW79uA Date: Fri, 3 Feb 2017 08:13:43 +0000 Message-ID: <8EC1A298-D7AB-4991-9406-96BD269021AC@gsma.com> References: <148599131437.18680.9777611954473801850.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3259) authentication-results: spf=none (sender IP is ) smtp.mailfrom=nrooney@gsma.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [51.6.68.10] x-ms-office365-filtering-correlation-id: 8aeda6cb-e956-43a0-f6e8-08d44c0c91f1 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:VI1PR0401MB2064; x-microsoft-exchange-diagnostics: 1; VI1PR0401MB2064; 7:KJtePWxBK9gTibL4CyeoS7LraQ1SsCpkyd46P2hY27ZyOqPUK3GBtTKXyNwWjrYSPPKzE06u76h+vMcrIktbpw6gXLP8n1sUTESRNJ6cm3nOELvYpt+IglQb2bYPa/4VvGoatAi5InM02/KGKJzPxuWTmCIaaPwcPYQzjSOAW7uxzeFsr0PNn9Lo+gLPdCEgCsBxijNVEKaztOrnSQYbGXJDAMdqkhA+IObAqCA9VdPQuqIEeSmq1FDExWgmPz6ke/fDhxEMf8SnJ8ZcxgTF12cJYXggoRl6Nts/+M8bs0A0u2uFmEHjzUDDYsKOZXGG/JQ+RY8Wh3oSXhcR9NrY/0A7f2x91izcdSbaN4Pt5GE9Y5fI/FtEvgFoZO3tDCuNlDRLGpUBXoUQouf8r4jZrK5ixkHMvCvbMYBElJ3dCNQvZiaSFoWBy6rI77fdXeB2Re3BCY/6YWQI76p0xcZycS0payaUzil79I2Q9O2i23kN1ur8p0sYJewrdLtD8igbwUXz7puLY4CIYQRq2mkxJA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(20161123558025)(6072148); SRVR:VI1PR0401MB2064; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0401MB2064; x-forefront-prvs: 02070414A1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(39450400003)(24454002)(189002)(199003)(66654002)(8676002)(54896002)(6506006)(81156014)(230783001)(3660700001)(38730400001)(81166006)(86362001)(6486002)(229853002)(39060400001)(33656002)(66066001)(77096006)(25786008)(97736004)(106356001)(2900100001)(3846002)(122556002)(68736007)(6436002)(6116002)(4326007)(105586002)(102836003)(2906002)(3280700002)(106116001)(110136003)(5660300001)(92566002)(50226002)(6246003)(8936002)(2950100002)(53936002)(189998001)(101416001)(7736002)(50986999)(82746002)(6512007)(6306002)(53546003)(76176999)(83716003)(236005)(99286003)(36756003)(57306001)(54906002)(5890100001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0401MB2064; H:VI1PR0401MB2064.eurprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: gsma.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_8EC1A298D7AB4991940696BD269021ACgsmacom_" MIME-Version: 1.0 X-OriginatorOrg: gsma.com X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Feb 2017 08:13:43.7017 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72a4ff82-fec3-469d-aafb-ac8276216699 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0401MB2064 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: VI1PR0401MB2064.eurprd04.prod.outlook.com X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-originalclientipaddress: 51.6.68.10 X-MS-Exchange-CrossPremises-avstamp-service: 1.0 X-MS-Exchange-CrossPremises-disclaimer-hash: 78ca8040c6722e32c2f5b0a45bf37e74b9409d645a53be96aa19958e0cee0f00 X-MS-Exchange-CrossPremises-antispam-scancontext: DIR:Originating; SFV:NSPM; SKIP:0; X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-OrganizationHeadersPreserved: VI1PR0401MB2064.eurprd04.prod.outlook.com Archived-At: Cc: "slim@ietf.org" , Bernard Aboba Subject: Re: [Slim] draft-ietf-slim-negotiating-human-language-06.txt X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 08:13:51 -0000 --_000_8EC1A298D7AB4991940696BD269021ACgsmacom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Many thanks Randall! Natasha Rooney | Internet Engineering Director | Internet and Web Team | Te= chnology | GSMA | nrooney@gsma.com | +44 (0) 7730 = 219 765 | @thisNatasha | Skype: nrooney@gsm.org On 2 Feb 2017, at 18:20, Randall Gellens > wrote: Version -06 of the human language negotiation draft is uploaded. It addres= ses all open issues. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Citizens for corrupt government, unclean water, higher taxes, unsafe streets, and poor schools. _______________________________________________ SLIM mailing list SLIM@ietf.org https://www.ietf.org/mailman/listinfo/slim This email and its attachments are intended for the above named only and ma= y be confidential. If they have come to you in error you must take no actio= n based on them, nor must you copy or show them to anyone; please reply to = this email or call +44 207 356 0600 and highlight the error. --_000_8EC1A298D7AB4991940696BD269021ACgsmacom_ Content-Type: text/html; charset="us-ascii" Content-ID: <279B96457996FD45BC19887D1FCB656A@eurprd04.prod.outlook.com> Content-Transfer-Encoding: quoted-printable Many thanks Randall!

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

On 2 Feb 2017, at 18:20, Randall Gellens <rg+ietf@randy.pensive.org= > wrote:

Version -06 of the human language negotiation draft is uplo= aded.  It addresses all open issues.

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

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

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

--_000_8EC1A298D7AB4991940696BD269021ACgsmacom_-- From nobody Fri Feb 3 09:27:00 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 4075212948B for ; Fri, 3 Feb 2017 09:26:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.888 X-Spam-Level: X-Spam-Status: No, score=-5.888 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=-3.199, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=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 tms-CMUXbZWO for ; Fri, 3 Feb 2017 09:26:56 -0800 (PST) Received: from resqmta-po-11v.sys.comcast.net (resqmta-po-11v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:170]) (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 98D3B129471 for ; Fri, 3 Feb 2017 09:26:56 -0800 (PST) Received: from resomta-po-16v.sys.comcast.net ([96.114.154.240]) by resqmta-po-11v.sys.comcast.net with SMTP id ZhcFcNRF15l5NZhdQcnI5v; Fri, 03 Feb 2017 17:26:56 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1486142816; bh=T9M/aJCMjrnWRf8S90bJyz/m23gI32x2Vo0D/gZ/UD0=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=eLuJJ/xt5K+0ns5mgVJg7MNk1oyadXfkuvIfb5W5psBwWvIIYYldQGbHDwdQ5pej9 z534SH5/tJh/cV4ByHGOaZbLMKRxUsw2Jtb26vEdm91sitf4/LjFtJPsyj/u+MuYQS +seG4lfEJ9CxegxxjSyPSrejh3l9BGjroRuB+AlQIM1URUqJjLewHyqIboXcNhtSUo 68ZonSS2hkO5h6ZJirRwud685Rj9MF2S8kSPyhDnzGDDNIz+GCIQDXSjm6CwkBHdLW uhSleMvezfTDyE26+tylgzI1Im2Ra0A4VI7AC82XQfEf8uXydger95NjhjmyxO2Nlr SSTTjz4yXI8aw== Received: from [192.168.1.110] ([73.186.127.100]) by resomta-po-16v.sys.comcast.net with SMTP id ZhdPcUkfWZHQdZhdPc7y2s; Fri, 03 Feb 2017 17:26:56 +0000 To: slim@ietf.org References: <148605947823.13893.99763238254146987.idtracker@ietfa.amsl.com> <8e229648-a96f-394b-1e3c-911d90ad5855@comcast.net> From: Paul Kyzivat Message-ID: <6763b6f3-379d-047a-627c-f347bd5096d9@comcast.net> Date: Fri, 3 Feb 2017 12:26:55 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfITqfsjkFRGbkOUDZz5x6eSpYKFocSjiX0Ci7NZ7JoOT1igWq/X40CLMW30WQURhfUIJ4lhRPbZrB4ToAbBEQItcihq+21HBemnxkYPKK32d6wSwVV35 LSBzUyCP3Frz8z9/nG4/5R8+6conRSVFmZK0whhpBRTU4oAmlUDl5u2C Archived-At: Subject: Re: [Slim] I-D Action: draft-ietf-slim-negotiating-human-language-06.txt X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 17:26:58 -0000 On 2/2/17 7:20 PM, Randall Gellens wrote: > At 1:59 PM -0500 2/2/17, Paul Kyzivat wrote: > >> There is a lot of repeated material in section 6. It looks like an >> editing error. > > Are you talking about the two tables, one per attribute? I think that's > a consequence of switching to the larger table template. Oh, duh. Sorry. IMO you only need to supply the common syntax once, and reference it in the other place. Also, you are missing a reference to the value syntax. I suggest: Contact Name: Randall Gellens Contact Email Address: rg+ietf@randy.pensive.org Attribute Name: humintlang-recv Attribute Value: humintlang-value Attribute Syntax: humintlang-value = Language-Tag [ asterisk ] ; Language-Tag defined in RFC 5646 asterisk = "*" Attribute Semantics: Described in Section 5.2 of TBD: THIS DOCUMENT Usage Level: media Charset Dependent: No Purpose: See Section 5.2 of TBD: THIS DOCUMENT O/A Procedures: See Section 5.2 of TBD: THIS DOCUMENT Reference: TBD: THIS DOCUMENT Contact Name: Randall Gellens Contact Email Address: rg+ietf@randy.pensive.org Attribute Name: humintlang-send Attribute Value: humintlang-value Attribute Syntax: see above Attribute Semantics: Described in Section 5.2 of TBD: THIS DOCUMENT Usage Level: media Charset Dependent: No Purpose: See Section 5.2 of TBD: THIS DOCUMENT O/A Procedures: See Section 5.2 of TBD: THIS DOCUMENT Reference: TBD: THIS DOCUMENT Thanks, Paul >> On 2/2/17 1:17 PM, internet-drafts@ietf.org wrote: >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the Selection of Language for Internet >>> Media of the IETF. >>> >>> Title : Negotiating Human Language in Real-Time >>> Communications >>> Author : Randall Gellens >>> Filename : draft-ietf-slim-negotiating-human-language-06.txt >>> Pages : 19 >>> Date : 2017-02-02 >>> >>> Abstract: >>> Users have various human (natural) language needs, abilities, and >>> preferences regarding spoken, written, and signed languages. When >>> establishing interactive communication ("calls") there needs to be a >>> way to negotiate (communicate and match) the caller's language and >>> media needs with the capabilities of the called party. This is >>> especially important with emergency calls, where a call can be >>> handled by a call taker capable of communicating with the user, or a >>> translator or relay operator can be bridged into the call during >>> setup, but this applies to non-emergency calls as well (as an >>> example, when calling a company call center). >>> >>> This document describes the need and a solution using new SDP stream >>> attributes. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-slim-negotiating-human-language/ >>> >>> >>> There's also a htmlized version available at: >>> https://tools.ietf.org/html/draft-ietf-slim-negotiating-human-language-06 >>> >>> >>> A diff from the previous version is available at: >>> >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-slim-negotiating-human-language-06 >>> >>> >>> >>> 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 >>> >> >> _______________________________________________ >> SLIM mailing list >> SLIM@ietf.org >> https://www.ietf.org/mailman/listinfo/slim > > From nobody Sun Feb 5 15:54: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 26BFD1293F0 for ; Sun, 5 Feb 2017 15:54:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=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 ts8IJCyxjHDJ for ; Sun, 5 Feb 2017 15:54:48 -0800 (PST) Received: from bin-vsp-out-03.atm.binero.net (bin-mail-out-05.binero.net [195.74.38.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88FF2126D73 for ; Sun, 5 Feb 2017 15:54:47 -0800 (PST) X-Halon-ID: 6f71e3b1-ebfe-11e6-9c99-0050569116f7 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [83.209.158.27]) by bin-vsp-out-03.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Mon, 6 Feb 2017 00:54:30 +0100 (CET) To: slim@ietf.org References: <148605947823.13893.99763238254146987.idtracker@ietfa.amsl.com> <8e229648-a96f-394b-1e3c-911d90ad5855@comcast.net> <6763b6f3-379d-047a-627c-f347bd5096d9@comcast.net> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <4602bafb-53ac-70d5-7e1c-da069c5ff38c@omnitor.se> Date: Mon, 6 Feb 2017 00:54:41 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <6763b6f3-379d-047a-627c-f347bd5096d9@comcast.net> Content-Type: multipart/alternative; boundary="------------87F07023182C2DBE335A4AD4" Archived-At: Subject: Re: [Slim] I-D Action: draft-ietf-slim-negotiating-human-language-06.txt X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2017 23:54:51 -0000 This is a multi-part message in MIME format. --------------87F07023182C2DBE335A4AD4 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Randall, It is good to see the issues acted on. 1. I see that issues #2, #3, #4, #13 are completely done. 2. For #15, the use of BCP 47 instead of RFC 5646, I saw that you had problems with xml2rfc if you tried to consistently use BCP 47, so therefore it is a mix now and I assume that that will be acceptable. 3. For #6 about the attribute registration form, I wonder if it is still accepted to not use the RFC 4566 bis format? And if it is accepted, what is the procedure for adding RFC 4566bis format registration afterwards? (The reason for my question is that we will very soon need the WEBRTC specific values specified.) 4. I wonder if the syntax for the asterisk in the values is sufficiently strictly specified. In the beginning of 5.2, the attributes are described with something looking as a syntax description: a=humintlang-send: a=humintlang-recv: Later it is said: Each value MUST be a language tag perBCP 47 [RFC5646 ]. Then it is said: "In an offer, each language tag value MAY have an asterisk appended as the last character (after the language tag)." In 6. we have: "Attribute Syntax: humintlang-value = Language-Tag [ asterisk ] ; Language-Tag defined inRFC 5646 asterisk = "*" " It seems to me that sometimes the wording indicates that the asterisk is included in the language tag and sometimes appended to the language tag. I think this can be made clearer if the asterisk is mentioned already in the first syntax indication, maybe something like this: a=humintlang-send:[call completion option] a=humintlang-recv:[call completion option] 5. A syntax question: Does the syntax description in chapter 6 require that the asterisk follows without whitespace after the language tag? 6. We discussed earlier if the unusual syntax of the asterisk really would be accepted when the attribute shall be reviewed and registered. It is really a kind of session parameter that can be hooked on many times on media level attributes. Was the way we use it assured to be acceptable by the coming registration review? Regards Gunnar ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 Den 2017-02-03 kl. 18:26, skrev Paul Kyzivat: > On 2/2/17 7:20 PM, Randall Gellens wrote: >> At 1:59 PM -0500 2/2/17, Paul Kyzivat wrote: >> >>> There is a lot of repeated material in section 6. It looks like an >>> editing error. >> >> Are you talking about the two tables, one per attribute? I think that's >> a consequence of switching to the larger table template. > > Oh, duh. Sorry. > > IMO you only need to supply the common syntax once, and reference it > in the other place. Also, you are missing a reference to the value > syntax. I suggest: > > Contact Name: Randall Gellens > Contact Email Address: rg+ietf@randy.pensive.org > Attribute Name: humintlang-recv > Attribute Value: humintlang-value > Attribute Syntax: > > humintlang-value = Language-Tag [ asterisk ] > ; Language-Tag defined in RFC 5646 > asterisk = "*" > > Attribute Semantics: Described in Section 5.2 of TBD: THIS DOCUMENT > Usage Level: media > Charset Dependent: No > Purpose: See Section 5.2 of TBD: THIS DOCUMENT > O/A Procedures: See Section 5.2 of TBD: THIS DOCUMENT > Reference: TBD: THIS DOCUMENT > > Contact Name: Randall Gellens > Contact Email Address: rg+ietf@randy.pensive.org > Attribute Name: humintlang-send > Attribute Value: humintlang-value > Attribute Syntax: see above > Attribute Semantics: Described in Section 5.2 of TBD: THIS DOCUMENT > Usage Level: media > Charset Dependent: No > Purpose: See Section 5.2 of TBD: THIS DOCUMENT > O/A Procedures: See Section 5.2 of TBD: THIS DOCUMENT > Reference: TBD: THIS DOCUMENT > > > Thanks, > Paul > > >>> On 2/2/17 1:17 PM, internet-drafts@ietf.org wrote: >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. >>>> This draft is a work item of the Selection of Language for Internet >>>> Media of the IETF. >>>> >>>> Title : Negotiating Human Language in Real-Time >>>> Communications >>>> Author : Randall Gellens >>>> Filename : >>>> draft-ietf-slim-negotiating-human-language-06.txt >>>> Pages : 19 >>>> Date : 2017-02-02 >>>> >>>> Abstract: >>>> Users have various human (natural) language needs, abilities, and >>>> preferences regarding spoken, written, and signed languages. When >>>> establishing interactive communication ("calls") there needs to >>>> be a >>>> way to negotiate (communicate and match) the caller's language and >>>> media needs with the capabilities of the called party. This is >>>> especially important with emergency calls, where a call can be >>>> handled by a call taker capable of communicating with the user, >>>> or a >>>> translator or relay operator can be bridged into the call during >>>> setup, but this applies to non-emergency calls as well (as an >>>> example, when calling a company call center). >>>> >>>> This document describes the need and a solution using new SDP >>>> stream >>>> attributes. >>>> >>>> >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-slim-negotiating-human-language/ >>>> >>>> >>>> >>>> There's also a htmlized version available at: >>>> https://tools.ietf.org/html/draft-ietf-slim-negotiating-human-language-06 >>>> >>>> >>>> >>>> A diff from the previous version is available at: >>>> >>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-slim-negotiating-human-language-06 >>>> >>>> >>>> >>>> >>>> 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 >>>> >>> >>> _______________________________________________ >>> 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 --------------87F07023182C2DBE335A4AD4 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Randall,

It is good to see the issues acted on.

1. I see that issues #2, #3, #4, #13 are completely done.

2. For #15, the use of BCP 47 instead of RFC 5646, I saw that you had problems with xml2rfc if you tried to consistently use BCP 47, so therefore it is a mix now and I assume that that will be acceptable.

3. For #6 about the attribute registration form, I wonder if it is still accepted to not use the RFC 4566 bis format?
And if it is accepted, what is the procedure for adding RFC 4566bis format registration afterwards?
(The reason for my question is that we will very soon need the WEBRTC specific values specified.)


4. I wonder if the syntax for the asterisk in the values is sufficiently strictly specified.

In the beginning of 5.2, the attributes are described with something looking as a syntax description:

      a=humintlang-send:<language tag>
      a=humintlang-recv:<language tag>

Later it is said: 

 Each value MUST be a language tag per BCP 47 [RFC5646].

Then it is said: 
"In an offer, each language tag value MAY have an asterisk appended as
   the last character (after the language tag)."


In 6. we have:
"Attribute Syntax:

      humintlang-value =  Language-Tag [ asterisk ]
                          ; Language-Tag defined in RFC 5646
      asterisk         =  "*" 
"

It seems to me that sometimes the wording indicates that the 
asterisk is included in the language tag and sometimes appended to the language tag.
I think this can be made clearer if the asterisk is mentioned already in the first 
syntax indication, maybe something like this:

      a=humintlang-send:<language tag>[call completion option]
      a=humintlang-recv:<language tag>[call completion option]

5. A syntax question: Does the syntax description in chapter 6 
require that the asterisk follows without whitespace after the language tag?

6. We discussed earlier if the unusual syntax of the asterisk really would be
accepted when the attribute shall be reviewed and registered. It is really 
a kind of session parameter that can be hooked on many times on media level attributes.
Was the way we use it assured to be acceptable by the coming registration review?

Regards

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


 

 




Den 2017-02-03 kl. 18:26, skrev Paul Kyzivat:
On 2/2/17 7:20 PM, Randall Gellens wrote:
At 1:59 PM -0500 2/2/17, Paul Kyzivat wrote:

 There is a lot of repeated material in section 6. It looks like an
editing error.

Are you talking about the two tables, one per attribute?  I think that's
a consequence of switching to the larger table template.

Oh, duh. Sorry.

IMO you only need to supply the common syntax once, and reference it in the other place. Also, you are missing a reference to the value syntax. I suggest:

   Contact Name:  Randall Gellens
   Contact Email Address:  rg+ietf@randy.pensive.org
   Attribute Name:  humintlang-recv
   Attribute Value: humintlang-value
   Attribute Syntax:

      humintlang-value =  Language-Tag [ asterisk ]
                          ; Language-Tag defined in RFC 5646
      asterisk         =  "*"

   Attribute Semantics:  Described in Section 5.2 of TBD: THIS DOCUMENT
   Usage Level:  media
   Charset Dependent:  No
   Purpose:  See Section 5.2 of TBD: THIS DOCUMENT
   O/A Procedures:  See Section 5.2 of TBD: THIS DOCUMENT
   Reference:  TBD: THIS DOCUMENT

   Contact Name:  Randall Gellens
   Contact Email Address:  rg+ietf@randy.pensive.org
   Attribute Name:  humintlang-send
   Attribute Value: humintlang-value
   Attribute Syntax: see above
   Attribute Semantics:  Described in Section 5.2 of TBD: THIS DOCUMENT
   Usage Level:  media
   Charset Dependent:  No
   Purpose:  See Section 5.2 of TBD: THIS DOCUMENT
   O/A Procedures:  See Section 5.2 of TBD: THIS DOCUMENT
   Reference:  TBD: THIS DOCUMENT


    Thanks,
    Paul


 On 2/2/17 1:17 PM, internet-drafts@ietf.org wrote:

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

         Title           : Negotiating Human Language in Real-Time
Communications
         Author          : Randall Gellens
     Filename        : draft-ietf-slim-negotiating-human-language-06.txt
     Pages           : 19
     Date            : 2017-02-02

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

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


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


 There's also a htmlized version available at:
 https://tools.ietf.org/html/draft-ietf-slim-negotiating-human-language-06


 A diff from the previous version is available at:

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



 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


 _______________________________________________
 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
--------------87F07023182C2DBE335A4AD4-- From nobody Sun Feb 5 17:00:33 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1813129A62 for ; Sun, 5 Feb 2017 17:00:31 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -1.891 X-Spam-Level: X-Spam-Status: No, score=-1.891 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_FILL_THIS_FORM_SHORT=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 RAdjObtHiuRz for ; Sun, 5 Feb 2017 17:00:30 -0800 (PST) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 36FBD1294C9 for ; Sun, 5 Feb 2017 17:00:30 -0800 (PST) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Sun, 5 Feb 2017 16:54:07 -0800 Mime-Version: 1.0 Message-Id: In-Reply-To: <4602bafb-53ac-70d5-7e1c-da069c5ff38c@omnitor.se> References: <148605947823.13893.99763238254146987.idtracker@ietfa.amsl.com> <8e229648-a96f-394b-1e3c-911d90ad5855@comcast.net> <6763b6f3-379d-047a-627c-f347bd5096d9@comcast.net> <4602bafb-53ac-70d5-7e1c-da069c5ff38c@omnitor.se> X-Mailer: Eudora for Mac OS X Date: Sun, 5 Feb 2017 16:55:15 -0800 To: Gunnar =?iso-8859-1?Q?Hellstr=F6m?= , slim@ietf.org From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 Archived-At: Subject: Re: [Slim] I-D Action: draft-ietf-slim-negotiating-human-language-06.txt X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 01:00:32 -0000 At 12:54 AM +0100 2/6/17, Gunnar Hellstr=F6m wrote: > Randall, > > It is good to see the issues acted on. > > 1. I see that issues #2, #3, #4, #13 are completely done. > > 2. For #15, the use of BCP 47 instead of RFC=20 > 5646, I saw that you had problems with xml2rfc=20 > if you tried to consistently use BCP 47, so=20 > therefore it is a mix now and I assume that=20 > that will be acceptable. > > 3. For #6 about the attribute registration=20 > form, I wonder if it is still accepted to not=20 > use the RFC 4566 bis format? > And if it is accepted, what is the procedure=20 > for adding RFC 4566bis format registration=20 > afterwards? > (The reason for my question is that we will=20 > very soon need the WEBRTC specific values=20 > specified.) 4566-bis is an expired draft, not an RFC, so it=20 is not normative. However, I have adopted a=20 format that is virtually identical to it, only=20 omitting one completely redundant field. I think=20 for the post-LC revision of the draft, I might=20 rearrange it to put the attribute name first=20 rather than the contact name, to avoid confusion. > > > 4. I wonder if the syntax for the asterisk in=20 > the values is sufficiently strictly specified. > > In the beginning of 5.2, the attributes are=20 > described with something looking as a syntax=20 > description: > > a=3Dhumintlang-send: > a=3Dhumintlang-recv: > > Later it is said: > > Each value MUST be a language tag per=20 > BCP 47=20 > [RFC5646]. > > Then it is said: > "In an offer, each language tag value MAY have an asterisk appended as > the last character (after the language tag)." > > > In 6. we have: > "Attribute Syntax: > > humintlang-value =3D Language-Tag [ asterisk ] > ; Language-Tag=20 > defined in=20 > RFC 5646 > asterisk =3D "*" > " > > It seems to me that sometimes the wording indicates that the > asterisk is included in the language tag and=20 > sometimes appended to the language tag. > I think this can be made clearer if the=20 > asterisk is mentioned already in the first > syntax indication, maybe something like this: > > a=3Dhumintlang-send:[call completion option] > a=3Dhumintlang-recv:[call completion option] The syntax is specified in ABNF. It indicates=20 that a language tag is required and an asterisk=20 may optionally be appended. I believe this is=20 consistent with the text. > > 5. A syntax question: Does the syntax description in chapter 6 > require that the asterisk follows without whitespace after the language t= ag? The ABNF rules in RFC 5234 do not include=20 implicit white space, so the asterisk must=20 immediately follow the language tag. > > 6. We discussed earlier if the unusual syntax of the asterisk really= would be > accepted when the attribute shall be reviewed and registered. It is reall= y > a kind of session parameter that can be hooked=20 > on many times on media level attributes. > Was the way we use it assured to be acceptable=20 > by the coming registration review? I am not aware of any objections. --Randall > > Regards > > Gunnar > > ----------------------------------------- > Gunnar Hellstr=F6m > Omnitor > gunnar.hellstrom@omnitor.se > +46 708 204 288 > > > > > > > > > > Den 2017-02-03 kl. 18:26, skrev Paul Kyzivat: > >> On 2/2/17 7:20 PM, Randall Gellens wrote: >> >>> At 1:59 PM -0500 2/2/17, Paul Kyzivat wrote: >>> >>>> There is a lot of repeated material in section 6. It looks like an >>>> editing error. >>>> >>> >>> Are you talking about the two tables, one per attribute? I think that's >>> a consequence of switching to the larger table template. >>> >> >> Oh, duh. Sorry. >> >> IMO you only need to supply the common syntax=20 >> once, and reference it in the other place.=20 >> Also, you are missing a reference to the value=20 >> syntax. I suggest: >> >> Contact Name: Randall Gellens >> Contact Email Address:=20 >> rg+ietf@randy.pensive.org >> Attribute Name: humintlang-recv >> Attribute Value: humintlang-value >> Attribute Syntax: >> >> humintlang-value =3D Language-Tag [ asterisk ] >> ; Language-Tag defined in RFC 5646 >> asterisk =3D "*" >> >> Attribute Semantics: Described in Section 5.2 of TBD: THIS DOCUMENT >> Usage Level: media >> Charset Dependent: No >> Purpose: See Section 5.2 of TBD: THIS DOCUMENT >> O/A Procedures: See Section 5.2 of TBD: THIS DOCUMENT >> Reference: TBD: THIS DOCUMENT >> >> Contact Name: Randall Gellens >> Contact Email Address:=20 >> rg+ietf@randy.pensive.org >> Attribute Name: humintlang-send >> Attribute Value: humintlang-value >> Attribute Syntax: see above >> Attribute Semantics: Described in Section 5.2 of TBD: THIS DOCUMENT >> Usage Level: media >> Charset Dependent: No >> Purpose: See Section 5.2 of TBD: THIS DOCUMENT >> O/A Procedures: See Section 5.2 of TBD: THIS DOCUMENT >> Reference: TBD: THIS DOCUMENT >> >> >> Thanks, >> Paul >> >>>> On 2/2/17 1:17 PM,=20 >>>> internet-drafts@ietf.org=20 >>>> wrote: >>>> >>>>> >>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>> directories. >>>>> This draft is a work item of the Selection of Language for Internet >>>>> Media of the IETF. >>>>> >>>>> Title : Negotiating Human Language in Real-Time >>>>> Communications >>>>> Author : Randall Gellens >>>>> Filename : draft-ietf-slim-negotiating-human-language-06.txt >>>>> Pages : 19 >>>>> Date : 2017-02-02 >>>>> >>>>> Abstract: >>>>> Users have various human (natural) language needs, abilities, and >>>>> preferences regarding spoken, written, and signed languages. When >>>>> establishing interactive communication ("calls") there needs to be a >>>>> way to negotiate (communicate and match) the caller's language and >>>>> media needs with the capabilities of the called party. This is >>>>> especially important with emergency calls, where a call can be >>>>> handled by a call taker capable of communicating with the user, or a >>>>> translator or relay operator can be bridged into the call during >>>>> setup, but this applies to non-emergency calls as well (as an >>>>> example, when calling a company call center). >>>>> >>>>> This document describes the need and a solution using new SDP stream >>>>> attributes. >>>>> >>>>> >>>>> The IETF datatracker status page for this draft is: >>>>>=20 >>>>> https://datatracker.ietf.org/doc/draft-ietf-slim-negotiating-human-l= anguage/ >>>>> >>>>> >>>>> There's also a htmlized version available at: >>>>>=20 >>>>> https://tools.ietf.org/html/draft-ietf-slim-negotiating-human-language-= 06 >>>>> >>>>> >>>>> A diff from the previous version is available at: >>>>> >>>>>=20 >>>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-slim-negotiating= -human-language-06 >>>>> >>>>> >>>>> >>>>> 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-draf= ts/ >>>>> >>>>> _______________________________________________ >>>>> SLIM mailing list >>>>> SLIM@ietf.org >>>>>=20 >>>>> https://www.ietf.org/mailm= an/listinfo/slim >>>>> >>>> >>>> _______________________________________________ >>>> SLIM mailing list >>>> SLIM@ietf.org >>>>=20 >>>> https://www.ietf.org/mailma= n/listinfo/slim >>>> >>> >>> >> >> _______________________________________________ >> SLIM mailing list >> SLIM@ietf.org >>=20 >> https://www.ietf.org/mailman/= listinfo/slim >> > > -- > ----------------------------------------- > Gunnar Hellstr=F6m > Omnitor > gunnar.hellstrom@omnitor.se > +46 708 204 288 > > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- One forgets words as one forgets names. One's vocabulary needs constant fertilization or it will die. --Evelyn Waugh From nobody Mon Feb 6 00:11: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 4B9F312949B for ; Mon, 6 Feb 2017 00:11:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=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 cMJJEjud1K1J for ; Mon, 6 Feb 2017 00:11:19 -0800 (PST) Received: from bin-vsp-out-04.atm.binero.net (bin-mail-out-05.binero.net [195.74.38.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A057126579 for ; Mon, 6 Feb 2017 00:11:18 -0800 (PST) X-Halon-ID: d3bc3bfc-ec43-11e6-93b2-005056917c0c Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [83.209.158.27]) by bin-vsp-out-04.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Mon, 6 Feb 2017 09:11:13 +0100 (CET) To: Randall Gellens , slim@ietf.org References: <148605947823.13893.99763238254146987.idtracker@ietfa.amsl.com> <8e229648-a96f-394b-1e3c-911d90ad5855@comcast.net> <6763b6f3-379d-047a-627c-f347bd5096d9@comcast.net> <4602bafb-53ac-70d5-7e1c-da069c5ff38c@omnitor.se> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <3f42636f-c171-731e-ad26-5325ce1f9444@omnitor.se> Date: Mon, 6 Feb 2017 09:11:12 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Slim] I-D Action: draft-ietf-slim-negotiating-human-language-06.txt X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 08:11:22 -0000 Den 2017-02-06 kl. 01:55, skrev Randall Gellens: > At 12:54 AM +0100 2/6/17, Gunnar Hellström wrote: > >> Randall, >> >> It is good to see the issues acted on. >> >> 1. I see that issues #2, #3, #4, #13 are completely done. >> >> 2. For #15, the use of BCP 47 instead of RFC 5646, I saw that you >> had problems with xml2rfc if you tried to consistently use BCP 47, so >> therefore it is a mix now and I assume that that will be acceptable. >> >> 3. For #6 about the attribute registration form, I wonder if it is >> still accepted to not use the RFC 4566 bis format? >> And if it is accepted, what is the procedure for adding RFC 4566bis >> format registration afterwards? >> (The reason for my question is that we will very soon need the >> WEBRTC specific values specified.) > > 4566-bis is an expired draft, not an RFC, so it is not normative. > However, I have adopted a format that is virtually identical to it, > only omitting one completely redundant field. I think for the post-LC > revision of the draft, I might rearrange it to put the attribute name > first rather than the contact name, to avoid confusion. 4566bis-18 was published last Saturday. The form contains for "Usage level", the dcsa(subprotocol) value that will be used for real-time text. It also contains a Mux category that should have a regular value. I agree that these are from drafts and I think we need guidance from IANA if it is appropriate to include them. > >> >> >> 4. I wonder if the syntax for the asterisk in the values is >> sufficiently strictly specified. >> >> In the beginning of 5.2, the attributes are described with something >> looking as a syntax description: >> >> a=humintlang-send: >> a=humintlang-recv: >> >> Later it is said: >> >> Each value MUST be a language tag per >> BCP 47 >> [RFC5646]. >> >> Then it is said: >> "In an offer, each language tag value MAY have an asterisk appended as >> the last character (after the language tag)." >> >> >> In 6. we have: >> "Attribute Syntax: >> >> humintlang-value = Language-Tag [ asterisk ] >> ; Language-Tag defined in >> RFC 5646 >> asterisk = "*" >> " >> >> It seems to me that sometimes the wording indicates that the >> asterisk is included in the language tag and sometimes appended to >> the language tag. >> I think this can be made clearer if the asterisk is mentioned >> already in the first >> syntax indication, maybe something like this: >> >> a=humintlang-send:[call completion option] >> a=humintlang-recv:[call completion option] > > The syntax is specified in ABNF. It indicates that a language tag is > required and an asterisk may optionally be appended. I believe this > is consistent with the text. But the first appearance early in 5.2 also looks as a syntax description in ABNF, and it does not include the asterisk. And the language goes back and forth between saying that the asterisk is included in the language tag ( which is not true) and saying that it is appended ( that is not shown in the first syntax description ). Readers can possibly figure out now when we have the examples, but the description is not exactly clean. > >> >> 5. A syntax question: Does the syntax description in chapter 6 >> require that the asterisk follows without whitespace after the >> language tag? > > The ABNF rules in RFC 5234 do not include implicit white space, so the > asterisk must immediately follow the language tag. > >> >> 6. We discussed earlier if the unusual syntax of the asterisk really >> would be >> accepted when the attribute shall be reviewed and registered. It is >> really >> a kind of session parameter that can be hooked on many times on >> media level attributes. >> Was the way we use it assured to be acceptable by the coming >> registration review? > > I am not aware of any objections. Paul indicated on 2016-07-28 that once the main issues were sorted out, a better analysis can be done to see if it can be registered by IANA, and took some examples of what can be seen as unclear or not appropriate with the current use of the asterisk. I think we have reached that stage now. Having the asterisk placed on the media level should have some meaning but it currently has only session level influence. I can provide proposals for media level influence so that it possibly can stay as a media level value. Gunnar > > --Randall > >> >> Regards >> >> Gunnar >> >> ----------------------------------------- >> Gunnar Hellström >> Omnitor >> gunnar.hellstrom@omnitor.se >> +46 708 204 288 >> >> >> >> >> >> >> >> >> >> Den 2017-02-03 kl. 18:26, skrev Paul Kyzivat: >> >>> On 2/2/17 7:20 PM, Randall Gellens wrote: >>> >>>> At 1:59 PM -0500 2/2/17, Paul Kyzivat wrote: >>>> >>>>> There is a lot of repeated material in section 6. It looks like an >>>>> editing error. >>>>> >>>> >>>> Are you talking about the two tables, one per attribute? I think >>>> that's >>>> a consequence of switching to the larger table template. >>>> >>> >>> Oh, duh. Sorry. >>> >>> IMO you only need to supply the common syntax once, and reference >>> it in the other place. Also, you are missing a reference to the >>> value syntax. I suggest: >>> >>> Contact Name: Randall Gellens >>> Contact Email Address: >>> rg+ietf@randy.pensive.org >>> Attribute Name: humintlang-recv >>> Attribute Value: humintlang-value >>> Attribute Syntax: >>> >>> humintlang-value = Language-Tag [ asterisk ] >>> ; Language-Tag defined in RFC 5646 >>> asterisk = "*" >>> >>> Attribute Semantics: Described in Section 5.2 of TBD: THIS DOCUMENT >>> Usage Level: media >>> Charset Dependent: No >>> Purpose: See Section 5.2 of TBD: THIS DOCUMENT >>> O/A Procedures: See Section 5.2 of TBD: THIS DOCUMENT >>> Reference: TBD: THIS DOCUMENT >>> >>> Contact Name: Randall Gellens >>> Contact Email Address: >>> rg+ietf@randy.pensive.org >>> Attribute Name: humintlang-send >>> Attribute Value: humintlang-value >>> Attribute Syntax: see above >>> Attribute Semantics: Described in Section 5.2 of TBD: THIS DOCUMENT >>> Usage Level: media >>> Charset Dependent: No >>> Purpose: See Section 5.2 of TBD: THIS DOCUMENT >>> O/A Procedures: See Section 5.2 of TBD: THIS DOCUMENT >>> Reference: TBD: THIS DOCUMENT >>> >>> >>> Thanks, >>> Paul >>> >>>>> On 2/2/17 1:17 PM, >>>>> internet-drafts@ietf.org wrote: >>>>> >>>>>> >>>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>>> directories. >>>>>> This draft is a work item of the Selection of Language for Internet >>>>>> Media of the IETF. >>>>>> >>>>>> Title : Negotiating Human Language in Real-Time >>>>>> Communications >>>>>> Author : Randall Gellens >>>>>> Filename : draft-ietf-slim-negotiating-human-language-06.txt >>>>>> Pages : 19 >>>>>> Date : 2017-02-02 >>>>>> >>>>>> Abstract: >>>>>> Users have various human (natural) language needs, abilities, and >>>>>> preferences regarding spoken, written, and signed languages. When >>>>>> establishing interactive communication ("calls") there needs to >>>>>> be a >>>>>> way to negotiate (communicate and match) the caller's language and >>>>>> media needs with the capabilities of the called party. This is >>>>>> especially important with emergency calls, where a call can be >>>>>> handled by a call taker capable of communicating with the user, >>>>>> or a >>>>>> translator or relay operator can be bridged into the call during >>>>>> setup, but this applies to non-emergency calls as well (as an >>>>>> example, when calling a company call center). >>>>>> >>>>>> This document describes the need and a solution using new SDP >>>>>> stream >>>>>> attributes. >>>>>> >>>>>> >>>>>> The IETF datatracker status page for this draft is: >>>>>> >>>>>> https://datatracker.ietf.org/doc/draft-ietf-slim-negotiating-human-language/ >>>>>> >>>>>> >>>>>> >>>>>> There's also a htmlized version available at: >>>>>> >>>>>> https://tools.ietf.org/html/draft-ietf-slim-negotiating-human-language-06 >>>>>> >>>>>> >>>>>> >>>>>> A diff from the previous version is available at: >>>>>> >>>>>> >>>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-slim-negotiating-human-language-06 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> 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 >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> SLIM mailing list >>>>> SLIM@ietf.org >>>>> >>>>> https://www.ietf.org/mailman/listinfo/slim >>>>> >>>>> >>>> >>>> >>> >>> _______________________________________________ >>> SLIM mailing list >>> SLIM@ietf.org >>> >>> https://www.ietf.org/mailman/listinfo/slim >>> >>> >> >> -- >> ----------------------------------------- >> Gunnar Hellström >> Omnitor >> gunnar.hellstrom@omnitor.se >> +46 708 204 288 >> >> _______________________________________________ >> SLIM mailing list >> SLIM@ietf.org >> https://www.ietf.org/mailman/listinfo/slim > > -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 From nobody Mon Feb 6 07:28:00 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 34C6D129E79; Mon, 6 Feb 2017 07:27:52 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.42.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <148639487217.18865.13611191877947090796.idtracker@ietfa.amsl.com> Date: Mon, 06 Feb 2017 07:27:52 -0800 Archived-At: Cc: slim@ietf.org, alexey.melnikov@isode.com, draft-ietf-slim-negotiating-human-language@ietf.org, slim-chairs@ietf.org, bernard.aboba@gmail.com Subject: [Slim] Last Call: (Negotiating Human Language in Real-Time Communications) to Proposed Standard X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 15:27:52 -0000 The IESG has received a request from the Selection of Language for Internet Media WG (slim) to consider the following document: - 'Negotiating Human Language in Real-Time Communications' 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-02-20. 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 Users have various human (natural) language needs, abilities, and preferences regarding spoken, written, and signed languages. When establishing interactive communication ("calls") there needs to be a way to negotiate (communicate and match) the caller's language and media needs with the capabilities of the called party. This is especially important with emergency calls, where a call can be handled by a call taker capable of communicating with the user, or a translator or relay operator can be bridged into the call during setup, but this applies to non-emergency calls as well (as an example, when calling a company call center). This document describes the need and a solution using new SDP stream attributes. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-slim-negotiating-human-language/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-slim-negotiating-human-language/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-saintandre-sip-xmpp-chat: Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): One-to-One Text Chat (None - ) Note that some of these references may already be listed in the acceptable Downref Registry. From nobody Mon Feb 13 02:35: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 047701293DF for ; Mon, 13 Feb 2017 02:35:08 -0800 (PST) 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=unavailable 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 Eqg9BP-yCfCM for ; Mon, 13 Feb 2017 02:35:04 -0800 (PST) Received: from bin-vsp-out-01.atm.binero.net (bin-mail-out-06.binero.net [195.74.38.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2894A1295CB for ; Mon, 13 Feb 2017 02:34:59 -0800 (PST) X-Halon-ID: 09cc9353-f1d8-11e6-a131-005056917a89 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [83.209.158.27]) by bin-vsp-out-01.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Mon, 13 Feb 2017 11:34:45 +0100 (CET) From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= References: <148639487217.18865.13611191877947090796.idtracker@ietfa.amsl.com> To: "slim@ietf.org" , ietf@ietf.org Message-ID: <21d6ddb3-ebbd-833e-f5ff-800bdf144d2d@omnitor.se> Date: Mon, 13 Feb 2017 11:34:53 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <148639487217.18865.13611191877947090796.idtracker@ietfa.amsl.com> Content-Type: multipart/mixed; boundary="------------14511186B3059DA30155E67B" Archived-At: Subject: Re: [Slim] Last Call: (Negotiating Human Language in Real-Time Communications) to Proposed Standard X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 10:35:08 -0000 This is a multi-part message in MIME format. --------------14511186B3059DA30155E67B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I have reviewed draft-ietf-slim-negotiating-human-language-06.txt and have composed a proposed edited version adjusted for my comments below, and additionally for some minor editorial issues. The attached version is a rough edit of the txt file version. Accepted edits need to be re-done in the XML version. Please use a diff to find all edit proposals. The main ones are listed below with reference to sections in the files. ------------------------------------------------------------------------------------------------- 1. Inexact wording about the syntax of the new attributes. Sections 5 and 5.2, . The text sometimes indicate that the value of the attributes is a language tag, and sometimes a language tag with an optionally appended asterisk. The syntax shown in section 5.2 is also not in alignment with the syntax shown in section 6. In 5.2 it is shown without the optional asterisk, and in 6 with the optional asterisk. Proposed action: Make the attribute syntax equal in sections 5.2 and 6. Make sure that when "Language-Tag" is mentioned, it is only about the language tag part of the attribute value, and when the attribute value is mentioned, it is about the complete value, including the optional modifier. Changes: Last line in 5. Change "be" to "contain" Add [ asterisk ] last in both syntax lines in 5.2. Multiple small changes in section 5.2. to adjust wording to be more exact. - See attached draft. -------------------------------------------------------------------------------------------------------------------------------- 2. Reminiscense of earlier syntax. In a couple of places, there is wording left over from a recently abandoned syntax for the attributes. In an earlier version, each attribute value could contain multiple language-tags. Now, there is just one language-tag in each attribute value. Changes: At end of page 6: Old: "The values constitute a list of languages in preference order" New: "The values from multiple attributes constitute a list of languages in preference order per direction" At end of Section 5.3, the comparison with Accept-Language syntax is not valid anymore. Delete: "(similar to SIP Accept-Language syntax)" ---------------------------------------------------------------------------------------------------------------------------------- 3. Inexact wording about O/A procedure in section 5.2 The answers are called "accepted language", but within paranthesis it is mentioned that it is only in most cases that it is selected from the offer. More suitable is then to just call it just "language": Old: " In an answer, 'humintlang-send' is the accepted language the answerer will send (which in most cases is one of the languages in the offer's 'humintlang-recv'), and 'humintlang-recv' is the accepted language the answerer expects to receive (which in most cases is one of the languages in the offer's 'humintlang-send')." New: "In an answer, 'humintlang-send' indicates the language the answerer will send (which in most cases is one of the languages in the offer's 'humintlang-recv'), and 'humintlang-recv' indicates the language the answerer expects to receive (which in most cases is one of the languages in the offer's 'humintlang-send')." ----------------------------------------------------------------------------------------------- 4. Inexact note at end of section 5.2. The note at end of 5.2 has a short discussion about accepted media as if it should possibly be influenced by the matching languages. This discussion is not really valid. A media section is a request to set up a media stream, unrelated to the language indications. The devices should deny media because they are not needed for language communication. This is made more clear in an extended note. Old: "Note that media and language negotiation might result in more media streams being accepted than are needed by the users (e.g., if more preferred and less preferred combinations of media and language are all accepted)." New: "Note that media and language negotiation might result in more media streams being accepted than are needed by the users for language exchange (e.g., if more preferred and less preferred combinations of media and language are all accepted). This is normal and accepted, because the humintlang attribute is not intended to restrict media streams to be used only for language exchange." --------------------------------------------------------------------------------- 5. Make use of the asterisk modifier on media level with session scope also for media level purposes The asterisk modifier optionally appended on attribute values has in the original -06 draft only a session effect. It is specified to indicate if the call should be rejected or not if languages do not match. It can be appended to any humintlang attribute in the whole SDP without any change in effect. This independancy of placement indicates that it is wrongly placed. With the current definition, it should be a single separate session level attribute. Instead of specifying a separate session level attribute, it is proposed that the asterisk gets an expanded definition, so that its placement conveys meaning of value for the successful language negotiation. It has been discussed in the SLIM WG that the specification lacks two functions, required by the specifications by other bodies who are waiting for the results of SLIM real-time work. (e.g. 3GPP TS 22.228 and ETSI TR 103 201). 3GPP TS 22.228 requires "The system should be able to negotiate the user's desired language(s) and modalities, per media stream and/or session, in order of preference." Thus negotiation with preference indication within the session is required, not only within each media. ETSI TR 103 201 says "the Total Conversation user should be able to indicate the preferred method of communication for each direction of the session, so that the call-taker can be selected appropriately or an appropriate assisting service be invoked. " Saying "preferred" means that it should also be possible to indicate less preferred alternatives. The most urgent of these functions can be fulfilled in a simple but sufficient way by extending the meaning of the asterisk. That is the possibility to indicate a difference in preference between languages in different modalities. There is an apparent risk that many calls will start and continue in an inconvenient modaity if this differentiation is not introduced. See the proposed replaced section 5.3 and extended examples in section 5.5. Earlier discussions on this topic has not resulted in a sufficiently simple mechanism. The extended use of the asterisk proposed here is intended to introduce the required simplification, and yet meet the most urgent needs. Changes: In 5.2 Old: "In an offer, each language tag value MAY have an asterisk appended as the last character (after the language tag). The asterisk indicates a request by the caller to not fail the call if there is no language in common." New: "In an offer or answer, each attribute value MAY have a modifier appended as the last character (after the Language-Tag). This specification defines one value for the modifier; an asterisk ("*"). The asterisk included in a humintlang attribute value in the SDP indicates a lower preference for the indicated language and a request by the caller to not reject the call if there is no language in common." In 5.3. The whole section replaced by: " 5.3. Preferences within the session It is of high importance for a smooth start of a call that the answering party is answering the call using the best matching language(s) and modality(ies) suitable for the continuation of the call. Switching language and modality during the call by agreement between the participants is often time consuming. Without support of detailed language and modality negotiation the particiants may have a tendency to continue the call in the initial language and modality even if a more convenient common language and modality combination is available. In order to support the decision on which of the available language(s) and modality(ies) to use initially in the call, a simple two-level preference indicator is specified here for inclusion as a modifier in the humintlang attribute values. The preference indicator is also used as an indicator that the call SHOULD be established even if no language match is found. The asterisk ("*") is used as a preference indicator within the session. Low relative preference for a language and modality to be used in the session SHOULD be indicated by appending an asterisk after the language tag in the attribute value. This indication from the offering party SHOULD be interpreted by the answering party as a request to use a higher preferred language and modality when answering the call if available, but otherwise accept a lower preferred language and modality combination if that is available. When satisfying languages and modalities in the offer is regarded to be so important that the whole call SHOULD be rejected if no match can be provided in the session in one or both directions, then the asterisk shall not be appended on any indicated language in the whole session description. For the case when no specific preference is desired, but the offering party does not want the call to be rejected, all indicated languages and modalities SHOULD have an asterisk appended. In an answer, the language(s) and modality(ies) that the answering party will use initially in the answer SHOULD be indicated without an appended asterisk. Any language and modality available for later use in the session MAY be indicated by a language tag with an appended asterisk. In the case when more than two parties participate in the call, the language and modality indications provided to each party SHOULD be the sum of the indications from the other parties. The use of the preference indicator as specified above does not provide for distinguishing between the case when two or more language/modality combinations in the same direction are desired for use simultaneously versus the case when two or more language/modality combinations for the same directions are provided as selectable alternatives without specific preference differentiation. The context or other specifications may introduce the possibility to distinguish between these cases. When a party in a call has no indications that two or more language/modality combinations for each direction are desired simultaeously in the call, the party SHOULD assume that satisfying one is sufficient. Other specifications may add other attribute value modifiers than the asterisk. If an unknown modifier is detected, the modifier SHALL be ignored." In section 6. Reference to semantics in the attribute registrations are expanded from 5.2 to 5.2-5.3. --------------------------------------------------------------------------------------------------- 6. The cases in the "Silly states" section 5.4 are not all silly. Section 5.4 contains some proposed interpretations of unusual language indications. They are not silly, but just unusual. Therefore change the name of the section to "5.4 Unusual indications" The section contains too weak specification about what to do with the unusual indications. That may cause a risk that a user who gets accustomed to one behavior in contact with certain UAs, suddeenly gets another behavior in contact with another UA. Change: Old: "An offer MUST NOT be created where the language does not make sense for the media type. If such an offer is received, the receiver MAY reject the media, ignore the language specified, or attempt to interpret the intent (e.g., if American Sign Language is specified for an audio media stream, this might be interpreted as a desire to use spoken English)." To: "An offer MUST NOT be created where the language does not make sense for the media type. If such an offer is received, the receiver SHOULD ignore the language specified." Also add the following at the end of 5.4 to explain the choice of interpretation of a spoken/written language tag in a video medium to be a request to see the speaker rather than having text captions overlayed on video. "There is no difference between language tags for spoken and written languages. The spoken or written language tag indicated for a video stream could therefore be interpreted as a capability or request to use text captions overlayed on the video stream. The interpretation according to this specification SHALL however be to have a view of the speaker." ----------------------------------------------------------------------------------------------------------- 7. Examples section 5.5 requires expansion Section 5.5 Examples has very little explanations and show just a few cases. The section is proposed to be expanded, with O/A examples with descriptions and alternative outcomes in order to more thoroughly describe the intended use. See 5.5 in the the attached file for the proposed expansion. ------------------------------------------------------------------------------------------------------------ 8. Include more fields for attribute registration from 4566bis Section 6 has the form for attribute registration by IANA. There are a couple of fields missing that will be important for use of the specification in the WebRTC environment. Include these fields if that is allowable according to current IANA procedures and if that does not delay the publication of this draft. These fields are needed for use of text media in WebRTC. Change: In two locations from: "Usage Level: media" to: "Usage Level: media, dcsa(subprotocol)" Insert in two locations in the registration forms: "Mux Category: NORMAL" --------------------------------------------------------------------------------------------------------------- With these proposed modifications accepted I am convinced that the result will be useful for its purpose. Regards Gunnar Hellstrom ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 Den 2017-02-06 kl. 16:27, skrev The IESG: > The IESG has received a request from the Selection of Language for > Internet Media WG (slim) to consider the following document: > - 'Negotiating Human Language in Real-Time Communications' > 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-02-20. 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 > > > Users have various human (natural) language needs, abilities, and > preferences regarding spoken, written, and signed languages. When > establishing interactive communication ("calls") there needs to be a > way to negotiate (communicate and match) the caller's language and > media needs with the capabilities of the called party. This is > especially important with emergency calls, where a call can be > handled by a call taker capable of communicating with the user, or a > translator or relay operator can be bridged into the call during > setup, but this applies to non-emergency calls as well (as an > example, when calling a company call center). > > This document describes the need and a solution using new SDP stream > attributes. > > > > > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-slim-negotiating-human-language/ > > IESG discussion can be tracked via > https://datatracker.ietf.org/doc/draft-ietf-slim-negotiating-human-language/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-saintandre-sip-xmpp-chat: Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): One-to-One Text Chat (None - ) > Note that some of these references may already be listed in the acceptable Downref Registry. > > -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 --------------14511186B3059DA30155E67B Content-Type: text/plain; charset=UTF-8; name="draft-ietf-slim-negotiating-human-language-06g.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="draft-ietf-slim-negotiating-human-language-06g.txt" CgoKCk5ldHdvcmsgV29ya2luZyBHcm91cCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgUi4gR2VsbGVucwpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgQ29yZSBUZWNobm9sb2d5IENvbnN1bHRpbmcKSW50ZW5kZWQgc3Rh dHVzOiBTdGFuZGFyZHMgVHJhY2sgICAgICAgICAgICAgICAgICAgICAgIEZlYnJ1YXJ5IDEy LCAyMDE3CkV4cGlyZXM6IEF1Z3VzdCA2LCAyMDE3CgoKICAgICAgICAgTmVnb3RpYXRpbmcg SHVtYW4gTGFuZ3VhZ2UgaW4gUmVhbC1UaW1lIENvbW11bmljYXRpb25zCiAgICAgICAgICAg ICBkcmFmdC1pZXRmLXNsaW0tbmVnb3RpYXRpbmctaHVtYW4tbGFuZ3VhZ2UtMDZnaAoKQWJz dHJhY3QKCiAgIFVzZXJzIGhhdmUgdmFyaW91cyBodW1hbiAobmF0dXJhbCkgbGFuZ3VhZ2Ug bmVlZHMsIGFiaWxpdGllcywgYW5kCiAgIHByZWZlcmVuY2VzIHJlZ2FyZGluZyBzcG9rZW4s IHdyaXR0ZW4sIGFuZCBzaWduZWQgbGFuZ3VhZ2VzLiAgV2hlbgogICBlc3RhYmxpc2hpbmcg aW50ZXJhY3RpdmUgY29tbXVuaWNhdGlvbiAoImNhbGxzIikgdGhlcmUgbmVlZHMgdG8gYmUg YQogICB3YXkgdG8gbmVnb3RpYXRlIChjb21tdW5pY2F0ZSBhbmQgbWF0Y2gpIHRoZSBjYWxs ZXIncyBsYW5ndWFnZSBhbmQKICAgbWVkaWEgbmVlZHMgd2l0aCB0aGUgY2FwYWJpbGl0aWVz IG9mIHRoZSBjYWxsZWQgcGFydHkuICBUaGlzIGlzCiAgIGVzcGVjaWFsbHkgaW1wb3J0YW50 IHdpdGggZW1lcmdlbmN5IGNhbGxzLCB3aGVyZSBhIGNhbGwgY2FuIGJlCiAgIGhhbmRsZWQg YnkgYSBjYWxsIHRha2VyIGNhcGFibGUgb2YgY29tbXVuaWNhdGluZyB3aXRoIHRoZSB1c2Vy LCBvciBhCiAgIHRyYW5zbGF0b3Igb3IgcmVsYXkgb3BlcmF0b3IgY2FuIGJlIGJyaWRnZWQg aW50byB0aGUgY2FsbCBkdXJpbmcKICAgc2V0dXAsIGJ1dCB0aGlzIGFwcGxpZXMgdG8gbm9u LWVtZXJnZW5jeSBjYWxscyBhcyB3ZWxsIChhcyBhbgogICBleGFtcGxlLCB3aGVuIGNhbGxp bmcgYSBjb21wYW55IGNhbGwgY2VudGVyKS4KCiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVz IHRoZSBuZWVkIGFuZCBhIHNvbHV0aW9uIHVzaW5nIG5ldyBTRFAgc3RyZWFtCiAgIGF0dHJp YnV0ZXMuCgpTdGF0dXMgb2YgVGhpcyBNZW1vCgogICBUaGlzIEludGVybmV0LURyYWZ0IGlz IHN1Ym1pdHRlZCBpbiBmdWxsIGNvbmZvcm1hbmNlIHdpdGggdGhlCiAgIHByb3Zpc2lvbnMg b2YgQkNQIDc4IGFuZCBCQ1AgNzkuCgogICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcg ZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZwogICBUYXNrIEZvcmNlIChJ RVRGKS4gIE5vdGUgdGhhdCBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZQogICB3 b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC1EcmFmdHMuICBUaGUgbGlzdCBvZiBjdXJy ZW50IEludGVybmV0LQogICBEcmFmdHMgaXMgYXQgaHR0cDovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RyYWZ0cy9jdXJyZW50Ly4KCiAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9j dW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRocwogICBhbmQgbWF5IGJl IHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0 IGFueQogICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJh ZnRzIGFzIHJlZmVyZW5jZQogICBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhh biBhcyAid29yayBpbiBwcm9ncmVzcy4iCgogICBUaGlzIEludGVybmV0LURyYWZ0IHdpbGwg ZXhwaXJlIG9uIEF1Z3VzdCA2LCAyMDE3LgoKQ29weXJpZ2h0IE5vdGljZQoKICAgQ29weXJp Z2h0IChjKSAyMDE3IElFVEYgVHJ1c3QgYW5kIHRoZSBwZXJzb25zIGlkZW50aWZpZWQgYXMg dGhlCiAgIGRvY3VtZW50IGF1dGhvcnMuICBBbGwgcmlnaHRzIHJlc2VydmVkLgoKCgoKCkdl bGxlbnMgICAgICAgICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCA2LCAyMDE3ICAgICAgICAg ICAgICAgICBbUGFnZSAxXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgTmVnb3RpYXRpbmcg SHVtYW4gTGFuZ3VhZ2UgICAgICAgICAgRmVicnVhcnkgMjAxNwoKCiAgIFRoaXMgZG9jdW1l bnQgaXMgc3ViamVjdCB0byBCQ1AgNzggYW5kIHRoZSBJRVRGIFRydXN0J3MgTGVnYWwKICAg UHJvdmlzaW9ucyBSZWxhdGluZyB0byBJRVRGIERvY3VtZW50cwogICAoaHR0cDovL3RydXN0 ZWUuaWV0Zi5vcmcvbGljZW5zZS1pbmZvKSBpbiBlZmZlY3Qgb24gdGhlIGRhdGUgb2YKICAg cHVibGljYXRpb24gb2YgdGhpcyBkb2N1bWVudC4gIFBsZWFzZSByZXZpZXcgdGhlc2UgZG9j dW1lbnRzCiAgIGNhcmVmdWxseSwgYXMgdGhleSBkZXNjcmliZSB5b3VyIHJpZ2h0cyBhbmQg cmVzdHJpY3Rpb25zIHdpdGggcmVzcGVjdAogICB0byB0aGlzIGRvY3VtZW50LiAgQ29kZSBD b21wb25lbnRzIGV4dHJhY3RlZCBmcm9tIHRoaXMgZG9jdW1lbnQgbXVzdAogICBpbmNsdWRl IFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UgdGV4dCBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiA0 LmUgb2YKICAgdGhlIFRydXN0IExlZ2FsIFByb3Zpc2lvbnMgYW5kIGFyZSBwcm92aWRlZCB3 aXRob3V0IHdhcnJhbnR5IGFzCiAgIGRlc2NyaWJlZCBpbiB0aGUgU2ltcGxpZmllZCBCU0Qg TGljZW5zZS4KClRhYmxlIG9mIENvbnRlbnRzCgogICAxLiAgSW50cm9kdWN0aW9uICAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDMKICAgMi4g IFRlcm1pbm9sb2d5IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gICA1CiAgIDMuICBEZXNpcmVkIFNlbWFudGljcyAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNQogICA0LiAgVGhlIGV4aXN0aW5nICds YW5nJyBhdHRyaWJ1dGUgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDUKICAg NS4gIFByb3Bvc2VkIFNvbHV0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gICA2CiAgICAgNS4xLiAgUmF0aW9uYWxlIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNgogICAgIDUuMi4gIFRoZSAnaHVt aW50bGFuZy1zZW5kJyBhbmQgJ2h1bWludGxhbmctcmVjdicgYXR0cmlidXRlcyAgLiAgIDYK ICAgICA1LjMuICBQcmVmZXJlbmNlcyB3aXRoaW4gdGhlIHNlc3Npb24gIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gICA4CiAgICAgNS40LiAgVW51c3VhbCBpbmRpY2F0aW9ucyAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgOAogICAgIDUuNS4gIEV4YW1w bGVzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAg IDkKICAgNi4gIElBTkEgQ29uc2lkZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gICA5CiAgIDcuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxMAogICA4LiAgUHJpdmFj eSBDb25zaWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAgMTAKICAgOS4gIENoYW5nZXMgZnJvbSBQcmV2aW91cyBWZXJzaW9ucyAgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gIDEwCiAgICAgOS4xLiAgQ2hhbmdlcyBmcm9tIGRyYWZ0 LWlldGYtc2xpbS0uLi4tMDQgdG8gZHJhZnQtaWV0Zi0KICAgICAgICAgICBzbGltLS4uLi0w NiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDEwCiAg ICAgOS4yLiAgQ2hhbmdlcyBmcm9tIGRyYWZ0LWlldGYtc2xpbS0uLi4tMDIgdG8gZHJhZnQt aWV0Zi0KICAgICAgICAgICBzbGltLS4uLi0wMyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gIDExCiAgICAgOS4zLiAgQ2hhbmdlcyBmcm9tIGRyYWZ0 LWlldGYtc2xpbS0uLi4tMDEgdG8gZHJhZnQtaWV0Zi0KICAgICAgICAgICBzbGltLS4uLi0w MiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDExCiAg ICAgOS40LiAgQ2hhbmdlcyBmcm9tIGRyYWZ0LWlldGYtc2xpbS0uLi4tMDAgdG8gZHJhZnQt aWV0Zi0KICAgICAgICAgICBzbGltLS4uLi0wMSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gIDExCiAgICAgOS41LiAgQ2hhbmdlcyBmcm9tIGRyYWZ0 LWdlbGxlbnMtc2xpbS0uLi4tMDMgdG8gZHJhZnQtaWV0Zi0KICAgICAgICAgICBzbGltLS4u Li0wMCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDEx CiAgICAgOS42LiAgQ2hhbmdlcyBmcm9tIGRyYWZ0LWdlbGxlbnMtc2xpbS0uLi4tMDIgdG8g ZHJhZnQtZ2VsbGVucy0KICAgICAgICAgICBzbGltLS4uLi0wMyAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDExCiAgICAgOS43LiAgQ2hhbmdlcyBm cm9tIGRyYWZ0LWdlbGxlbnMtc2xpbS0uLi4tMDEgdG8gZHJhZnQtZ2VsbGVucy0KICAgICAg ICAgICBzbGltLS4uLi0wMiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gIDExCiAgICAgOS44LiAgQ2hhbmdlcyBmcm9tIGRyYWZ0LWdlbGxlbnMtc2xp bS0uLi4tMDAgdG8gZHJhZnQtZ2VsbGVucy0KICAgICAgICAgICBzbGltLS4uLi0wMSAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDExCiAgICAgOS45 LiAgQ2hhbmdlcyBmcm9tIGRyYWZ0LWdlbGxlbnMtbW11c2ljLS4uLi0wMiB0byBkcmFmdC0K ICAgICAgICAgICBnZWxsZW5zLXNsaW0tLi4uLTAwIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gIDExCiAgICAgOS4xMC4gQ2hhbmdlcyBmcm9tIGRyYWZ0LWdlbGxl bnMtbW11c2ljLS4uLi0wMSB0byAtMDIgLiAuIC4gLiAuICAxMgogICAgIDkuMTEuIENoYW5n ZXMgZnJvbSBkcmFmdC1nZWxsZW5zLW1tdXNpYy0uLi4tMDAgdG8gLTAxIC4gLiAuIC4gLiAg MTIKICAgICA5LjEyLiBDaGFuZ2VzIGZyb20gZHJhZnQtZ2VsbGVucy0uLi4tMDIgdG8gZHJh ZnQtZ2VsbGVucy0KICAgICAgICAgICBtbXVzaWMtLi4uLTAwIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDEyCgoKCkdlbGxlbnMgICAgICAgICAgICAg ICAgICBFeHBpcmVzIEF1Z3VzdCA2LCAyMDE3ICAgICAgICAgICAgICAgICBbUGFnZSAyXQoM CkludGVybmV0LURyYWZ0ICAgICAgICAgTmVnb3RpYXRpbmcgSHVtYW4gTGFuZ3VhZ2UgICAg ICAgICAgRmVicnVhcnkgMjAxNwoKCiAgICAgOS4xMy4gQ2hhbmdlcyBmcm9tIGRyYWZ0LWdl bGxlbnMtLi4uLTAxIHRvIC0wMiAgLiAuIC4gLiAuIC4gLiAuICAxMwogICAgIDkuMTQuIENo YW5nZXMgZnJvbSBkcmFmdC1nZWxsZW5zLS4uLi0wMCB0byAtMDEgIC4gLiAuIC4gLiAuIC4g LiAgMTMKICAgMTAuIENvbnRyaWJ1dG9ycyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gIDEzCiAgIDExLiBBY2tub3dsZWRnbWVudHMgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxMwogICAxMi4gUmVm ZXJlbmNlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAgMTQKICAgICAxMi4xLiAgTm9ybWF0aXZlIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE0CiAgICAgMTIuMi4gIEluZm9ybWF0aW9uYWwg UmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxNAogICBBcHBl bmRpeCBBLiAgSGlzdG9yaWMgQWx0ZXJuYXRpdmUgUHJvcG9zYWw6IENhbGxlci1wcmVmcyAg LiAuIC4gLiAgMTQKICAgICBBLjEuICBVc2Ugb2YgQ2FsbGVyIFByZWZlcmVuY2VzIFdpdGhv dXQgQWRkaXRpb25zIC4gLiAuIC4gLiAuIC4gIDE1CiAgICAgQS4yLiAgQWRkaXRpb25hbCBD YWxsZXIgUHJlZmVyZW5jZXMgZm9yIEFzeW1tZXRyaWMgTmVlZHMgIC4gLiAuICAxNwogICAg ICAgQS4yLjEuICBDYWxsZXIgUHJlZmVyZW5jZXMgZm9yIEFzeW1tZXRyaWMgTW9kYWxpdHkg TmVlZHMgIC4gLiAgMTcKICAgICAgIEEuMi4yLiAgQ2FsbGVyIFByZWZlcmVuY2VzIGZvciBB c3ltbWV0cmljIExhbmd1YWdlIFRhZ3MgLiAuIC4gIDE4CiAgIEF1dGhvcidzIEFkZHJlc3Mg IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxOQoK MS4gIEludHJvZHVjdGlvbgoKICAgQSBtdXR1YWxseSBjb21wcmVoZW5zaWJsZSBsYW5ndWFn ZSBpcyBoZWxwZnVsIGZvciBodW1hbgogICBjb21tdW5pY2F0aW9uLiAgVGhpcyBkb2N1bWVu dCBhZGRyZXNzZXMgdGhlIHJlYWwtdGltZSwgaW50ZXJhY3RpdmUKICAgc2lkZSBvZiB0aGUg aXNzdWUuICBBIGNvbXBhbmlvbiBkb2N1bWVudCBvbiBsYW5ndWFnZSBzZWxlY3Rpb24gaW4K ICAgZW1haWwgW0ktRC5pZXRmLXNsaW0tbXVsdGlsYW5nY29udGVudF0gYWRkcmVzc2VzIHRo ZSBub24tcmVhbC10aW1lCiAgIHNpZGUuCgogICBXaGVuIHNldHRpbmcgdXAgaW50ZXJhY3Rp dmUgY29tbXVuaWNhdGlvbiBzZXNzaW9ucyAodXNpbmcgU0lQIG9yCiAgIG90aGVyIHByb3Rv Y29scyksIGh1bWFuIChuYXR1cmFsKSBsYW5ndWFnZSBhbmQgbWVkaWEgbW9kYWxpdHkKICAg KHNwb2tlbiwgc2lnbmVkLCB3cml0dGVuKSBuZWdvdGlhdGlvbiBtYXkgYmUgbmVlZGVkLiAg VW5sZXNzIHRoZQogICBjYWxsZXIgYW5kIGNhbGxlZSBrbm93IGVhY2ggb3RoZXIgb3IgdGhl cmUgaXMgY29udGV4dHVhbCBvciBvdXQgb2YKICAgYmFuZCBpbmZvcm1hdGlvbiBmcm9tIHdo aWNoIHRoZSBsYW5ndWFnZShzKSBhbmQgbWVkaWEgbW9kYWxpdGllcyBjYW4KICAgYmUgZGV0 ZXJtaW5lZCwgdGhlcmUgaXMgYSBuZWVkIGZvciBzcG9rZW4sIHNpZ25lZCwgb3Igd3JpdHRl bgogICBsYW5ndWFnZXMgdG8gYmUgbmVnb3RpYXRlZCBiYXNlZCBvbiB0aGUgY2FsbGVyJ3Mg bmVlZHMgYW5kIHRoZQogICBjYWxsZWUncyBjYXBhYmlsaXRpZXMuICBUaGlzIG5lZWQgYXBw bGllcyB0byBib3RoIGVtZXJnZW5jeSBhbmQgbm9uLQogICBlbWVyZ2VuY3kgY2FsbHMuICBG b3IgdmFyaW91cyByZWFzb25zLCBpbmNsdWRpbmcgdGhlIGFiaWxpdHkgdG8KICAgZXN0YWJs aXNoIG11bHRpcGxlIHN0cmVhbXMgdXNpbmcgZGlmZmVyZW50IG1lZGlhIChlLmcuLCB2b2lj ZSwgdGV4dCwKICAgdmlkZW8pLCBpdCBtYWtlcyBzZW5zZSB0byB1c2UgYSBwZXItc3RyZWFt IG5lZ290aWF0aW9uIG1lY2hhbmlzbSwgaW4KICAgdGhpcyBjYXNlLCBTRFAuCgogICBUaGlz IGFwcHJvYWNoIGhhcyBhIG51bWJlciBvZiBiZW5lZml0cywgaW5jbHVkaW5nIHRoYXQgaXQg aXMgZ2VuZXJpYwogICAoYXBwbGllcyB0byBhbGwgaW50ZXJhY3RpdmUgY29tbXVuaWNhdGlv bnMgbmVnb3RpYXRlZCB1c2luZyBTRFApIGFuZAogICBub3QgbGltaXRlZCB0byBlbWVyZ2Vu Y3kgY2FsbHMuICBJbiBzb21lIGNhc2VzIHN1Y2ggYSBmYWNpbGl0eSBpc24ndAogICBuZWVk ZWQsIGJlY2F1c2UgdGhlIGxhbmd1YWdlIGlzIGtub3duIGZyb20gdGhlIGNvbnRleHQgKHN1 Y2ggYXMgd2hlbgogICBhIGNhbGxlciBwbGFjZXMgYSBjYWxsIHRvIGEgc2lnbiBsYW5ndWFn ZSByZWxheSBjZW50ZXIsIHRvIGEgZnJpZW5kLAogICBvciBjb2xsZWFndWUpLiAgQnV0IGl0 IGlzIGNsZWFybHkgdXNlZnVsIGluIG1hbnkgb3RoZXIgY2FzZXMuICBGb3IKICAgZXhhbXBs ZSwgc29tZW9uZSBjYWxsaW5nIGEgY29tcGFueSBjYWxsIGNlbnRlciBvciBhIFB1YmxpYyBT YWZldHkKICAgQW5zd2VyaW5nIFBvaW50IChQU0FQKSBzaG91bGQgYmUgYWJsZSB0byBpbmRp Y2F0ZSBpZiBvbmUgb3IgbW9yZQogICBzcGVjaWZpYyBzaWduZWQsIHdyaXR0ZW4sIGFuZC9v ciBzcG9rZW4gbGFuZ3VhZ2VzIGFyZSBwcmVmZXJyZWQsIHRoZQogICBjYWxsZWUgc2hvdWxk IGJlIGFibGUgdG8gaW5kaWNhdGUgaXRzIGNhcGFiaWxpdGllcyBpbiB0aGlzIGFyZWEsIGFu ZAogICB0aGUgY2FsbCBwcm9jZWVkIHVzaW5nIGluLWNvbW1vbiBsYW5ndWFnZShzKSBhbmQg bWVkaWEgZm9ybXMuCgoKCgoKR2VsbGVucyAgICAgICAgICAgICAgICAgIEV4cGlyZXMgQXVn dXN0IDYsIDIwMTcgICAgICAgICAgICAgICAgIFtQYWdlIDNdCgwKSW50ZXJuZXQtRHJhZnQg ICAgICAgICBOZWdvdGlhdGluZyBIdW1hbiBMYW5ndWFnZSAgICAgICAgICBGZWJydWFyeSAy MDE3CgoKICAgU2luY2UgdGhpcyBpcyBhIHByb3RvY29sIG1lY2hhbmlzbSwgdGhlIHVzZXIg ZXF1aXBtZW50IChVRSBjbGllbnQpCiAgIG5lZWRzIHRvIGtub3cgdGhlIHVzZXIncyBwcmVm ZXJyZWQgbGFuZ3VhZ2VzOyBhIHJlYXNvbmFibGUgdGVjaG5pcXVlCiAgIGNvdWxkIGluY2x1 ZGUgYSBjb25maWd1cmF0aW9uIG1lY2hhbmlzbSB3aXRoIGEgZGVmYXVsdCBvZiB0aGUKICAg bGFuZ3VhZ2Ugb2YgdGhlIHVzZXIgaW50ZXJmYWNlLiAgSW4gc29tZSBjYXNlcywgYSBVRSBj b3VsZCB0aWUKICAgbGFuZ3VhZ2UgYW5kIG1lZGlhIHByZWZlcmVuY2VzLCBzdWNoIGFzIGEg cHJlZmVyZW5jZSBmb3IgYSB2aWRlbwogICBzdHJlYW0gdXNpbmcgYSBzaWduZWQgbGFuZ3Vh Z2UgYW5kL29yIGEgdGV4dCBvciBhdWRpbyBzdHJlYW0gdXNpbmcgYQogICB3cml0dGVuL3Nw b2tlbiBsYW5ndWFnZS4KCiAgIEluY2x1ZGluZyB0aGUgdXNlcidzIGh1bWFuIChuYXR1cmFs KSBsYW5ndWFnZSBwcmVmZXJlbmNlcyBpbiB0aGUKICAgc2Vzc2lvbiBlc3RhYmxpc2htZW50 IG5lZ290aWF0aW9uIGlzIGluZGVwZW5kZW50IG9mIHRoZSB1c2Ugb2YgYQogICByZWxheSBz ZXJ2aWNlIGFuZCBpcyB0cmFuc3BhcmVudCB0byBhIHZvaWNlIHNlcnZpY2UgcHJvdmlkZXIu ICBGb3IKICAgZXhhbXBsZSwgYXNzdW1lIGEgdXNlciB3aXRoaW4gdGhlIFVuaXRlZCBTdGF0 ZXMgd2hvIHNwZWFrcyBTcGFuaXNoCiAgIGJ1dCBub3QgRW5nbGlzaCBwbGFjZXMgYSB2b2lj ZSBjYWxsLiAgVGhlIGNhbGwgY291bGQgYmUgYW4gZW1lcmdlbmN5CiAgIGNhbGwgb3IgcGVy aGFwcyB0byBhbiBhaXJsaW5lIHJlc2VydmF0aW9uIGRlc2suICBUaGUgbGFuZ3VhZ2UKICAg aW5mb3JtYXRpb24gaXMgdHJhbnNwYXJlbnQgdG8gdGhlIHZvaWNlIHNlcnZpY2UgcHJvdmlk ZXIsIGJ1dCBpcyBwYXJ0CiAgIG9mIHRoZSBzZXNzaW9uIG5lZ290aWF0aW9uIGJldHdlZW4g dGhlIFVFIGFuZCB0aGUgdGVybWluYXRpbmcgZW50aXR5LgogICBJbiB0aGUgY2FzZSBvZiBh IGNhbGwgdG8gZS5nLiwgYW4gYWlybGluZSwgdGhlIGNhbGwgY291bGQgYmUKICAgYXV0b21h dGljYWxseSBoYW5kbGVkIGJ5IGEgU3BhbmlzaC1zcGVha2luZyBhZ2VudC4gIEluIHRoZSBj YXNlIG9mIGFuCiAgIGVtZXJnZW5jeSBjYWxsLCB0aGUgRW1lcmdlbmN5IFNlcnZpY2VzIElQ IG5ldHdvcmsgKEVTSW5ldCkgYW5kIHRoZQogICBQU0FQIG1heSBjaG9vc2UgdG8gdGFrZSB0 aGUgbGFuZ3VhZ2UgYW5kIG1lZGlhIHByZWZlcmVuY2VzIGludG8KICAgYWNjb3VudCB3aGVu IGRldGVybWluaW5nIGhvdyB0byBwcm9jZXNzIHRoZSBjYWxsLgoKICAgQnkgdHJlYXRpbmcg bGFuZ3VhZ2UgYXMgYW5vdGhlciBhdHRyaWJ1dGUgdGhhdCBpcyBuZWdvdGlhdGVkIGFsb25n CiAgIHdpdGggb3RoZXIgYXNwZWN0cyBvZiBhIG1lZGlhIHN0cmVhbSwgaXQgYmVjb21lcyBw b3NzaWJsZSB0bwogICBhY2NvbW1vZGF0ZSBhIHJhbmdlIG9mIHVzZXJzJyBuZWVkcyBhbmQg Y2FsbGVkIHBhcnR5IGZhY2lsaXRpZXMuICBGb3IKICAgZXhhbXBsZSwgc29tZSB1c2VycyBt YXkgYmUgYWJsZSB0byBzcGVhayBzZXZlcmFsIGxhbmd1YWdlcywgYnV0IGhhdmUKICAgYSBw cmVmZXJlbmNlLiAgU29tZSBjYWxsZWQgcGFydGllcyBtYXkgc3VwcG9ydCBzb21lIG9mIHRo b3NlCiAgIGxhbmd1YWdlcyBpbnRlcm5hbGx5IGJ1dCByZXF1aXJlIHRoZSB1c2Ugb2YgYSB0 cmFuc2xhdGlvbiBzZXJ2aWNlIGZvcgogICBvdGhlcnMsIG9yIG1heSBoYXZlIGEgbGltaXRl ZCBudW1iZXIgb2YgY2FsbCB0YWtlcnMgYWJsZSB0byB1c2UKICAgY2VydGFpbiBsYW5ndWFn ZXMuICBBbm90aGVyIGV4YW1wbGUgd291bGQgYmUgYSB1c2VyIHdobyBpcyBhYmxlIHRvCiAg IHNwZWFrIGJ1dCBpcyBkZWFmIG9yIGhhcmQtb2YtaGVhcmluZyBhbmQgcmVxdWlyZXMgYSB2 b2ljZSBzdHJlYW0gcGx1cwogICBhIHRleHQgc3RyZWFtLiAgTWFraW5nIGxhbmd1YWdlIGEg bWVkaWEgYXR0cmlidXRlIGFsbG93cyB0aGUgc3RhbmRhcmQKICAgc2Vzc2lvbiBuZWdvdGlh dGlvbiBtZWNoYW5pc20gdG8gaGFuZGxlIHRoaXMgYnkgcHJvdmlkaW5nIHRoZQogICBpbmZv cm1hdGlvbiBhbmQgbWVjaGFuaXNtIGZvciB0aGUgZW5kcG9pbnRzIHRvIG1ha2UgYXBwcm9w cmlhdGUKICAgZGVjaXNpb25zLgoKICAgUmVnYXJkaW5nIHJlbGF5IHNlcnZpY2VzLCBpbiB0 aGUgY2FzZSBvZiBhbiBlbWVyZ2VuY3kgY2FsbCByZXF1aXJpbmcKICAgc2lnbiBsYW5ndWFn ZSBzdWNoIGFzIEFTTCwgdGhlcmUgYXJlIGN1cnJlbnRseSB0d28gY29tbW9uIGFwcHJvYWNo ZXM6CiAgIHRoZSBjYWxsZXIgaW5pdGlhdGVzIHRoZSBjYWxsIHRvIGEgcmVsYXkgY2VudGVy LCBvciB0aGUgY2FsbGVyIHBsYWNlcwogICB0aGUgY2FsbCB0byBlbWVyZ2VuY3kgc2Vydmlj ZXMgKGUuZy4sIDkxMSBpbiB0aGUgVS5TLiBvciAxMTIgaW4KICAgRXVyb3BlKS4gIChJbiBh IHZhcmlhbnQgb2YgdGhlIHNlY29uZCBjYXNlLCB0aGUgdm9pY2Ugc2VydmljZQogICBwcm92 aWRlciBpbnZva2VzIGEgcmVsYXkgc2VydmljZSBhcyB3ZWxsIGFzIGVtZXJnZW5jeSBzZXJ2 aWNlcy4pICBJbgogICB0aGUgZm9ybWVyIGNhc2UsIHRoZSBsYW5ndWFnZSBuZWVkIGlzIGFu Y2lsbGFyeSBhbmQgc3VwcGxlbWVudGFsLiAgSW4KICAgdGhlIG5vbi12YXJpYW50IHNlY29u ZCBjYXNlLCB0aGUgRVNJbmV0IGFuZC9vciBQU0FQIG1heSB0YWtlIHRoZSBuZWVkCiAgIGZv ciBzaWduIGxhbmd1YWdlIGludG8gYWNjb3VudCBhbmQgYnJpZGdlIGluIGEgcmVsYXkgY2Vu dGVyLiAgSW4gdGhpcwogICBjYXNlLCB0aGUgRVNJbmV0IGFuZCBQU0FQIGhhdmUgYWxsIHRo ZSBzdGFuZGFyZCBpbmZvcm1hdGlvbiBhdmFpbGFibGUKICAgKHN1Y2ggYXMgbG9jYXRpb24p IGJ1dCBhcmUgYWJsZSB0byBicmlkZ2UgdGhlIHJlbGF5IHNvb25lciBpbiB0aGUKICAgY2Fs bCBwcm9jZXNzaW5nLgoKCgpHZWxsZW5zICAgICAgICAgICAgICAgICAgRXhwaXJlcyBBdWd1 c3QgNiwgMjAxNyAgICAgICAgICAgICAgICAgW1BhZ2UgNF0KDApJbnRlcm5ldC1EcmFmdCAg ICAgICAgIE5lZ290aWF0aW5nIEh1bWFuIExhbmd1YWdlICAgICAgICAgIEZlYnJ1YXJ5IDIw MTcKCgogICBCeSBtYWtpbmcgdGhpcyBmYWNpbGl0eSBwYXJ0IG9mIHRoZSBlbmQtdG8tZW5k IG5lZ290aWF0aW9uLCB0aGUKICAgcXVlc3Rpb24gb2Ygd2hpY2ggZW50aXR5IHByb3ZpZGVz IG9yIGVuZ2FnZXMgdGhlIHJlbGF5IHNlcnZpY2UKICAgYmVjb21lcyBzZXBhcmF0ZSBmcm9t IHRoZSBjYWxsIHByb2Nlc3NpbmcgbWVjaGFuaWNzOyBpZiB0aGUgY2FsbGVyCiAgIGRpcmVj dHMgdGhlIGNhbGwgdG8gYSByZWxheSBzZXJ2aWNlIHRoZW4gdGhlIGh1bWFuIGxhbmd1YWdl CiAgIG5lZ290aWF0aW9uIGZhY2lsaXR5IHByb3ZpZGVzIGV4dHJhIGluZm9ybWF0aW9uIHRv IHRoZSByZWxheSBzZXJ2aWNlCiAgIGJ1dCBjYWxscyB3aWxsIHN0aWxsIGZ1bmN0aW9uIHdp dGhvdXQgaXQ7IGlmIHRoZSBjYWxsZXIgZGlyZWN0cyB0aGUKICAgY2FsbCB0byBlbWVyZ2Vu Y3kgc2VydmljZXMsIHRoZW4gdGhlIEVTSW5ldC9QU0FQIGFyZSBhYmxlIHRvIHRha2UgdGhl CiAgIHVzZXIncyBodW1hbiBsYW5ndWFnZSBuZWVkcyBpbnRvIGFjY291bnQsIGUuZy4sIGJ5 IGFzc2lnbmluZyB0byBhCiAgIHNwZWNpZmljIHF1ZXVlIG9yIGNhbGwgdGFrZXIgb3IgYnJp ZGdpbmcgaW4gYSByZWxheSBzZXJ2aWNlIG9yCiAgIHRyYW5zbGF0b3IuCgogICBUaGUgdGVy bSAibmVnb3RpYXRpb24iIGlzIHVzZWQgaGVyZSByYXRoZXIgdGhhbiAiaW5kaWNhdGlvbiIg YmVjYXVzZQogICBodW1hbiBsYW5ndWFnZSAoc3Bva2VuL3dyaXR0ZW4vc2lnbmVkKSBpcyBz b21ldGhpbmcgdGhhdCBjYW4gYmUKICAgbmVnb3RpYXRlZCBpbiB0aGUgc2FtZSB3YXkgYXMg d2hpY2ggZm9ybXMgb2YgbWVkaWEgKGF1ZGlvL3RleHQvdmlkZW8pCiAgIG9yIHdoaWNoIGNv ZGVjcy4gIEZvciBleGFtcGxlLCBpZiB3ZSB0aGluayBvZiBub24tZW1lcmdlbmN5IGNhbGxz LAogICBzdWNoIGFzIGEgdXNlciBjYWxsaW5nIGFuIGFpcmxpbmUgcmVzZXJ2YXRpb24gY2Vu dGVyLCB0aGUgdXNlciBtYXkKICAgaGF2ZSBhIHNldCBvZiBsYW5ndWFnZXMgaGUgb3Igc2hl IHNwZWFrcywgd2l0aCBwZXJoYXBzIHByZWZlcmVuY2VzCiAgIGZvciBvbmUgb3IgYSBmZXcs IHdoaWxlIHRoZSBhaXJsaW5lIHJlc2VydmF0aW9uIGNlbnRlciB3aWxsIHN1cHBvcnQgYQog ICBmaXhlZCBzZXQgb2YgbGFuZ3VhZ2VzLiAgTmVnb3RpYXRpb24gU0hPVUxEIHNlbGVjdCB0 aGUgdXNlcidzIG1vc3QKICAgcHJlZmVycmVkIGxhbmd1YWdlIHRoYXQgaXMgc3VwcG9ydGVk IGJ5IHRoZSBjYWxsIGNlbnRlci4gIEJvdGggc2lkZXMKICAgc2hvdWxkIGJlIGF3YXJlIG9m IHdoaWNoIGxhbmd1YWdlIHdhcyBuZWdvdGlhdGVkLiAgVGhpcyBpcwogICBjb25jZXB0dWFs bHkgc2ltaWxhciB0byB0aGUgd2F5IG90aGVyIGFzcGVjdHMgb2YgZWFjaCBtZWRpYSBzdHJl YW0KICAgYXJlIG5lZ290aWF0ZWQgdXNpbmcgU0RQIChlLmcuLCBtZWRpYSB0eXBlIGFuZCBj b2RlY3MpLgoKMi4gIFRlcm1pbm9sb2d5CgogICBUaGUga2V5IHdvcmRzICJNVVNUIiwgIk1V U1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIsCiAgICJTSE9VTEQi LCAiU0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIsICJNQVkiLCBhbmQgIk9QVElPTkFMIiBp biB0aGlzCiAgIGRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQg aW4gUkZDIDIxMTkgW1JGQzIxMTldLgoKMy4gIERlc2lyZWQgU2VtYW50aWNzCgogICBUaGUg ZGVzaXJlZCBzb2x1dGlvbiBpcyBhIG1lZGlhIGF0dHJpYnV0ZSAocHJlZmVyYWJseSBwZXIg ZGlyZWN0aW9uKQogICB0aGF0IE1BWSBiZSB1c2VkIHdpdGhpbiBhbiBvZmZlciB0byBpbmRp Y2F0ZSB0aGUgcHJlZmVycmVkIGxhbmd1YWdlCiAgIG9mIGVhY2ggKGRpcmVjdGlvbiBvZiBh KSBtZWRpYSBzdHJlYW0sIGFuZCB3aXRoaW4gYW4gYW5zd2VyIHRvCiAgIGluZGljYXRlIHRo ZSBhY2NlcHRlZCBsYW5ndWFnZS4gIFRoZSBzZW1hbnRpY3Mgb2YgaW5jbHVkaW5nIG11bHRp cGxlCiAgIHZhbHVlcyBmb3IgYSBtZWRpYSBzdHJlYW0gd2l0aGluIGFuIG9mZmVyIGlzIHRo YXQgdGhlIGxhbmd1YWdlcyBhcmUKICAgbGlzdGVkIGluIG9yZGVyIG9mIHByZWZlcmVuY2Uu CgogICAoTmVnb3RpYXRpbmcgbXVsdGlwbGUgc2ltdWx0YW5lb3VzIGxhbmd1YWdlcyB3aXRo aW4gYSBtZWRpYSBzdHJlYW0gaXMKICAgb3V0IG9mIHNjb3BlLCBhcyB0aGUgY29tcGxleGl0 eSBvZiBkb2luZyBzbyBvdXR3ZWlnaHMgdGhlCiAgIHVzZWZ1bG5lc3MuKQoKNC4gIFRoZSBl eGlzdGluZyAnbGFuZycgYXR0cmlidXRlCgogICBSRkMgNDU2NiBbUkZDNDU2Nl0gc3BlY2lm aWVzIGFuIGF0dHJpYnV0ZSAnbGFuZycgd2hpY2ggYXBwZWFycwogICBzaW1pbGFyIHRvIHdo YXQgaXMgbmVlZGVkIGhlcmUsIGJ1dCBpcyBub3Qgc3VmZmljaWVudGx5IGRldGFpbGVkIGZv cgogICB1c2UgaGVyZS4gIEluIGFkZGl0aW9uLCBpdCBpcyBub3QgbWVudGlvbmVkIGluIFtS RkMzMjY0XSBhbmQgdGhlcmUKCgoKR2VsbGVucyAgICAgICAgICAgICAgICAgIEV4cGlyZXMg QXVndXN0IDYsIDIwMTcgICAgICAgICAgICAgICAgIFtQYWdlIDVdCgwKSW50ZXJuZXQtRHJh ZnQgICAgICAgICBOZWdvdGlhdGluZyBIdW1hbiBMYW5ndWFnZSAgICAgICAgICBGZWJydWFy eSAyMDE3CgoKICAgYXJlIG5vIGtub3duIGltcGxlbWVudGF0aW9ucyBpbiBTSVAuICBGdXJ0 aGVyLCB0aGVyZSBpcyB2YWx1ZSBpbgogICBiZWluZyBhYmxlIHRvIHNwZWNpZnkgbGFuZ3Vh Z2UgcGVyIGRpcmVjdGlvbiAoc2VuZGluZyBhbmQgcmVjZWl2aW5nKS4KICAgVGhpcyBkb2N1 bWVudCB0aGVyZWZvcmUgZGVmaW5lcyB0d28gbmV3IGF0dHJpYnV0ZXMuCgo1LiAgUHJvcG9z ZWQgU29sdXRpb24KCiAgIEFuIFNEUCBhdHRyaWJ1dGUgKHBlciBkaXJlY3Rpb24pIHNlZW1z IHRoZSBuYXR1cmFsIGNob2ljZSB0bwogICBuZWdvdGlhdGUgaHVtYW4gKG5hdHVyYWwpIGxh bmd1YWdlIG9mIGFuIGludGVyYWN0aXZlIG1lZGlhIHN0cmVhbS4KICAgVGhlIGF0dHJpYnV0 ZSB2YWx1ZSBTSE9VTEQgY29udGFpbiBhIGxhbmd1YWdlIHRhZyBwZXIgQkNQIDQ3IFtSRkM1 NjQ2XQoKNS4xLiAgUmF0aW9uYWxlCgogICBUaGUgZGVjaXNpb24gdG8gYmFzZSB0aGUgcHJv cG9zYWwgYXQgdGhlIG1lZGlhIG5lZ290aWF0aW9uIGxldmVsLCBhbmQKICAgc3BlY2lmaWNh bGx5IHRvIHVzZSBTRFAsIGNhbWUgYWZ0ZXIgc2lnbmlmaWNhbnQgZGViYXRlIGFuZAogICBk aXNjdXNzaW9uLiAgRnJvbSBhbiBlbmdpbmVlcmluZyBzdGFuZHBvaW50LCBpdCBpcyBwb3Nz aWJsZSB0byBtZWV0CiAgIHRoZSBvYmplY3RpdmVzIHVzaW5nIGEgdmFyaWV0eSBvZiBtZWNo YW5pc21zLCBidXQgbm9uZSBhcmUgcGVyZmVjdC4KICAgTm9uZSBvZiB0aGUgcHJvcG9zZWQg YWx0ZXJuYXRpdmVzIHdhcyBjbGVhcmx5IGJldHRlciB0ZWNobmljYWxseSBpbgogICBlbm91 Z2ggd2F5cyB0byB3aW4gb3ZlciBwcm9wb25lbnRzIG9mIHRoZSBvdGhlcnMsIGFuZCBub25l IHdlcmUKICAgY2xlYXJseSBzbyBiYWQgdGVjaG5pY2FsbHkgYXMgdG8gYmUgZWFzaWx5IHJl amVjdGVkLiAgQXMgaXMgb2Z0ZW4gdGhlCiAgIGNhc2UgaW4gZW5naW5lZXJpbmcsIGNob29z aW5nIHRoZSBzb2x1dGlvbiBpcyBhIG1hdHRlciBvZiBiYWxhbmNpbmcKICAgdHJhZGUtb2Zm cywgYW5kIHVsdGltYXRlbHkgbW9yZSBhIG1hdHRlciBvZiB0YXN0ZSB0aGFuIHRlY2huaWNh bAogICBtZXJpdC4gIFRoZSB0d28gbWFpbiBwcm9wb3NhbHMgd2VyZSB0byB1c2UgU0RQIGFu ZCBTSVAuICBTRFAgaGFzIHRoZQogICBhZHZhbnRhZ2UgdGhhdCB0aGUgbGFuZ3VhZ2UgaXMg bmVnb3RpYXRlZCB3aXRoIHRoZSBtZWRpYSB0byB3aGljaCBpdAogICBhcHBsaWVzLCB3aGls ZSBTSVAgaGFzIHRoZSBpc3N1ZSB0aGF0IHRoZSBsYW5ndWFnZXMgZXhwcmVzc2VkIG1heSBu b3QKICAgbWF0Y2ggdGhlIFNEUCBtZWRpYSBuZWdvdGlhdGVkIChmb3IgZXhhbXBsZSwgYSBz ZXNzaW9uIGNvdWxkCiAgIG5lZ290aWF0ZSB2aWRlbyBhdCB0aGUgU0lQIGxldmVsIGJ1dCBm YWlsIHRvIG5lZ290aWF0ZSBhbnkgdmlkZW8KICAgbWVkaWEgc3RyZWFtIGF0IHRoZSBTRFAg bGF5ZXIpLgoKICAgVGhlIG1lY2hhbmlzbSBkZXNjcmliZWQgaGVyZSBmb3IgU0RQIGNhbiBi ZSBhZGFwdGVkIHRvIG1lZGlhCiAgIG5lZ290aWF0aW9uIHByb3RvY29scyBvdGhlciB0aGFu IFNEUC4KCjUuMi4gIFRoZSAnaHVtaW50bGFuZy1zZW5kJyBhbmQgJ2h1bWludGxhbmctcmVj dicgYXR0cmlidXRlcwoKICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIHR3byBtZWRpYS1sZXZl bCBhdHRyaWJ1dGVzIHN0YXJ0aW5nIHdpdGgKICAgJ2h1bWludGxhbmcnIChzaG9ydCBmb3Ig Imh1bWFuIGludGVyYWN0aXZlIGxhbmd1YWdlIikgdG8gbmVnb3RpYXRlCiAgIHdoaWNoIGh1 bWFuIGxhbmd1YWdlIGlzIHVzZWQgaW4gZWFjaCBpbnRlcmFjdGl2ZSBtZWRpYSBzdHJlYW0u ICBUaGVyZQogICBhcmUgdHdvIGF0dHJpYnV0ZXMsIG9uZSBlbmRpbmcgaW4gIi1zZW5kIiBh bmQgdGhlIG90aGVyIGluICItcmVjdiIsCiAgIHJlZ2lzdGVyZWQgaW4gU2VjdGlvbiA2IGFu ZCBkZXNjcmliZWQgaGVyZToKCiAgICAgIGE9aHVtaW50bGFuZy1zZW5kOjxMYW5ndWFnZS1U YWc+W2FzdGVyaXNrXQogICAgICBhPWh1bWludGxhbmctcmVjdjo8TGFuZ3VhZ2UtVGFnPlth c3Rlcmlza10KCiAgIEVhY2ggY2FuIGFwcGVhciBtdWx0aXBsZSB0aW1lcyBpbiBhbiBvZmZl ciBmb3IgYSBtZWRpYSBzdHJlYW0uCgogICBJbiBhbiBvZmZlciwgZWFjaCAnaHVtaW50bGFu Zy1zZW5kJyBhdHRyaWJ1dGUgaW5kaWNhdGVzIGEgbGFuZ3VhZ2UgdGhlCiAgIG9mZmVyZXIg aXMgd2lsbGluZyB0byB1c2Ugd2hlbiBzZW5kaW5nIHVzaW5nIHRoZSBtZWRpYSwgYW5kCiAg ICdodW1pbnRsYW5nLXJlY3YnIGluZGljYXRlcyBhIGxhbmd1YWdlIHRoZSBvZmZlcmVyIGlz IHdpbGxpbmcgdG8gdXNlIHdoZW4KICAgcmVjZWl2aW5nIHVzaW5nIHRoZSBtZWRpYS4gIFRo ZSBMYW5ndWFnZS1UYWcgdmFsdWVzIGZyb20gbXVsdGlwbGUgCiAgIGF0dHJpYnV0ZXMgY29u c3RpdHV0ZSBhIGxpc3Qgb2YgbGFuZ3VhZ2VzIGluIHByZWZlcmVuY2Ugb3JkZXIgcGVyIGRp cmVjdGlvbiAKICAgKGZpcnN0IGlzIG1vc3QgcHJlZmVycmVkKS4KCgoKR2VsbGVucyAgICAg ICAgICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDYsIDIwMTcgICAgICAgICAgICAgICAgIFtQ YWdlIDZdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICBOZWdvdGlhdGluZyBIdW1hbiBMYW5n dWFnZSAgICAgICAgICBGZWJydWFyeSAyMDE3CgoKICAgIAoJCglXaGVuIGEgbWVkaWEgaXMg aW50ZW5kZWQgZm9yIGxhbmd1YWdlIHVzZSBpbiBvbmUgZGlyZWN0aW9uIG9ubHkgKHN1Y2gg CglhcyBhIHVzZXIgd2l0aCBzcGVlY2gtaW1wYWlybWVudCBpcyBzZW5kaW5nIHVzaW5nIHRl eHQgYW5kIHJlY2VpdmluZyAKCXVzaW5nIGF1ZGlvKSwgZWl0aGVyIGh1bWludGxhbmctc2Vu ZCBvciBodW1pbnRsYW5nLXJlY3YgTUFZIGJlIG9taXR0ZWQuCglXaGVuIGEgbWVkaWEgaXMg bm90IHByaW1hcmlseSBpbnRlbmRlZCBmb3IgbGFuZ3VhZ2UgKGZvciBleGFtcGxlLCBhIAoJ dmlkZW8gb3IgYXVkaW8gc3RyZWFtIGludGVuZGVkIGZvciBiYWNrZ3JvdW5kIG9ubHkpIGJv dGggU0hPVUxEIGJlIG9taXR0ZWQuCiAgIE90aGVyd2lzZSwgYm90aCBTSE9VTEQgaGF2ZSB0 aGUgc2FtZSB2YWx1ZXMgaW4gdGhlIHNhbWUgb3JkZXIuIFRoZQogICB0d28gU0hPVUxEIE5P VCBiZSBzZXQgdG8gbGFuZ3VhZ2VzIHdoaWNoIGFyZSBkaWZmaWN1bHQgdG8gbWF0Y2gKICAg dG9nZXRoZXIgKGUuZy4sIHNwZWNpZnlpbmcgYSBkZXNpcmUgdG8gc2VuZCBhdWRpbyBpbiBI dW5nYXJpYW4gYW5kCiAgIHJlY2VpdmUgYXVkaW8gaW4gUG9ydHVndWVzZSB3aWxsIG1ha2Ug aXQgZGlmZmljdWx0IHRvIHN1Y2Nlc3NmdWxseQogICBjb21wbGV0ZSB0aGUgY2FsbCkuCgog ICBJbiBhbiBhbnN3ZXIsICdodW1pbnRsYW5nLXNlbmQnIGluZGljYXRlcyB0aGUgbGFuZ3Vh Z2UgdGhlIGFuc3dlcmVyCiAgIHdpbGwgc2VuZCAod2hpY2ggaW4gbW9zdCBjYXNlcyBpcyBv bmUgb2YgdGhlIGxhbmd1YWdlcyBpbiB0aGUgb2ZmZXIncwogICAnaHVtaW50bGFuZy1yZWN2 JyksIGFuZCAnaHVtaW50bGFuZy1yZWN2JyBpbmRpY2F0ZXMgdGhlIGxhbmd1YWdlCiAgIHRo ZSBhbnN3ZXJlciBleHBlY3RzIHRvIHJlY2VpdmUgKHdoaWNoIGluIG1vc3QgY2FzZXMgaXMg b25lIG9mIHRoZQogICBsYW5ndWFnZXMgaW4gdGhlIG9mZmVyJ3MgJ2h1bWludGxhbmctc2Vu ZCcpLgoKICAgRWFjaCBMYW5ndWFnZS1UYWcgdmFsdWUgTVVTVCBiZSBhIGxhbmd1YWdlIHRh ZyBwZXIgQkNQIDQ3IFtSRkM1NjQ2XS4gIAogICBCQ1AgNDcgZGVzY3JpYmVzIG1lY2hhbmlz bXMgZm9yIG1hdGNoaW5nIGxhbmd1YWdlIHRhZ3MuICBOb3RlIHRoYXQgCiAgIFtSRkM1NjQ2 XSBTZWN0aW9uIDQuMSBhZHZpc2VzIHRvICJ0YWcgY29udGVudCB3aXNlbHkiIGFuZCBub3Qg aW5jbHVkZQogICB1bm5lY2Vzc2FyeSBzdWJ0YWdzLgoKICAgSW4gYW4gb2ZmZXIgb3IgYW5z d2VyLCBlYWNoIGF0dHJpYnV0ZSB2YWx1ZSBNQVkgaGF2ZSBhIG1vZGlmaWVyIGFwcGVuZGVk IGFzCiAgIHRoZSBsYXN0IGNoYXJhY3RlciAoYWZ0ZXIgdGhlIExhbmd1YWdlLVRhZykuIFRo aXMgc3BlY2lmaWNhdGlvbiBkZWZpbmVzIG9uZSAKICAgdmFsdWUgZm9yIHRoZSBtb2RpZmll cjsgYW4gYXN0ZXJpc2sgKCIqIikuIFRoZSBhc3RlcmlzayBpbmNsdWRlZCBpbiBhIGh1bWlu dGxhbmcgCiAgIGF0dHJpYnV0ZSB2YWx1ZSBpbiB0aGUgU0RQIGluZGljYXRlcyBhIGxvd2Vy IHByZWZlcmVuY2UgZm9yIHRoZSBpbmRpY2F0ZWQgCiAgIGxhbmd1YWdlIGFuZCBhIHJlcXVl c3QgYnkgdGhlIGNhbGxlciB0byBub3QgcmVqZWN0IHRoZSBjYWxsIGlmIHRoZXJlIAogICBp cyBubyBsYW5ndWFnZSBpbiBjb21tb24uICAKICAgU2VlIFNlY3Rpb24gNS4zIGZvciBtb3Jl IGluZm9ybWF0aW9uIGFuZCBkaXNjdXNzaW9uLgoKICAgV2hlbiBwbGFjaW5nIGFuIGVtZXJn ZW5jeSBjYWxsLCBhbmQgaW4gYW55IG90aGVyIGNhc2Ugd2hlcmUgdGhlCiAgIGxhbmd1YWdl IGNhbm5vdCBiZSBhc3N1bWVkIGZyb20gY29udGV4dCwgZWFjaCBtZWRpYSBzdHJlYW0gaW4g YW4KICAgb2ZmZXIgcHJpbWFyaWx5IGludGVuZGVkIGZvciBodW1hbiBsYW5ndWFnZSBjb21t dW5pY2F0aW9uIFNIT1VMRAogICBzcGVjaWZ5IGJvdGggKG9yIGluIHNvbWUgY2FzZXMgYXMg ZGVzY3JpYmVkIGFib3ZlLCBvbmUgb2YpIHRoZSAKICAgJ2h1bWludGxhbmctc2VuZCcgYW5k ICdodW1pbnRsYW5nLXJlY3YnIGF0dHJpYnV0ZXMuCgogICBOb3RlIHRoYXQgd2hpbGUgc2ln bmVkIGxhbmd1YWdlIHRhZ3MgYXJlIHVzZWQgd2l0aCBhIHZpZGVvIHN0cmVhbSB0bwogICBp bmRpY2F0ZSBzaWduIGxhbmd1YWdlLCBhIHNwb2tlbiBsYW5ndWFnZSB0YWcgZm9yIGEgdmlk ZW8gc3RyZWFtIGluCiAgIHBhcmFsbGVsIHdpdGggYW4gYXVkaW8gc3RyZWFtIHdpdGggdGhl IHNhbWUgc3Bva2VuIGxhbmd1YWdlIHRhZwogICBpbmRpY2F0ZXMgYSByZXF1ZXN0IGZvciBh IHN1cHBsZW1lbnRhbCB2aWRlbyBzdHJlYW0gdG8gc2VlIHRoZQogICBzcGVha2VyLgoKICAg Q2xpZW50cyBhY3Rpbmcgb24gYmVoYWxmIG9mIGVuZCB1c2VycyBhcmUgZXhwZWN0ZWQgdG8g c2V0IG9uZSBvciBib3RoCiAgICdodW1pbnRsYW5nLXNlbmQnIGFuZCAnaHVtaW50bGFuZy1y ZWN2JyBhdHRyaWJ1dGVzIG9uIGVhY2ggbWVkaWEKICAgc3RyZWFtIHByaW1hcmlseSBpbnRl bmRlZCBmb3IgaHVtYW4gY29tbXVuaWNhdGlvbiBpbiBhbiBvZmZlciB3aGVuCiAgIHBsYWNp bmcgYW4gb3V0Z29pbmcgc2Vzc2lvbiwgYW5kIGVpdGhlciBpZ25vcmUgb3IgdGFrZSBpbnRv CiAgIGNvbnNpZGVyYXRpb24gdGhlIGF0dHJpYnV0ZXMgd2hlbiByZWNlaXZpbmcgaW5jb21p bmcgY2FsbHMsIGJhc2VkIG9uCiAgIGxvY2FsIGNvbmZpZ3VyYXRpb24gYW5kIGNhcGFiaWxp dGllcy4gIFN5c3RlbXMgYWN0aW5nIG9uIGJlaGFsZiBvZgogICBjYWxsIGNlbnRlcnMgYW5k IFBTQVBzIGFyZSBleHBlY3RlZCB0byB0YWtlIGludG8gYWNjb3VudCB0aGUgdmFsdWVzCiAg IHdoZW4gcHJvY2Vzc2luZyBpbmJvdW5kIGNhbGxzLgoKCgpHZWxsZW5zICAgICAgICAgICAg ICAgICAgRXhwaXJlcyBBdWd1c3QgNiwgMjAxNyAgICAgICAgICAgICAgICAgW1BhZ2UgN10K DApJbnRlcm5ldC1EcmFmdCAgICAgICAgIE5lZ290aWF0aW5nIEh1bWFuIExhbmd1YWdlICAg ICAgICAgIEZlYnJ1YXJ5IDIwMTcKCgogICBOb3RlIHRoYXQgbWVkaWEgYW5kIGxhbmd1YWdl IG5lZ290aWF0aW9uIG1pZ2h0IHJlc3VsdCBpbiBtb3JlIG1lZGlhCiAgIHN0cmVhbXMgYmVp bmcgYWNjZXB0ZWQgdGhhbiBhcmUgbmVlZGVkIGJ5IHRoZSB1c2VycyBmb3IgbGFuZ3VhZ2Ug CiAgIGV4Y2hhbmdlIChlLmcuLCBpZiBtb3JlIHByZWZlcnJlZCBhbmQgbGVzcyBwcmVmZXJy ZWQgY29tYmluYXRpb25zIAogICBvZiBtZWRpYSBhbmQgbGFuZ3VhZ2UgYXJlIGFsbCBhY2Nl cHRlZCkuIFRoaXMgaXMgbm9ybWFsIGFuZCBhY2NlcHRlZCwKICAgYmVjYXVzZSB0aGUgaHVt aW50bGFuZyBhdHRyaWJ1dGUgaXMgbm90IGludGVuZGVkIHRvIHJlc3RyaWN0IG1lZGlhCiAg IHN0cmVhbXMgdG8gYmUgdXNlZCBvbmx5IGZvciBsYW5ndWFnZSBleGNoYW5nZS4KCjUuMy4g IFByZWZlcmVuY2VzIHdpdGhpbiB0aGUgc2Vzc2lvbgoKICAgSXQgaXMgb2YgaGlnaCBpbXBv cnRhbmNlIGZvciBhIHNtb290aCBzdGFydCBvZiBhIGNhbGwgdGhhdCB0aGUgCiAgIGFuc3dl cmluZyBwYXJ0eSBpcyBhbnN3ZXJpbmcgdGhlIGNhbGwgdXNpbmcgdGhlIGJlc3QgbWF0Y2hp bmcgCiAgIGxhbmd1YWdlKHMpIGFuZCBtb2RhbGl0eShpZXMpIHN1aXRhYmxlIGZvciB0aGUg Y29udGludWF0aW9uIG9mIHRoZSBjYWxsLiAKICAgU3dpdGNoaW5nIGxhbmd1YWdlIGFuZCBt b2RhbGl0eSBkdXJpbmcgdGhlIGNhbGwgYnkgYWdyZWVtZW50IGJldHdlZW4gCiAgIHRoZSBw YXJ0aWNpcGFudHMgaXMgb2Z0ZW4gdGltZSBjb25zdW1pbmcuIFdpdGhvdXQgc3VwcG9ydCBv ZiBkZXRhaWxlZCAKICAgbGFuZ3VhZ2UgYW5kIG1vZGFsaXR5IG5lZ290aWF0aW9uIHRoZSBw YXJ0aWNpYW50cyBtYXkgaGF2ZSBhIHRlbmRlbmN5IAogICB0byBjb250aW51ZSB0aGUgY2Fs bCBpbiB0aGUgaW5pdGlhbCBsYW5ndWFnZSBhbmQgbW9kYWxpdHkgZXZlbiBpZiBhIAogICBt b3JlIGNvbnZlbmllbnQgY29tbW9uIGxhbmd1YWdlIGFuZCBtb2RhbGl0eSBjb21iaW5hdGlv biBpcyBhdmFpbGFibGUuIAogICBJbiBvcmRlciB0byBzdXBwb3J0IHRoZSBkZWNpc2lvbiBv biB3aGljaCBvZiB0aGUgYXZhaWxhYmxlIGxhbmd1YWdlKHMpCiAgIGFuZCBtb2RhbGl0eShp ZXMpIHRvIHVzZSBpbml0aWFsbHkgaW4gdGhlIGNhbGwsIGEgc2ltcGxlIHR3by1sZXZlbCAK ICAgcHJlZmVyZW5jZSBpbmRpY2F0b3IgaXMgc3BlY2lmaWVkIGhlcmUgZm9yIGluY2x1c2lv biBhcyBhIG1vZGlmaWVyIAogICBpbiB0aGUgaHVtaW50bGFuZyBhdHRyaWJ1dGUgdmFsdWVz LiBUaGUgcHJlZmVyZW5jZSBpbmRpY2F0b3IgaXMgYWxzbwogICB1c2VkIGFzIGFuIGluZGlj YXRvciB0aGF0IHRoZSBjYWxsIFNIT1VMRCBiZSBlc3RhYmxpc2hlZCBldmVuIGlmIG5vIAog ICBsYW5ndWFnZSBtYXRjaCBpcyBmb3VuZC4gCgogICBUaGUgYXN0ZXJpc2sgKCIqIikgaXMg dXNlZCBhcyBhIHByZWZlcmVuY2UgaW5kaWNhdG9yIHdpdGhpbiB0aGUgc2Vzc2lvbi4gCiAg IExvdyByZWxhdGl2ZSBwcmVmZXJlbmNlIGZvciBhIGxhbmd1YWdlIGFuZCBtb2RhbGl0eSB0 byBiZSB1c2VkIGluIHRoZQogICBzZXNzaW9uIFNIT1VMRCBiZSBpbmRpY2F0ZWQgYnkgYXBw ZW5kaW5nIGFuIGFzdGVyaXNrIGFmdGVyIHRoZSBsYW5ndWFnZQogICB0YWcgaW4gdGhlIGF0 dHJpYnV0ZSB2YWx1ZS4gVGhpcyBpbmRpY2F0aW9uIGZyb20gdGhlIG9mZmVyaW5nIHBhcnR5 IAogICBTSE9VTEQgYmUgaW50ZXJwcmV0ZWQgYnkgdGhlIGFuc3dlcmluZyBwYXJ0eSBhcyBh IHJlcXVlc3QgdG8gdXNlIGEKICAgaGlnaGVyIHByZWZlcnJlZCBsYW5ndWFnZSBhbmQgbW9k YWxpdHkgd2hlbiBhbnN3ZXJpbmcgdGhlIGNhbGwgaWYgCiAgIGF2YWlsYWJsZSwgYnV0IG90 aGVyd2lzZSBhY2NlcHQgYSBsb3dlciBwcmVmZXJyZWQgbGFuZ3VhZ2UgYW5kIAogICBtb2Rh bGl0eSBjb21iaW5hdGlvbiBpZiB0aGF0IGlzIGF2YWlsYWJsZS4gV2hlbiBzYXRpc2Z5aW5n IGxhbmd1YWdlcwogICBhbmQgbW9kYWxpdGllcyBpbiB0aGUgb2ZmZXIgaXMgcmVnYXJkZWQg dG8gYmUgc28gaW1wb3J0YW50IHRoYXQgdGhlIAogICB3aG9sZSBjYWxsIFNIT1VMRCBiZSBy ZWplY3RlZCBpZiBubyBtYXRjaCBjYW4gYmUgcHJvdmlkZWQgaW4gdGhlIAogICBzZXNzaW9u IGluIG9uZSBvciBib3RoIGRpcmVjdGlvbnMsIHRoZW4gdGhlIGFzdGVyaXNrIHNoYWxsIG5v dCBiZSAKICAgYXBwZW5kZWQgb24gYW55IGluZGljYXRlZCBsYW5ndWFnZSBpbiB0aGUgd2hv bGUgc2Vzc2lvbiBkZXNjcmlwdGlvbi4KICAgRm9yIHRoZSBjYXNlIHdoZW4gbm8gc3BlY2lm aWMgcHJlZmVyZW5jZSBpcyBkZXNpcmVkLCBidXQgdGhlIG9mZmVyaW5nCiAgIHBhcnR5IGRv ZXMgbm90IHdhbnQgdGhlIGNhbGwgdG8gYmUgcmVqZWN0ZWQsIGFsbCBpbmRpY2F0ZWQgbGFu Z3VhZ2VzIAogICBhbmQgbW9kYWxpdGllcyBTSE9VTEQgaGF2ZSBhbiBhc3RlcmlzayBhcHBl bmRlZC4KCiAgIEluIGFuIGFuc3dlciwgdGhlIGxhbmd1YWdlKHMpIGFuZCBtb2RhbGl0eShp ZXMpIHRoYXQgdGhlIGFuc3dlcmluZyAKICAgcGFydHkgd2lsbCB1c2UgaW5pdGlhbGx5IGlu IHRoZSBhbnN3ZXIgU0hPVUxEIGJlIGluZGljYXRlZCB3aXRob3V0IAogICBhbiBhcHBlbmRl ZCBhc3Rlcmlzay4gQW55IGxhbmd1YWdlIGFuZCBtb2RhbGl0eSBhdmFpbGFibGUgZm9yIGxh dGVyIAogICB1c2UgaW4gdGhlIHNlc3Npb24gTUFZIGJlIGluZGljYXRlZCBieSBhIGxhbmd1 YWdlIHRhZyB3aXRoIGFuIAogICBhcHBlbmRlZCBhc3Rlcmlzay4KICAgCiAgIEluIHRoZSBj YXNlIHdoZW4gbW9yZSB0aGFuIHR3byBwYXJ0aWVzIHBhcnRpY2lwYXRlIGluIHRoZSBjYWxs LCAKICAgdGhlIGxhbmd1YWdlIGFuZCBtb2RhbGl0eSBpbmRpY2F0aW9ucyBwcm92aWRlZCB0 byBlYWNoIHBhcnR5IAogICBTSE9VTEQgYmUgdGhlIHN1bSBvZiB0aGUgaW5kaWNhdGlvbnMg ZnJvbSB0aGUgb3RoZXIgcGFydGllcy4KICAgCiAgIFRoZSB1c2Ugb2YgdGhlIHByZWZlcmVu Y2UgaW5kaWNhdG9yIGFzIHNwZWNpZmllZCBhYm92ZSBkb2VzIAogICBub3QgcHJvdmlkZSBm b3IgZGlzdGluZ3Vpc2hpbmcgYmV0d2VlbiB0aGUgY2FzZSB3aGVuIHR3byBvciAKICAgbW9y ZSBsYW5ndWFnZS9tb2RhbGl0eSBjb21iaW5hdGlvbnMgaW4gdGhlIHNhbWUgZGlyZWN0aW9u IAogICBhcmUgZGVzaXJlZCBmb3IgdXNlIHNpbXVsdGFuZW91c2x5IHZlcnN1cyB0aGUgY2Fz ZSB3aGVuIHR3bwogICBvciBtb3JlIGxhbmd1YWdlL21vZGFsaXR5IGNvbWJpbmF0aW9ucyBm b3IgdGhlIHNhbWUgZGlyZWN0aW9ucyAKICAgYXJlIHByb3ZpZGVkIGFzIHNlbGVjdGFibGUg YWx0ZXJuYXRpdmVzIHdpdGhvdXQgc3BlY2lmaWMgCiAgIHByZWZlcmVuY2UgZGlmZmVyZW50 aWF0aW9uLiBUaGUgY29udGV4dCBvciBvdGhlciBzcGVjaWZpY2F0aW9ucyAKICAgbWF5IGlu dHJvZHVjZSB0aGUgcG9zc2liaWxpdHkgdG8gZGlzdGluZ3Vpc2ggYmV0d2VlbiB0aGVzZSBj YXNlcy4gCiAgIFdoZW4gYSBwYXJ0eSBpbiBhIGNhbGwgaGFzIG5vIGluZGljYXRpb25zIHRo YXQgdHdvIG9yIG1vcmUgCiAgIGxhbmd1YWdlL21vZGFsaXR5IGNvbWJpbmF0aW9ucyBmb3Ig ZWFjaCBkaXJlY3Rpb24gYXJlIGRlc2lyZWQgCiAgIHNpbXVsdGFlb3VzbHkgaW4gdGhlIGNh bGwsIHRoZSBwYXJ0eSBTSE9VTEQgYXNzdW1lIHRoYXQgCiAgIHNhdGlzZnlpbmcgb25lIGlz IHN1ZmZpY2llbnQuCiAgIAogICBPdGhlciBzcGVjaWZpY2F0aW9ucyBtYXkgYWRkIG90aGVy IGF0dHJpYnV0ZSB2YWx1ZSBtb2RpZmllcnMgdGhhbgogICB0aGUgYXN0ZXJpc2suIElmIGFu IHVua25vd24gbW9kaWZpZXIgaXMgZGV0ZWN0ZWQsIHRoZSBtb2RpZmllcgogICBTSEFMTCBi ZSBpZ25vcmVkLgogICAKNS40LiAgVW51c3VhbCBpbmRpY2F0aW9ucwoKCiAgIEl0IGlzIHBv c3NpYmxlIHRvIHNwZWNpZnkgYW4gdW51c3VhbCBpbmRpY2F0aW9ubiB3aGVyZSB0aGUgbGFu Z3VhZ2UKICAgc3BlY2lmaWVkIGRvZXMgbm90IG1ha2Ugc2Vuc2UgZm9yIHRoZSBtZWRpYSB0 eXBlLCBzdWNoIGFzIHNwZWNpZnlpbmcKICAgYSBzaWduZWQgbGFuZ3VhZ2UgZm9yIGFuIGF1 ZGlvIG1lZGlhIHN0cmVhbS4KCiAgIEFuIG9mZmVyIE1VU1QgTk9UIGJlIGNyZWF0ZWQgd2hl cmUgdGhlIGxhbmd1YWdlIGRvZXMgbm90IG1ha2Ugc2Vuc2UKICAgZm9yIHRoZSBtZWRpYSB0 eXBlLiAgSWYgc3VjaCBhbiBvZmZlciBpcyByZWNlaXZlZCwgdGhlIHJlY2VpdmVyIFNIT1VM RCAKICAgaWdub3JlIHRoZSBsYW5ndWFnZSBzcGVjaWZpZWQuCgogICBIb3dldmVyLCB0aGVy ZSBhcmUgaW5kaWNhdGlvbnMgd2hpY2ggbG9vayBpbGxvZ2ljYWwsIGJ1dCBjYW4gYmUKICAg YXNzaWduZWQgdmFsaWQgaW50ZXJwcmV0YXRpb25zLgogICAKICAgQSBzcG9rZW4gbGFuZ3Vh Z2UgdGFnIGZvciBhIHZpZGVvIHN0cmVhbSBpbiBjb25qdW5jdGlvbiB3aXRoIGFuIGF1ZGlv CiAgIHN0cmVhbSB3aXRoIHRoZSBzYW1lIGxhbmd1YWdlIGluZGljYXRlcyBhIHJlcXVlc3Qg Zm9yCiAgIHN1cHBsZW1lbnRhbCB2aWRlbyB0byBzZWUgdGhlIHNwZWFrZXIuCiAgIAogICBU aGVyZSBpcyBubyBkaWZmZXJlbmNlIGJldHdlZW4gbGFuZ3VhZ2UgdGFncyBmb3Igc3Bva2Vu IGFuZCB3cml0dGVuIAogICBsYW5ndWFnZXMuIFRoZSBzcG9rZW4gb3Igd3JpdHRlbiBsYW5n dWFnZSB0YWcgaW5kaWNhdGVkIGZvciBhIHZpZGVvCiAgIHN0cmVhbSBjb3VsZCB0aGVyZWZv cmUgYmUgaW50ZXJwcmV0ZWQgYXMgYSBjYXBhYmlsaXR5IG9yIHJlcXVlc3QgdG8KICAgdXNl IHRleHQgY2FwdGlvbnMgb3ZlcmxheWVkIG9uIHRoZSB2aWRlbyBzdHJlYW0uIFRoZSBpbnRl cnByZXRhdGlvbiAKICAgYWNjb3JkaW5nIHRvIHRoaXMgc3BlY2lmaWNhdGlvbiBTSEFMTCBo b3dldmVyIGJlIHRvIGhhdmUgYSB2aWV3IG9mIAogICB0aGUgc3BlYWtlci4gCiAgIAoKCgoK CgoKCkdlbGxlbnMgICAgICAgICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCA2LCAyMDE3ICAg ICAgICAgICAgICAgICBbUGFnZSA4XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgTmVnb3Rp YXRpbmcgSHVtYW4gTGFuZ3VhZ2UgICAgICAgICAgRmVicnVhcnkgMjAxNwoKCjUuNS4gIEV4 YW1wbGVzCgogICBTb21lIGluZm9ybWF0aXZlIGV4YW1wbGVzIGFyZSBzaG93biBiZWxvdy4g IE9ubHkgdGhlIG1vc3QgZGlyZWN0bHkgCiAgIHJlbGV2YW50IHBvcnRpb25zIG9mIHRoZSBT RFAgYmxvY2sgYXJlIHNob3duLCBmb3IgY2xhcml0eS4KCjUuNS4xIFByZWZlcmVuY2UgZm9y IGEgc3Bva2VuIGxhbmd1YWdlIGFuZCBkZXNpcmUgdG8gZmFpbCB0aGUgY2FsbCBpZiBub3Qg bWV0CgogICBBIGNhbGxpbmcgdXNlciBkb2VzIG9ubHkgd2FudCB0byB1c2Ugc3Bva2VuIFJ1 c3NpYW4gYW5kIHdhbnQgdGhlIGNhbGwgdG8KICAgYmUgcmVqZWN0ZWQgaWYgdGhpcyBwcmVm ZXJlbmNlIGlzIG5vdCBtZXQuIFZpZGVvIGlzIGFsc28gaW5jbHVkZWQgaW4gCiAgIHRoZSBv ZmZlciBidXQgbm90IGZvciBsYW5ndWFnZSBjb21tdW5pY2F0aW9uIHB1cnBvc2UuCgogICAg ICBtPWF1ZGlvIDQ5MTcwIFJUUC9BVlAgMAogICAgICBhPWh1bWludGxhbmctc2VuZDpydQog ICAgICBhPWh1bWludGxhbmctcmVjdjpydQoKICAgICAgbT12aWRlbyA1MTM3MiBSVFAvQVZQ IDM0CgogICBUaGUgZGVzaXJlIHRvIGdldCB0aGUgY2FsbCByZWplY3RlZCBpZiB0aGUgbGFu Z3VhZ2UgcHJlZmVyZW5jZXMgYXJlIAogICBub3QgbWV0IGlzIGluZGljYXRlZCBieSBub3Qg YXBwZW5kaW5nIGFueSBhc3RlcmlzayBvbiBhbnkgb2YgdGhlIAogICBodW1pbnRsYW5nIGF0 dHJpYnV0ZXMuIFRoZSBhbnN3ZXJpbmcgcGFydHkgaGFzIGNhcGFiaWxpdHkgaW4gc3Bva2Vu IAogICBSdXNzaWFuLCBidXQgbm8gdmlkZW8gY2FwYWJpbGl0eSBpbiB0aGUgVUUsIHNvIHRo ZSBhbnN3ZXIgCiAgIHdpbGwgY29udGFpbiB0aGUgZm9sbG93aW5nOgoKICAgICAgbT1hdWRp byA1NDAwMCBSVFAvQVZQIDAKICAgICAgYT1odW1pbnRsYW5nLXNlbmQ6cnUKICAgICAgYT1o dW1pbnRsYW5nLXJlY3Y6cnUKCiAgICAgIG09dmlkZW8gMCBSVFAvQVZQIDM0CgkgIAogICAK CjUuNS4yIFByZWZlcmVuY2UgZm9yIHNwb2tlbiBsYW5ndWFnZSBhbmQgY2FwYWJpbGl0eSBp biBzaWduIGxhbmd1YWdlCgogICBUaGlzIFNEUCBzaG93cyBwcmVmZXJlbmNlIGZvciBzcG9r ZW4gRW5nbGlzaCBib3RoIHdheXMuIFRoZSB1c2VyIAogICBhbHNvIGhhcyBrbm93bGVkZ2Ug aW4gQW1lcmljYW4gc2lnbiBsYW5ndWFnZSBidXQgYnkgaW5kaWNhdGlvbiBvZiAKICAgdGhl IGFzdGVyaXNrcyBvbiB0aGVzZSBhdHRyaWJ1dGUgdmFsdWVzLCB0aGUgdXNlciBkb2VzIG5v dCBwcmVmZXIgCiAgIHRoYXQgbW9kYWxpdHkuIFRleHQgaXMgaW5jbHVkZWQgaW4gdGhlIG9m ZmVyIGJ1dCB3aXRoIG5vIGluZGljYXRpb24KICAgdG8gYmUgdXNlZCBwcmltYXJpbHkgZm9y IGluaXRpYWwgbGFuZ3VhZ2UgZXhjaGFuZ2UuIAogICBUaGUgY2FsbCBpcyBhbHNvIHJlcXVl c3RlZCB0byBub3QgYmUgcmVqZWN0ZWQgZXZlbiBpZiBub25lIG9mIHRoZSAKICAgaW5kaWNh dGVkIGxhbmd1YWdlcyBjYW4gYmUgcHJvdmlkZWQuCgoKCiAgICAgIG09YXVkaW8gNDkxNzAg UlRQL0FWUCAwCiAgICAgIGE9aHVtaW50bGFuZy1zZW5kOmVuCiAgICAgIGE9aHVtaW50bGFu Zy1yZWN2OmVuCgogICAgICBtPXZpZGVvIDUxMzcyIFJUUC9BVlAgMzEgMzIKICAgICAgYT1o dW1pbnRsYW5nLXNlbmQ6YXNlKgogICAgICBhPWh1bWludGxhbmctcmVjdjphc2UqCgoJICBt PXRleHQgNDU2NzAgUlRQL0FWUCAxMDAgMTAyCgo1LjUuMyBQcmVmZXJlbmNlIGZvciBzcG9r ZW4gYW5kIGNhcGFiaWxpdHkgZm9yIHdyaXR0ZW4gbGFuZ3VhZ2VzCSAgCgogICBUaGlzIG9m ZmVyIHNob3dzIHByZWZlcmVuY2UgZm9yIHNwb2tlbiBTcGFuaXNoIGFuZCBCYXNxdWUgaW4g dGhpcyAKICAgb3JkZXIsIGFuZCBhdCBsb3dlciBwcmVmZXJlbmNlIGEgY2FwYWJpbGl0eSBm b3Igd3JpdHRlbiBTcGFuaXNoLCAKICAgQmFzcXVlIGFuZCBhbHNvIEVuZ2xpc2guIFZpZGVv IGlzIGluY2x1ZGUgd2l0aG91dCBhbnkgaW5kaWNhdGlvbiAKICAgb2YgdXNlIGZvciBsYW5n dWFnZSBjb21tdW5pY2F0aW9uIHB1cnBvc2VzLgogICBUaGUgY2FsbCBpcyBhbHNvIHJlcXVl c3RlZCB0byBub3QgYmUgcmVqZWN0ZWQgZXZlbiBpZiBub25lIG9mIAogICB0aGVzZSBsYW5n dWFnZXMgY2FuIGJlIHByb3ZpZGVkLgoJICAKICAgICAgbT1hdWRpbyA0OTI1MCBSVFAvQVZQ IDIwCiAgICAgIGE9aHVtaW50bGFuZy1zZW5kOmVzCiAgICAgIGE9aHVtaW50bGFuZy1yZWN2 OmVzCiAgICAgIGE9aHVtaW50bGFuZy1zZW5kOmV1CiAgICAgIGE9aHVtaW50bGFuZy1yZWN2 OmV1CgogICAgICBtPXRleHQgNDUwMjAgUlRQL0FWUCAxMDMgMTA0CiAgICAgIGE9aHVtaW50 bGFuZy1zZW5kOmVzKgogICAgICBhPWh1bWludGxhbmctcmVjdjplcyoKICAgICAgYT1odW1p bnRsYW5nLXNlbmQ6ZXUqCiAgICAgIGE9aHVtaW50bGFuZy1yZWN2OmV1KgogICAgICBhPWh1 bWludGxhbmctc2VuZDplbioKICAgICAgYT1odW1pbnRsYW5nLXJlY3Y6ZW4qCgkgIAoJICBt PXZpZGVvIDU0MzMyIFJUUC9BVlAgMzIgOTYKCSAgCiAgIEEgY29ycmVzcG9uZGluZyBhbnN3 ZXIgY2FuIGluZGljYXRlIHRoYXQgdGhlIGFuc3dlcmluZyBwYXJ0eSAKICAgaXMgb25seSBj YXBhYmxlIHRvIG1ha2UgdGhlIGNhbGwgaW4gd3JpdHRlbiBFbmdsaXNoLgogICBUaGUgb3Ro ZXIgbWVkaWEgYXJlIGFjY2VwdGVkIGJ1dCBub3QgaW50ZW5kZWQgdG8gYmUgdXNlZCBmb3Ig CiAgIGFueSBkb21pbmF0aW5nIGxhbmd1YWdlIGNvbW11bmljYXRpb24uCgoJICBtPWF1ZGlv IDYwMDAwIFJUUC9BVlAgMjAJCgkgIAogICAgICBtPXRleHQgNDUwNDAgUlRQL0FWUCAxMDMg MTA0CiAgICAgIGE9aHVtaW50bGFuZy1yZWN2OmVuCiAgICAgIGE9aHVtaW50bGFuZy1zZW5k OmVuCSAKCgkgIG09dmlkZW8gNTYwMDAgUlRQL0FWUCAgOTYJICAKCgkgIAo1LjUuNCBQcmVm ZXJlbmNlIGZvciBzcGVha2luZyBhbmQgcmVjZWl2aW5nIHRleHQKCiAgIEluIHRoaXMgZXhh bXBsZSBhIEZyZW5jaCB1c2VyIHdpdGggaGVhcmluZyBsb3NzIHByZWZlcnMgdG8gc3BlYWsg CiAgIGFuZCBwcmVmZXJzIHRvIHJlY2VpdmUgcmVhbC10aW1lIHRleHQuIFRoZSB1c2VyIGFs c28gYmVuZWZpdHMgCiAgIGZyb20gcmVjZWl2aW5nIHNwb2tlbiBGcmVuY2gsIGJ1dCBkb2Vz IG5vdCBoYW5kbGUgYSBjb252ZXJzYXRpb24KICAgaW4ganVzdCBzcG9rZW4gRnJlbmNoIHdl bGwuIFRoZSB1c2VyIGFsc28gZG9lcyBub3QgZmVlbCByYXBpZCAKICAgZW5vdWdoIG9uIHRo ZSBrZXlib2FyZCwgc28gc2VuZGluZyB0ZXh0IGlzIG5vdCBhbiBhbHRlcm5hdGl2ZS4KICAg CiAgIFRoZSBjYWxsaW5nIHVzZXIgd291bGQgbGlrZSB0byBpbmRpY2F0ZSB0aGF0IHRoZXJl IGlzIHZhbHVlIHRvIAogICByZWNlaXZlIHNwb2tlbiBGcmVuY2ggdG9nZXRoZXIgd2l0aCB0 aGUgcmVjaWV2ZWQgdGV4dC4gVGhlIAogICBjdXJyZW50IHNwZWNpZmljYXRpb24gaGFzIG5v IHdheSB0byBpbmRpY2F0ZSB0aGF0IHByZWZlcmVuY2UsIAogICBzbyBvbmx5IHRoZSBsb3dl ciBwcmVmZXJlbmNlIGZvciByZWNlaXZlZCBzcG9rZW4gRnJlbmNoIGFzIGFuIAogICBhbHRl cm5hdGl2ZSBpcyBpbmRpY2F0ZWQuIAogICBUaGUgY2FsbGluZyB1c2VyIHdhbnQgdGhlIGNh bGwgdG8gZ28gdGhyb3VnaCBldmVuIGlmIHRoZSAKICAgbGFuZ3VhZ2VzIGRvIG5vdCBtYXRj aC4gVGhpcyBpcyBpbmRpY2F0ZWQgYnkgdGhlIGFzdGVyaXNrIAogICBhcHBlbmRlZCBvbiB0 aGUgbG93ZXIgcHJlZmVyZW5jZSBhdHRyaWJ1dGUgZm9yIHJlY2VpdmVkIEZyZW5jaC4gCgog ICBXaGVuIGNhbGxpbmcsIHRoZSBvZmZlciBtYXkgYmU6CgogICAgICBtPWF1ZGlvIDQ5MjUw IFJUUC9BVlAgMjAKICAgICAgYT1odW1pbnRsYW5nLXNlbmQ6ZnIKICAgICAgYT1odW1pbnRs YW5nLXJlY3Y6ZnIqCgogICAgICBtPXRleHQgNDUwMjAgUlRQL0FWUCAxMDMgMTA0CiAgICAg IGE9aHVtaW50bGFuZy1yZWN2OmZyCgogCiAgIFRoZSBhbnN3ZXJpbmcgcGFydHkgZGV0ZWN0 cyB0aGUgdHdvIHByZWZlcnJlZCBhdHRyaWJ1dGVzIHdpdGhvdXQKICAgYW4gYXN0ZXJpc2sg dG8gYmUgdGhlIG1haW4gcHJlZmVycmVkIGxhbmd1YWdlcyBmb3IgdGhlIGNvbnZlcnNhdGlv biwKICAgYW5kIGhhcyBjYXBhYmlsaXR5IGZvciB0aGlzIGNvbWJpbmF0aW9uLiBUaGUgYW5z d2VyIHdpbGwgYmU6CgogICAgICBtPWF1ZGlvIDQ5MzAwIFJUUC9BVlAgMjAKICAgICAgYT1o dW1pbnRsYW5nLXJlY3Y6ZnIKCiAgICAgIG09dGV4dCA0NTYwMCBSVFAvQVZQIDEwMyAxMDQK ICAgICAgYT1odW1pbnRsYW5nLXNlbmQ6ZnIJICAKCgogICBUaGUgc2FtZSB1c2VyIGlzIGN1 c3RvbWVyIG9mIGEgcmVsYXkgc2VydmljZSB0aGF0IGNhbiBiZSBpbnZva2VkIGlmIAogICB0 aGUgYW5zd2VyIGRvZXMgbm90IHNhdGlzZnkgdGhlIGhpZ2hlc3QgcHJlZmVyZW5jZSBvZiB0 aGUgY2FsbGluZyB1c2VyLiAKICAgSW4gYW5vdGhlciBjYWxsIHN0YXJ0aW5nIHdpdGggdGhl IHNhbWUgb2ZmZXIsIHRoZSBpbml0aWFsIGFuc3dlciBtYXkgCiAgIGJlIGZyb20gYSB1c2Vy IHdobyBoYXMgbm8gdGV4dCBjYXBhYmlsaXRpZXMuIEluc3RlYWQgdGhlIGFuc3dlcmluZyAK ICAgcGFydHkgZGV0ZWN0cyB0aGF0IGFuc3dlcmluZyB3aXRoIHNwb2tlbiBGcmVuY2ggaXMg YW4gb3B0aW9uIGV2ZW4gCiAgIGlmIGl0IGlzIGxlc3MgcHJlZmVycmVkLiBUaGUgYW5zd2Vy IGluIHRoaXMgY2FzZSBpbmRpY2F0ZXMgc3Bva2VuIAogICBGcmVuY2ggaW4gYm90aCBkaXJl Y3Rpb25zLgoKICAgICAgbT1hdWRpbyA0OTMwMCBSVFAvQVZQIDIwCiAgICAgIGE9aHVtaW50 bGFuZy1yZWN2OmZyCgkgIGE9aHVtaW50bGFuZy1zZW5kOmZyCgogICAgICBtPXRleHQgMCBS VFAvQVZQIDEwMyAxMDQKCiAgIFRoZSBhbnN3ZXIgaXMgYW5hbHl6ZWQgYnkgdGhlIGNhbGxp bmcgdXNlcidzIFVFIGFuZCB0aGUgbGFjayAKICAgb2YgdGhlIHByZWZlcnJlZCByZWNlaXZl ZCBGcmVuY2ggdGV4dCBpcyBkZXRlY3RlZC4gVGhlIFVFIAogICBpbnZva2VzIHRoZSByZWxh eSBzZXJ2aWNlIGFzIGEgdGhpcmQgcGFydHkgaW4gdGhlIGNhbGwsIGluIG9yZGVyIAogICB0 byBnZXQgdGhlIHNwb2tlbiBGcmVuY2ggZnJvbSB0aGUgY2FsbGVkIHVzZXIgdG8gYmUgdHJh bnNsYXRlZCB0byAKICAgRnJlbmNoIHRleHQuIFRoZSBzcG9rZW4gRnJlbmNoIGZyb20gdGhl IGFuc3dlcmluZyBwYXJ0eSB3aWxsIGJlIAogICBkZWxpdmVyZWQgdG8gYm90aCB0aGUgY2Fs bGluZyB1c2VyIGFuZCB0aGUgcmVsYXkgc2VydmljZS4gVGhlIAogICBpbnZvY2F0aW9uIG9m IHRoZSByZWxheSBzZXJ2aWNlIGlzIGEgc2VwYXJhdGUgYXBwbGljYXRpb24gYWN0aW9uIAog ICBhbmQgdGhlIHNpZ25hbGluZyBub3QgaW5jbHVkZWQgaGVyZS4gCgkgIAoJCgo2LiAgSUFO QSBDb25zaWRlcmF0aW9ucwoKICAgSUFOQSBpcyBraW5kbHkgcmVxdWVzdGVkIHRvIGFkZCB0 d28gZW50cmllcyB0byB0aGUgJ2F0dC1maWVsZCAobWVkaWEKICAgbGV2ZWwgb25seSknIHRh YmxlIG9mIHRoZSBTRFAgcGFyYW1ldGVycyByZWdpc3RyeToKCiAgIENvbnRhY3QgTmFtZTog IFJhbmRhbGwgR2VsbGVucwogICBDb250YWN0IEVtYWlsIEFkZHJlc3M6ICByZytpZXRmQHJh bmR5LnBlbnNpdmUub3JnCiAgIEF0dHJpYnV0ZSBOYW1lOiAgaHVtaW50bGFuZy1yZWN2CiAg IEF0dHJpYnV0ZSBTeW50YXg6CgogICAgICBodW1pbnRsYW5nLXZhbHVlID0gIExhbmd1YWdl LVRhZyBbIGFzdGVyaXNrIF0KICAgICAgICAgICAgICAgICAgICAgICAgICA7IExhbmd1YWdl LVRhZyBkZWZpbmVkIGluIFJGQyA1NjQ2CgkgIGFzdGVyaXNrICAgICAgICAgPSAgIioiCgog ICBBdHRyaWJ1dGUgU2VtYW50aWNzOiAgRGVzY3JpYmVkIGluIFNlY3Rpb24gNS4yLTUuMyBv ZiBUQkQ6IFRISVMgRE9DVU1FTlQKICAgVXNhZ2UgTGV2ZWw6ICBtZWRpYSwgZGNzYShzdWJw cm90b2NvbCkKICAgQ2hhcnNldCBEZXBlbmRlbnQ6ICBObwogICBQdXJwb3NlOiAgU2VlIFNl Y3Rpb24gNS4yLTUuMyBvZiBUQkQ6IFRISVMgRE9DVU1FTlQKICAgTXV4IENhdGVnb3J5OiBO T1JNQUwKICAgTy9BIFByb2NlZHVyZXM6ICBTZWUgU2VjdGlvbiA1LjItNS4zIG9mIFRCRDog VEhJUyBET0NVTUVOVAogICBSZWZlcmVuY2U6ICBUQkQ6IFRISVMgRE9DVU1FTlQKCiAgIENv bnRhY3QgTmFtZTogIFJhbmRhbGwgR2VsbGVucwogICBDb250YWN0IEVtYWlsIEFkZHJlc3M6 ICByZytpZXRmQHJhbmR5LnBlbnNpdmUub3JnCgoKCkdlbGxlbnMgICAgICAgICAgICAgICAg ICBFeHBpcmVzIEF1Z3VzdCA2LCAyMDE3ICAgICAgICAgICAgICAgICBbUGFnZSA5XQoMCklu dGVybmV0LURyYWZ0ICAgICAgICAgTmVnb3RpYXRpbmcgSHVtYW4gTGFuZ3VhZ2UgICAgICAg ICAgRmVicnVhcnkgMjAxNwoKCiAgIEF0dHJpYnV0ZSBOYW1lOiAgaHVtaW50bGFuZy1zZW5k CiAgIEF0dHJpYnV0ZSBTeW50YXg6CgogICAgICBodW1pbnRsYW5nLXZhbHVlID0gIExhbmd1 YWdlLVRhZyBbIGFzdGVyaXNrIF0KICAgICAgICAgICAgICAgICAgICAgICAgICA7IExhbmd1 YWdlLVRhZyBkZWZpbmVkIGluIFJGQyA1NjQ2CgkgIGFzdGVyaXNrICAgICAgICAgPSAgIioi CgogICBBdHRyaWJ1dGUgU2VtYW50aWNzOiAgRGVzY3JpYmVkIGluIFNlY3Rpb24gNS4yLTUu MyBvZiBUQkQ6IFRISVMgRE9DVU1FTlQKICAgVXNhZ2UgTGV2ZWw6ICBtZWRpYSwgZGNzYShz dWJwcm90b2NvbCkKICAgQ2hhcnNldCBEZXBlbmRlbnQ6ICBObwogICBQdXJwb3NlOiAgU2Vl IFNlY3Rpb24gNS4yLTUuMyBvZiBUQkQ6IFRISVMgRE9DVU1FTlQKICAgTXV4IENhdGVnb3J5 OiBOT1JNQUwKICAgTy9BIFByb2NlZHVyZXM6ICBTZWUgU2VjdGlvbiA1LjItNS4zIG9mIFRC RDogVEhJUyBET0NVTUVOVAogICBSZWZlcmVuY2U6ICBUQkQ6IFRISVMgRE9DVU1FTlQKCjcu ICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucwoKICAgVGhlIFNlY3VyaXR5IENvbnNpZGVyYXRp b25zIG9mIEJDUCA0NyBbUkZDNTY0Nl0gYXBwbHkgaGVyZS4gIEluCiAgIGFkZGl0aW9uLCBp ZiB0aGUgJ2h1bWludGxhbmctc2VuZCcgb3IgJ2h1bWludGxhbmctcmVjdicgdmFsdWVzIGFy ZQogICBhbHRlcmVkIG9yIGRlbGV0ZWQgZW4gcm91dGUsIHRoZSBzZXNzaW9uIGNvdWxkIGZh aWwgb3IgbGFuZ3VhZ2VzCiAgIGluY29tcHJlaGVuc2libGUgdG8gdGhlIGNhbGxlciBjb3Vs ZCBiZSBzZWxlY3RlZDsgaG93ZXZlciwgdGhpcyBpcwogICBhbHNvIGEgcmlzayBpZiBhbnkg U0RQIHBhcmFtZXRlcnMgYXJlIG1vZGlmaWVkIGVuIHJvdXRlLgoKOC4gIFByaXZhY3kgQ29u c2lkZXJhdGlvbnMKCiAgIExhbmd1YWdlIGFuZCBtZWRpYSBpbmZvcm1hdGlvbiBjYW4gc3Vn Z2VzdCBhIHVzZXIncyBuYXRpb25hbGl0eSwKICAgYmFja2dyb3VuZCwgYWJpbGl0aWVzLCBk aXNhYmlsaXRpZXMsIGV0Yy4KCjkuICBDaGFuZ2VzIGZyb20gUHJldmlvdXMgVmVyc2lvbnMK CiAgIFJGQyBFRElUT1I6IFBsZWFzZSByZW1vdmUgdGhpcyBzZWN0aW9uIHByaW9yIHRvIHB1 YmxpY2F0aW9uLgoKOS4xLiAgQ2hhbmdlcyBmcm9tIGRyYWZ0LWlldGYtc2xpbS0uLi4tMDQg dG8gZHJhZnQtaWV0Zi1zbGltLS4uLi0wNgoKICAgbyAgRGVsZXRlZCBTZWN0aW9uIDMgKCJF eHBlY3RlZCBVc2UiKQogICBvICBSZXdvcmRlZCBtb2RhbGl0aWVzIGluIEludHJvZHVjdGlv biBmcm9tICJ2b2ljZSwgdmlkZW8sIHRleHQiIHRvCiAgICAgICJzcG9rZW4sIHNpZ25lZCwg d3JpdHRlbiIKICAgbyAgUmV3b3JkZWQgdGV4dCBhYm91dCAiaW5jcmVhc2luZ2x5IGZpbmUt Z3JhaW5lZCBkaXN0aW5jdGlvbnMiIHRvCiAgICAgIGluc3RlYWQgbWVyZWx5IHBvaW50IHRv IEJDUCA0NyBTZWN0aW9uIDQuMSdzIGFkdmljZSB0byAidGFnCiAgICAgIGNvbnRlbnQgd2lz ZWx5IiBhbmQgbm90IGluY2x1ZGUgdW5uZWNlc3Nhcnkgc3VidGFncwogICBvICBDaGFuZ2Vk IElBTkEgcmVnaXN0cmF0aW9uIG9mIG5ldyBTRFAgYXR0cmlidXRlcyB0byBmb2xsb3cgUkZD IDQ1NjYKICAgICAgdGVtcGxhdGUgd2l0aCBleHRyYSBmaWVsZHMgc3VnZ2VzdGVkIGluIDQ1 NjYtYmlzIChleHBpcmVkIGRyYWZ0KQogICBvICBEZWxldGVkICIoa25vd24gYXMgdm9pY2Ug Y2Fycnkgb3ZlcikiCiAgIG8gIENoYW5nZWQgdGV4dHVhbCBpbnN0YW5jZWQgb2YgUkZDIDU2 NDYgdG8gQkNQIDQ3LCBhbHRob3VnaCBhY3R1YWwKICAgICAgcmVmZXJlbmNlIHJlbWFpbnMg UkZDIGR1ZSB0byB4bWwycmZjIGxpbWl0YXRpb25zCgoKCgoKCgpHZWxsZW5zICAgICAgICAg ICAgICAgICAgRXhwaXJlcyBBdWd1c3QgNiwgMjAxNyAgICAgICAgICAgICAgICBbUGFnZSAx MF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgIE5lZ290aWF0aW5nIEh1bWFuIExhbmd1YWdl ICAgICAgICAgIEZlYnJ1YXJ5IDIwMTcKCgo5LjIuICBDaGFuZ2VzIGZyb20gZHJhZnQtaWV0 Zi1zbGltLS4uLi0wMiB0byBkcmFmdC1pZXRmLXNsaW0tLi4uLTAzCgogICBvICBBZGRlZCBF eGFtcGxlcwogICBvICBBZGRlZCBQcml2YWN5IENvbnNpZGVyYXRpb25zIHNlY3Rpb24KICAg byAgT3RoZXIgZWRpdG9yaWFsIGNoYW5nZXMgZm9yIGNsYXJpdHkKCjkuMy4gIENoYW5nZXMg ZnJvbSBkcmFmdC1pZXRmLXNsaW0tLi4uLTAxIHRvIGRyYWZ0LWlldGYtc2xpbS0uLi4tMDIK CiAgIG8gIERlbGV0ZWQgbW9zdCBvZiBTZWN0aW9uIDQgYW5kIHJlcGxhY2VkIHdpdGggYSB2 ZXJ5IHNob3J0IHN1bW1hcnkKICAgbyAgUmVwbGFjZWQgIndpc2hlcyB0byIgd2l0aCAiaXMg d2lsbGluZyB0byIgaW4gU2VjdGlvbiA1LjIKICAgbyAgUmV3b3JkZWQgZGVzY3JpcHRpb24g b2YgYXR0cmlidXRlIHVzYWdlIHRvIGNsYXJpZnkgd2hlbiB0byBzZXQKICAgICAgYm90aCwg b25seSBvbmUsIG9yIG5laXRoZXIKICAgbyAgRGVsZXRlZCBhbGwgdXNlcyBvZiAiSU1TIgog ICBvICBPdGhlciBlZGl0b3JpYWwgY2hhbmdlcyBmb3IgY2xhcml0eQoKOS40LiAgQ2hhbmdl cyBmcm9tIGRyYWZ0LWlldGYtc2xpbS0uLi4tMDAgdG8gZHJhZnQtaWV0Zi1zbGltLS4uLi0w MQoKICAgbyAgRWRpdG9yaWFsIGNoYW5nZXMgdG8gd29yZGluZyBpbiBTZWN0aW9uIDUuCgo5 LjUuICBDaGFuZ2VzIGZyb20gZHJhZnQtZ2VsbGVucy1zbGltLS4uLi0wMyB0byBkcmFmdC1p ZXRmLXNsaW0tLi4uLTAwCgogICBvICBVcGRhdGVkIHRpdGxlIHRvIHJlZmxlY3QgV0cgYWRv cHRpb24KCjkuNi4gIENoYW5nZXMgZnJvbSBkcmFmdC1nZWxsZW5zLXNsaW0tLi4uLTAyIHRv IGRyYWZ0LWdlbGxlbnMtCiAgICAgIHNsaW0tLi4uLTAzCgogICBvICBSZW1vdmVkIFVzZSBD YXNlcyBzZWN0aW9uLCBwZXIgZmFjZS10by1mYWNlIGRpc2N1c3Npb24gYXQgSUVURiA5Mwog ICBvICBSZW1vdmVkIGRpc2N1c3Npb24gb2Ygcm91dGluZywgcGVyIGZhY2UtdG8tZmFjZSBk aXNjdXNzaW9uIGF0IElFVEYKICAgICAgOTMKCjkuNy4gIENoYW5nZXMgZnJvbSBkcmFmdC1n ZWxsZW5zLXNsaW0tLi4uLTAxIHRvIGRyYWZ0LWdlbGxlbnMtCiAgICAgIHNsaW0tLi4uLTAy CgogICBvICBVcGRhdGVkIE5FTkEgdXNhZ2UgbWVudGlvbgogICBvICBSZW1vdmVkIGJhY2tn cm91bmQgdGV4dCByZWZlcmVuY2UgdG8gZHJhZnQtc2FpbnRhbmRyZS1zaXAteG1wcC0KICAg ICAgY2hhdC0wNCBzaW5jZSB0aGF0IGRyYWZ0IGV4cGlyZWQKCjkuOC4gIENoYW5nZXMgZnJv bSBkcmFmdC1nZWxsZW5zLXNsaW0tLi4uLTAwIHRvIGRyYWZ0LWdlbGxlbnMtCiAgICAgIHNs aW0tLi4uLTAxCgogICBvICBSZXZpc2lvbiB0byBrZWVwIGRyYWZ0IGZyb20gZXhwaXJpbmcK CjkuOS4gIENoYW5nZXMgZnJvbSBkcmFmdC1nZWxsZW5zLW1tdXNpYy0uLi4tMDIgdG8gZHJh ZnQtZ2VsbGVucy0KICAgICAgc2xpbS0uLi4tMDAKCiAgIG8gIENoYW5nZWQgbmFtZSBmcm9t IC1tbXVzaWMtIHRvIC1zbGltLSB0byByZWZsZWN0IHByb3Bvc2VkIFdHIG5hbWUKICAgbyAg QXMgYSByZXN1bHQgb2YgdGhlIGZhY2UtdG8tZmFjZSBkaXNjdXNzaW9uIGluIFRvcm9udG8s IHRoZSBTRFAgdnMKICAgICAgU0lQIGlzc3VlIHdhcyByZXNvbHZlZCBieSBnb2luZyBiYWNr IHRvIFNEUCwgdGFraW5nIG91dCB0aGUgU0lQCgoKCkdlbGxlbnMgICAgICAgICAgICAgICAg ICBFeHBpcmVzIEF1Z3VzdCA2LCAyMDE3ICAgICAgICAgICAgICAgIFtQYWdlIDExXQoMCklu dGVybmV0LURyYWZ0ICAgICAgICAgTmVnb3RpYXRpbmcgSHVtYW4gTGFuZ3VhZ2UgICAgICAg ICAgRmVicnVhcnkgMjAxNwoKCiAgICAgIGhpbnQsIGFuZCBjb252ZXJ0aW5nIHdoYXQgaGFk IGJlZW4gYSBzZXQgb2YgYWx0ZXJuYXRlIHByb3Bvc2FscwogICAgICBmb3IgdmFyaW91cyB3 YXlzIG9mIGRvaW5nIGl0IHdpdGhpbiBTSVAgaW50byBhbiBpbmZvcm1hdGl2ZSBhbm5leAog ICAgICBzZWN0aW9uIHdoaWNoIGluY2x1ZGVzIGJhY2tncm91bmQgb24gd2h5IFNEUCBpcyB0 aGUgcHJvcG9zYWwKICAgbyAgQWRkZWQgbWVudGlvbiB0aGF0IGVuYWJsaW5nIGEgbXV0dWFs bHkgY29tcHJlaGVuc2libGUgbGFuZ3VhZ2UgaXMKICAgICAgYSBnZW5lcmFsIHByb2JsZW0g b2Ygd2hpY2ggdGhpcyBkb2N1bWVudCBhZGRyZXNzZXMgdGhlIHJlYWwtdGltZQogICAgICBz aWRlLCB3aXRoIHJlZmVyZW5jZSB0byBbSS1ELmlldGYtc2xpbS1tdWx0aWxhbmdjb250ZW50 XSB3aGljaAogICAgICBhZGRyZXNzZXMgdGhlIG5vbi1yZWFsLXRpbWUgc2lkZS4KCjkuMTAu ICBDaGFuZ2VzIGZyb20gZHJhZnQtZ2VsbGVucy1tbXVzaWMtLi4uLTAxIHRvIC0wMgoKICAg byAgQWRkZWQgY2xhcmlmeWluZyB0ZXh0IG9uIGxlYXZpbmcgYXR0cmlidXRlcyB1bnNldCBm b3IgbWVkaWEgbm90CiAgICAgIHByaW1hcmlseSBpbnRlbmRlZCBmb3IgaHVtYW4gbGFuZ3Vh Z2UgY29tbXVuaWNhdGlvbiAoZS5nLiwKICAgICAgYmFja2dyb3VuZCBhdWRpbyBvciB2aWRl bykuCiAgIG8gIEFkZGVkIG5ldyBzZWN0aW9uIEFwcGVuZGl4IEEgKCJBbHRlcm5hdGl2ZSBQ cm9wb3NhbDogQ2FsbGVyLQogICAgICBwcmVmcyIpIGRpc2N1c3NpbmcgdXNlIG9mIFNJUC1s ZXZlbCBDYWxsZXItcHJlZnMgaW5zdGVhZCBvZiBTRFAtCiAgICAgIGxldmVsLgoKOS4xMS4g IENoYW5nZXMgZnJvbSBkcmFmdC1nZWxsZW5zLW1tdXNpYy0uLi4tMDAgdG8gLTAxCgogICBv ICBSZWxheGVkIGxhbmd1YWdlIG9uIHNldHRpbmcgLXNlbmQgYW5kIC1yZWNlaXZlIHRvIHNh bWUgdmFsdWVzOwogICAgICBhZGRlZCB0ZXh0IG9uIGxlYXZpbmcgb24gZW1wdHkgdG8gaW5k aWNhdGUgYXN5bW1ldHJpYyB1c2FnZS4KICAgbyAgQWRkZWQgdGV4dCB0aGF0IGNsaWVudHMg b24gYmVoYWxmIG9mIGVuZCB1c2VycyBhcmUgZXhwZWN0ZWQgdG8gc2V0CiAgICAgIHRoZSBh dHRyaWJ1dGVzIG9uIG91dGdvaW5nIGNhbGxzIGFuZCBpZ25vcmUgb24gaW5jb21pbmcgY2Fs bHMKICAgICAgd2hpbGUgc3lzdGVtcyBvbiBiZWhhbGYgb2YgY2FsbCBjZW50ZXJzIGFuZCBQ U0FQcyBhcmUgZXhwZWN0ZWQgdG8KICAgICAgdGFrZSB0aGUgYXR0cmlidXRlcyBpbnRvIGFj Y291bnQgd2hlbiBwcm9jZXNzaW5nIGluY29taW5nIGNhbGxzLgoKOS4xMi4gIENoYW5nZXMg ZnJvbSBkcmFmdC1nZWxsZW5zLS4uLi0wMiB0byBkcmFmdC1nZWxsZW5zLW1tdXNpYy0uLi4t MDAKCiAgIG8gIFVwZGF0ZWQgdGV4dCB0byByZWZlciB0byBSRkMgNTY0NiByYXRoZXIgdGhh biB0aGUgSUFOQSBsYW5ndWFnZQogICAgICBzdWJ0YWdzIHJlZ2lzdHJ5IGRpcmVjdGx5Lgog ICBvICBNb3ZlZCBkaXNjdXNzaW9uIG9mIGV4aXN0aW5nICdsYW5nJyBhdHRyaWJ1dGUgb3V0 IG9mICJQcm9wb3NlZAogICAgICBTb2x1dGlvbiIgc2VjdGlvbiBhbmQgaW50byBvd24gc2Vj dGlvbiBub3cgdGhhdCBpdCBpcyBub3QgcGFydCBvZgogICAgICBwcm9wb3NhbC4KICAgbyAg VXBkYXRlZCB0ZXh0IGFib3V0IGV4aXN0aW5nICdsYW5nJyBhdHRyaWJ1dGUuCiAgIG8gIEFk ZGVkIGV4YW1wbGUgdXNlIGNhc2VzLgogICBvICBSZXBsYWNlZCBwcm9wb3NlZCBzaW5nbGUg J2h1bWludGxhbmcnIGF0dHJpYnV0ZSB3aXRoICdodW1pbnRsYW5nLQogICAgICBzZW5kJyBh bmQgJ2h1bWludGxhbmctcmVjdicgcGVyIEhhcmFsZCdzIHJlcXVlc3QvaW5mb3JtYXRpb24g dGhhdAogICAgICBpdCB3YXMgYSBtaXN1c2Ugb2YgU0RQIHRvIHVzZSB0aGUgc2FtZSBhdHRy aWJ1dGUgZm9yIHNlbmRpbmcgYW5kCiAgICAgIHJlY2VpdmluZy4KICAgbyAgQWRkZWQgc2Vj dGlvbiBkZXNjcmliaW5nIHVzYWdlIGJlaW5nIGFkdmlzb3J5IHZzIHJlcXVpcmVkIGFuZCB0 ZXh0CiAgICAgIGluIGF0dHJpYnV0ZSBzZWN0aW9uLgogICBvICBBZGRlZCBzZWN0aW9uIG9u IFNJUCAiaGludCIgaGVhZGVyIChub3QgeWV0IG5haWxlZCBkb3duIGJldHdlZW4KICAgICAg bmV3IGFuZCBleGlzdGluZyBoZWFkZXIpLgogICBvICBBZGRlZCB0ZXh0IGRpc2N1c3Npbmcg dXNhZ2UgaW4gcG9saWN5LWJhc2VkIHJvdXRpbmcgZnVuY3Rpb24gb3IKICAgICAgdXNlIG9m IFNJUCBoZWFkZXIgImhpbnQiIGlmIHVuYWJsZSB0byBkbyBzby4KICAgbyAgQWRkZWQgU0hP VUxEIHRoYXQgdGhlIHZhbHVlIG9mIHRoZSBwYXJhbWV0ZXJzIHN0aWNrIHRvIHRoZSBsYXJn ZXN0CiAgICAgIGdyYW51bGFyaXR5IG9mIGxhbmd1YWdlIHRhZ3MuCgoKCgpHZWxsZW5zICAg ICAgICAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgNiwgMjAxNyAgICAgICAgICAgICAgICBb UGFnZSAxMl0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgIE5lZ290aWF0aW5nIEh1bWFuIExh bmd1YWdlICAgICAgICAgIEZlYnJ1YXJ5IDIwMTcKCgogICBvICBBZGRlZCB0ZXh0IHRvIElu dHJvZHVjdGlvbiB0byBiZSB0cnkgYW5kIGJlIG1vcmUgY2xlYXIgYWJvdXQKICAgICAgcHVy cG9zZSBvZiBkb2N1bWVudCBhbmQgcHJvYmxlbSBiZWluZyBzb2x2ZWQuCiAgIG8gIE1hbnkg d29yZGluZyBpbXByb3ZlbWVudHMgYW5kIGNsYXJpZmljYXRpb25zIHRocm91Z2hvdXQgdGhl CiAgICAgIGRvY3VtZW50LgogICBvICBGaWxsZWQgaW4gU2VjdXJpdHkgQ29uc2lkZXJhdGlv bnMuCiAgIG8gIEZpbGxlZCBpbiBJQU5BIENvbnNpZGVyYXRpb25zLgogICBvICBBZGRlZCB0 byBBY2tub3dsZWRnbWVudHMgdGhvc2Ugd2hvIHBhcnRpY2lwYXRlZCBpbiB0aGUgT3JsYW5k byBhZC0KICAgICAgaG9jIGRpc2N1c3Npb24gYXMgd2VsbCBhcyB0aG9zZSB3aG8gcGFydGlj aXBhdGVkIGluIGVtYWlsCiAgICAgIGRpc2N1c3Npb24gYW5kIHNpZGUgb25lLW9uLW9uZSBk aXNjdXNzaW9ucy4KCjkuMTMuICBDaGFuZ2VzIGZyb20gZHJhZnQtZ2VsbGVucy0uLi4tMDEg dG8gLTAyCgogICBvICBVcGRhdGVkIHRleHQgZm9yIChwb3NzaWJsZSkgbmV3IGF0dHJpYnV0 ZSAiaHVtaW50bGFuZyIgdG8KICAgICAgcmVmZXJlbmNlIFJGQyA1NjQ2CiAgIG8gIEFkZGVk IGNsYXJpZnlpbmcgdGV4dCBmb3IgKHBvc3NpYmxlKSByZS11c2Ugb2YgZXhpc3RpbmcgJ2xh bmcnCiAgICAgIGF0dHJpYnV0ZSBzYXlpbmcgdGhhdCB0aGUgcmVnaXN0cmF0aW9uIHdvdWxk IGJlIHVwZGF0ZWQgdG8gcmVmbGVjdAogICAgICBkaWZmZXJlbnQgc2VtYW50aWNzIGZvciBt dWx0aXBsZSB2YWx1ZXMgZm9yIGludGVyYWN0aXZlIHZlcnN1cwogICAgICBub24taW50ZXJh Y3RpdmUgbWVkaWEuCiAgIG8gIEFkZGVkIGNsYXJpZnlpbmcgdGV4dCBmb3IgKHBvc3NpYmxl KSBuZXcgYXR0cmlidXRlICJodW1pbnRsYW5nIiB0bwogICAgICBhdHRlbXB0IHRvIGJldHRl ciBkZXNjcmliZSB0aGUgcm9sZSBvZiBsYW5ndWFnZSB0YWdzIGluIG1lZGlhIGluCiAgICAg IGFuIG9mZmVyIGFuZCBhbiBhbnN3ZXIuCgo5LjE0LiAgQ2hhbmdlcyBmcm9tIGRyYWZ0LWdl bGxlbnMtLi4uLTAwIHRvIC0wMQoKICAgbyAgQ2hhbmdlZCBuYW1lIG9mIChwb3NzaWJsZSkg bmV3IGF0dHJpYnV0ZSBmcm9tICdodW1sYW5nIiB0bwogICAgICAiaHVtaW50bGFuZyIKICAg byAgQWRkZWQgZGlzY3Vzc2lvbiBvZiBzaWxseSBzdGF0ZSAobGFuZ3VhZ2Ugbm90IGFwcHJv cHJpYXRlIGZvcgogICAgICBtZWRpYSB0eXBlKQogICBvICBBZGRlZCBWb2ljZSBDYXJyeSBP dmVyIGV4YW1wbGUKICAgbyAgQWRkZWQgbWVudGlvbiBvZiBtdWx0aWxpbmd1YWwgcGVvcGxl IGFuZCBtdWx0aXBsZSBsYW5ndWFnZXMKICAgbyAgTWlub3IgdGV4dCBjbGFyaWZpY2F0aW9u cwoKMTAuICBDb250cmlidXRvcnMKCiAgIEd1bm5hciBIZWxsc3Ryb20gZGVzZXJ2ZXMgc3Bl Y2lhbCBtZW50aW9uIGZvciBoaXMgcmV2aWV3cywKICAgYXNzaXN0YW5jZSwgYW5kIGVzcGVj aWFsbHkgZm9yIGNvbnRyaWJ1dGluZyB0aGUgY29yZSB0ZXh0IGluCiAgIEFwcGVuZGl4IEEu CgoxMS4gIEFja25vd2xlZGdtZW50cwoKICAgTWFueSB0aGFua3MgdG8gQmVybmFyZCBBYm9i YSwgSGFyYWxkIEFsdmVzdHJhbmQsIEZsZW1taW5nIEFuZHJlYXNlbiwKICAgRnJhbmNvaXMg QXVkZXQsIEVyaWMgQnVyZ2VyLCBLZWl0aCBEcmFnZSwgRG91ZyBFd2VsbCwgQ2hyaXN0aWFu CiAgIEdyb3ZlcywgQW5kcmV3IEh1dHRvbiwgSGFkcmllbCBLYXBsYW4sIEFyaSBLZXJhbmVu LCBKb2huIEtsZW5zaW4sCiAgIFBhdWwgS3l6aXZhdCwgSm9obiBMZXZpbmUsIEFsZXhleSBN ZWxuaWtvdiwgSmFtZXMgUG9saywgUGV0ZSBSZXNuaWNrLAogICBQZXRlciBTYWludC1BbmRy ZSwgYW5kIERhbGUgV29ybGV5IGZvciByZXZpZXdzLCBjb3JyZWN0aW9ucywKICAgc3VnZ2Vz dGlvbnMsIGFuZCBwYXJ0aWNpcGF0aW5nIGluIGluLXBlcnNvbiBhbmQgZW1haWwgZGlzY3Vz c2lvbnMuCgoKCgoKR2VsbGVucyAgICAgICAgICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDYs IDIwMTcgICAgICAgICAgICAgICAgW1BhZ2UgMTNdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAg ICBOZWdvdGlhdGluZyBIdW1hbiBMYW5ndWFnZSAgICAgICAgICBGZWJydWFyeSAyMDE3CgoK MTIuICBSZWZlcmVuY2VzCgoxMi4xLiAgTm9ybWF0aXZlIFJlZmVyZW5jZXMKCiAgIFtSRkMy MTE5XSAgQnJhZG5lciwgUy4sICJLZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNzIHRvIEluZGlj YXRlCiAgICAgICAgICAgICAgUmVxdWlyZW1lbnQgTGV2ZWxzIiwgQkNQIDE0LCBSRkMgMjEx OSwKICAgICAgICAgICAgICBET0kgMTAuMTc0ODcvUkZDMjExOSwgTWFyY2ggMTk5NywKICAg ICAgICAgICAgICA8aHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzIxMTk+LgoK ICAgW1JGQzQ1NjZdICBIYW5kbGV5LCBNLiwgSmFjb2Jzb24sIFYuLCBhbmQgQy4gUGVya2lu cywgIlNEUDogU2Vzc2lvbgogICAgICAgICAgICAgIERlc2NyaXB0aW9uIFByb3RvY29sIiwg UkZDIDQ1NjYsIERPSSAxMC4xNzQ4Ny9SRkM0NTY2LAogICAgICAgICAgICAgIEp1bHkgMjAw NiwgPGh0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmM0NTY2Pi4KCiAgIFtSRkM1 NjQ2XSAgUGhpbGxpcHMsIEEuLCBFZC4gYW5kIE0uIERhdmlzLCBFZC4sICJUYWdzIGZvciBJ ZGVudGlmeWluZwogICAgICAgICAgICAgIExhbmd1YWdlcyIsIEJDUCA0NywgUkZDIDU2NDYs IERPSSAxMC4xNzQ4Ny9SRkM1NjQ2LAogICAgICAgICAgICAgIFNlcHRlbWJlciAyMDA5LCA8 aHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzU2NDY+LgoKMTIuMi4gIEluZm9y bWF0aW9uYWwgUmVmZXJlbmNlcwoKICAgW0ktRC5pZXRmLXNsaW0tbXVsdGlsYW5nY29udGVu dF0KICAgICAgICAgICAgICBUb21raW5zb24sIE4uIGFuZCBOLiBCb3JlbnN0ZWluLCAiTXVs dGlwbGUgTGFuZ3VhZ2UKICAgICAgICAgICAgICBDb250ZW50IFR5cGUiLCBkcmFmdC1pZXRm LXNsaW0tbXVsdGlsYW5nY29udGVudC0wNiAod29yawogICAgICAgICAgICAgIGluIHByb2dy ZXNzKSwgT2N0b2JlciAyMDE2LgoKICAgW1JGQzMyNjRdICBSb3NlbmJlcmcsIEouIGFuZCBI LiBTY2h1bHpyaW5uZSwgIkFuIE9mZmVyL0Fuc3dlciBNb2RlbAogICAgICAgICAgICAgIHdp dGggU2Vzc2lvbiBEZXNjcmlwdGlvbiBQcm90b2NvbCAoU0RQKSIsIFJGQyAzMjY0LAogICAg ICAgICAgICAgIERPSSAxMC4xNzQ4Ny9SRkMzMjY0LCBKdW5lIDIwMDIsCiAgICAgICAgICAg ICAgPGh0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmMzMjY0Pi4KCiAgIFtSRkMz ODQwXSAgUm9zZW5iZXJnLCBKLiwgU2NodWx6cmlubmUsIEguLCBhbmQgUC4gS3l6aXZhdCwK ICAgICAgICAgICAgICAiSW5kaWNhdGluZyBVc2VyIEFnZW50IENhcGFiaWxpdGllcyBpbiB0 aGUgU2Vzc2lvbgogICAgICAgICAgICAgIEluaXRpYXRpb24gUHJvdG9jb2wgKFNJUCkiLCBS RkMgMzg0MCwKICAgICAgICAgICAgICBET0kgMTAuMTc0ODcvUkZDMzg0MCwgQXVndXN0IDIw MDQsCiAgICAgICAgICAgICAgPGh0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmMz ODQwPi4KCiAgIFtSRkMzODQxXSAgUm9zZW5iZXJnLCBKLiwgU2NodWx6cmlubmUsIEguLCBh bmQgUC4gS3l6aXZhdCwgIkNhbGxlcgogICAgICAgICAgICAgIFByZWZlcmVuY2VzIGZvciB0 aGUgU2Vzc2lvbiBJbml0aWF0aW9uIFByb3RvY29sIChTSVApIiwKICAgICAgICAgICAgICBS RkMgMzg0MSwgRE9JIDEwLjE3NDg3L1JGQzM4NDEsIEF1Z3VzdCAyMDA0LAogICAgICAgICAg ICAgIDxodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjMzg0MT4uCgpBcHBlbmRp eCBBLiAgSGlzdG9yaWMgQWx0ZXJuYXRpdmUgUHJvcG9zYWw6IENhbGxlci1wcmVmcwoKICAg VGhlIGRlY2lzaW9uIHRvIGJhc2UgdGhlIHByb3Bvc2FsIGF0IHRoZSBtZWRpYSBuZWdvdGlh dGlvbiBsZXZlbCwgYW5kCiAgIHNwZWNpZmljYWxseSB0byB1c2UgU0RQLCBjYW1lIGFmdGVy IHNpZ25pZmljYW50IGRlYmF0ZSBhbmQKICAgZGlzY3Vzc2lvbi4gIEl0IGlzIHBvc3NpYmxl IHRvIG1lZXQgdGhlIG9iamVjdGl2ZXMgdXNpbmcgYSB2YXJpZXR5IG9mCiAgIG1lY2hhbmlz bXMsIGJ1dCBub25lIGFyZSBwZXJmZWN0LiAgVXNpbmcgU0RQIG1lYW5zIGRlYWxpbmcgd2l0 aCB0aGUKICAgY29tcGxleGl0eSBvZiBTRFAsIGFuZCBsZWF2ZXMgb3V0IHJlYWwtdGltZSBz ZXNzaW9uIHByb3RvY29scyB0aGF0IGRvCiAgIG5vdCB1c2UgU0RQLiAgVGhlIG1ham9yIGFs dGVybmF0aXZlIHByb3Bvc2FsIHdhcyB0byB1c2UgU0lQLiAgVXNpbmcKCgoKR2VsbGVucyAg ICAgICAgICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDYsIDIwMTcgICAgICAgICAgICAgICAg W1BhZ2UgMTRdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICBOZWdvdGlhdGluZyBIdW1hbiBM YW5ndWFnZSAgICAgICAgICBGZWJydWFyeSAyMDE3CgoKICAgU0lQIGxlYXZlcyBvdXQgbm9u LVNJUCBzZXNzaW9uIHByb3RvY29scywgYnV0IG1vcmUgZnVuZGFtZW50YWxseSwKICAgd291 bGQgb2NjdXIgYXQgYSBkaWZmZXJlbnQgbGF5ZXIgdGhhbiB0aGUgbWVkaWEgbmVnb3RpYXRp b24uICBUaGlzCiAgIHJlc3VsdHMgaW4gYSBtb3JlIGZyYWdpbGUgc29sdXRpb24gc2luY2Ug dGhlIG1lZGlhIG1vZGFsaXR5IGFuZAogICBsYW5ndWFnZSB3b3VsZCBiZSBuZWdvdGlhdGVk IHVzaW5nIFNJUCwgYW5kIHRoZW4gdGhlIHNwZWNpZmljIG1lZGlhCiAgIGZvcm1hdHMgKHdo aWNoIGluaGVyZW50bHkgaW5jbHVkZSB0aGUgbW9kYWxpdHkpIHdvdWxkIGJlIG5lZ290aWF0 ZWQKICAgYXQgYSBkaWZmZXJlbnQgbGV2ZWwgKHR5cGljYWxseSBTRFAsIGVzcGVjaWFsbHkg aW4gdGhlIGVtZXJnZW5jeQogICBjYWxsaW5nIGNhc2VzKSwgbWFraW5nIGl0IGVhc2llciB0 byBoYXZlIG1pc21hdGNoZXMgKHN1Y2ggYXMgd2hlcmUKICAgdGhlIG1lZGlhIG1vZGFsaXR5 IG5lZ290aWF0ZWQgaW4gU0lQIGRvbid0IG1hdGNoIHdoYXQgd2FzIG5lZ290aWF0ZWQKICAg dXNpbmcgU0RQKS4KCiAgIEFuIGFsdGVybmF0aXZlIHByb3Bvc2FsIHdhcyB0byB1c2UgdGhl IFNJUC1sZXZlbCBDYWxsZXIgUHJlZmVyZW5jZXMKICAgbWVjaGFuaXNtIGZyb20gUkZDIDM4 NDAgW1JGQzM4NDBdIGFuZCBSRkMgMzg0MSBbUkZDMzg0MV0uCgogICBUaGUgQ2FsbGVyLXBy ZWZzIG1lY2hhbmlzbSBpbmNsdWRlcyBhIHByaW9yaXR5IHN5c3RlbTsgdGhpcyB3b3VsZAog ICBhbGxvdyBkaWZmZXJlbnQgY29tYmluYXRpb25zIG9mIG1lZGlhIGFuZCBsYW5ndWFnZXMg dG8gYmUgYXNzaWduZWQKICAgZGlmZmVyZW50IHByaW9yaXRpZXMuICBUaGUgZXZhbHVhdGlv biBhbmQgZGVjaXNpb25zIG9uIHdoYXQgdG8gZG8KICAgd2l0aCB0aGUgY2FsbCBjYW4gYmUg ZG9uZSBlaXRoZXIgYnkgcHJveGllcyBhbG9uZyB0aGUgY2FsbCBwYXRoLCBvcgogICBieSB0 aGUgYWRkcmVzc2VkIFVBLiAgRXZhbHVhdGlvbiBvZiBhbHRlcm5hdGl2ZXMgZm9yIHJvdXRp bmcgaXMKICAgZGVzY3JpYmVkIGluIFJGQyAzODQxIFtSRkMzODQxXS4KCkEuMS4gIFVzZSBv ZiBDYWxsZXIgUHJlZmVyZW5jZXMgV2l0aG91dCBBZGRpdGlvbnMKCiAgIFRoZSBmb2xsb3dp bmcgd291bGQgYmUgcG9zc2libGUgd2l0aG91dCBhZGRpbmcgYW55IG5ldyByZWdpc3RlcmVk CiAgIHRhZ3M6CgogICBQb3RlbnRpYWwgY2FsbGVycyBhbmQgcmVjaXBpZW50cyBNQVkgaW5j bHVkZSBpbiB0aGUgQ29udGFjdCBmaWVsZCBpbgogICB0aGVpciBTSVAgcmVnaXN0cmF0aW9u cyBtZWRpYSBhbmQgbGFuZ3VhZ2UgdGFncyBhY2NvcmRpbmcgdG8gdGhlCiAgIGpvaW50IGNh cGFiaWxpdGllcyBvZiB0aGUgVUEgYW5kIHRoZSBodW1hbiB1c2VyIGFjY29yZGluZyB0byBS RkMgMzg0MAogICBbUkZDMzg0MF0uCgogICBUaGUgbW9zdCByZWxldmFudCBtZWRpYSBjYXBh YmlsaXR5IHRhZ3MgYXJlICJ2aWRlbyIsICJ0ZXh0IiBhbmQKICAgImF1ZGlvIi4gIEVhY2gg dGFnIHJlcHJlc2VudHMgYSBjYXBhYmlsaXR5IHRvIHVzZSB0aGUgbWVkaWEgaW4gdHdvLQog ICB3YXkgY29tbXVuaWNhdGlvbi4KCiAgIExhbmd1YWdlIGNhcGFiaWxpdGllcyBhcmUgZGVj bGFyZWQgd2l0aCBhIGNvbW1hLXNlcGFyYXRlZCBsaXN0IG9mCiAgIGxhbmd1YWdlcyB0aGF0 IGNhbiBiZSB1c2VkIGluIHRoZSBjYWxsIGFzIHBhcmFtZXRlcnMgdG8gdGhlIHRhZwogICAi bGFuZ3VhZ2U9Ii4KCiAgIFRoaXMgaXMgYW4gZXhhbXBsZSBvZiBob3cgaXQgaXMgdXNlZCBp biBhIFNJUCBSRUdJU1RFUjoKCgoKICAgICAgUkVHSVNURVIgICAgdXNlckBleGFtcGxlLm5l dAogICAgICBDb250YWN0OiAgICA8c2lwOnVzZXIxQGV4YW1wbGUubmV0PiBhdWRpbzsgdmlk ZW87IHRleHQ7CiAgICAgICAgICAgICAgICAgIGxhbmd1YWdlPSJlbixlcyxhc2UiCgogICBJ bmNsdWRpbmcgdGhpcyBpbmZvcm1hdGlvbiBpbiBTSVAgUkVHSVNURVIgYWxsb3dzIHByb3hp ZXMgdG8gYWN0IG9uCiAgIHRoZSBpbmZvcm1hdGlvbi4gIEZvciB0aGUgcHJvYmxlbSBzZXQg YWRkcmVzc2VkIGJ5IHRoaXMgZG9jdW1lbnQsIGl0CgoKCkdlbGxlbnMgICAgICAgICAgICAg ICAgICBFeHBpcmVzIEF1Z3VzdCA2LCAyMDE3ICAgICAgICAgICAgICAgIFtQYWdlIDE1XQoM CkludGVybmV0LURyYWZ0ICAgICAgICAgTmVnb3RpYXRpbmcgSHVtYW4gTGFuZ3VhZ2UgICAg ICAgICAgRmVicnVhcnkgMjAxNwoKCiAgIGlzIG5vdCBhbnRpY2lwYXRlZCB0aGF0IHByb3hp ZXMgd2lsbCBkbyBzbyB1c2luZyByZWdpc3RyYXRpb24gZGF0YS4KICAgRnVydGhlciwgdGhl cmUgYXJlIGNsYXNzZXMgb2YgZGV2aWNlcyAoc3VjaCBhcyBjZWxsdWxhciBtb2JpbGUKICAg cGhvbmVzKSB0aGF0IGFyZSBub3QgYW50aWNpcGF0ZWQgdG8gaW5jbHVkZSB0aGlzIGluZm9y bWF0aW9uIGluIHRoZWlyCiAgIHJlZ2lzdHJhdGlvbnMuICBIZW5jZSwgdXNlIGluIHJlZ2lz dHJhdGlvbiBpcyBPUFRJT05BTC4KCiAgIEluIGEgY2FsbCwgYSBsaXN0IG9mIGFjY2VwdGFi bGUgbWVkaWEgYW5kIGxhbmd1YWdlIGNvbWJpbmF0aW9ucyBpcwogICBkZWNsYXJlZCwgYW5k IGEgcHJpb3JpdHkgYXNzaWduZWQgdG8gZWFjaCBjb21iaW5hdGlvbi4KCiAgIFRoaXMgaXMg ZG9uZSBieSB0aGUgQWNjZXB0LUNvbnRhY3QgaGVhZGVyIGZpZWxkLCB3aGljaCBkZWZpbmVz CiAgIGRpZmZlcmVudCBjb21iaW5hdGlvbnMgb2YgbWVkaWEgYW5kIGxhbmd1YWdlcyBhbmQg YXNzaWducyBwcmlvcml0aWVzCiAgIGZvciBjb21wbGV0aW5nIHRoZSBjYWxsIHdpdGggdGhl IFNJUCBVUkkgcmVwcmVzZW50ZWQgYnkgdGhhdCBDb250YWN0LgogICBBIHByaW9yaXR5IGlz IGFzc2lnbmVkIHRvIGVhY2ggc2V0IGFzIGEgc28tY2FsbGVkICJxLXZhbHVlIiB3aGljaAog ICByYW5nZXMgZnJvbSAxIChtb3N0IHByZWZlcnJlZCkgdG8gMCAobGVhc3QgcHJlZmVycmVk KS4KCiAgIFVzaW5nIHRoZSBBY2NlcHQtQ29udGFjdCBoZWFkZXIgZmllbGQgaW4gSU5WSVRF IHJlcXVlc3RzIGFuZAogICByZXNwb25zZXMgYWxsb3dzIHRoZXNlIGNhcGFiaWxpdGllcyB0 byBiZSBleHByZXNzZWQgYW5kIHVzZWQgZHVyaW5nCiAgIGNhbGwgc2V0LXVwLiAgQ2xpZW50 cyBTSE9VTEQgaW5jbHVkZSB0aGlzIGluZm9ybWF0aW9uIGluIElOVklURQogICByZXF1ZXN0 cyBhbmQgcmVzcG9uc2VzLgoKICAgRXhhbXBsZToKCgoKICAgICAgQWNjZXB0LUNvbnRhY3Q6 ICAgICo7IHRleHQ7IGxhbmd1YWdlPSJlbiI7IHE9MC4yCiAgICAgIEFjY2VwdC1Db250YWN0 OiAgICAqOyB2aWRlbzsgbGFuZ3VhZ2U9ImFzZSI7IHE9MC44CgogICBUaGlzIGV4YW1wbGUg c2hvd3MgdGhlIGhpZ2hlc3QgcHJlZmVyZW5jZSBleHByZXNzZWQgYnkgdGhlIGNhbGxlciBp cwogICB0byB1c2UgdmlkZW8gd2l0aCBBbWVyaWNhbiBTaWduIExhbmd1YWdlIChsYW5ndWFn ZSBjb2RlICJhc2UiKS4gIEFzIGEKICAgZmFsbGJhY2ssIGl0IGlzIGFjY2VwdGFibGUgdG8g Z2V0IHRoZSBjYWxsIGNvbm5lY3RlZCB3aXRoIG9ubHkKICAgRW5nbGlzaCB0ZXh0IHVzZWQg Zm9yIGh1bWFuIGNvbW11bmljYXRpb24uICBPdGhlciBtZWRpYSBtYXkgb2YgY291cnNlCiAg IGJlIGNvbm5lY3RlZCBhcyB3ZWxsLCB3aXRob3V0IGV4cGVjdGF0aW9uIHRoYXQgaXQgd2ls bCBiZSB1c2FibGUgYnkKICAgdGhlIGNhbGxlciBmb3IgaW50ZXJhY3RpdmUgY29tbXVuaWNh dGlvbnMgKGJ1dCBtYXkgc3RpbGwgYmUgaGVscGZ1bAogICB0byB0aGUgY2FsbGVyKS4KCiAg IFRoaXMgc3lzdGVtIHNhdGlzZmllcyBhbGwgdGhlIG5lZWRzIGRlc2NyaWJlZCBpbiB0aGUg cHJldmlvdXMKICAgY2hhcHRlcnMsIGV4Y2VwdCB0aGF0IGxhbmd1YWdlIHNwZWNpZmljYXRp b25zIGRvIG5vdCBtYWtlIGFueQogICBkaXN0aW5jdGlvbiBiZXR3ZWVuIHNwb2tlbiBhbmQg d3JpdHRlbiBsYW5ndWFnZSwgYW5kIHRoYXQgdGhlIG5lZWQKICAgZm9yIGRpcmVjdGlvbmFs aXR5IGluIHRoZSBzcGVjaWZpY2F0aW9uIGNhbm5vdCBiZSBmdWxmaWxsZWQuCgogICBUbyBz b21lIGRlZ3JlZSB0aGUgbGFjayBvZiBtZWRpYSBzcGVjaWZpY2F0aW9uIGJldHdlZW4gc3Bl ZWNoIGFuZAogICB0ZXh0IGluIGxhbmd1YWdlIHRhZ3MgY2FuIGJlIGNvbXBlbnNhdGVkIGJ5 IG9ubHkgc3BlY2lmeWluZyB0aGUKICAgaW1wb3J0YW50IG1lZGl1bSBpbiB0aGUgQWNjZXB0 LUNvbnRhY3QgZmllbGQuCgogICBUaHVzLCBhIHVzZXIgd2hvIHdhbnRzIHRvIHVzZSBFbmds aXNoIG1haW5seSBmb3IgdGV4dCB3b3VsZCBzcGVjaWZ5OgoKCgogICAgICBBY2NlcHQtQ29u dGFjdDogICAgKjt0ZXh0O2xhbmd1YWdlPSJlbiI7cT0xLjAKCgoKR2VsbGVucyAgICAgICAg ICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDYsIDIwMTcgICAgICAgICAgICAgICAgW1BhZ2Ug MTZdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICBOZWdvdGlhdGluZyBIdW1hbiBMYW5ndWFn ZSAgICAgICAgICBGZWJydWFyeSAyMDE3CgoKICAgV2hpbGUgYSB1c2VyIHdobyB3YW50cyB0 byB1c2UgRW5nbGlzaCBtYWlubHkgZm9yIHNwZWVjaCBidXQgYWNjZXB0IGl0CiAgIGZvciB0 ZXh0IHdvdWxkIHNwZWNpZnk6CgoKCiAgICAgIEFjY2VwdC1Db250YWN0OiAgICAqO2F1ZGlv O2xhbmd1YWdlPSJlbiI7cT0wLjgKICAgICAgQWNjZXB0LUNvbnRhY3Q6ICAgICo7dGV4dDts YW5ndWFnZT0iZW4iO3E9MC4yCgogICBIb3dldmVyLCBhIHVzZXIgd2hvIHdvdWxkIGxpa2Ug dG8gdGFsaywgYnV0IHJlY2VpdmUgdGV4dCBiYWNrIGhhcyBubwogICB3YXkgdG8gZG8gaXQg d2l0aCB0aGUgZXhpc3Rpbmcgc3BlY2lmaWNhdGlvbi4KCkEuMi4gIEFkZGl0aW9uYWwgQ2Fs bGVyIFByZWZlcmVuY2VzIGZvciBBc3ltbWV0cmljIE5lZWRzCgogICBJbiBvcmRlciB0byBi ZSBhYmxlIHRvIHNwZWNpZnkgYXN5bW1ldHJpYyBwcmVmZXJlbmNlcywgdGhlcmUgYXJlIHR3 bwogICBwb3NzaWJpbGl0aWVzLiAgRWl0aGVyIG5ldyBsYW5ndWFnZSB0YWdzIGluIHRoZSBz dHlsZSBvZiB0aGUKICAgaHVtaW50bGFuZyBwYXJhbWV0ZXJzIGRlc2NyaWJlZCBhYm92ZSBm b3IgU0RQIGNvdWxkIGJlIHJlZ2lzdGVyZWQsIG9yCiAgIGFkZGl0aW9uYWwgbWVkaWEgdGFn cyBkZXNjcmliaW5nIHRoZSBhc3ltbWV0cnkgY291bGQgYmUgcmVnaXN0ZXJlZC4KCkEuMi4x LiAgQ2FsbGVyIFByZWZlcmVuY2VzIGZvciBBc3ltbWV0cmljIE1vZGFsaXR5IE5lZWRzCgog ICBUaGUgZm9sbG93aW5nIG5ldyBtZWRpYSB0YWdzIHNob3VsZCBiZSBkZWZpbmVkOgoKICAg ICAgc3BlZWNoLXJlY2VpdmUKICAgICAgc3BlZWNoLXNlbmQKICAgICAgdGV4dC1yZWNlaXZl CiAgICAgIHRleHQtc2VuZAogICAgICBzaWduLXNlbmQKICAgICAgc2lnbi1yZWNlaXZlCgog ICBBIHVzZXIgd2hvIHByZWZlcnMgdG8gdGFsayBhbmQgZ2V0IHRleHQgaW4gcmV0dXJuIGlu IEVuZ2xpc2ggd291bGQKICAgcmVnaXN0ZXIgdGhlIGZvbGxvd2luZyAoaWYgaW5jbHVkaW5n IHRoaXMgaW5mb3JtYXRpb24gaW4gcmVnaXN0cmF0aW9uCiAgIGRhdGEpOgoKCgogICAgICBS RUdJU1RFUiAgICB1c2VyQGV4YW1wbGUubmV0CiAgICAgIENvbnRhY3Q6ICAgIDxzaXA6dXNl cjFAZXhhbXBsZS5uZXQ+IGF1ZGlvO3RleHQ7c3BlZWNoLXNlbmQ7dGV4dC0KICAgICAgICAg ICAgICAgICAgcmVjZWl2ZTtsYW5ndWFnZT0iZW4iCgogICBBdCBjYWxsIHRpbWUsIGEgdXNl ciB3aG8gcHJlZmVycyB0byB0YWxrIGFuZCBnZXQgdGV4dCBpbiByZXR1cm4gaW4KICAgRW5n bGlzaCB3b3VsZCBzZXQgdGhlIEFjY2VwdC1Db250YWN0IGhlYWRlciBmaWVsZCB0bzoKCgoK ICAgICAgQWNjZXB0LUNvbnRhY3Q6ICAgICo7IGF1ZGlvOyB0ZXh0OyBzcGVlY2gtcmVjZWl2 ZTsgdGV4dC1zZW5kOwogICAgICAgICAgICAgICAgICAgICAgICAgbGFuZ3VhZ2U9ImVuIjtx PTAuOAogICAgICBBY2NlcHQtQ29udGFjdDogICAgKjsgdGV4dDsgbGFuZ3VhZ2U9ImVuIjsg cT0wLjIKCgoKCkdlbGxlbnMgICAgICAgICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCA2LCAy MDE3ICAgICAgICAgICAgICAgIFtQYWdlIDE3XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAg TmVnb3RpYXRpbmcgSHVtYW4gTGFuZ3VhZ2UgICAgICAgICAgRmVicnVhcnkgMjAxNwoKCiAg IE5vdGUgdGhhdCB0aGUgZGlyZWN0aW9ucyBzcGVjaWZpZWQgaGVyZSBhcmUgYXMgdmlld2Vk IGZyb20gdGhlIGNhbGxlZQogICBzaWRlIHRvIG1hdGNoIHdoYXQgdGhlIGNhbGxlZSBoYXMg cmVnaXN0ZXJlZC4KCiAgIEEgYnJpZGdlIGFycmFuZ2VkIGZvciBpbnZva2luZyBhIHJlbGF5 IHNlcnZpY2Ugc3BlY2lmaWNhbGx5IGFycmFuZ2VkCiAgIGZvciBjYXB0aW9uZWQgdGVsZXBo b255IHdvdWxkIHJlZ2lzdGVyIHRoZSBmb2xsb3dpbmcgZm9yIHN1cHBvcnRpbmcKICAgY2Fs bGluZyB1c2VyczoKCgoKICAgICAgUkVHSVNURVIgICAgY3RAY3RyZWxheS5uZXQKICAgICAg Q29udGFjdDogICAgPHNpcDpjdDFAY3RyZWxleS5uZXQ+IGF1ZGlvOyB0ZXh0OyBzcGVlY2gt cmVjZWl2ZTsKICAgICAgICAgICAgICAgICAgdGV4dC1zZW5kOyBsYW5ndWFnZT0iZW4iCgog ICBBIGJyaWRnZSBhcnJhbmdlZCBmb3IgaW52b2tpbmcgYSByZWxheSBzZXJ2aWNlIHNwZWNp ZmljYWxseSBhcnJhbmdlZAogICBmb3IgY2FwdGlvbmVkIHRlbGVwaG9ueSB3b3VsZCByZWdp c3RlciB0aGUgZm9sbG93aW5nIGZvciBzdXBwb3J0aW5nCiAgIGNhbGxlZCB1c2VyczoKCgoK ICAgICAgUkVHSVNURVIgICAgY3RAY3RyZWxheS5uZXQKICAgICAgQ29udGFjdDogICAgPHNp cDpjdDJAY3RyZWxleS5uZXQ+IGF1ZGlvOyB0ZXh0OyBzcGVlY2gtc2VuZDsgdGV4dC0KICAg ICAgICAgICAgICAgICAgcmVjZWl2ZTsgbGFuZ3VhZ2U9ImVuIgoKICAgQXQgY2FsbCB0aW1l LCB0aGVzZSBhbHRlcm5hdGl2ZXMgYXJlIGluY2x1ZGVkIGluIHRoZSBsaXN0IG9mIHBvc3Np YmxlCiAgIG91dGNvbWUgb2YgdGhlIGNhbGwgcm91dGluZyBieSB0aGUgU0lQIHByb3hpZXMg YW5kIHRoZSBwcm9wZXIgcmVsYXkKICAgc2VydmljZSBpcyBpbnZva2VkLgoKQS4yLjIuICBD YWxsZXIgUHJlZmVyZW5jZXMgZm9yIEFzeW1tZXRyaWMgTGFuZ3VhZ2UgVGFncwoKICAgQW4g YWx0ZXJuYXRpdmUgaXMgdG8gcmVnaXN0ZXIgbmV3IGxhbmd1YWdlIHRhZ3MgZm9yIHRoZSBw dXJwb3NlIG9mCiAgIGFzeW1tZXRyaWMgbGFuZ3VhZ2UgdXNhZ2UuCgogICBJbnN0ZWFkIG9m IHVzaW5nICJsYW5ndWFnZT0iLCBzaXggbmV3IGxhbmd1YWdlIHRhZ3Mgd291bGQgYmUKICAg cmVnaXN0ZXJlZDoKCiAgICAgIGh1bWludGxhbmctdGV4dC1yZWN2CiAgICAgIGh1bWludGxh bmctdGV4dC1zZW5kCiAgICAgIGh1bWludGxhbmctc3BlZWNoLXJlY3YKICAgICAgaHVtaW50 bGFuZy1zcGVlY2gtc2VuZAogICAgICBodW1pbnRsYW5nLXNpZ24tcmVjdgogICAgICBodW1p bnRsYW5nLXNpZ24tc2VuZAoKICAgVGhlc2UgbGFuZ3VhZ2UgdGFncyB3b3VsZCBiZSB1c2Vk IGluc3RlYWQgb2YgdGhlIHJlZ3VsYXIKICAgYmlkaXJlY3Rpb25hbCBsYW5ndWFnZSB0YWdz LCBhbmQgdXNlcnMgd2l0aCBiaWRpcmVjdGlvbmFsCiAgIGNhcGFiaWxpdGllcyBTSE9VTEQg c3BlY2lmeSB2YWx1ZXMgZm9yIGJvdGggZGlyZWN0aW9ucy4gIFNlcnZpY2VzCiAgIHNwZWNp ZmljYWxseSBhcnJhbmdlZCBmb3Igc3VwcG9ydGluZyB1c2VycyB3aXRoIGFzeW1tZXRyaWMg bmVlZHMKICAgU0hPVUxEIHNwZWNpZnkgb25seSB0aGUgYXN5bW1ldHJ5IHRoZXkgc3VwcG9y dC4KCgoKCkdlbGxlbnMgICAgICAgICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCA2LCAyMDE3 ICAgICAgICAgICAgICAgIFtQYWdlIDE4XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgTmVn b3RpYXRpbmcgSHVtYW4gTGFuZ3VhZ2UgICAgICAgICAgRmVicnVhcnkgMjAxNwoKCkF1dGhv cidzIEFkZHJlc3MKCiAgIFJhbmRhbGwgR2VsbGVucwogICBDb3JlIFRlY2hub2xvZ3kgQ29u c3VsdGluZwoKICAgRW1haWw6IHJnK2lldGZAcmFuZHkucGVuc2l2ZS5vcmcKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKR2VsbGVucyAgICAgICAgICAg ICAgICAgIEV4cGlyZXMgQXVndXN0IDYsIDIwMTcgICAgICAgICAgICAgICAgW1BhZ2UgMTld Cg== --------------14511186B3059DA30155E67B-- From nobody Mon Feb 13 09:54: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 AC70512971E for ; Mon, 13 Feb 2017 09:54:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hHrogFx07403 for ; Mon, 13 Feb 2017 09:54:01 -0800 (PST) Received: from p3plwbeout03-03.prod.phx3.secureserver.net (p3plsmtp03-03-2.prod.phx3.secureserver.net [72.167.218.215]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C847E1296F7 for ; Mon, 13 Feb 2017 09:54:01 -0800 (PST) Received: from localhost ([72.167.218.132]) by p3plwbeout03-03.prod.phx3.secureserver.net with bizsmtp id kHtx1u0022rz53401HtxCB; Mon, 13 Feb 2017 10:53:57 -0700 X-SID: kHtx1u0022rz53401 Received: (qmail 16049 invoked by uid 99); 13 Feb 2017 17:53:57 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 208.51.143.189 User-Agent: Workspace Webmail 6.6.2 Message-Id: <20170213105355.665a7a7059d7ee80bb4d670165c8327d.1c694c05b8.wbe@email03.godaddy.com> From: "Doug Ewell" To: slim@ietf.org, ietf@ietf.org Date: Mon, 13 Feb 2017 10:53:55 -0700 Mime-Version: 1.0 Archived-At: Cc: =?UTF-8?Q?Gunnar=5FHellstr=C3=B6m?= Subject: Re: [Slim] Last Call: (Negotiating Human Language in Real-Time Communications) to Proposed Standard X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 17:54:03 -0000 Gunnar Hellstr=C3=B6m wrote:=0A=0A> 5. Make use of the asterisk modifier on= media level with session scope=0A> also for media level purposes =0A>=0A> = The asterisk modifier optionally appended on attribute values has in=0A> th= e original -06 draft only a session effect. It is specified to=0A> indicate= if the call should be rejected or not if languages do not=0A> match. It ca= n be appended to any humintlang attribute in the whole SDP=0A> without any = change in effect. This independancy of placement indicates=0A> that it is w= rongly placed. With the current definition, it should be a=0A> single separ= ate session level attribute. Instead of specifying a=0A> separate session l= evel attribute, it is proposed that the asterisk=0A> gets an expanded defin= ition, so that its placement conveys meaning of=0A> value for the successfu= l language negotiation. =0A>=0A> It has been discussed in the SLIM WG that = the specification lacks two=0A> functions, required by the specifications b= y other bodies who are=0A> waiting for the results of SLIM real-time work. = (e.g. 3GPP TS 22.228=0A> and ETSI TR 103 201). 3GPP TS 22.228 requires "The= system should be=0A> able to negotiate the user's desired language(s) and = modalities, per=0A> media stream and/or session, in order of preference." T= hus negotiation=0A> with preference indication within the session is requir= ed, not only=0A> within each media. ETSI TR 103 201 says "the Total Convers= ation user=0A> should be able to indicate the preferred method of communica= tion for=0A> each direction of the session, so that the call-taker can be s= elected=0A> appropriately or an appropriate assisting service be invoked. "= Saying=0A> "preferred" means that it should also be possible to indicate l= ess=0A> preferred alternatives.=0A=0AGunnar, who participated extensively i= n the SLIM WG, appears to be=0Aattempting to re-introduce a mechanism to in= dicate preference of=0Amodality which was considered and rejected multiple = times by the WG.=0A=0AWG rejection of Gunnar's previous proposals to do thi= s was based on=0Areluctance to try to solve this particular problem in the = first version=0Aof the spec, not on any of the specific mechanisms proposed= to solve the=0Aproblem. Proposing a new or modified mechanism during IETF = LC appears to=0Abe an attempt to rehash an argument made, but not won, in t= he WG.=0A=0AIf this concerns a different issue, not merely a different way = of=0Aapproaching it, please accept my apology and explain more clearly how = it=0Ais different.=0A=0A =0A--=0ADoug Ewell | Thornton, CO, US | ewellic.or= g From nobody Mon Feb 13 11:07: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 0B7C71296EE; Mon, 13 Feb 2017 11:07:23 -0800 (PST) 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 lD0fWYeyPSNu; Mon, 13 Feb 2017 11:07:21 -0800 (PST) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 055881297F0; Mon, 13 Feb 2017 11:07:19 -0800 (PST) Received: by mail-vk0-x231.google.com with SMTP id r136so66896567vke.1; Mon, 13 Feb 2017 11:07:18 -0800 (PST) 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=NDew0FUK8ElkqHlOhFFJAoOgzkDKBO5BiBkfzY1cYYU=; b=QwyqV12/Om7EB+mBGX0WgX78zxA9vPhc901aewOeBrCiW8lOYYkzXzQMRvBDQuNbvN pBAqzJ4FyOxtFSt7H39+mclF177fA/qeh4jkYL52tykux03EREbJMu3aSk76Uc2hBq2d DVyJm45wYey6YzMcrmDlSboXScS5R091/TRwz5mq1B2nbwKlHO0bKzvfu+FyB4k/g5O3 +/usNpFGqS1EHH5VA1rKtjoArWphmh8QW49ztM53xsHr4kYdUz9yg+vGQ0exuZTv9fiL VHvNMqoRNVmOhvkREtktBu+uknuBgY7XB9RnYBXanKFKRWVkmyzJH3jhGGPp0tNcRa/W YqMw== 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=NDew0FUK8ElkqHlOhFFJAoOgzkDKBO5BiBkfzY1cYYU=; b=n14XZLifLmaj43fg5OzZuv5vQ/Jy7/9ej5RZ+N2ly2hMehNJhjHscwee5ekak4vbnc pr6uQc5/bt44NlR6KLzPIRBk4ycdUfMVYi1J3tTEDFDZPMvOPQBFD6vr6gCm7Xw5LiN9 SxZvpZlouFTQhPX7WIzTHxb4oKJDu0PiUIJql8min+8AHWX/tLUxcP88Z4fLyMteuO3Q uSK6L4dnoKfNlXXNTLhzVnyoe1BSsIi1yOEJq3CBJkA3J/uujg2rFE8ubf+tMgWUGzKg mmXyNO9FSDV4jSoAwQvN7qQXnscY99rdUlnZCSFD/JF1hf7FSNoSJA4BMPJ51LyAdWUs CWSA== X-Gm-Message-State: AMke39kk6wnT5cZ2fmD3xTJfruyj362JL7zHgPuAHR1Q6mPfQNPDGj6gjbSkQNkap5EaP5QB9SRYuO5+OPO+eA== X-Received: by 10.31.191.71 with SMTP id p68mr9926607vkf.50.1487012837822; Mon, 13 Feb 2017 11:07:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.88.90 with HTTP; Mon, 13 Feb 2017 11:06:57 -0800 (PST) From: Bernard Aboba Date: Mon, 13 Feb 2017 11:06:57 -0800 Message-ID: To: slim@ietf.org, ietf@ietf.org Content-Type: multipart/alternative; boundary=001a114ddaf8f9996105486e27b7 Archived-At: Subject: Re: [Slim] IETF last call for draft-ietf-slim-negotiating-human-language (Section 5.4) X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 19:07:23 -0000 --001a114ddaf8f9996105486e27b7 Content-Type: text/plain; charset=UTF-8 Looking over Section 5.4, it seems to me that the title "Silly States" may not be appropriate, because it mixes discussion of combinations of media and language that have an "undefined" meaning with combinations for which normative guidance can be provided So rather than having a single "Silly States" section, perhaps we can have a section on "Undefined States" (for those combinations which have an undefined meaning) provide normative guidance on defined combinations elsewhere. 5.4 . Silly States It is possible to specify a "silly state" where the language specified does not make sense for the media type, such as specifying a signed language for an audio media stream. An offer MUST NOT be created where the language does not make sense for the media type. If such an offer is received, the receiver MAY reject the media, ignore the language specified, or attempt to interpret the intent (e.g., if American Sign Language is specified for an audio media stream, this might be interpreted as a desire to use spoken English). A spoken language tag for a video stream in conjunction with an audio stream with the same language might indicate a request for supplemental video to see the speaker. [BA] Rather than using terms like "might" for combinations that could have a defined meaning, I would like to see the specification provide normative language on these use cases. In particular, I would like the specification to describe: a. What it means when a spoken language tag is included for a video stream. Is this to be interpreted as a request for captioning? b. What it means when a signed language tag is included for an audio stream. Is the meaning of this "undefined" and if so, should it be ignored? c. What it means when a signed language tag is included for a text stream. If some of these scenarios are not defined, the specification can say "this combination does not have a defined meaning" or something like that. --001a114ddaf8f9996105486e27b7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
L= ooking over Section 5.4, it seems to me that the title "Silly States&q= uot; may not be appropriate, because it mixes discussion of combinations=C2=A0of media and language that have an &quo= t;undefined" meaning with combinations=C2=A0for which normative guidance can be provided =C2=A0So rather = than having a single "Silly States" section, perhaps we can have = a section on "Undefined States" (for those combinations which hav= e an undefined meaning) provide normative guidance on defined combinations = elsewhere.

5.4.  Silly States


   It is possible to specify a "silly state" where the language
   specified does not make sense for the media type, such as specifying
   a signed language for an audio media stream.
   An offer MUST NOT be created where the language does not mak=
e sense
   for the media type.  If such an offer is received, the receiver MAY
   reject the media, ignore the language specified, or attempt to
   interpret the intent (e.g., if American Sign Language is specified
   for an audio media stream, this might be interpreted as a desire to
   use spoken English).

   A spoken language tag for a video stream in conjunction with an audio
   stream with the same language might indicate a request for
   supplemental video to see the speaker.

[BA] Rather than using te=
rms like "might" for combinations that could have a
defined meaning, I would like to see the specific=
ation provide normative 
language on=
 these use cases. In particular, I would like the specification to describe=
: 

a. What it means when a spoken language tag is included for a vi=
deo stream. 
Is this to be interpret=
ed as a request for captioning?
b. W=
hat it means when a signed language tag is included for an audio stream.
Is the meaning of this "undefined=
" and if so, should it be ignored?
c. What it means when a signed language tag is included for a text stre=
am.

If some of these scenarios are not defined, the specification c=
an say
"this combination does n=
ot have a defined meaning" or something like that.
<= /div> --001a114ddaf8f9996105486e27b7-- From nobody Mon Feb 13 13:23:49 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 3A74812958B for ; Mon, 13 Feb 2017 13:23:45 -0800 (PST) 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=unavailable 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 A7jZ4TOVjDjy for ; Mon, 13 Feb 2017 13:23:42 -0800 (PST) Received: from bin-vsp-out-01.atm.binero.net (bin-mail-out-06.binero.net [195.74.38.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04CA71293EE for ; Mon, 13 Feb 2017 13:23:41 -0800 (PST) X-Halon-ID: aa1a1d32-f232-11e6-a131-005056917a89 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [83.209.158.27]) by bin-vsp-out-01.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Mon, 13 Feb 2017 22:23:29 +0100 (CET) To: Bernard Aboba , slim@ietf.org, ietf@ietf.org References: From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <64c8d9d7-9df8-023e-6d47-4807cc0e30b7@omnitor.se> Date: Mon, 13 Feb 2017 22:23:36 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------C46E57F1D025166BA2EA8432" Archived-At: Subject: Re: [Slim] IETF last call for draft-ietf-slim-negotiating-human-language (Section 5.4) X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 21:23:45 -0000 This is a multi-part message in MIME format. --------------C46E57F1D025166BA2EA8432 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Bernard, I just issued comments where I also included the "silly states" topic with similar views as yours. Den 2017-02-13 kl. 20:06, skrev Bernard Aboba: > Looking over Section 5.4, it seems to me that the title "Silly States" > may not be appropriate, because it mixes discussion of combinations of > media and language that have an "undefined" meaning with combinations > for which normative guidance can be provided So rather than having a > single "Silly States" section, perhaps we can have a section on > "Undefined States" (for those combinations which have an undefined > meaning) provide normative guidance on defined combinations elsewhere. > > > 5.4 > . > Silly States > > > > It is possible to specify a "silly state" where the language > specified does not make sense for the media type, such as specifying > a signed language for an audio media stream. > An offer MUST NOT be created where the language does not make sense > for the media type. If such an offer is received, the receiver MAY > reject the media, ignore the language specified, or attempt to > interpret the intent (e.g., if American Sign Language is specified > for an audio media stream, this might be interpreted as a desire to > use spoken English). > > A spoken language tag for a video stream in conjunction with an audio > stream with the same language might indicate a request for > supplemental video to see the speaker. > [BA] Rather than using terms like "might" for combinations that could have a > defined meaning, I would like to see the specification provide normative > language on these use cases. In particular, I would like the specification to describe: > a. What it means when a spoken language tag is included for a video stream. > Is this to be interpreted as a request for captioning? > b. What it means when a signed language tag is included for an audio stream. > Is the meaning of this "undefined" and if so, should it be ignored? > c. What it means when a signed language tag is included for a text stream. > If some of these scenarios are not defined, the specification can say > "this combination does not have a defined meaning" or something like that. See my recent comments for more views. I support the idea to be normative and specific when possible. A complication is that there is no difference between language tags for written and spoken language. So we have the following possible combinations and interpretations of "silly states" 1. Spoken/written tag in video media, can mean to see a speaking person, or to provide captions overlayed on video. With some hesitation I suggest to let it mean to see a speaking person. The draft adds a requirement to have the same language in the audio stream in the same direction to have that interpretation. Should that mean that if there is another language in the audio stream, then the spoken/written tag in the video stream should mean captions in the specified language? That sounds useful for some cases, but complex to interpret and unfair to the users who would benefit from captions in the same language as in audio. Summary: I think we had better to use the interpretation to see a speaking person regardless of what language is indicated for audio. 2. Signed language tag in audio media, can mean audio from a signing person. That could be anything between near silence and spoken words corresponding to the signed signs as far as feasible. This is usually seen as disturbing to sign language users but it exists, e.g. when one erson needs to communicate with both hearing and deaf persons simultaneously. There are also variants of signing, called sign supported language, with signs expressed with spoken language word order and grammar. That can more easily be combined with spoken language, but would more likely be indicated by spoken language tag in audio media. Summary: I am inclined to let signed language tag in audio media mean audio from the signing person and possibly used for the rare cases when it has some relevance for language communication. 3. Sign language tag in text media. There are some ways to represent sign language in various kinds of symbol or text representation. Some are represented in Unicode. One is a system called Sign Writing. Some fingerspelling methods also have fonts corresponding to characters in code pages. There is also an informal way to write manuscripts for signing in words with capitals approximately corresponding to signs, often with some notation added for unique sign language ways of expression that has no direct correspondance to words. None of these systems above are common in real-time conversation, but I have seen examples of such use. Summary: I think we can leave freedom here and just specify that a sign language tag in text media means some representation of sign language or a corresponding fingerspelling system in text media. If these conclusions are accepted, we can formulate modified text. Note that the case with spoken/written language tag in video media is mentioned in two places in the draft. Regards 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 --------------C46E57F1D025166BA2EA8432 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Bernard,

I just issued comments where I also included the "silly states" topic with similar views as yours.


Den 2017-02-13 kl. 20:06, skrev Bernard Aboba:
Looking over Section 5.4, it seems to me that the title "Silly States" may not be appropriate, because it mixes discussion of combinations of media and language that have an "undefined" meaning with combinations for which normative guidance can be provided  So rather than having a single "Silly States" section, perhaps we can have a section on "Undefined States" (for those combinations which have an undefined meaning) provide normative guidance on defined combinations elsewhere.

5.4.  Silly States


   It is possible to specify a "silly state" where the language
   specified does not make sense for the media type, such as specifying
   a signed language for an audio media stream.
   An offer MUST NOT be created where the language does not make sense
   for the media type.  If such an offer is received, the receiver MAY
   reject the media, ignore the language specified, or attempt to
   interpret the intent (e.g., if American Sign Language is specified
   for an audio media stream, this might be interpreted as a desire to
   use spoken English).

   A spoken language tag for a video stream in conjunction with an audio
   stream with the same language might indicate a request for
   supplemental video to see the speaker.

            
[BA] Rather than using terms like "might" for combinations that could have a

            
defined meaning, I would like to see the specification provide normative 

            
language on these use cases. In particular, I would like the specification to describe: 

            

            
a. What it means when a spoken language tag is included for a video stream. 

            
Is this to be interpreted as a request for captioning?

            
b. What it means when a signed language tag is included for an audio stream.

            
Is the meaning of this "undefined" and if so, should it be ignored?

            
c. What it means when a signed language tag is included for a text stream.

            

            
If some of these scenarios are not defined, the specification can say

            
"this combination does not have a defined meaning" or something like that.

          

        

    

    See my recent comments for more views. I support the idea to be
    normative and specific when possible.

    A complication is that there is no difference between language tags
    for written and spoken language. 

    

    So we have the following possible combinations and interpretations
    of "silly states"

    

    1. Spoken/written tag in video media, can mean to see a speaking
    person, or to provide captions overlayed on video.

    With some hesitation I suggest to let it mean to see a speaking
    person. The draft adds a requirement to have the same language in
    the audio stream in the same direction to have that interpretation. 
    Should that mean that if there is another language in the audio
    stream, then the spoken/written tag in the video stream should mean
    captions in the specified language? That sounds useful for some
    cases, but complex to interpret and unfair to the users who would
    benefit from captions in the same language as in audio. 

    Summary: I think we had better to use the interpretation to see a
    speaking person regardless of what language is indicated for audio.

    

    2. Signed language tag in audio media, can mean audio from a signing
    person. That could be anything between near silence and spoken words
    corresponding to the signed signs as far as feasible. This is
    usually seen as disturbing to sign language users but it exists,
    e.g. when one erson needs to communicate with both hearing and deaf
    persons simultaneously. There are also variants of signing, called
    sign supported language, with signs expressed with spoken language
    word order and grammar. That can more easily be combined with spoken
    language, but would more likely be indicated by spoken language tag
    in audio media.

    Summary: I am inclined to let signed language tag in audio media
    mean audio from the signing person and possibly used for the rare
    cases when it has some relevance for language communication. 

    

    3. Sign language tag in text media. There are some ways to represent
    sign language in various kinds of symbol or text representation.
    Some are represented in Unicode. One is a system called Sign
    Writing. Some fingerspelling methods also have fonts corresponding
    to characters in code pages. There is also an informal way to write
    manuscripts for signing in words with capitals approximately
    corresponding to signs, often with some notation added for unique
    sign language ways of expression that has no direct correspondance
    to words. None of these systems above are common in real-time
    conversation, but I have seen examples of such use.

    Summary: I think we can leave freedom here and just specify that a
    sign language tag in text media means some representation of sign
    language or a corresponding fingerspelling system in text media. 

         

    If these conclusions are accepted, we can formulate modified text.
    Note that the case with spoken/written language tag in video media
    is mentioned in two places in the draft.

    

    Regards

    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

  


--------------C46E57F1D025166BA2EA8432--


From nobody Mon Feb 13 13:58: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 6745B1298C2; Mon, 13 Feb 2017 13:58:25 -0800 (PST)
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 x-oxuQ_tK314; Mon, 13 Feb 2017 13:58:23 -0800 (PST)
Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (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 263D812999A; Mon, 13 Feb 2017 13:58:23 -0800 (PST)
Received: by mail-vk0-x22b.google.com with SMTP id x75so69526773vke.2; Mon, 13 Feb 2017 13:58:23 -0800 (PST)
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=ypas3XVQ5I03Rxr8AopWeugndkhd5CZLUAaFm/cj0ZM=; b=kj7h3mKt7p26Fct/jpZ2Fnpq2+Tz5sxl2BxJerOWhA+XmybQN29foFOB46czaUsJ4d TSVM//aNkkqgUUtby30+MKU0irqRCYmJeabvO4b44ssvqc51JItVOXMXn8cYuFqD/v56 Vghjt5QTEQIbKmz4pxfBUTqs0iD12seDUXWI8cQhioyH4i9d8h0sTy+hMdPXXlFLw5Bn HDFtzBmGVjvKLNFp5fiPLTObAeYQzYsuqZYF1BVq3LRvryVPDEqTIaZAmIbUYa5K0NBP 7ZRABjLY468sAI5+zQGCdXHivQEdv+31zE5VDEo+eivxmxr7aSmPdD9HXjjZUrMpbQDx kg3g==
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=ypas3XVQ5I03Rxr8AopWeugndkhd5CZLUAaFm/cj0ZM=; b=Qeixb+quLB1U2Tt4JyZBSeBlxNkVv9fkW28UV/dku6SGmgIGeZqFM/7Z471MIOeT+F D9r05ftCCD0UzFObjP6flAhu8lPQKhm3Ac+SmQUbS0c/jeWK1pMVeWd1q/NkCfDv35Nr z+BzlboJj80OJxdTaP1n48wo1fHSu76gHM6Cj/dvOcv4VsmzNg2fBelNQvrWb4uXVNpH Ffra/d82Wax7kWhVOkyIReQXU9bkNxDaBj3+EXXjV9LDS8jL2nBDcyddSekMzOWJZ6L5 UazAPjLwqZSo2WXcOaZlLP1KSph3QbPxfcITk5VcyTUMGBckCrhT3xEQRlWEVEE9zEIr 7s8w==
X-Gm-Message-State: AMke39nSdj4gbXrOXqW6ncoC71MYAaajbbH4L3YFH1g7PagNBqCDnfrfm5N1fBkiJVQDZGbE/FyK0Wb9J3ABuQ==
X-Received: by 10.31.205.133 with SMTP id d127mr12359828vkg.18.1487023102142;  Mon, 13 Feb 2017 13:58:22 -0800 (PST)
MIME-Version: 1.0
Received: by 10.176.88.90 with HTTP; Mon, 13 Feb 2017 13:58:01 -0800 (PST)
In-Reply-To: <64c8d9d7-9df8-023e-6d47-4807cc0e30b7@omnitor.se>
References:  <64c8d9d7-9df8-023e-6d47-4807cc0e30b7@omnitor.se>
From: Bernard Aboba 
Date: Mon, 13 Feb 2017 13:58:01 -0800
Message-ID: 
To: =?UTF-8?Q?Gunnar_Hellstr=C3=B6m?= 
Content-Type: multipart/alternative; boundary=001a114dcffac6b08e0548708bab
Archived-At: 
Cc: slim@ietf.org, ietf@ietf.org
Subject: Re: [Slim] IETF last call for draft-ietf-slim-negotiating-human-language (Section 5.4)
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Feb 2017 21:58:25 -0000

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

Gunnar said:

"With some hesitation I suggest to let it mean to see a speaking person."

[BA] Is this for the purpose of enabling lip reading?

Assuming that we go that way, how would captioning be negotiated?

On Mon, Feb 13, 2017 at 1:23 PM, Gunnar Hellstr=C3=B6m <
gunnar.hellstrom@omnitor.se> wrote:

> Bernard,
>
> I just issued comments where I also included the "silly states" topic wit=
h
> similar views as yours.
>
> Den 2017-02-13 kl. 20:06, skrev Bernard Aboba:
>
> Looking over Section 5.4, it seems to me that the title "Silly States" ma=
y
> not be appropriate, because it mixes discussion of combinations of media
> and language that have an "undefined" meaning with combinations for which
> normative guidance can be provided  So rather than having a single "Silly
> States" section, perhaps we can have a section on "Undefined States" (for
> those combinations which have an undefined meaning) provide normative
> guidance on defined combinations elsewhere.
>
> 5.4 .  Silly States
>
>    It is possible to specify a "silly state" where the language
>    specified does not make sense for the media type, such as specifying
>    a signed language for an audio media stream.
>
>    An offer MUST NOT be created where the language does not make sense
>    for the media type.  If such an offer is received, the receiver MAY
>    reject the media, ignore the language specified, or attempt to
>    interpret the intent (e.g., if American Sign Language is specified
>    for an audio media stream, this might be interpreted as a desire to
>    use spoken English).
>
>    A spoken language tag for a video stream in conjunction with an audio
>    stream with the same language might indicate a request for
>    supplemental video to see the speaker.
>
> [BA] Rather than using terms like "might" for combinations that could hav=
e a
>
> defined meaning, I would like to see the specification provide normative
>
> language on these use cases. In particular, I would like the specificatio=
n to describe:
>
> a. What it means when a spoken language tag is included for a video strea=
m.
>
> Is this to be interpreted as a request for captioning?
>
> b. What it means when a signed language tag is included for an audio stre=
am.
>
> Is the meaning of this "undefined" and if so, should it be ignored?
>
> c. What it means when a signed language tag is included for a text stream=
.
>
> If some of these scenarios are not defined, the specification can say
>
> "this combination does not have a defined meaning" or something like that=
.
>
> See my recent comments for more views. I support the idea to be normative
> and specific when possible.
> A complication is that there is no difference between language tags for
> written and spoken language.
>
> So we have the following possible combinations and interpretations of
> "silly states"
>
> 1. Spoken/written tag in video media, can mean to see a speaking person,
> or to provide captions overlayed on video.
> With some hesitation I suggest to let it mean to see a speaking person.
> The draft adds a requirement to have the same language in the audio strea=
m
> in the same direction to have that interpretation.  Should that mean that
> if there is another language in the audio stream, then the spoken/written
> tag in the video stream should mean captions in the specified language?
> That sounds useful for some cases, but complex to interpret and unfair to
> the users who would benefit from captions in the same language as in audi=
o.
> Summary: I think we had better to use the interpretation to see a speakin=
g
> person regardless of what language is indicated for audio.
>
> 2. Signed language tag in audio media, can mean audio from a signing
> person. That could be anything between near silence and spoken words
> corresponding to the signed signs as far as feasible. This is usually see=
n
> as disturbing to sign language users but it exists, e.g. when one erson
> needs to communicate with both hearing and deaf persons simultaneously.
> There are also variants of signing, called sign supported language, with
> signs expressed with spoken language word order and grammar. That can mor=
e
> easily be combined with spoken language, but would more likely be indicat=
ed
> by spoken language tag in audio media.
> Summary: I am inclined to let signed language tag in audio media mean
> audio from the signing person and possibly used for the rare cases when i=
t
> has some relevance for language communication.
>
> 3. Sign language tag in text media. There are some ways to represent sign
> language in various kinds of symbol or text representation. Some are
> represented in Unicode. One is a system called Sign Writing. Some
> fingerspelling methods also have fonts corresponding to characters in cod=
e
> pages. There is also an informal way to write manuscripts for signing in
> words with capitals approximately corresponding to signs, often with some
> notation added for unique sign language ways of expression that has no
> direct correspondance to words. None of these systems above are common in
> real-time conversation, but I have seen examples of such use.
> Summary: I think we can leave freedom here and just specify that a sign
> language tag in text media means some representation of sign language or =
a
> corresponding fingerspelling system in text media.
>
> If these conclusions are accepted, we can formulate modified text. Note
> that the case with spoken/written language tag in video media is mentione=
d
> in two places in the draft.
>
> Regards
> Gunnar
>
>
>
>
> _______________________________________________
> SLIM mailing listSLIM@ietf.orghttps://www.ietf.org/mailman/listinfo/slim
>
>
> --
> -----------------------------------------
> Gunnar Hellstr=C3=B6m
> Omnitorgunnar.hellstrom@omnitor.se
> +46 708 204 288
>
>

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


Gunnar said:=C2=A0

"With some hesitation I suggest to let it mean to see a s=
peaking person."
[BA] Is this for the pu=
rpose of enabling lip reading?

Assuming that we go that way, how would captioning be=
 negotiated? =C2=A0

On Mon, Feb 13, 2017 at 1:23 PM, Gunnar Hellstr=C3=B6m=
 <gunnar.hellstrom@omnitor.se> wrote:

 =20
   =20
 =20
  

    
Bernard,

    
I just issued comments where I also included the "silly states&=
quot;
      topic with similar views as yours.

    

    

    
Den 2017-02-13 kl.=
 20:06, skrev Bernard
      Aboba:

    

    

      

          
Looking over Section 5.4, it seems to me that the title
            "Silly States" may not be appropriate, because it mix=
es
            discussion of combinations=C2=
=A0of
              media and language that have an "undefined" meaning=
 with
              combinations=C2=A0for
              which normative guidance can be provided =C2=A0So rather than
              having a single "Silly States" section, perhaps we =
can
              have a section on "Undefined States" (for those
              combinations which have an undefined meaning) provide
              normative guidance on defined combinations elsewhere.<=
/div>
          


          

          

            
5.4.  Silly States


   It is possible to specify a "silly state" where the language
   specified does not make sense for the media type, such as specifying
   a signed language for an audio media stream.

            
   An o=
ffer MUST NOT be created where the language does not make sense
   for the media type.  If such an offer is received, the receiver MAY
   reject the media, ignore the language specified, or attempt to
   interpret the intent (e.g., if American Sign Language is specified
   for an audio media stream, this might be interpreted as a desire to
   use spoken English).

   A spoken language tag for a video stream in conjunction with an audio
   stream with the same language might indicate a request for
   supplemental video to see the speaker.

            

            
[BA] Ra=
ther than using terms like "might" for combinations that could ha=
ve a

            
defined=
 meaning, I would like to see the specification provide normative 

            
languag=
e on these use cases. In particular, I would like the specification to desc=
ribe: 

            

            
a. What=
 it means when a spoken language tag is included for a video stream. 

            
Is this=
 to be interpreted as a request for captioning?

            
b. What=
 it means when a signed language tag is included for an audio stream.

            
Is the =
meaning of this "undefined" and if so, should it be ignored?
            
c. What=
 it means when a signed language tag is included for a text stream.

            

            
If some=
 of these scenarios are not defined, the specification can say

            
"t=
his combination does not have a defined meaning" or something like tha=
t.

          

        

    

    See my recent comments for more views. I support the idea to be
    normative and specific when possible.

    A complication is that there is no difference between language tags
    for written and spoken language. 

    

    So we have the following possible combinations and interpretations
    of "silly states"

    

    1. Spoken/written tag in video media, can mean to see a speaking
    person, or to provide captions overlayed on video.

    With some hesitation I suggest to let it mean to see a speaking
    person. The draft adds a requirement to have the same language in
    the audio stream in the same direction to have that interpretation.=C2=
=A0
    Should that mean that if there is another language in the audio
    stream, then the spoken/written tag in the video stream should mean
    captions in the specified language? That sounds useful for some
    cases, but complex to interpret and unfair to the users who would
    benefit from captions in the same language as in audio. 

    Summary: I think we had better to use the interpretation to see a
    speaking person regardless of what language is indicated for audio.

    

    2. Signed language tag in audio media, can mean audio from a signing
    person. That could be anything between near silence and spoken words
    corresponding to the signed signs as far as feasible. This is
    usually seen as disturbing to sign language users but it exists,
    e.g. when one erson needs to communicate with both hearing and deaf
    persons simultaneously. There are also variants of signing, called
    sign supported language, with signs expressed with spoken language
    word order and grammar. That can more easily be combined with spoken
    language, but would more likely be indicated by spoken language tag
    in audio media.

    Summary: I am inclined to let signed language tag in audio media
    mean audio from the signing person and possibly used for the rare
    cases when it has some relevance for language communication. 

    

    3. Sign language tag in text media. There are some ways to represent
    sign language in various kinds of symbol or text representation.
    Some are represented in Unicode. One is a system called Sign
    Writing. Some fingerspelling methods also have fonts corresponding
    to characters in code pages. There is also an informal way to write
    manuscripts for signing in words with capitals approximately
    corresponding to signs, often with some notation added for unique
    sign language ways of expression that has no direct correspondance
    to words. None of these systems above are common in real-time
    conversation, but I have seen examples of such use.

    Summary: I think we can leave freedom here and just specify that a
    sign language tag in text media means some representation of sign
    language or a corresponding fingerspelling system in text media. 

    =C2=A0=C2=A0 =C2=A0 

    If these conclusions are accepted, we can formulate modified text.
    Note that the case with spoken/written language tag in video media
    is mentioned in two places in the draft.

    

    Regards

    Gunnar

    =C2=A0

    

      

      

      

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


    

    

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

  






--001a114dcffac6b08e0548708bab--


From nobody Mon Feb 13 14:21:42 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 27A5B12998C; Mon, 13 Feb 2017 14:21:41 -0800 (PST)
X-Quarantine-ID: 
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -1.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 zRPJPoCsGk1r; Mon, 13 Feb 2017 14:21:39 -0800 (PST)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 2C38512942F; Mon, 13 Feb 2017 14:21:39 -0800 (PST)
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Mon, 13 Feb 2017 14:13:52 -0800
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <21d6ddb3-ebbd-833e-f5ff-800bdf144d2d@omnitor.se>
References: <148639487217.18865.13611191877947090796.idtracker@ietfa.amsl.com> <21d6ddb3-ebbd-833e-f5ff-800bdf144d2d@omnitor.se>
X-Mailer: Eudora for Mac OS X
Date: Mon, 13 Feb 2017 14:18:15 -0800
To: Gunnar =?iso-8859-1?Q?Hellstr=F6m?=  , "slim@ietf.org" , ietf@ietf.org
From: Randall Gellens 
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
Archived-At: 
Subject: Re: [Slim] Last Call:  (Negotiating Human Language in Real-Time Communications) to Proposed Standard
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Feb 2017 22:21:41 -0000

Hi Gunnar,

Please see inline.

At 11:34 AM +0100 2/13/17, Gunnar Hellstr=F6m wrote:

>  I have reviewed=20
> draft-ietf-slim-negotiating-human-language-06.txt=20
> and have composed a proposed edited version=20
> adjusted for my comments below, and=20
> additionally for some minor editorial issues.
>
>  The attached version is a rough edit of the txt=20
> file version. Accepted edits need to be re-done=20
> in the XML version.
>
>  Please use a diff to find all edit proposals.=20
> The main ones are listed below with reference=20
> to sections in the files.
>
>=20
> --------------------------------------------------------------------------=
-----------------------
>
>  1. Inexact wording about the syntax of the new attributes.
>
>  Sections 5 and 5.2,  .
>
>  The text sometimes indicate that the value of=20
> the attributes is a language tag, and sometimes=20
> a language tag with an optionally appended=20
> asterisk. The syntax shown in section 5.2 is=20
> also not in alignment with the syntax shown in=20
> section 6. In 5.2 it is shown without the=20
> optional asterisk, and in 6 with the optional=20
> asterisk.

I will delete the syntax description from 5.2 to avoid confusion.

>
>  Proposed action:  Make the attribute syntax=20
> equal in sections 5.2 and 6. Make sure that=20
> when "Language-Tag" is mentioned, it is only=20
> about the language tag part of the attribute=20
> value, and when the attribute value is=20
> mentioned, it is about the complete value,=20
> including the optional modifier.
>
>  Changes:
>
>  Last line in 5.  Change "be" to "contain"
>
>  Add [ asterisk ] last in both syntax lines in 5.2.

I will adjust the text in the last line of 5 and=20
clarify the text for the use of "the values" in=20
5.2.

>
>  Multiple small changes in section 5.2. to=20
> adjust wording to be more exact. - See attached=20
> draft.
>
>=20
> --------------------------------------------------------------------------=
------------------------------------------------------
>
>  2. Reminiscense of earlier syntax.
>
>  In a couple of places, there is wording left=20
> over from a recently abandoned syntax for the=20
> attributes. In an earlier version, each=20
> attribute value could contain multiple=20
> language-tags. Now, there is just one=20
> language-tag in each attribute value.
>
>  Changes:
>  At end of page 6:
>  Old:  "The values constitute a list of languages in preference order"
>
>  New: "The values from multiple attributes=20
> constitute a list of languages in preference=20
> order per direction"
>
>  At end of Section 5.3, the comparison with=20
> Accept-Language syntax is not valid anymore.
>
>  Delete: "(similar to SIP Accept-Language syntax)"

OK.

>
>=20
> --------------------------------------------------------------------------=
--------------------------------------------------------
>
>  3. Inexact wording about O/A procedure in section 5.2
>
>  The answers are called "accepted language", but=20
> within paranthesis it is mentioned that it is=20
> only in most cases that it is selected from the=20
> offer. More suitable is then to just call it=20
> just "language":
>
>  Old:
>  " In an answer, 'humintlang-send' is the accepted language the answerer
>  will send (which in most cases is one of the languages in the offer's
>  'humintlang-recv'), and 'humintlang-recv' is the accepted language
>  the answerer expects to receive (which in most cases is one of the
>  languages in the offer's 'humintlang-send')."
>
>  New:
>
>  "In an answer, 'humintlang-send' indicates the language the answerer
>  will send (which in most cases is one of the languages in the offer's
>  'humintlang-recv'), and 'humintlang-recv' indicates the language
>  the answerer expects to receive (which in most cases is one of the
>  languages in the offer's 'humintlang-send')."

I will delete the two instances of "accepted" in 5.3.

>
>=20
> --------------------------------------------------------------------------=
---------------------
>
>  4. Inexact note at end of section 5.2.
>
>  The note at end of 5.2 has a short discussion=20
> about accepted media as if it should possibly=20
> be influenced by the matching languages. This=20
> discussion is not really valid. A media section=20
> is a request to set up a media stream,=20
> unrelated to the language indications. The=20
> devices should deny media because they are not=20
> needed for language communication. This is made=20
> more clear in an extended note.
>
>  Old:
>
>      "Note that media and language negotiation might result in more media
>      streams being accepted than are needed by the users (e.g., if more
>      preferred and less preferred combinations of media and language are
>      all accepted)."
>
>  New:
>
>  "Note that media and language negotiation might result in more media
>  streams being accepted than are needed by the users for language
>  exchange (e.g., if more preferred and less preferred combinations
>  of media and language are all accepted). This is normal and accepted,
>  because the humintlang attribute is not intended to restrict media
>  streams to be used only for language exchange."

I'll clarify the text.

>
>=20
> --------------------------------------------------------------------------=
-------
>
>  5. Make use of the asterisk modifier on media=20
> level with session scope also for media level=20
> purposes
>
>  The asterisk modifier optionally appended on=20
> attribute values has in the original -06 draft=20
> only a session effect. It is specified to=20
> indicate if the call should be rejected or not=20
> if languages do not match. It can be appended=20
> to any humintlang attribute in the whole SDP=20
> without any change in effect. This independancy=20
> of placement indicates that it is wrongly=20
> placed. With the current definition, it should=20
> be a single separate session level attribute.=20
> Instead of specifying a separate session level=20
> attribute, it is proposed that the asterisk=20
> gets an expanded definition, so that its=20
> placement conveys meaning of value for the=20
> successful language negotiation.
>
>  It has been discussed in the SLIM WG that the=20
> specification lacks two functions, required by=20
> the specifications by other bodies who are=20
> waiting for the results of SLIM real-time work.=20
> (e.g. 3GPP TS 22.228 and ETSI TR 103 201). 3GPP=20
> TS 22.228 requires "The system should be able=20
> to negotiate the user's desired language(s) and=20
> modalities, per media stream and/or session, in=20
> order of preference." Thus negotiation
>  with preference indication within the session=20
> is required, not only within each media.
>  ETSI TR 103 201 says "the Total Conversation=20
> user should be able to indicate the preferred=20
> method of communication for each direction of=20
> the session, so that the call-taker can be=20
> selected appropriately or an appropriate=20
> assisting service be invoked. " Saying=20
> "preferred" means
>  that it should also be possible to indicate less preferred alternatives.
>
>  The most urgent of these functions can be=20
> fulfilled in a simple but sufficient way by=20
> extending the meaning of the asterisk. That is=20
> the possibility to indicate a difference in=20
> preference between languages in different=20
> modalities. There is an apparent risk that many=20
> calls will start and continue in an=20
> inconvenient modaity if this differentiation is=20
> not introduced. See the proposed replaced=20
> section 5.3 and extended examples in section=20
> 5.5.
>
>  Earlier discussions on this topic has not=20
> resulted in a sufficiently simple mechanism.=20
> The extended use of the asterisk proposed here=20
> is intended to introduce the required=20
> simplification, and yet meet the most urgent=20
> needs.

The WG discussed various proposals regarding the=20
asterisk and did not reach a conclusion to change=20
what is in the draft.

>
>
>  Changes:
>
>  In 5.2
>
>  Old:
>
>  "In an offer, each language tag value MAY have an asterisk appended as
>  the last character (after the language tag).  The asterisk indicates
>  a request by the caller to not fail the call if there is no language
>  in common."
>
>  New:
>
>  "In an offer or answer, each attribute value=20
> MAY have a modifier appended as the last=20
> character (after the Language-Tag). This=20
> specification defines one value for the=20
> modifier; an asterisk ("*"). The asterisk=20
> included in a humintlang attribute value in the=20
> SDP indicates a lower preference for the=20
> indicated language and a request by the caller=20
> to not reject the call if there is no language=20
> in common."
>
>  In 5.3. The whole section replaced by:
>
>  "
>  5.3.  Preferences within the session
>
>  It is of high importance for a smooth start of a call that the
>  answering party is answering the call using the best matching
>  language(s) and modality(ies) suitable for the continuation of the call.
>  Switching language and modality during the call by agreement between
>  the participants is often time consuming. Without support of detailed
>  language and modality negotiation the particiants may have a tendency
>  to continue the call in the initial language and modality even if a
>  more convenient common language and modality combination is available.
>  In order to support the decision on which of the available language(s)
>  and modality(ies) to use initially in the call, a simple two-level
>  preference indicator is specified here for inclusion as a modifier
>  in the humintlang attribute values. The preference indicator is also
>  used as an indicator that the call SHOULD be established even if no
>  language match is found.
>
>  The asterisk ("*") is used as a preference indicator within the session.
>  Low relative preference for a language and modality to be used in the
>  session SHOULD be indicated by appending an asterisk after the language
>  tag in the attribute value. This indication from the offering party
>  SHOULD be interpreted by the answering party as a request to use a
>  higher preferred language and modality when answering the call if
>  available, but otherwise accept a lower preferred language and
>  modality combination if that is available. When satisfying languages
>  and modalities in the offer is regarded to be so important that the
>  whole call SHOULD be rejected if no match can be provided in the
>  session in one or both directions, then the asterisk shall not be
>  appended on any indicated language in the whole session description.
>  For the case when no specific preference is desired, but the offering
>  party does not want the call to be rejected, all indicated languages
>  and modalities SHOULD have an asterisk appended.
>
>  In an answer, the language(s) and modality(ies) that the answering
>  party will use initially in the answer SHOULD be indicated without
>  an appended asterisk. Any language and modality available for later
>  use in the session MAY be indicated by a language tag with an
>  appended asterisk.
>
>  In the case when more than two parties participate in the call,
>  the language and modality indications provided to each party
>  SHOULD be the sum of the indications from the other parties.
>
>  The use of the preference indicator as specified above does
>  not provide for distinguishing between the case when two or
>  more language/modality combinations in the same direction
>  are desired for use simultaneously versus the case when two
>  or more language/modality combinations for the same directions
>  are provided as selectable alternatives without specific
>  preference differentiation. The context or other specifications
>  may introduce the possibility to distinguish between these cases.
>  When a party in a call has no indications that two or more
>  language/modality combinations for each direction are desired
>  simultaeously in the call, the party SHOULD assume that
>  satisfying one is sufficient.
>
>  Other specifications may add other attribute value modifiers than
>  the asterisk. If an unknown modifier is detected, the modifier
>  SHALL be ignored."
>
>  In section 6.
>
>  Reference to semantics in the attribute=20
> registrations are expanded from 5.2 to 5.2-5.3.
>
>=20
> --------------------------------------------------------------------------=
-------------------------
>
>  6. The cases in the "Silly states" section 5.4 are not all silly.
>
>  Section 5.4 contains some proposed=20
> interpretations of unusual language indications.
>
>  They are not silly, but just unusual. Therefore=20
> change the name of the section to
>
>  "5.4 Unusual indications"
>
>  The section contains too weak specification=20
> about what to do with the unusual indications.=20
> That may cause a risk that a user who gets=20
> accustomed to one behavior in contact with=20
> certain UAs, suddeenly gets another behavior in=20
> contact with another UA.
>
>  Change:
>  Old:
>
>  "An offer MUST NOT be created where the language does not make sense
>  for the media type.  If such an offer is received, the receiver MAY
>  reject the media, ignore the language specified, or attempt to
>  interpret the intent (e.g., if American Sign Language is specified
>  for an audio media stream, this might be interpreted as a desire to
>  use spoken English)."
>
>  To:
>
>  "An offer MUST NOT be created where the language does not make sense
>  for the media type.  If such an offer is received, the receiver SHOULD
>  ignore the language specified."

OK.

>
>
>  Also add the following at the end of 5.4 to=20
> explain the choice of interpretation of a=20
> spoken/written language tag in a video medium=20
> to be a request to see the speaker rather than=20
> having text captions overlayed on video.
>
>  "There is no difference between language tags for spoken and written
>  languages. The spoken or written language tag indicated for a video
>  stream could therefore be interpreted as a capability or request to
>  use text captions overlayed on the video stream. The interpretation
>  according to this specification SHALL however be to have a view of
>  the speaker."

I don't think we need to talk about how to=20
interpret non-signed language tags in a video=20
stream.

>
>=20
> --------------------------------------------------------------------------=
---------------------------------
>
>  7. Examples section 5.5 requires expansion
>
>  Section 5.5 Examples has very little=20
> explanations and show just a few cases. The=20
> section is proposed to be expanded, with O/A=20
> examples with descriptions and alternative=20
> outcomes in order to more thoroughly describe=20
> the intended use.
>
>  See 5.5 in the the attached file for the proposed expansion.
>
>=20
> --------------------------------------------------------------------------=
----------------------------------
>
>  8. Include more fields for attribute registration from 4566bis
>
>  Section 6 has the form for attribute=20
> registration by IANA. There are a couple of=20
> fields missing that will be important for use=20
> of the specification in the WebRTC environment.=20
> Include these fields if that is allowable=20
> according to current IANA procedures and if=20
> that does not delay the publication of this=20
> draft. These fields are needed for use of text=20
> media in WebRTC.
>
>  Change:
>
>  In two locations from:
>      "Usage Level:  media"
>
>  to:
>
>      "Usage Level:  media, dcsa(subprotocol)"
>
>  Insert in two locations in the registration forms:
>  "Mux Category: NORMAL"


I think this suggestion exceeds a simple=20
editorial change, and therefore would need to be=20
discussed on the WG list with WG consensus before=20
it can be adopted.  I would also note that these=20
fields can be added to the attribute registration=20
later, according to the rules for the registry=20
(http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xhtml),=20
which I believe are "Specification Required."

>
>=20
> --------------------------------------------------------------------------=
-------------------------------------
>
>
>  With these proposed modifications accepted I am=20
> convinced that the result will be useful for=20
> its purpose.
>
>  Regards
>
>  Gunnar Hellstrom
>
>  -----------------------------------------
>  Gunnar Hellstr=F6m
>  Omnitor
>  gunnar.hellstrom@omnitor.se
>  +46 708 204 288
>
>
>
>
>  Den 2017-02-06 kl. 16:27, skrev The IESG:
>>  The IESG has received a request from the Selection of Language for
>>  Internet Media WG (slim) to consider the following document:
>>  - 'Negotiating Human Language in Real-Time Communications'
>>      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-02-20. Exceptionally, comments may b=
e
>>  sent to iesg@ietf.org instead. In either case, please retain the
>>  beginning of the Subject line to allow automated sorting.
>>
>>  Abstract
>>
>>
>>      Users have various human (natural) language needs, abilities, and
>>      preferences regarding spoken, written, and signed languages.  When
>>      establishing interactive communication ("calls") there needs to be a
>>      way to negotiate (communicate and match) the caller's language and
>>      media needs with the capabilities of the called party.  This is
>>      especially important with emergency calls, where a call can be
>>      handled by a call taker capable of communicating with the user, or a
>>      translator or relay operator can be bridged into the call during
>>      setup, but this applies to non-emergency calls as well (as an
>>      example, when calling a company call center).
>>
>>      This document describes the need and a solution using new SDP stream
>>      attributes.
>>
>>
>>
>>
>>  The file can be obtained via
>>  https://datatracker.ietf.org/doc/draft-ietf-slim-negotiating-human-langu=
age/
>>
>>  IESG discussion can be tracked via
>>=20
>> https://datatracker.ietf.org/doc/draft-ietf-slim-negotiating-human-langua=
ge/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-saintandre-sip-xmpp-chat:=20
>> Interworking between the Session Initiation=20
>> Protocol (SIP) and the Extensible Messaging=20
>> and Presence Protocol (XMPP): One-to-One Text=20
>> Chat (None - )
>>  Note that some of these references may already=20
>> be listed in the acceptable Downref Registry.
>>
>
>  --
>  -----------------------------------------
>  Gunnar Hellstr=F6m
>  Omnitor
>  gunnar.hellstrom@omnitor.se
>  +46 708 204 288
>
>
>
>
>  Attachment converted:=20
> TiLand:draft-ietf-slim-nego#41BE1A.txt=20
> (TEXT/R*ch) (0041BE1A)
>  _______________________________________________
>  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: ---------------
Voltaire said "The art of government consists of taking as much money
as possible from one party of citizens to give to the other."  The
difference between the dominant political parties is which groups they
assign which roles.


From nobody Mon Feb 13 14:23: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 CD1FC129994 for ; Mon, 13 Feb 2017 14:23:20 -0800 (PST)
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=unavailable 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 ixW_xhC75oCB for ; Mon, 13 Feb 2017 14:23:17 -0800 (PST)
Received: from bin-vsp-out-03.atm.binero.net (vsp-unauthed02.binero.net [195.74.38.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16FB812998C for ; Mon, 13 Feb 2017 14:23:16 -0800 (PST)
X-Halon-ID: f7c137f6-f23a-11e6-9c99-0050569116f7
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [83.209.158.27]) by bin-vsp-out-03.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Mon, 13 Feb 2017 23:22:55 +0100 (CET)
To: Bernard Aboba 
References:  <64c8d9d7-9df8-023e-6d47-4807cc0e30b7@omnitor.se> 
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: <6dc77c0f-6d3d-5945-e936-6f7523003b9c@omnitor.se>
Date: Mon, 13 Feb 2017 23:23:12 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------D4945B31890E75A6F10555B3"
Archived-At: 
Cc: slim@ietf.org, ietf@ietf.org
Subject: Re: [Slim] IETF last call for draft-ietf-slim-negotiating-human-language (Section 5.4)
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Feb 2017 22:23:21 -0000

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

Den 2017-02-13 kl. 22:58, skrev Bernard Aboba:
> Gunnar said:
>
> "With some hesitation I suggest to let it mean to see a speaking person."
>
> [BA] Is this for the purpose of enabling lip reading?
Yes
>
> Assuming that we go that way, how would captioning be negotiated?
It is best placed in text media.

But captions overlayed on video in the media stream is a used technology 
so it would be good to be able to specify it.
That we cannot do it is again a sad effect of the language tags not 
distinguishing between spoken and written modality.
I once had an ambition to try to specify a notation for that to be added 
to BCP 47, but did not succeed to get any real discussion going on the 
topic.

Eventually there may be a need to specify a Modality attribute. That may 
be needed for media specified e.g. as m=application where the protocol 
can carry all kinds of modality and it is not apparent from the m-line 
what it is. These are however not common for real-time conversational 
purposes, so I do not think it is urgent to solve the problem for 
m=application now.  But maybe for captioning in video media?

/Gunnar


>
> On Mon, Feb 13, 2017 at 1:23 PM, Gunnar Hellström 
> > wrote:
>
>     Bernard,
>
>     I just issued comments where I also included the "silly states"
>     topic with similar views as yours.
>
>
>     Den 2017-02-13 kl. 20:06, skrev Bernard Aboba:
>>     Looking over Section 5.4, it seems to me that the title "Silly
>>     States" may not be appropriate, because it mixes discussion of
>>     combinations of media and language that have an "undefined"
>>     meaning with combinations for which normative guidance can be
>>     provided  So rather than having a single "Silly States" section,
>>     perhaps we can have a section on "Undefined States" (for those
>>     combinations which have an undefined meaning) provide normative
>>     guidance on defined combinations elsewhere.
>>
>>
>>           5.4
>>           .
>>           Silly States
>>
>>
>>
>>         It is possible to specify a "silly state" where the language
>>         specified does not make sense for the media type, such as specifying
>>         a signed language for an audio media stream.
>>         An offer MUST NOT be created where the language does not make sense
>>         for the media type.  If such an offer is received, the receiver MAY
>>         reject the media, ignore the language specified, or attempt to
>>         interpret the intent (e.g., if American Sign Language is specified
>>         for an audio media stream, this might be interpreted as a desire to
>>         use spoken English).
>>
>>         A spoken language tag for a video stream in conjunction with an audio
>>         stream with the same language might indicate a request for
>>         supplemental video to see the speaker.
>>     [BA] Rather than using terms like "might" for combinations that could have a
>>     defined meaning, I would like to see the specification provide normative
>>     language on these use cases. In particular, I would like the specification to describe:
>>     a. What it means when a spoken language tag is included for a video stream.
>>     Is this to be interpreted as a request for captioning?
>>     b. What it means when a signed language tag is included for an audio stream.
>>     Is the meaning of this "undefined" and if so, should it be ignored?
>>     c. What it means when a signed language tag is included for a text stream.
>>     If some of these scenarios are not defined, the specification can say
>>     "this combination does not have a defined meaning" or something like that.
>     See my recent comments for more views. I support the idea to be
>     normative and specific when possible.
>     A complication is that there is no difference between language
>     tags for written and spoken language.
>
>     So we have the following possible combinations and interpretations
>     of "silly states"
>
>     1. Spoken/written tag in video media, can mean to see a speaking
>     person, or to provide captions overlayed on video.
>     With some hesitation I suggest to let it mean to see a speaking
>     person. The draft adds a requirement to have the same language in
>     the audio stream in the same direction to have that
>     interpretation.  Should that mean that if there is another
>     language in the audio stream, then the spoken/written tag in the
>     video stream should mean captions in the specified language? That
>     sounds useful for some cases, but complex to interpret and unfair
>     to the users who would benefit from captions in the same language
>     as in audio.
>     Summary: I think we had better to use the interpretation to see a
>     speaking person regardless of what language is indicated for audio.
>
>     2. Signed language tag in audio media, can mean audio from a
>     signing person. That could be anything between near silence and
>     spoken words corresponding to the signed signs as far as feasible.
>     This is usually seen as disturbing to sign language users but it
>     exists, e.g. when one erson needs to communicate with both hearing
>     and deaf persons simultaneously. There are also variants of
>     signing, called sign supported language, with signs expressed with
>     spoken language word order and grammar. That can more easily be
>     combined with spoken language, but would more likely be indicated
>     by spoken language tag in audio media.
>     Summary: I am inclined to let signed language tag in audio media
>     mean audio from the signing person and possibly used for the rare
>     cases when it has some relevance for language communication.
>
>     3. Sign language tag in text media. There are some ways to
>     represent sign language in various kinds of symbol or text
>     representation. Some are represented in Unicode. One is a system
>     called Sign Writing. Some fingerspelling methods also have fonts
>     corresponding to characters in code pages. There is also an
>     informal way to write manuscripts for signing in words with
>     capitals approximately corresponding to signs, often with some
>     notation added for unique sign language ways of expression that
>     has no direct correspondance to words. None of these systems above
>     are common in real-time conversation, but I have seen examples of
>     such use.
>     Summary: I think we can leave freedom here and just specify that a
>     sign language tag in text media means some representation of sign
>     language or a corresponding fingerspelling system in text media.
>
>     If these conclusions are accepted, we can formulate modified text.
>     Note that the case with spoken/written language tag in video media
>     is mentioned in two places in the draft.
>
>     Regards
>     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
>
> _______________________________________________
> 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

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


  
    
  
  
    Den 2017-02-13 kl. 22:58, skrev Bernard Aboba:

    

      
Gunnar said: 
        


        

        
"With some hesitation I
            suggest to let it mean to see a speaking person."

      

    

    

      

        


          

        
[BA] Is this for the purpose
            of enabling lip reading?

      

    

    Yes

    

      

        


        

        
Assuming that we go that
            way, how would captioning be negotiated?  

          

      

    

    It is best placed in text media. 

    

    But captions overlayed on video in the media stream is a used
    technology so it would be good to be able to specify it.

    That we cannot do it
    is again a sad effect of the language tags not distinguishing
    between spoken and written modality.

    I once had an ambition to try to specify a notation for that to be
    added to BCP 47, but did not succeed to get any real discussion
    going on the topic. 

    

    Eventually there may be a need to specify a Modality attribute. That
    may be needed for media specified e.g. as m=application where the
    protocol can carry all kinds of modality and it is not apparent from
    the m-line what it is. These are however not common for real-time
    conversational purposes, so I do not think it is urgent to solve the
    problem for m=application now.  But maybe for captioning in video
    media?

    

    /Gunnar 

    

    

    

      


        
On Mon, Feb 13, 2017 at 1:23 PM, Gunnar
          Hellström <gunnar.hellstrom@omnitor.se>
          wrote:

          

            

              
Bernard,

              
I just issued comments where I also included the "silly
                states" topic with similar views as yours.

              

              

                
 

                  
Den
                    2017-02-13 kl. 20:06, skrev Bernard Aboba:

                  

                  

                    

                        
Looking over Section 5.4, it seems to me
                          that the title "Silly States" may not be
                          appropriate, because it mixes discussion of
                          combinations of
                            media and language that have an "undefined"
                            meaning with combinations for which normative
                            guidance can be provided  So rather than
                            having a single "Silly States" section,
                            perhaps we can have a section on "Undefined
                            States" (for those combinations which have
                            an undefined meaning) provide normative
                            guidance on defined combinations elsewhere.

                        


                        

                        

                          
5.4.  Silly States


   It is possible to specify a "silly state" where the language
   specified does not make sense for the media type, such as specifying
   a signed language for an audio media stream.

                          
   An offer MUST NOT be created where the language does not make sense
   for the media type.  If such an offer is received, the receiver MAY
   reject the media, ignore the language specified, or attempt to
   interpret the intent (e.g., if American Sign Language is specified
   for an audio media stream, this might be interpreted as a desire to
   use spoken English).

   A spoken language tag for a video stream in conjunction with an audio
   stream with the same language might indicate a request for
   supplemental video to see the speaker.

                          
[BA] Rather than using terms like "might" for combinations that could have a

                          
defined meaning, I would like to see the specification provide normative 

                          
language on these use cases. In particular, I would like the specification to describe: 

                          
a. What it means when a spoken language tag is included for a video stream. 

                          
Is this to be interpreted as a request for captioning?

                          
b. What it means when a signed language tag is included for an audio stream.

                          
Is the meaning of this "undefined" and if so, should it be ignored?

                          
c. What it means when a signed language tag is included for a text stream.

                          
If some of these scenarios are not defined, the specification can say

                          
"this combination does not have a defined meaning" or something like that.

                        

                      

                  

                

              

              See my recent comments for more views. I support the idea
              to be normative and specific when possible.

              A complication is that there is no difference between
              language tags for written and spoken language. 

              

              So we have the following possible combinations and
              interpretations of "silly states"

              

              1. Spoken/written tag in video media, can mean to see a
              speaking person, or to provide captions overlayed on
              video.

              With some hesitation I suggest to let it mean to see a
              speaking person. The draft adds a requirement to have the
              same language in the audio stream in the same direction to
              have that interpretation.  Should that mean that if there
              is another language in the audio stream, then the
              spoken/written tag in the video stream should mean
              captions in the specified language? That sounds useful for
              some cases, but complex to interpret and unfair to the
              users who would benefit from captions in the same language
              as in audio. 

              Summary: I think we had better to use the interpretation
              to see a speaking person regardless of what language is
              indicated for audio.

              

              2. Signed language tag in audio media, can mean audio from
              a signing person. That could be anything between near
              silence and spoken words corresponding to the signed signs
              as far as feasible. This is usually seen as disturbing to
              sign language users but it exists, e.g. when one erson
              needs to communicate with both hearing and deaf persons
              simultaneously. There are also variants of signing, called
              sign supported language, with signs expressed with spoken
              language word order and grammar. That can more easily be
              combined with spoken language, but would more likely be
              indicated by spoken language tag in audio media.

              Summary: I am inclined to let signed language tag in audio
              media mean audio from the signing person and possibly used
              for the rare cases when it has some relevance for language
              communication. 

              

              3. Sign language tag in text media. There are some ways to
              represent sign language in various kinds of symbol or text
              representation. Some are represented in Unicode. One is a
              system called Sign Writing. Some fingerspelling methods
              also have fonts corresponding to characters in code pages.
              There is also an informal way to write manuscripts for
              signing in words with capitals approximately corresponding
              to signs, often with some notation added for unique sign
              language ways of expression that has no direct
              correspondance to words. None of these systems above are
              common in real-time conversation, but I have seen examples
              of such use.

              Summary: I think we can leave freedom here and just
              specify that a sign language tag in text media means some
              representation of sign language or a corresponding
              fingerspelling system in text media. 

                   

              If these conclusions are accepted, we can formulate
              modified text. Note that the case with spoken/written
              language tag in video media is mentioned in two places in
              the draft.

              

              Regards

              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

  











_______________________________________________
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

--------------D4945B31890E75A6F10555B3--


From nobody Mon Feb 13 14:27:33 2017
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35828129997; Mon, 13 Feb 2017 14:27:32 -0800 (PST)
X-Quarantine-ID: 
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -1.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 NApbPRhqef7U; Mon, 13 Feb 2017 14:27:30 -0800 (PST)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id C45BF129439; Mon, 13 Feb 2017 14:27:30 -0800 (PST)
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Mon, 13 Feb 2017 14:19:44 -0800
Mime-Version: 1.0
Message-Id: 
In-Reply-To: 
References: 
X-Mailer: Eudora for Mac OS X
Date: Mon, 13 Feb 2017 14:26:28 -0800
To: Bernard Aboba , slim@ietf.org, ietf@ietf.org
From: Randall Gellens 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
Archived-At: 
Subject: Re: [Slim] IETF last call for draft-ietf-slim-negotiating-human-language (Section 5.4)
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Feb 2017 22:27:32 -0000

At 11:06 AM -0800 2/13/17, Bernard Aboba wrote:

>  Looking over Section 5.4, it seems to me that the title "Silly 
> States" may not be appropriate, because it mixes discussion of 
> combinations of media and language that have an "undefined" meaning 
> with combinations for which normative guidance can be provided  So 
> rather than having a single "Silly States" section, perhaps we can 
> have a section on "Undefined States" (for those combinations which 
> have an undefined meaning) provide normative guidance on defined 
> combinations elsewhere.
>
> 
> 5.4. 
> Silly States
>
>
>
>     It is possible to specify a "silly state" where the language
>     specified does not make sense for the media type, such as specifying
>     a signed language for an audio media stream.
>     An offer MUST NOT be created where the language does not make sense
>     for the media type.  If such an offer is received, the receiver MAY
>     reject the media, ignore the language specified, or attempt to
>     interpret the intent (e.g., if American Sign Language is specified
>     for an audio media stream, this might be interpreted as a desire to
>     use spoken English).
>
>     A spoken language tag for a video stream in conjunction with an audio
>     stream with the same language might indicate a request for
>     supplemental video to see the speaker.
>
>  [BA] Rather than using terms like "might" for combinations that could have a
>  defined meaning, I would like to see the specification provide normative
>  language on these use cases. In particular, I would like the 
> specification to describe:
>
>  a. What it means when a spoken language tag is included for a video stream.
>  Is this to be interpreted as a request for captioning?
>  b. What it means when a signed language tag is included for an audio stream.
>  Is the meaning of this "undefined" and if so, should it be ignored?
>  c. What it means when a signed language tag is included for a text stream.
>
>  If some of these scenarios are not defined, the specification can say
>  "this combination does not have a defined meaning" or something like that.

I will change the section title to "Undefined Combinations" and 
replace the text with:

    Specifying a non-signed language tag for a video media stream, or a
    signed language tag for a non-video media stream, is not defined.  An
    offer with such a combination SHOULD NOT be created.  If such an
    offer is received, the receiver MAY ignore the language specified.

I think this retains the intent of the old section while avoiding 
wading into the unclear issue of intent of such combinations.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
I suppose when it gets to that point, we shan't know how it does it.
    --Alan Turing


From nobody Mon Feb 13 15:10: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 DFA841294D6 for ; Mon, 13 Feb 2017 15:10:01 -0800 (PST)
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 B65lTam2ZQAg for ; Mon, 13 Feb 2017 15:09:59 -0800 (PST)
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 86C201299A1 for ; Mon, 13 Feb 2017 15:09:59 -0800 (PST)
X-Halon-ID: 84449b9f-f241-11e6-a131-005056917a89
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [83.209.158.27]) by bin-vsp-out-01.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Tue, 14 Feb 2017 00:09:48 +0100 (CET)
To: Randall Gellens , Bernard Aboba , slim@ietf.org, ietf@ietf.org
References:  
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: <5625f5e6-740c-6364-1d64-5006a49f0581@omnitor.se>
Date: Tue, 14 Feb 2017 00:09:55 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
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] IETF last call for draft-ietf-slim-negotiating-human-language (Section 5.4)
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Feb 2017 23:10:02 -0000

Randall,

I prefer that you wait for conclusion on the topic of "silly states".

And I agree with Bernard that we should (and can) be normative and 
explicit in how to interpret all the unusual combinations.

/Gunnar


Den 2017-02-13 kl. 23:26, skrev Randall Gellens:
> At 11:06 AM -0800 2/13/17, Bernard Aboba wrote:
>
>>  Looking over Section 5.4, it seems to me that the title "Silly 
>> States" may not be appropriate, because it mixes discussion of 
>> combinations of media and language that have an "undefined" meaning 
>> with combinations for which normative guidance can be provided  So 
>> rather than having a single "Silly States" section, perhaps we can 
>> have a section on "Undefined States" (for those combinations which 
>> have an undefined meaning) provide normative guidance on defined 
>> combinations elsewhere.
>>
>>
>> 5.4. 
>> Silly States
>>
>>
>>
>>     It is possible to specify a "silly state" where the language
>>     specified does not make sense for the media type, such as specifying
>>     a signed language for an audio media stream.
>>     An offer MUST NOT be created where the language does not make sense
>>     for the media type.  If such an offer is received, the receiver MAY
>>     reject the media, ignore the language specified, or attempt to
>>     interpret the intent (e.g., if American Sign Language is specified
>>     for an audio media stream, this might be interpreted as a desire to
>>     use spoken English).
>>
>>     A spoken language tag for a video stream in conjunction with an 
>> audio
>>     stream with the same language might indicate a request for
>>     supplemental video to see the speaker.
>>
>>  [BA] Rather than using terms like "might" for combinations that 
>> could have a
>>  defined meaning, I would like to see the specification provide 
>> normative
>>  language on these use cases. In particular, I would like the 
>> specification to describe:
>>
>>  a. What it means when a spoken language tag is included for a video 
>> stream.
>>  Is this to be interpreted as a request for captioning?
>>  b. What it means when a signed language tag is included for an audio 
>> stream.
>>  Is the meaning of this "undefined" and if so, should it be ignored?
>>  c. What it means when a signed language tag is included for a text 
>> stream.
>>
>>  If some of these scenarios are not defined, the specification can say
>>  "this combination does not have a defined meaning" or something like 
>> that.
>
> I will change the section title to "Undefined Combinations" and 
> replace the text with:
>
>    Specifying a non-signed language tag for a video media stream, or a
>    signed language tag for a non-video media stream, is not defined.  An
>    offer with such a combination SHOULD NOT be created.  If such an
>    offer is received, the receiver MAY ignore the language specified.
>
> I think this retains the intent of the old section while avoiding 
> wading into the unclear issue of intent of such combinations.
>

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


From nobody Mon Feb 13 15:10: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 97E7E1298C6 for ; Mon, 13 Feb 2017 15:10:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.786
X-Spam-Level: 
X-Spam-Status: No, score=-3.786 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.887, URIBL_BLOCKED=0.001] autolearn=unavailable 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 JzgEaZDoLk6y for ; Mon, 13 Feb 2017 15:10:04 -0800 (PST)
Received: from p3plwbeout03-04.prod.phx3.secureserver.net (p3plsmtp03-04-2.prod.phx3.secureserver.net [72.167.218.216]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 923A61299A1 for ; Mon, 13 Feb 2017 15:10:02 -0800 (PST)
Received: from localhost ([72.167.218.132]) by p3plwbeout03-04.prod.phx3.secureserver.net with bizsmtp id kPA21u0032rz53401PA20y; Mon, 13 Feb 2017 16:10:02 -0700
X-SID: kPA21u0032rz53401
Received: (qmail 1405 invoked by uid 99); 13 Feb 2017 23:10:02 -0000
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"
X-Originating-IP: 208.51.143.189
User-Agent: Workspace Webmail 6.6.2
Message-Id: <20170213161000.665a7a7059d7ee80bb4d670165c8327d.917539e857.wbe@email03.godaddy.com>
From: "Doug Ewell" 
To: "=?UTF-8?Q?Gunnar=5FHellstr=C3=B6m?=" , "Bernard Aboba" 
Date: Mon, 13 Feb 2017 16:10:00 -0700
Mime-Version: 1.0
Archived-At: 
Cc: slim@ietf.org, ietf@ietf.org
Subject: Re: [Slim] IETF last call for draft-ietf-slim-negotiating-human-language (Section 5.4)
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Feb 2017 23:10:06 -0000

Gunnar Hellstr=C3=B6m wrote:=0A=0A> But captions overlayed on video in the =
media stream is a used=0A> technology so it would be good to be able to spe=
cify it.=0A> That we cannot do it is again a sad effect of the language tag=
s not=0A> distinguishing between spoken and written modality.=0A=0Ase-Latn =
=3D Swedish written in Latin script=0Ase-Cyrl =3D Swedish written in Cyrill=
ic script=0Ase-Maya =3D Swedish written in Mayan hieroglyphs=0A=0Ase-Zxxx =
=3D Swedish, explicitly not written=0A=0A"se-Zxxx, fi-Latn" =3D content inc=
ludes non-written Swedish plus Finnish=0Awritten in Latin script=0A=0AExamp=
les of multiple streams of content, such as video in one language=0Athat is=
 subtitled in another, call for multiple language tags. That is=0Anot a sho=
rtcoming or failure of the language tag mechanism. See RFC=0A5646, Section =
4.3.=0A=0AAll of this was discussed in the WG by the same parties.=0A=0A> I=
 once had an ambition to try to specify a notation for that to be=0A> added=
 to BCP 47, but did not succeed to get any real discussion going=0A> on the=
 topic. =0A =0AI searched the ietf-languages archives and did not find any =
sort of post=0Aor proposal from you. I forwarded one of your messages from =
SLIM to that=0Alist in November 2015, expecting you to follow up with a pro=
posal, but=0Anothing materialized.=0A =0A--=0ADoug Ewell | Thornton, CO, US=
 | ewellic.org=0A


From nobody Mon Feb 13 15:19: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 DAAD21299EF; Mon, 13 Feb 2017 15:19:05 -0800 (PST)
X-Quarantine-ID: 
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -1.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 hjABq6TuFWbF; Mon, 13 Feb 2017 15:19:04 -0800 (PST)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 7BF6D1299E3; Mon, 13 Feb 2017 15:19:02 -0800 (PST)
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Mon, 13 Feb 2017 15:11:14 -0800
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <5625f5e6-740c-6364-1d64-5006a49f0581@omnitor.se>
References:   <5625f5e6-740c-6364-1d64-5006a49f0581@omnitor.se>
X-Mailer: Eudora for Mac OS X
Date: Mon, 13 Feb 2017 15:18:58 -0800
To: Gunnar =?iso-8859-1?Q?Hellstr=F6m?=  , Bernard Aboba , slim@ietf.org, ietf@ietf.org
From: Randall Gellens 
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
Archived-At: 
Subject: Re: [Slim] IETF last call for draft-ietf-slim-negotiating-human-language (Section 5.4)
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Feb 2017 23:19:06 -0000

At 12:09 AM +0100 2/14/17, Gunnar Hellstr=F6m wrote:

>  I prefer that you wait for conclusion on the topic of "silly states".
>
>  And I agree with Bernard that we should (and=20
> can) be normative and explicit in how to=20
> interpret all the unusual combinations.

I think we're better off not saying what the=20
meaning is since we do not have a deployed base=20
of experience.  The replacement text allows=20
cooperating implementations to send such states=20
if they wish.  If consensus emerges later as to=20
what such states mean, a revised draft or an=20
extension draft can be published that spells it=20
out.



>  Den 2017-02-13 kl. 23:26, skrev Randall Gellens:
>>  At 11:06 AM -0800 2/13/17, Bernard Aboba wrote:
>>
>>>   Looking over Section 5.4, it seems to me=20
>>> that the title "Silly States" may not be=20
>>> appropriate, because it mixes discussion of=20
>>> combinations of media and language that have=20
>>> an "undefined" meaning with combinations for=20
>>> which normative guidance can be provided  So=20
>>> rather than having a single "Silly States"=20
>>> section, perhaps we can have a section on=20
>>> "Undefined States" (for those combinations=20
>>> which have an undefined meaning) provide=20
>>> normative guidance on defined combinations=20
>>> elsewhere.
>>>
>>>
>>>=20
>>> 5.4.=20
>>> Silly States
>>>
>>>
>>>
>>>      It is possible to specify a "silly state" where the language
>>>      specified does not make sense for the media type, such as specifyin=
g
>>>      a signed language for an audio media stream.
>>>      An offer MUST NOT be created where the language does not make sense
>>>      for the media type.  If such an offer is received, the receiver MAY
>>>      reject the media, ignore the language specified, or attempt to
>>>      interpret the intent (e.g., if American Sign Language is specified
>>>      for an audio media stream, this might be interpreted as a desire to
>>>      use spoken English).
>>>
>>>      A spoken language tag for a video stream in conjunction with an aud=
io
>>>      stream with the same language might indicate a request for
>>>      supplemental video to see the speaker.
>>>
>>>   [BA] Rather than using terms like "might"=20
>>> for combinations that could have a
>>>   defined meaning, I would like to see the specification provide normati=
ve
>>>   language on these use cases. In particular,=20
>>> I would like the specification to describe:
>>>
>>>   a. What it means when a spoken language tag=20
>>> is included for a video stream.
>>>   Is this to be interpreted as a request for captioning?
>>>   b. What it means when a signed language tag=20
>>> is included for an audio stream.
>>>   Is the meaning of this "undefined" and if so, should it be ignored?
>>>   c. What it means when a signed language tag is included for a text str=
eam.
>>>
>>>   If some of these scenarios are not defined, the specification can say
>>>   "this combination does not have a defined meaning" or something like t=
hat.
>>
>>  I will change the section title to "Undefined=20
>> Combinations" and replace the text with:
>>
>>     Specifying a non-signed language tag for a video media stream, or a
>>     signed language tag for a non-video media stream, is not defined.  An
>>     offer with such a combination SHOULD NOT be created.  If such an
>>     offer is received, the receiver MAY ignore the language specified.
>>
>>  I think this retains the intent of the old=20
>> section while avoiding wading into the unclear=20
>> issue of intent of such combinations.
>>
>
>  --
>  -----------------------------------------
>  Gunnar Hellstr=F6m
>  Omnitor
>  gunnar.hellstrom@omnitor.se
>  +46 708 204 288
>
>  _______________________________________________
>  SLIM mailing list
>  SLIM@ietf.org
>  https://www.ietf.org/mailman/listinfo/slim


-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Please take note:
Do not read this fortune under penalty of law.
Violators will be prosecuted.
(Penal Code sec. 2.3.2 (II.a.))


From nobody Mon Feb 13 15:44:33 2017
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 567C012998C for ; Mon, 13 Feb 2017 15:44:31 -0800 (PST)
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 0-DcQIxrRkEo for ; Mon, 13 Feb 2017 15:44:30 -0800 (PST)
Received: from resqmta-po-04v.sys.comcast.net (resqmta-po-04v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:163]) (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 5DE751294D6 for ; Mon, 13 Feb 2017 15:44:30 -0800 (PST)
Received: from resomta-po-02v.sys.comcast.net ([96.114.154.226]) by resqmta-po-04v.sys.comcast.net with SMTP id dQI5cWDmRxUJadQIHcoP4S; Mon, 13 Feb 2017 23:44:29 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1487029469; bh=XyZX5J9yYk2avN2Vi2Ri3etdETXd7yvG+EB0FIME7PE=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=f5E7Tsvqf9gfcDaz9ZrcW47TRtVD9flHQRJFd2NrFxvm4qVAQwJL40zPXrqFKvZYk FRG4CExqlOSmvaWN0nk5acnHcXa4i8AcOqAhhCOZ1GlFGEH9wfXcFNYwqXOLbd9IHH DOvs+BmXon4FrhC2dWzt+KTLpkeMIs+KWgxEr1Q9jV8HEMCo9gnNLuRBX5JMG/bfDG iEfKuUBBWJg/ne1ypMQkJZs6Pf4cBl4vsuLvFVid6WYOIsdETPCybTvtMFlEyQ+ISx KhJRm9nQv3J357VHNCzwe8Zx5eIeG+HWzKuNlyCi5thsP4CJP9uDgK6yA0Xsrtwldb u54hQYZ1DNtYw==
Received: from [192.168.1.110] ([73.186.127.100]) by resomta-po-02v.sys.comcast.net with SMTP id dQIGcQSR0k3bxdQIGcq474; Mon, 13 Feb 2017 23:44:29 +0000
To: slim@ietf.org
References: <20170213105355.665a7a7059d7ee80bb4d670165c8327d.1c694c05b8.wbe@email03.godaddy.com>
From: Paul Kyzivat 
Message-ID: 
Date: Mon, 13 Feb 2017 18:44:28 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <20170213105355.665a7a7059d7ee80bb4d670165c8327d.1c694c05b8.wbe@email03.godaddy.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-CMAE-Envelope: MS4wfP6g8bdI5Qdvz4lblvOPs7eCKevPdI9/SujPSYTBlaF+znEudttB9sxHj0rCBj1DXlGn2qgKUcOrq+hhxELqUkDpxC+GPfbTV+3Oe26NkeGWlyzJEJ7j wGdeS3ZMCfODtNY7WEDm18M223uAI+E6n8TiytpqXhfPo2pk062eTdJi
Archived-At: 
Subject: Re: [Slim] Last Call:  (Negotiating Human Language in Real-Time Communications) to Proposed Standard
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Feb 2017 23:44:31 -0000

On 2/13/17 12:53 PM, Doug Ewell wrote:

> Gunnar, who participated extensively in the SLIM WG, appears to be
> attempting to re-introduce a mechanism to indicate preference of
> modality which was considered and rejected multiple times by the WG.
>
> WG rejection of Gunnar's previous proposals to do this was based on
> reluctance to try to solve this particular problem in the first version
> of the spec, not on any of the specific mechanisms proposed to solve the
> problem. Proposing a new or modified mechanism during IETF LC appears to
> be an attempt to rehash an argument made, but not won, in the WG.
>
> If this concerns a different issue, not merely a different way of
> approaching it, please accept my apology and explain more clearly how it
> is different.

Gunnar's comment makes multiple points. You have highlighted one of them 
and ignored the others.

Even if you reject that one, consider the others. Notably:

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

I accept the WG's decision not to address the "preference" issue. But 
this attachment to the "ugly child", if not addressed, invites getting 
IESG LC comments.

	Thanks,
	Paul


From nobody Mon Feb 13 16:16: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 AB003129400 for ; Mon, 13 Feb 2017 16:16:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 MzB7C22OWMZ4 for ; Mon, 13 Feb 2017 16:16:10 -0800 (PST)
Received: from p3plwbeout03-06.prod.phx3.secureserver.net (p3plsmtp03-06-2.prod.phx3.secureserver.net [72.167.218.218]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A19A129437 for ; Mon, 13 Feb 2017 16:16:08 -0800 (PST)
Received: from localhost ([72.167.218.135]) by p3plwbeout03-06.prod.phx3.secureserver.net with bizsmtp id kQG81u0012vs63s01QG8Qj; Mon, 13 Feb 2017 17:16:08 -0700
X-SID: kQG81u0012vs63s01
Received: (qmail 30421 invoked by uid 99); 14 Feb 2017 00:16:08 -0000
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"
X-Originating-IP: 208.51.143.189
User-Agent: Workspace Webmail 6.6.3
Message-Id: <20170213171605.665a7a7059d7ee80bb4d670165c8327d.fce7ee4dbe.wbe@email03.godaddy.com>
From: "Doug Ewell" 
To: "Paul Kyzivat" , slim@ietf.org, ietf@ietf.org
Date: Mon, 13 Feb 2017 17:16:05 -0700
Mime-Version: 1.0
Archived-At: 
Subject: Re: [Slim] Last Call:  (Negotiating Human Language in Real-Time Communications) to Proposed Standard
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Feb 2017 00:16:11 -0000

Paul Kyzivat wrote:=0A=0A> Gunnar's comment makes multiple points. You have=
 highlighted one of=0A> them and ignored the others.=0A=0ASome of Gunnar's =
points were excellent, such as the observation that the=0Aterminology is in=
consistent as to whether the asterisk is part of the=0Atag.=0A=0AI did not =
attempt to respond to all of Gunnar's points, nor did I think=0Athat was ne=
cessary.=0A=0A> I accept the WG's decision not to address the "preference" =
issue. But=0A> this attachment to the "ugly child", if not addressed, invit=
es getting=0A> IESG LC comments.=0A=0AI'm not sure what this refers to, but=
 I'm happy to refrain from further=0Acomments on this LC if you think they =
might put the draft in jeopardy.=0A=0A--=0ADoug Ewell | Thornton, CO, US | =
ewellic.org=0A


From nobody Mon Feb 13 16:34:38 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 28F9A12944B for ; Mon, 13 Feb 2017 16:34:37 -0800 (PST)
X-Quarantine-ID: 
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iHIX0TaYkGY6 for ; Mon, 13 Feb 2017 16:34:36 -0800 (PST)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id E45FB129437 for ; Mon, 13 Feb 2017 16:34:35 -0800 (PST)
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Mon, 13 Feb 2017 16:26:47 -0800
Mime-Version: 1.0
Message-Id: 
In-Reply-To: 
References: <20170213105355.665a7a7059d7ee80bb4d670165c8327d.1c694c05b8.wbe@email0 3.godaddy.com> 
X-Mailer: Eudora for Mac OS X
Date: Mon, 13 Feb 2017 16:34:33 -0800
To: Paul Kyzivat , slim@ietf.org
From: Randall Gellens 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
Archived-At: 
Subject: Re: [Slim] Last Call:  (Negotiating Human Language in Real-Time Communications) to Proposed Standard
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Feb 2017 00:34:37 -0000

At 6:44 PM -0500 2/13/17, Paul Kyzivat wrote:

>  On 2/13/17 12:53 PM, Doug Ewell wrote:
>
>>  Gunnar, who participated extensively in the SLIM WG, appears to be
>>  attempting to re-introduce a mechanism to indicate preference of
>>  modality which was considered and rejected multiple times by the WG.
>>
>>  WG rejection of Gunnar's previous proposals to do this was based on
>>  reluctance to try to solve this particular problem in the first version
>>  of the spec, not on any of the specific mechanisms proposed to solve the
>>  problem. Proposing a new or modified mechanism during IETF LC appears to
>>  be an attempt to rehash an argument made, but not won, in the WG.
>>
>>  If this concerns a different issue, not merely a different way of
>>  approaching it, please accept my apology and explain more clearly how it
>>  is different.
>
>  Gunnar's comment makes multiple points. You have highlighted one of 
> them and ignored the others.
>
>  Even if you reject that one, consider the others. Notably:
>
>  - 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.
>
>  I accept the WG's decision not to address the "preference" issue. 
> But this attachment to the "ugly child", if not addressed, invites 
> getting IESG LC comments.

Hi Paul,

I don't believe the WG has any particular love for the asterisk 
syntax, but felt it was good enough for what's needed, and didn't see 
any benefit from anything else.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
You're most kind.  In fact, you're every kind.
          --Robert Preston in _Victor/Victoria_


From nobody Mon Feb 13 23:06:37 2017
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDEF2129A1E for ; Mon, 13 Feb 2017 23:06:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 NOVCvRMbqElw for ; Mon, 13 Feb 2017 23:06:18 -0800 (PST)
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 7CE8212954C for ; Mon, 13 Feb 2017 23:06:18 -0800 (PST)
X-Halon-ID: 0e14430b-f284-11e6-a131-005056917a89
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [83.209.158.27]) by bin-vsp-out-01.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Tue, 14 Feb 2017 08:06:06 +0100 (CET)
To: Doug Ewell , Bernard Aboba 
References: <20170213161000.665a7a7059d7ee80bb4d670165c8327d.917539e857.wbe@email03.godaddy.com>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: 
Date: Tue, 14 Feb 2017 08:06:14 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <20170213161000.665a7a7059d7ee80bb4d670165c8327d.917539e857.wbe@email03.godaddy.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: slim@ietf.org, ietf@ietf.org
Subject: Re: [Slim] IETF last call for draft-ietf-slim-negotiating-human-language (Section 5.4)
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Feb 2017 07:06:28 -0000

Doug,

Thanks for pointing at the Zxxx script subtag for non-written content.

I think we can document the use of it for the view of a speaker in video 
media when indicated by a spoken/written language tag.

I have tried before to propose to use the script subtag to indicate 
written language, but got opposition because many languages have their 
main script subtag suppressed. However, the language around suppressed 
script subtags indicate that there are cases when the use is 
appropriate. We  can document that text captions in the video stream 
shall (or should) be indicated with a script subtag.

But, to keep it simple, the use of Zxxx scrit subtag on the view of a 
speaker should be sufficient.

That could conclude the unusual combinations:

1. Spoken/written tag in video media, can mean to see a speaking person, 
or to provide captions overlayed on video.

When the intention is to indicate overlayed captions in the video 
stream, the script subtag Zxxx SHALL be used.

Otherwise, a view of a speaking person is indicated.

2. Signed language tag in audio media,
means audio from a person using sign language, and SHOULD only be used 
for rare cases when it has some relevance for language communication.

3. Sign language tag in text media.

SHALL be used for any approximate text coded representation of sign 
language or fingerspelling.

I suggest that these conclusions form the base for a redefined section 5.4.

--------------------------------------------------------------------------
About my efforts to discuss modality in the language list: The list was 
closed when I tried to subscribe or send to it, and I did not see any 
response on a question I sent about how to get a discussion on the 
modality topic.

But I am happy now with your pointing out the Zxxx script. a 
spoken/written language with Zxxx script is quite obviously not written 
and not signed, so then it is spoken. Good.

Thanks

Gunnar


Den 2017-02-14 kl. 00:10, skrev Doug Ewell:
> Gunnar Hellström wrote:
>
>> But captions overlayed on video in the media stream is a used
>> technology so it would be good to be able to specify it.
>> That we cannot do it is again a sad effect of the language tags not
>> distinguishing between spoken and written modality.
> se-Latn = Swedish written in Latin script
> se-Cyrl = Swedish written in Cyrillic script
> se-Maya = Swedish written in Mayan hieroglyphs
>
> se-Zxxx = Swedish, explicitly not written
>
> "se-Zxxx, fi-Latn" = content includes non-written Swedish plus Finnish
> written in Latin script
>
> Examples of multiple streams of content, such as video in one language
> that is subtitled in another, call for multiple language tags. That is
> not a shortcoming or failure of the language tag mechanism. See RFC
> 5646, Section 4.3.
>
> All of this was discussed in the WG by the same parties.
>
>> I once had an ambition to try to specify a notation for that to be
>> added to BCP 47, but did not succeed to get any real discussion going
>> on the topic.
>   
> I searched the ietf-languages archives and did not find any sort of post
> or proposal from you. I forwarded one of your messages from SLIM to that
> list in November 2015, expecting you to follow up with a proposal, but
> nothing materialized.
>   
> --
> Doug Ewell | Thornton, CO, US | ewellic.org
>
>
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim

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


From nobody Tue Feb 14 02:01: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 732F7129416 for ; Tue, 14 Feb 2017 02:01:53 -0800 (PST)
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=unavailable 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 xjqX13lCWg95 for ; Tue, 14 Feb 2017 02:01:50 -0800 (PST)
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 21EB31294C4 for ; Tue, 14 Feb 2017 02:01:49 -0800 (PST)
X-Halon-ID: 97e150fd-f29c-11e6-af90-005056917f90
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [83.209.158.27]) by bin-vsp-out-02.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Tue, 14 Feb 2017 11:01:45 +0100 (CET)
To: Bernard Aboba 
References: <20170213161000.665a7a7059d7ee80bb4d670165c8327d.917539e857.wbe@email03.godaddy.com> 
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: <4c4ef65a-a907-cf5e-4b2c-835fb55d0146@omnitor.se>
Date: Tue, 14 Feb 2017 11:01:45 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------2CC544CEA01C203ECDFDC8F6"
Archived-At: 
Cc: slim@ietf.org, ietf@ietf.org, Doug Ewell 
Subject: Re: [Slim] IETF last call for draft-ietf-slim-negotiating-human-language (Section 5.4)
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Feb 2017 10:01:53 -0000

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

My proposal for a reworded section 5.4 is:

5.4.  Unusual language indications

It is possible to specify an unusual indication where the language
specified may look unexpected for the media type.

For such cases the following guidance SHALL be applied for the 
humintlang attributes used in these situations.

 1. A view of a speaking person in the video stream SHALL, when it has
    relevance for speech perception, be indicated by a Language-Tag for
    spoken/written language with the "Zxxx" script subtag to indicate
    that the contents is not written.

 2. Text captions included in the video stream SHALL be indicated by a
    Language-Tag for spoken/written language.

 3. Any approximate representation of sign language or fingerspelling in
    the text media stream SHALL be indicated by a Language-Tag for a
    sign language in text media.

 4. When sign language related audio from a person using sign language
    is of importance for language communication, this SHALL be indicated
    by a Language-Tag for a sign language in audio media.

-------------------------------------------------------------------------------
This paragraph in 5.2 should be deleted because it is a duplication.

"   Note that while signed language tags are used with a video stream to
    indicate sign language, a spoken language tag for a video stream in
    parallel with an audio stream with the same spoken language tag
    indicates a request for a supplemental video stream to see the
    speaker."

Regards

Gunnar

Den 2017-02-14 kl. 08:06, skrev Gunnar Hellström:
> Doug,
>
> Thanks for pointing at the Zxxx script subtag for non-written content.
>
> I think we can document the use of it for the view of a speaker in 
> video media when indicated by a spoken/written language tag.
>
> I have tried before to propose to use the script subtag to indicate 
> written language, but got opposition because many languages have their 
> main script subtag suppressed. However, the language around suppressed 
> script subtags indicate that there are cases when the use is 
> appropriate. We  can document that text captions in the video stream 
> shall (or should) be indicated with a script subtag.
>
> But, to keep it simple, the use of Zxxx scrit subtag on the view of a 
> speaker should be sufficient.
>
> That could conclude the unusual combinations:
>
> 1. Spoken/written tag in video media, can mean to see a speaking 
> person, or to provide captions overlayed on video.
>
> When the intention is to indicate overlayed captions in the video 
> stream, the script subtag Zxxx SHALL be used.
>
> Otherwise, a view of a speaking person is indicated.
>
> 2. Signed language tag in audio media,
> means audio from a person using sign language, and SHOULD only be used 
> for rare cases when it has some relevance for language communication.
>
> 3. Sign language tag in text media.
>
> SHALL be used for any approximate text coded representation of sign 
> language or fingerspelling.
>
> I suggest that these conclusions form the base for a redefined section 
> 5.4.
>
> -------------------------------------------------------------------------- 
>
> About my efforts to discuss modality in the language list: The list 
> was closed when I tried to subscribe or send to it, and I did not see 
> any response on a question I sent about how to get a discussion on the 
> modality topic.
>
> But I am happy now with your pointing out the Zxxx script. a 
> spoken/written language with Zxxx script is quite obviously not 
> written and not signed, so then it is spoken. Good.
>
> Thanks
>
> Gunnar
>
>
> Den 2017-02-14 kl. 00:10, skrev Doug Ewell:
>> Gunnar Hellström wrote:
>>
>>> But captions overlayed on video in the media stream is a used
>>> technology so it would be good to be able to specify it.
>>> That we cannot do it is again a sad effect of the language tags not
>>> distinguishing between spoken and written modality.
>> se-Latn = Swedish written in Latin script
>> se-Cyrl = Swedish written in Cyrillic script
>> se-Maya = Swedish written in Mayan hieroglyphs
>>
>> se-Zxxx = Swedish, explicitly not written
>>
>> "se-Zxxx, fi-Latn" = content includes non-written Swedish plus Finnish
>> written in Latin script
>>
>> Examples of multiple streams of content, such as video in one language
>> that is subtitled in another, call for multiple language tags. That is
>> not a shortcoming or failure of the language tag mechanism. See RFC
>> 5646, Section 4.3.
>>
>> All of this was discussed in the WG by the same parties.
>>
>>> I once had an ambition to try to specify a notation for that to be
>>> added to BCP 47, but did not succeed to get any real discussion going
>>> on the topic.
>>   I searched the ietf-languages archives and did not find any sort of 
>> post
>> or proposal from you. I forwarded one of your messages from SLIM to that
>> list in November 2015, expecting you to follow up with a proposal, but
>> nothing materialized.
>>   --
>> Doug Ewell | Thornton, CO, US | ewellic.org
>>
>>
>> _______________________________________________
>> 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


--------------2CC544CEA01C203ECDFDC8F6
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
My proposal for a reworded section 5.4 is:

    
5.4.  Unusual language indications

    

    
It is possible to specify an unusual indication where the
      language

      specified may look unexpected for the media type.

    
For such cases the following guidance SHALL be applied for the
      humintlang attributes used in these situations.

    
    
      
  1. A view of a speaking person in the video stream SHALL, when it
        has relevance for speech perception, be indicated by a
        Language-Tag for spoken/written language with the "Zxxx" script
        subtag to indicate that the contents is not written.
    
        
    
      
    2. 
      
  2. Text captions included in the video stream SHALL be indicated
        by a Language-Tag for spoken/written language.
    
        
    
      
    3. 
      
  3. Any approximate representation of sign language or
        fingerspelling in the text media stream SHALL be indicated by a
        Language-Tag for a sign language in text media.
    
        
    
      
    4. 
      
  4. When sign language related audio from a person using sign
        language is of importance for language communication, this SHALL
        be indicated by a Language-Tag for a sign language in audio
        media.  
    
      
    5. 
    

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

    This paragraph in 5.2 should be deleted because it is a duplication.

    

    "   Note that while signed language tags are used with a video
    stream to

       indicate sign language, a spoken language tag for a video stream
    in

       parallel with an audio stream with the same spoken language tag

       indicates a request for a supplemental video stream to see the

       speaker."

    

    Regards

    

    Gunnar

    

    
Den 2017-02-14 kl. 08:06, skrev Gunnar
      Hellström:

    

    
Doug,
      

      

      Thanks for pointing at the Zxxx script subtag for non-written
      content.
      

      

      I think we can document the use of it for the view of a speaker in
      video media when indicated by a spoken/written language tag.
      

      

      I have tried before to propose to use the script subtag to
      indicate written language, but got opposition because many
      languages have their main script subtag suppressed. However, the
      language around suppressed script subtags indicate that there are
      cases when the use is appropriate. We  can document that text
      captions in the video stream shall (or should) be indicated with a
      script subtag.
      

      

      But, to keep it simple, the use of Zxxx scrit subtag on the view
      of a speaker should be sufficient.
      

      

      That could conclude the unusual combinations:
      

      

      1. Spoken/written tag in video media, can mean to see a speaking
      person, or to provide captions overlayed on video.
      

      

      When the intention is to indicate overlayed captions in the video
      stream, the script subtag Zxxx SHALL be used.
      

      

      Otherwise, a view of a speaking person is indicated.
      

      

      2. Signed language tag in audio media,
      

      means audio from a person using sign language, and SHOULD only be
      used for rare cases when it has some relevance for language
      communication.
      

      

      3. Sign language tag in text media.
      

      

      SHALL be used for any approximate text coded representation of
      sign language or fingerspelling.
      

      

      I suggest that these conclusions form the base for a redefined
      section 5.4.
      

      

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

      About my efforts to discuss modality in the language list: The
      list was closed when I tried to subscribe or send to it, and I did
      not see any response on a question I sent about how to get a
      discussion on the modality topic.
      

      

      But I am happy now with your pointing out the Zxxx script. a
      spoken/written language with Zxxx script is quite obviously not
      written and not signed, so then it is spoken. Good.
      

      

      Thanks
      

      

      Gunnar
      

      

      

      Den 2017-02-14 kl. 00:10, skrev Doug Ewell:
      

      
Gunnar Hellström wrote:
        

        

        
But captions overlayed on video in the
          media stream is a used
          

          technology so it would be good to be able to specify it.
          

          That we cannot do it is again a sad effect of the language
          tags not
          

          distinguishing between spoken and written modality.
          

        

        se-Latn = Swedish written in Latin script
        

        se-Cyrl = Swedish written in Cyrillic script
        

        se-Maya = Swedish written in Mayan hieroglyphs
        

        

        se-Zxxx = Swedish, explicitly not written
        

        

        "se-Zxxx, fi-Latn" = content includes non-written Swedish plus
        Finnish
        

        written in Latin script
        

        

        Examples of multiple streams of content, such as video in one
        language
        

        that is subtitled in another, call for multiple language tags.
        That is
        

        not a shortcoming or failure of the language tag mechanism. See
        RFC
        

        5646, Section 4.3.
        

        

        All of this was discussed in the WG by the same parties.
        

        

        
I once had an ambition to try to specify
          a notation for that to be
          

          added to BCP 47, but did not succeed to get any real
          discussion going
          

          on the topic.
          

        

          I searched the ietf-languages archives and did not find any
        sort of post
        

        or proposal from you. I forwarded one of your messages from SLIM
        to that
        

        list in November 2015, expecting you to follow up with a
        proposal, but
        

        nothing materialized.
        

          --
        

        Doug Ewell | Thornton, CO, US | ewellic.org
        

        

        

        _______________________________________________
        

        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

  


--------------2CC544CEA01C203ECDFDC8F6--


From nobody Tue Feb 14 09:40:19 2017
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C79441294DC; Tue, 14 Feb 2017 09:40:17 -0800 (PST)
X-Quarantine-ID: 
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dT1Ypiy9kXio; Tue, 14 Feb 2017 09:40:16 -0800 (PST)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 22902128E18; Tue, 14 Feb 2017 09:40:16 -0800 (PST)
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Tue, 14 Feb 2017 09:32:19 -0800
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <4c4ef65a-a907-cf5e-4b2c-835fb55d0146@omnitor.se>
References: <20170213161000.665a7a7059d7ee80bb4d670165c8327d.917539e857.wbe@email0 3.godaddy.com>  <4c4ef65a-a907-cf5e-4b2c-835fb55d0146@omnitor.se>
X-Mailer: Eudora for Mac OS X
Date: Tue, 14 Feb 2017 09:40:11 -0800
To: Gunnar =?iso-8859-1?Q?Hellstr=F6m?=  , Bernard Aboba 
From: Randall Gellens 
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
Archived-At: 
Cc: slim@ietf.org, ietf@ietf.org, Doug Ewell 
Subject: Re: [Slim] IETF last call for draft-ietf-slim-negotiating-human-language (Section 5.4)
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Feb 2017 17:40:18 -0000

At 11:01 AM +0100 2/14/17, Gunnar Hellstr=F6m wrote:

>  My proposal for a reworded section 5.4 is:
>
>  5.4.  Unusual language indications
>
>  It is possible to specify an unusual indication where the language
>  specified may look unexpected for the media type.
>
>  For such cases the following guidance SHALL be=20
> applied for the humintlang attributes used in=20
> these situations.
>
>  1.	A view of a speaking person in the video=20
> stream SHALL, when it has relevance for speech=20
> perception, be indicated by a Language-Tag for=20
> spoken/written language with the "Zxxx" script=20
> subtag to indicate that the contents is not=20
> written.
>
>  2.	Text captions included in the video=20
> stream SHALL be indicated by a Language-Tag for=20
> spoken/written language.
>
>  3.	Any approximate representation of sign=20
> language or fingerspelling in the text media=20
> stream SHALL be indicated by a Language-Tag for=20
> a sign language in text media.
>
>  4.	When sign language related audio from a=20
> person using sign language is of importance for=20
> language communication, this SHALL be indicated=20
> by a Language-Tag for a sign language in audio=20
> media.

[RG] As I said, I think we should avoid=20
specifying this until we have deployment=20
experience.


>
>=20
> --------------------------------------------------------------------------=
-----
>  This paragraph in 5.2 should be deleted because it is a duplication.
>
>  "   Note that while signed language tags are used with a video stream to
>     indicate sign language, a spoken language tag for a video stream in
>     parallel with an audio stream with the same spoken language tag
>     indicates a request for a supplemental video stream to see the
>     speaker."

[RG] I agree and will delete the paragraph.



>
>  Regards
>
>  Gunnar
>
>  Den 2017-02-14 kl. 08:06, skrev Gunnar Hellstr=F6m:
>
>>  Doug,
>>
>>  Thanks for pointing at the Zxxx script subtag for non-written content.
>>
>>  I think we can document the use of it for the=20
>> view of a speaker in video media when=20
>> indicated by a spoken/written language tag.
>>
>>  I have tried before to propose to use the=20
>> script subtag to indicate written language,=20
>> but got opposition because many languages have=20
>> their main script subtag suppressed. However,=20
>> the language around suppressed script subtags=20
>> indicate that there are cases when the use is=20
>> appropriate. We  can document that text=20
>> captions in the video stream shall (or should)=20
>> be indicated with a script subtag.
>>
>>  But, to keep it simple, the use of Zxxx scrit=20
>> subtag on the view of a speaker should be=20
>> sufficient.
>>
>>  That could conclude the unusual combinations:
>>
>>  1. Spoken/written tag in video media, can mean=20
>> to see a speaking person, or to provide=20
>> captions overlayed on video.
>>
>>  When the intention is to indicate overlayed=20
>> captions in the video stream, the script=20
>> subtag Zxxx SHALL be used.
>>
>>  Otherwise, a view of a speaking person is indicated.
>>
>>  2. Signed language tag in audio media,
>>  means audio from a person using sign language,=20
>> and SHOULD only be used for rare cases when it=20
>> has some relevance for language communication.
>>
>>  3. Sign language tag in text media.
>>
>>  SHALL be used for any approximate text coded=20
>> representation of sign language or=20
>> fingerspelling.
>>
>>  I suggest that these conclusions form the base for a redefined section 5=
=2E4.
>>
>>  ------------------------------------------------------------------------=
--
>>  About my efforts to discuss modality in the=20
>> language list: The list was closed when I=20
>> tried to subscribe or send to it, and I did=20
>> not see any response on a question I sent=20
>> about how to get a discussion on the modality=20
>> topic.
>>
>>  But I am happy now with your pointing out the=20
>> Zxxx script. a spoken/written language with=20
>> Zxxx script is quite obviously not written and=20
>> not signed, so then it is spoken. Good.
>>
>>  Thanks
>>
>>  Gunnar
>>
>>
>>  Den 2017-02-14 kl. 00:10, skrev Doug Ewell:
>>
>>>  Gunnar Hellstr=F6m wrote:
>>>
>>>>  But captions overlayed on video in the media stream is a used
>>>>  technology so it would be good to be able to specify it.
>>>>  That we cannot do it is again a sad effect of the language tags not
>>>>  distinguishing between spoken and written modality.
>>>>
>>>  se-Latn =3D Swedish written in Latin script
>>>  se-Cyrl =3D Swedish written in Cyrillic script
>>>  se-Maya =3D Swedish written in Mayan hieroglyphs
>>>
>>>  se-Zxxx =3D Swedish, explicitly not written
>>>
>>>  "se-Zxxx, fi-Latn" =3D content includes non-written Swedish plus Finnis=
h
>>>  written in Latin script
>>>
>>>  Examples of multiple streams of content, such as video in one language
>>>  that is subtitled in another, call for multiple language tags. That is
>>>  not a shortcoming or failure of the language tag mechanism. See RFC
>>>  5646, Section 4.3.
>>>
>>>  All of this was discussed in the WG by the same parties.
>>>
>>>>  I once had an ambition to try to specify a notation for that to be
>>>>  added to BCP 47, but did not succeed to get any real discussion going
>>>>  on the topic.
>>>>
>>>    I searched the ietf-languages archives and did not find any sort of p=
ost
>>>  or proposal from you. I forwarded one of your messages from SLIM to tha=
t
>>>  list in November 2015, expecting you to follow up with a proposal, but
>>>  nothing materialized.
>>>    --
>>>  Doug Ewell | Thornton, CO, US | ewellic.org
>>>
>>>
>>>  _______________________________________________
>>>  SLIM mailing list
>>>  SLIM@ietf.org
>>>=20
>>> https://www.ietf.org/mailman=
/listinfo/slim
>>>
>>
>
>  --
>  -----------------------------------------
>  Gunnar Hellstr=F6m
>  Omnitor
>  gunnar.hellstrom@omnitor.se
>  +46 708 204 288
>
>  _______________________________________________
>  SLIM mailing list
>  SLIM@ietf.org
>  https://www.ietf.org/mailman/listinfo/slim


-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
If you would look up bad labor relations in the dictionary, you
would have an American Airlines logo beside it.
    --U.S. District Judge Joe Kendall, issuing a restraining order
against an American Airlines APA pilot union sick out, 10 Feb 1999.


From nobody Tue Feb 14 11:59: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 9B9381297D4 for ; Tue, 14 Feb 2017 11:59:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 p0yl8cCmw1de for ; Tue, 14 Feb 2017 11:59:17 -0800 (PST)
Received: from bin-vsp-out-01.atm.binero.net (bin-mail-out-06.binero.net [195.74.38.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F14C7129559 for ; Tue, 14 Feb 2017 11:59:16 -0800 (PST)
X-Halon-ID: 0988c81c-f2f0-11e6-a131-005056917a89
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [83.209.158.27]) by bin-vsp-out-01.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Tue, 14 Feb 2017 20:59:04 +0100 (CET)
To: Randy Presuhn , ietf@ietf.org, "slim@ietf.org" 
References: <20170213161000.665a7a7059d7ee80bb4d670165c8327d.917539e857.wbe@email0 3.godaddy.com>  <4c4ef65a-a907-cf5e-4b2c-835fb55d0146@omnitor.se>  <434a4f06-f034-46ca-9df7-f59059e67e41@alumni.stanford.edu>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: <843f0cc1-2686-162d-25dc-0075847579bc@omnitor.se>
Date: Tue, 14 Feb 2017 20:59:12 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <434a4f06-f034-46ca-9df7-f59059e67e41@alumni.stanford.edu>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [Slim] IETF last call for draft-ietf-slim-negotiating-human-language (Section 5.4)
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Feb 2017 19:59:19 -0000

Den 2017-02-14 kl. 19:05, skrev Randy Presuhn:

> Hi -
>
> On 2/14/2017 9:40 AM, Randall Gellens wrote:
>> At 11:01 AM +0100 2/14/17, Gunnar Hellström wrote:
>>
>>>  My proposal for a reworded section 5.4 is:
>>>
>>>  5.4.  Unusual language indications
>>>
>>>  It is possible to specify an unusual indication where the language
>>>  specified may look unexpected for the media type.
>>>
>>>  For such cases the following guidance SHALL be applied for the
>>> humintlang attributes used in these situations.
>>>
>>>  1.    A view of a speaking person in the video stream SHALL, when it
>>> has relevance for speech perception, be indicated by a Language-Tag
>>> for spoken/written language with the "Zxxx" script subtag to indicate
>>> that the contents is not written.
>>>
>>>  2.    Text captions included in the video stream SHALL be indicated
>>> by a Language-Tag for spoken/written language.
>>>
>>>  3.    Any approximate representation of sign language or
>>> fingerspelling in the text media stream SHALL be indicated by a
>>> Language-Tag for a sign language in text media.
>>>
>>>  4.    When sign language related audio from a person using sign
>>> language is of importance for language communication, this SHALL be
>>> indicated by a Language-Tag for a sign language in audio media.
>>
>> [RG] As I said, I think we should avoid specifying this until we have
>> deployment experience.
> ...
>
> From a process perspective, it's far easier to remove constraints
> as a specification advances than it is to add them.
I agree. It is often better to specify normatively as far as you can 
imagine, so that interoperability and good functionality is achieved. 
Stopping halfway and have MAY in the specifications creates uncertainty 
and less useful specifications.

Furthermore, in this case we succeeded to discuss and sort out the 
interpretation of the unusual combinations.
I am very glad that we sorted out the difference between 1 and 2, and 
they are both real-life cases.

3 is not at all common, but I have seen products claiming to work for 
real-time communication with sign representation in text. So it is good 
to have it settled.

4. Is a bit more far fetched and may cause some questioning if there are 
real cases, and where the line should be drawn between indicating a 
spoken languge in the audio stream and indicating a sign language in the 
audio stream.
As I wiew it now, this combination will be very rare, but it is anyway 
good to be specific and normative about its coding.

Gunnar

>
> Randy
>

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


From nobody Tue Feb 14 12:40:05 2017
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D32AA12985D; Tue, 14 Feb 2017 12:39:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level: 
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-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 OzeGsLoScjzk; Tue, 14 Feb 2017 12:39:58 -0800 (PST)
Received: from smtp-fw-33001.amazon.com (smtp-fw-33001.amazon.com [207.171.190.10]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EB7B1296B2; Tue, 14 Feb 2017 12:39:58 -0800 (PST)
X-IronPort-AV: E=Sophos;i="5.35,162,1484006400"; d="scan'208";a="654281352"
Received: from sea19-co-svc-lb5-vlan3.sea.amazon.com (HELO email-inbound-relay-60015.pdx1.amazon.com) ([10.47.22.166]) by smtp-border-fw-out-33001.sea14.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Feb 2017 20:39:56 +0000
Received: from EX13MTAUWB001.ant.amazon.com (pdx1-ws-svc-p6-lb9-vlan3.pdx.amazon.com [10.236.137.198]) by email-inbound-relay-60015.pdx1.amazon.com (8.14.7/8.14.7) with ESMTP id v1EKdsix011955 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 14 Feb 2017 20:39:55 GMT
Received: from EX13D08UWB003.ant.amazon.com (10.43.161.186) by EX13MTAUWB001.ant.amazon.com (10.43.161.249) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 14 Feb 2017 20:39:55 +0000
Received: from EX13D08UWB002.ant.amazon.com (10.43.161.168) by EX13D08UWB003.ant.amazon.com (10.43.161.186) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 14 Feb 2017 20:39:55 +0000
Received: from EX13D08UWB002.ant.amazon.com ([10.43.161.168]) by EX13D08UWB002.ant.amazon.com ([10.43.161.168]) with mapi id 15.00.1104.000; Tue, 14 Feb 2017 20:39:55 +0000
From: "Phillips, Addison" 
To: =?iso-8859-1?Q?Gunnar_Hellstr=F6m?= , "Randy Presuhn" , "ietf@ietf.org" , "slim@ietf.org" 
Thread-Topic: [Slim] IETF last call for draft-ietf-slim-negotiating-human-language (Section 5.4)
Thread-Index: AQHShk5MdWFzLzaSL0G26SF4TAiur6FoFQsAgAAxCoCAAIAWgIAAJxpAgAAIijA=
Date: Tue, 14 Feb 2017 20:39:55 +0000
Message-ID: <44474907d69a42a0adb66cdc4933603a@EX13D08UWB002.ant.amazon.com>
References: <20170213161000.665a7a7059d7ee80bb4d670165c8327d.917539e857.wbe@email0 3.godaddy.com>  <4c4ef65a-a907-cf5e-4b2c-835fb55d0146@omnitor.se>  <434a4f06-f034-46ca-9df7-f59059e67e41@alumni.stanford.edu> <843f0cc1-2686-162d-25dc-0075847579bc@omnitor.se>
In-Reply-To: <843f0cc1-2686-162d-25dc-0075847579bc@omnitor.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.43.160.56]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Precedence: Bulk
Archived-At: 
Subject: Re: [Slim] IETF last call for draft-ietf-slim-negotiating-human-language (Section 5.4)
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Feb 2017 20:40:00 -0000

I have some allergy to the SHALL language: there is no way to automatically=
 determine conformance. Many language tags represent nonsensical values, du=
e to the nature of language tag composition. Content providers need to use =
care in selecting the tags that they use and this section is merely pointin=
g out good guidance for tag selection, albeit in a heavy-handed way. BCP47 =
RFC 5646 Section 4.1 [1] already provides most of this guidance and a refer=
ence to that source might be useful here, if only because that document req=
uires it:


   Standards, protocols, and applications that reference this document
   normatively but apply different rules to the ones given in this
   section MUST specify how language tag selection varies from the
   guidelines given here.


I would suggest reducing the SHALL items to SHOULD.

I'm not sure what #2 really means. Shouldn't text captions be indicated by =
the written language rather than the spoken language? And I'm not sure what=
 "spoken/written language" means.

Regards,

Addison

Addison Phillips
Principal SDE, I18N Architect (Amazon)
Chair (W3C I18N WG)

Internationalization is not a feature.
It is an architecture.

[1] https://tools.ietf.org/html/bcp47#section-4.1

-----Original Message-----
From: SLIM [mailto:slim-bounces@ietf.org] On Behalf Of Gunnar Hellstr=F6m
Sent: Tuesday, February 14, 2017 11:59 AM
To: Randy Presuhn ; ietf@ietf.org; slim@=
ietf.org
Subject: Re: [Slim] IETF last call for draft-ietf-slim-negotiating-human-la=
nguage (Section 5.4)

Den 2017-02-14 kl. 19:05, skrev Randy Presuhn:

> Hi -
>
> On 2/14/2017 9:40 AM, Randall Gellens wrote:
>> At 11:01 AM +0100 2/14/17, Gunnar Hellstr=F6m wrote:
>>
>>>  My proposal for a reworded section 5.4 is:
>>>
>>>  5.4.  Unusual language indications
>>>
>>>  It is possible to specify an unusual indication where the language =20
>>> specified may look unexpected for the media type.
>>>
>>>  For such cases the following guidance SHALL be applied for the=20
>>> humintlang attributes used in these situations.
>>>
>>>  1.    A view of a speaking person in the video stream SHALL, when it
>>> has relevance for speech perception, be indicated by a Language-Tag=20
>>> for spoken/written language with the "Zxxx" script subtag to=20
>>> indicate that the contents is not written.
>>>
>>>  2.    Text captions included in the video stream SHALL be indicated
>>> by a Language-Tag for spoken/written language.
>>>
>>>  3.    Any approximate representation of sign language or
>>> fingerspelling in the text media stream SHALL be indicated by a=20
>>> Language-Tag for a sign language in text media.
>>>
>>>  4.    When sign language related audio from a person using sign
>>> language is of importance for language communication, this SHALL be=20
>>> indicated by a Language-Tag for a sign language in audio media.
>>
>> [RG] As I said, I think we should avoid specifying this until we have=20
>> deployment experience.
> ...
>
> From a process perspective, it's far easier to remove constraints as a=20
> specification advances than it is to add them.
I agree. It is often better to specify normatively as far as you can imagin=
e, so that interoperability and good functionality is achieved.=20
Stopping halfway and have MAY in the specifications creates uncertainty and=
 less useful specifications.

Furthermore, in this case we succeeded to discuss and sort out the interpre=
tation of the unusual combinations.
I am very glad that we sorted out the difference between 1 and 2, and they =
are both real-life cases.

3 is not at all common, but I have seen products claiming to work for real-=
time communication with sign representation in text. So it is good to have =
it settled.

4. Is a bit more far fetched and may cause some questioning if there are re=
al cases, and where the line should be drawn between indicating a spoken la=
nguge in the audio stream and indicating a sign language in the audio strea=
m.
As I wiew it now, this combination will be very rare, but it is anyway good=
 to be specific and normative about its coding.

Gunnar

>
> Randy
>

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

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


From nobody Tue Feb 14 14: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 D7E951297C3; Tue, 14 Feb 2017 14:35:08 -0800 (PST)
X-Quarantine-ID: 
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VywZs4CehUDL; Tue, 14 Feb 2017 14:35:07 -0800 (PST)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 7603A12944F; Tue, 14 Feb 2017 14:35:07 -0800 (PST)
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Tue, 14 Feb 2017 14:27:08 -0800
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <4c4ef65a-a907-cf5e-4b2c-835fb55d0146@omnitor.se>
References: <20170213161000.665a7a7059d7ee80bb4d670165c8327d.917539e857.wbe@email0 3.godaddy.com>  <4c4ef65a-a907-cf5e-4b2c-835fb55d0146@omnitor.se>
X-Mailer: Eudora for Mac OS X
Date: Tue, 14 Feb 2017 14:35:02 -0800
To: Gunnar =?iso-8859-1?Q?Hellstr=F6m?=  , Bernard Aboba 
From: Randall Gellens 
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
Archived-At: 
Cc: slim@ietf.org, ietf@ietf.org, Doug Ewell 
Subject: Re: [Slim] IETF last call for draft-ietf-slim-negotiating-human-language (Section 5.4)
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Feb 2017 22:35:09 -0000

At 11:01 AM +0100 2/14/17, Gunnar Hellstr=F6m wrote:

>  My proposal for a reworded section 5.4 is:
>
>  5.4.  Unusual language indications
>
>  It is possible to specify an unusual indication where the language
>  specified may look unexpected for the media type.
>
>  For such cases the following guidance SHALL be=20
> applied for the humintlang attributes used in=20
> these situations.
>
>  1.	A view of a speaking person in the video=20
> stream SHALL, when it has relevance for speech=20
> perception, be indicated by a Language-Tag for=20
> spoken/written language with the "Zxxx" script=20
> subtag to indicate that the contents is not=20
> written.

What does "relevance for speech perception" mean=20
in the spec, and how is it determined?

>
>  2.	Text captions included in the video=20
> stream SHALL be indicated by a Language-Tag for=20
> spoken/written language.

Is this commonly supported such that it makes=20
sense to include in the current draft?  Perhaps=20
it should wait for an update that might include=20
similar functionality such as text captions for=20
audio streams.

>
>  3.	Any approximate representation of sign=20
> language or fingerspelling in the text media=20
> stream SHALL be indicated by a Language-Tag for=20
> a sign language in text media.

Same comment as for (2).

>
>  4.	When sign language related audio from a=20
> person using sign language is of importance for=20
> language communication, this SHALL be indicated=20
> by a Language-Tag for a sign language in audio=20
> media.

Same comment as for (1).


-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
They say that 90 per cent of TV is junk.  But 90 per cent
of *everything* is junk.
      --Gene Roddenberry, interview in TV Guide, Apr. 27, 1974
      (quoting Sturgeon's Revelation: "Ninety percent of
      everything is crap.")


From nobody Tue Feb 14 14:39: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 8F9F71293E3; Tue, 14 Feb 2017 14:39:53 -0800 (PST)
X-Quarantine-ID: <1Dt_4kyLjWE7>
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 1Dt_4kyLjWE7; Tue, 14 Feb 2017 14:39:52 -0800 (PST)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id AA9B91293D9; Tue, 14 Feb 2017 14:39:52 -0800 (PST)
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Tue, 14 Feb 2017 14:31:55 -0800
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <434a4f06-f034-46ca-9df7-f59059e67e41@alumni.stanford.edu>
References: <20170213161000.665a7a7059d7ee80bb4d670165c8327d.917539e857.wbe@email0 3.godaddy.com>  <4c4ef65a-a907-cf5e-4b2c-835fb55d0146@omnitor.se>  <434a4f06-f034-46ca-9df7-f59059e67e41@alumni.stanford.edu>
X-Mailer: Eudora for Mac OS X
Date: Tue, 14 Feb 2017 14:39:50 -0800
To: Randy Presuhn , ietf@ietf.org
From: Randall Gellens 
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
Archived-At: 
Cc: slim@ietf.org
Subject: Re: [Slim] IETF last call for draft-ietf-slim-negotiating-human-language (Section 5.4)
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Feb 2017 22:39:53 -0000

At 10:05 AM -0800 2/14/17, Randy Presuhn wrote:

>  Hi -
>
>  On 2/14/2017 9:40 AM, Randall Gellens wrote:
>>  At 11:01 AM +0100 2/14/17, Gunnar Hellstr=F6m wrote:
>>
>>>   My proposal for a reworded section 5.4 is:
>>>
>>>   5.4.  Unusual language indications
>>>
>>>   It is possible to specify an unusual indication where the language
>>>   specified may look unexpected for the media type.
>>>
>>>   For such cases the following guidance SHALL be applied for the
>>>  humintlang attributes used in these situations.
>>>
>>>   1.    A view of a speaking person in the video stream SHALL, when it
>>>  has relevance for speech perception, be indicated by a Language-Tag
>>>  for spoken/written language with the "Zxxx" script subtag to indicate
>>>  that the contents is not written.
>>>
>>>   2.    Text captions included in the video stream SHALL be indicated
>>>  by a Language-Tag for spoken/written language.
>>>
>>>   3.    Any approximate representation of sign language or
>>>  fingerspelling in the text media stream SHALL be indicated by a
>>>  Language-Tag for a sign language in text media.
>>>
>>>   4.    When sign language related audio from a person using sign
>>>  language is of importance for language communication, this SHALL be
>>>  indicated by a Language-Tag for a sign language in audio media.
>>
>>  [RG] As I said, I think we should avoid specifying this until we have
>>  deployment experience.
>  ...
>
>  From a process perspective, it's far easier to remove constraints
>  as a specification advances than it is to add them.

Which supports the text I proposed on Monday:

    Specifying a non-signed language tag for a video media stream, or a
    signed language tag for a non-video media stream, is not defined.  An
    offer with such a combination SHOULD NOT be created.  If such an
    offer is received, the receiver MAY ignore the language specified.

This proposed text has a mild constraint to not=20
include such combinations.  By using "SHOULD NOT"=20
and "MAY" we allow cooperating implementations to=20
use it without imposing semantic implications now=20
that might not be what we need in the future.=20
After we have some experience, we can either use=20
the existing attributes and language tags to=20
impose meanings as Gunnar suggests, or we might=20
find we need a different mechanism that has more=20
functionality.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
The solution to a problem changes the nature of the problem.


From nobody Tue Feb 14 14:44:44 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 C873D12943C; Tue, 14 Feb 2017 14:44:43 -0800 (PST)
X-Quarantine-ID: 
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NzDusL1yPUYV; Tue, 14 Feb 2017 14:44:41 -0800 (PST)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id C65AC12940D; Tue, 14 Feb 2017 14:44:41 -0800 (PST)
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Tue, 14 Feb 2017 14:36:44 -0800
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <843f0cc1-2686-162d-25dc-0075847579bc@omnitor.se>
References: <20170213161000.665a7a7059d7ee80bb4d670165c8327d.917539e857.wbe@email0 3.godaddy.com>  <4c4ef65a-a907-cf5e-4b2c-835fb55d0146@omnitor.se>  <434a4f06-f034-46ca-9df7-f59059e67e41@alumni.stanford.edu> <843f0cc1-2686-162d-25dc-0075847579bc@omnitor.se>
X-Mailer: Eudora for Mac OS X
Date: Tue, 14 Feb 2017 14:43:34 -0800
To: Gunnar =?iso-8859-1?Q?Hellstr=F6m?=  , Randy Presuhn , ietf@ietf.org, "slim@ietf.org" 
From: Randall Gellens 
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
Archived-At: 
Subject: Re: [Slim] IETF last call for draft-ietf-slim-negotiating-human-language (Section 5.4)
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Feb 2017 22:44:44 -0000

At 8:59 PM +0100 2/14/17, Gunnar Hellstr=F6m wrote:

>  Den 2017-02-14 kl. 19:05, skrev Randy Presuhn:
>
>>  Hi -
>>
>>  On 2/14/2017 9:40 AM, Randall Gellens wrote:
>>>  At 11:01 AM +0100 2/14/17, Gunnar Hellstr=F6m wrote:
>>>
>>>>   My proposal for a reworded section 5.4 is:
>>>>
>>>>   5.4.  Unusual language indications
>>>>
>>>>   It is possible to specify an unusual indication where the language
>>>>   specified may look unexpected for the media type.
>>>>
>>>>   For such cases the following guidance SHALL be applied for the
>>>>  humintlang attributes used in these situations.
>>>>
>>>>   1.    A view of a speaking person in the video stream SHALL, when it
>>>>  has relevance for speech perception, be indicated by a Language-Tag
>>>>  for spoken/written language with the "Zxxx" script subtag to indicate
>>>>  that the contents is not written.
>>>>
>>>>   2.    Text captions included in the video stream SHALL be indicated
>>>>  by a Language-Tag for spoken/written language.
>>>>
>>>>   3.    Any approximate representation of sign language or
>>>>  fingerspelling in the text media stream SHALL be indicated by a
>>>>  Language-Tag for a sign language in text media.
>>>>
>>>>   4.    When sign language related audio from a person using sign
>>>>  language is of importance for language communication, this SHALL be
>>>>  indicated by a Language-Tag for a sign language in audio media.
>>>
>>>  [RG] As I said, I think we should avoid specifying this until we have
>>>  deployment experience.
>>  ...
>>
>>  From a process perspective, it's far easier to remove constraints
>>  as a specification advances than it is to add them.
>  I agree. It is often better to specify=20
> normatively as far as you can imagine, so that=20
> interoperability and good functionality is=20
> achieved. Stopping halfway and have MAY in the=20
> specifications creates uncertainty and less=20
> useful specifications.

My reading of what Randy says is the opposite of=20
Gunnar's.  In my reading, Randy points out that=20
is it easier to remove the SHOULD NOT in the=20
future then it is to change the meaning of the=20
combinations or switch to a different mechanism.

In my experience, it's better to specify only=20
what we know we need and what we know we=20
understand.  Speculative specifications "as far=20
as you can imagine" more often lead to=20
interoperability problems, unnecessary=20
complexity, limitations on what's needed in the=20
future, and divergent implementations.

>
>  Furthermore, in this case we succeeded to=20
> discuss and sort out the interpretation of the=20
> unusual combinations.
>  I am very glad that we sorted out the=20
> difference between 1 and 2, and they are both=20
> real-life cases.
>
>  3 is not at all common, but I have seen=20
> products claiming to work for real-time=20
> communication with sign representation in text.=20
> So it is good to have it settled.
>
>  4. Is a bit more far fetched and may cause some=20
> questioning if there are real cases, and where=20
> the line should be drawn between indicating a=20
> spoken languge in the audio stream and=20
> indicating a sign language in the audio stream.
>  As I wiew it now, this combination will be very=20
> rare, but it is anyway good to be specific and=20
> normative about its coding.


-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
A day for firm decisions!!!!!  Or is it?


From nobody Tue Feb 14 16:21: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 546B1129442 for ; Tue, 14 Feb 2017 16:21:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.121
X-Spam-Level: 
X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, 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 o3LW4rD-wAG4 for ; Tue, 14 Feb 2017 16:21:36 -0800 (PST)
Received: from mail-it0-f54.google.com (mail-it0-f54.google.com [209.85.214.54]) (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 2290F129484 for ; Tue, 14 Feb 2017 16:21:36 -0800 (PST)
Received: by mail-it0-f54.google.com with SMTP id c7so54450291itd.1 for ; Tue, 14 Feb 2017 16:21:36 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=sK/tpB20jxzOLqJ60lPzTXfGAxvLfj8oyttxQYZakos=; b=iHeKym4OXONUHQ59JTkGu8nwPbFkE0gfh3o7yfmjoBVC6MPPijvT4cQXYBPPb2S0qs HWV+ZaXmY/YwN8DFtf2twwcYMsFW5pER4iCu8F49bRBjsyKdvjVqJrLTM8fKLlt42moj 0XdsQiqfersMsdGvUlyTnl9kfo7zr7hHtGdPQYutf4OXo5OvB68YJ5zvfVHdltFq9oMb 4MKW9iqJbUIvI7a1VfUFiCSwQQoNeiKLaSIIxCe/jItnND3T1ZzO3mrZRSrbzFm+jidV 4BS/j7L876d0y4KHYtLAK+aK4t3vx/FPO2jJNJ+GuWBDcwfgVH00/9cGHdawG9akJ43B WTYQ==
X-Gm-Message-State: AMke39mz55MwNTiSfdJN97v6Ve6DXuNbKMD5vM8furAPi0Mx9UdlUfB+F4AzsxZyaNffBpJ9
X-Received: by 10.84.236.9 with SMTP id q9mr35996783plk.96.1487118095087; Tue, 14 Feb 2017 16:21:35 -0800 (PST)
Received: from [192.168.1.114] (c-50-143-178-150.hsd1.ca.comcast.net. [50.143.178.150]) by smtp.gmail.com with ESMTPSA id g85sm3329042pfe.38.2017.02.14.16.21.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Feb 2017 16:21:34 -0800 (PST)
To: ietf@ietf.org, "slim@ietf.org" 
References: <20170213161000.665a7a7059d7ee80bb4d670165c8327d.917539e857.wbe@email0 3.godaddy.com>  <4c4ef65a-a907-cf5e-4b2c-835fb55d0146@omnitor.se>  <434a4f06-f034-46ca-9df7-f59059e67e41@alumni.stanford.edu> <843f0cc1-2686-162d-25dc-0075847579bc@omnitor.se> 
From: Randy Presuhn 
Message-ID: <84760193-19e6-1f53-43cc-32b0493a1844@alumni.stanford.edu>
Date: Tue, 14 Feb 2017 16:21:35 -0800
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
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] IETF last call for draft-ietf-slim-negotiating-human-language (Section 5.4)
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Feb 2017 00:21:37 -0000

Hi -

On 2/14/2017 2:43 PM, Randall Gellens wrote:
> At 8:59 PM +0100 2/14/17, Gunnar Hellström wrote:
>
>>  Den 2017-02-14 kl. 19:05, skrev Randy Presuhn:
>>
>>>  Hi -
>>>
>>>  On 2/14/2017 9:40 AM, Randall Gellens wrote:
>>>>  At 11:01 AM +0100 2/14/17, Gunnar Hellström wrote:
>>>>
>>>>>   My proposal for a reworded section 5.4 is:
>>>>>
>>>>>   5.4.  Unusual language indications
>>>>>
>>>>>   It is possible to specify an unusual indication where the language
>>>>>   specified may look unexpected for the media type.
>>>>>
>>>>>   For such cases the following guidance SHALL be applied for the
>>>>>  humintlang attributes used in these situations.
>>>>>
>>>>>   1.    A view of a speaking person in the video stream SHALL, when it
>>>>>  has relevance for speech perception, be indicated by a Language-Tag
>>>>>  for spoken/written language with the "Zxxx" script subtag to indicate
>>>>>  that the contents is not written.
>>>>>
>>>>>   2.    Text captions included in the video stream SHALL be indicated
>>>>>  by a Language-Tag for spoken/written language.
>>>>>
>>>>>   3.    Any approximate representation of sign language or
>>>>>  fingerspelling in the text media stream SHALL be indicated by a
>>>>>  Language-Tag for a sign language in text media.
>>>>>
>>>>>   4.    When sign language related audio from a person using sign
>>>>>  language is of importance for language communication, this SHALL be
>>>>>  indicated by a Language-Tag for a sign language in audio media.
>>>>
>>>>  [RG] As I said, I think we should avoid specifying this until we have
>>>>  deployment experience.
>>>  ...
>>>
>>>  From a process perspective, it's far easier to remove constraints
>>>  as a specification advances than it is to add them.
>>  I agree. It is often better to specify normatively as far as you can
>> imagine, so that interoperability and good functionality is achieved.
>> Stopping halfway and have MAY in the specifications creates
>> uncertainty and less useful specifications.
>
> My reading of what Randy says is the opposite of Gunnar's.  In my
> reading, Randy points out that is it easier to remove the SHOULD NOT in
> the future then it is to change the meaning of the combinations or
> switch to a different mechanism.
>
> In my experience, it's better to specify only what we know we need and
> what we know we understand.  Speculative specifications "as far as you
> can imagine" more often lead to interoperability problems, unnecessary
> complexity, limitations on what's needed in the future, and divergent
> implementations.

I think the difference in your positions comes down to

   (1) your respective notions of "what we know we need and what we
       know we understand";

   (2) whether you believe that the interoperability and conformance
       consequences of removing a "SHOULD NOT" could be the same
       as those merely retaining a "MUST" or "SHALL" - this determines
       whether Randy G.'s proposal provides a path for some future
       revision to mandate (if deployment experience substantiates the
       need/understanding) the behavior proposed by Gunnar.  That path
       is not at all obvious to me.

Randy


From nobody Tue Feb 14 16:39: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 ABD1A12953B; Tue, 14 Feb 2017 16:39:25 -0800 (PST)
X-Quarantine-ID: 
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BOoRFRq1mXJg; Tue, 14 Feb 2017 16:39:24 -0800 (PST)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 2893212945D; Tue, 14 Feb 2017 16:39:24 -0800 (PST)
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Tue, 14 Feb 2017 16:31:25 -0800
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <84760193-19e6-1f53-43cc-32b0493a1844@alumni.stanford.edu>
References: <20170213161000.665a7a7059d7ee80bb4d670165c8327d.917539e857.wbe@email0 3.godaddy.com>  <4c4ef65a-a907-cf5e-4b2c-835fb55d0146@omnitor.se>  <434a4f06-f034-46ca-9df7-f59059e67e41@alumni.stanford.edu> <843f0cc1-2686-162d-25dc-0075847579bc@omnitor.se>  <84760193-19e6-1f53-43cc-32b0493a1844@alumni.stanford.edu>
X-Mailer: Eudora for Mac OS X
Date: Tue, 14 Feb 2017 16:39:21 -0800
To: Randy Presuhn , ietf@ietf.org, "slim@ietf.org" 
From: Randall Gellens 
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
Archived-At: 
Subject: Re: [Slim] IETF last call for draft-ietf-slim-negotiating-human-language (Section 5.4)
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Feb 2017 00:39:26 -0000

At 4:21 PM -0800 2/14/17, Randy Presuhn wrote:

>  Hi -
>
>  On 2/14/2017 2:43 PM, Randall Gellens wrote:
>>  At 8:59 PM +0100 2/14/17, Gunnar Hellstr=F6m wrote:
>>
>>>   Den 2017-02-14 kl. 19:05, skrev Randy Presuhn:
>>>
>>>>   Hi -
>>>>
>>>>   On 2/14/2017 9:40 AM, Randall Gellens wrote:
>>>>>   At 11:01 AM +0100 2/14/17, Gunnar Hellstr=F6m wrote:
>>>>>
>>>>>>    My proposal for a reworded section 5.4 is:
>>>>>>
>>>>>>    5.4.  Unusual language indications
>>>>>>
>>>>>>    It is possible to specify an unusual indication where the language
>>>>>>    specified may look unexpected for the media type.
>>>>>>
>>>>>>    For such cases the following guidance SHALL be applied for the
>>>>>>   humintlang attributes used in these situations.
>>>>>>
>>>>>>    1.    A view of a speaking person in the video stream SHALL, when =
it
>>>>>>   has relevance for speech perception, be indicated by a Language-Tag
>>>>>>   for spoken/written language with the "Zxxx" script subtag to indica=
te
>>>>>>   that the contents is not written.
>>>>>>
>>>>>>    2.    Text captions included in the video stream SHALL be indicate=
d
>>>>>>   by a Language-Tag for spoken/written language.
>>>>>>
>>>>>>    3.    Any approximate representation of sign language or
>>>>>>   fingerspelling in the text media stream SHALL be indicated by a
>>>>>>   Language-Tag for a sign language in text media.
>>>>>>
>>>>>>    4.    When sign language related audio from a person using sign
>>>>>>   language is of importance for language communication, this SHALL be
>>>>>>   indicated by a Language-Tag for a sign language in audio media.
>>>>>
>>>>>   [RG] As I said, I think we should avoid specifying this until we hav=
e
>>>>>   deployment experience.
>>>>   ...
>>>>
>>>>   From a process perspective, it's far easier to remove constraints
>>>>   as a specification advances than it is to add them.
>>>   I agree. It is often better to specify normatively as far as you can
>>>  imagine, so that interoperability and good functionality is achieved.
>>>  Stopping halfway and have MAY in the specifications creates
>>>  uncertainty and less useful specifications.
>>
>>  My reading of what Randy says is the opposite of Gunnar's.  In my
>>  reading, Randy points out that is it easier to remove the SHOULD NOT in
>>  the future then it is to change the meaning of the combinations or
>>  switch to a different mechanism.
>>
>>  In my experience, it's better to specify only what we know we need and
>>  what we know we understand.  Speculative specifications "as far as you
>>  can imagine" more often lead to interoperability problems, unnecessary
>>  complexity, limitations on what's needed in the future, and divergent
>>  implementations.
>
>  I think the difference in your positions comes down to
>
>    (1) your respective notions of "what we know we need and what we
>        know we understand";
>
>    (2) whether you believe that the interoperability and conformance
>        consequences of removing a "SHOULD NOT" could be the same
>        as those merely retaining a "MUST" or "SHALL" - this determines
>        whether Randy G.'s proposal provides a path for some future
>        revision to mandate (if deployment experience substantiates the
>        need/understanding) the behavior proposed by Gunnar.  That path
>        is not at all obvious to me.

The purpose of the draft is to enable the two=20
endpoints of a real-time communication session to=20
agree which languages and media to use for=20
interactive communication.  We have a mechanism=20
of adding language tags to media stream=20
negotiations.  In most cases, the language and=20
media modality are an obvious fit.  There are=20
combinations of media and language where the=20
meaning is not so obvious, specifically, signed=20
language tags with a audio or text, and=20
non-signed language tags with video.  My proposal=20
is that we say offerer SHOULD NOT send such=20
combinations and answerer MAY ignore language.=20
This allows future specifications for the=20
underlying uses Gunnar wants (such as real-time=20
subtitles in video and signed equivalents in=20
text).  Such future specifications could define a=20
use for the language and media combinations and=20
remove the SHOULD NOT send and MAY ignore, or=20
could define a new mechanism.  I don't think we=20
know enough now to dictate what the solution=20
should be.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Dogs have owners.  Cats have staff.


From nobody Wed Feb 15 01:41: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 749B5129550 for ; Wed, 15 Feb 2017 01:41:09 -0800 (PST)
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 s0FwezCComxx for ; Wed, 15 Feb 2017 01:41:06 -0800 (PST)
Received: from bin-vsp-out-03.atm.binero.net (bin-mail-out-06.binero.net [195.74.38.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 436EB1294F7 for ; Wed, 15 Feb 2017 01:41:06 -0800 (PST)
X-Halon-ID: d244c837-f362-11e6-9c99-0050569116f7
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [83.209.158.27]) by bin-vsp-out-03.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Wed, 15 Feb 2017 10:40:43 +0100 (CET)
To: ietf@ietf.org, "slim@ietf.org" 
References: <20170213161000.665a7a7059d7ee80bb4d670165c8327d.917539e857.wbe@email0 3.godaddy.com>  <4c4ef65a-a907-cf5e-4b2c-835fb55d0146@omnitor.se>  <434a4f06-f034-46ca-9df7-f59059e67e41@alumni.stanford.edu> <843f0cc1-2686-162d-25dc-0075847579bc@omnitor.se>  <84760193-19e6-1f53-43cc-32b0493a1844@alumni.stanford.edu> 
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: <4f1f3a72-d8a9-4f41-4133-0e6d54aadec8@omnitor.se>
Date: Wed, 15 Feb 2017 10:41:00 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
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] IETF last call for draft-ietf-slim-negotiating-human-language (Section 5.4)
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Feb 2017 09:41:09 -0000

Den 2017-02-15 kl. 01:39, skrev Randall Gellens:
> At 4:21 PM -0800 2/14/17, Randy Presuhn wrote:
>
>>  Hi -
>>
>>  On 2/14/2017 2:43 PM, Randall Gellens wrote:
>>>  At 8:59 PM +0100 2/14/17, Gunnar Hellström wrote:
>>>
>>>>   Den 2017-02-14 kl. 19:05, skrev Randy Presuhn:
>>>>
>>>>>   Hi -
>>>>>
>>>>>   On 2/14/2017 9:40 AM, Randall Gellens wrote:
>>>>>>   At 11:01 AM +0100 2/14/17, Gunnar Hellström wrote:
>>>>>>
>>>>>>>    My proposal for a reworded section 5.4 is:
>>>>>>>
>>>>>>>    5.4.  Unusual language indications
>>>>>>>
>>>>>>>    It is possible to specify an unusual indication where the 
>>>>>>> language
>>>>>>>    specified may look unexpected for the media type.
>>>>>>>
>>>>>>>    For such cases the following guidance SHALL be applied for the
>>>>>>>   humintlang attributes used in these situations.
>>>>>>>
>>>>>>>    1.    A view of a speaking person in the video stream SHALL, 
>>>>>>> when it
>>>>>>>   has relevance for speech perception, be indicated by a 
>>>>>>> Language-Tag
>>>>>>>   for spoken/written language with the "Zxxx" script subtag to 
>>>>>>> indicate
>>>>>>>   that the contents is not written.
>>>>>>>
>>>>>>>    2.    Text captions included in the video stream SHALL be 
>>>>>>> indicated
>>>>>>>   by a Language-Tag for spoken/written language.
>>>>>>>
>>>>>>>    3.    Any approximate representation of sign language or
>>>>>>>   fingerspelling in the text media stream SHALL be indicated by a
>>>>>>>   Language-Tag for a sign language in text media.
>>>>>>>
>>>>>>>    4.    When sign language related audio from a person using sign
>>>>>>>   language is of importance for language communication, this 
>>>>>>> SHALL be
>>>>>>>   indicated by a Language-Tag for a sign language in audio media.
>>>>>>
>>>>>>   [RG] As I said, I think we should avoid specifying this until 
>>>>>> we have
>>>>>>   deployment experience.
>>>>>   ...
>>>>>
>>>>>   From a process perspective, it's far easier to remove constraints
>>>>>   as a specification advances than it is to add them.
>>>>   I agree. It is often better to specify normatively as far as you can
>>>>  imagine, so that interoperability and good functionality is achieved.
>>>>  Stopping halfway and have MAY in the specifications creates
>>>>  uncertainty and less useful specifications.
>>>
>>>  My reading of what Randy says is the opposite of Gunnar's. In my
>>>  reading, Randy points out that is it easier to remove the SHOULD 
>>> NOT in
>>>  the future then it is to change the meaning of the combinations or
>>>  switch to a different mechanism.
>>>
>>>  In my experience, it's better to specify only what we know we need and
>>>  what we know we understand.  Speculative specifications "as far as you
>>>  can imagine" more often lead to interoperability problems, unnecessary
>>>  complexity, limitations on what's needed in the future, and divergent
>>>  implementations.
>>
>>  I think the difference in your positions comes down to
>>
>>    (1) your respective notions of "what we know we need and what we
>>        know we understand";
>>
>>    (2) whether you believe that the interoperability and conformance
>>        consequences of removing a "SHOULD NOT" could be the same
>>        as those merely retaining a "MUST" or "SHALL" - this determines
>>        whether Randy G.'s proposal provides a path for some future
>>        revision to mandate (if deployment experience substantiates the
>>        need/understanding) the behavior proposed by Gunnar. That path
>>        is not at all obvious to me.
>
> The purpose of the draft is to enable the two endpoints of a real-time 
> communication session to agree which languages and media to use for 
> interactive communication.  We have a mechanism of adding language 
> tags to media stream negotiations.  In most cases, the language and 
> media modality are an obvious fit.  There are combinations of media 
> and language where the meaning is not so obvious, specifically, signed 
> language tags with a audio or text, and non-signed language tags with 
> video.  My proposal is that we say offerer SHOULD NOT send such 
> combinations and answerer MAY ignore language. This allows future 
> specifications for the underlying uses Gunnar wants (such as real-time 
> subtitles in video and signed equivalents in text).  Such future 
> specifications could define a use for the language and media 
> combinations and remove the SHOULD NOT send and MAY ignore, or could 
> define a new mechanism.  I don't think we know enough now to dictate 
> what the solution should be.
We have a fresh example from our own discussions in the SLIM group how 
unfortunate it is to not be sufficiently explicit in the first edition 
of a standard. The SDP Lang attribute in RFC 4566, where you (Randall) 
say it is intended for specifying a set of languages that all must be 
used in a session, while I say that it is intended for negotiation of at 
least one initial language. By having that uncertainty in a 
specification that has been published makes it very hard to sharpen up 
the specification afterwards because it would possibly make some 
implementations non conformant. And it makes potential implementors 
hesitant to use the current specifications, as it was with the SLIM work.

For 5.4.

I am OK with modifying from my latest proposal, but we need to be specific.
I am also OK with reducing the SHALLs to SHOULDs as Addison requested.

The situation is not that we lack knowledge. Here is what we know about 
the 4 cases of "unusual" indications:

1. View of the speaker in video. Very important for speech perception. 
Quality requirements are documented in ITU-T H-series Supplement 1. Of 
real use only as a complement to the same spoken language in audio. Now, 
when we know about the Zxxx notation for non-written, we also have a 
good way of specifying it precisely.
This case was also described in section 5.2 already.

2. Text captions in the video stream.
This can be either text merged into video and communicated as true part 
of the video image, or it can be a text component of a multimedia 
system, as MPEG-4, declared in SDP as m=video.
It has been used in some videophone products, but I have not seen it 
used lately.
It is a clearly defined case, and we can specify coding for it, but we 
do not at the moment know if it will be important to specify it.

3. Sign language or fingerspelling in the text stream.
I have seen a product using it for claimed sign language conversation. 
It is also in use in the simple text form with words in capitals 
approximately representing signs between persons involved in preparation 
of sign language productions and translations. But in that case it is in 
a session where they agree in other ways to start using the text stream 
for that purpose. So I think we can say that this is rare, and its use 
can be agreed by other means between the users. Still it is a clearly 
defined case.

4. Audio from signing person related to sign language. This is more 
vague than the others.  It may be a person signing in video and adding 
spoken words in audio to signing, but influenced by the word order and 
grammar of sign language with some ambition to make it reasonably 
understandable for both deaf and hearing participants. There are even 
some spoken words created from sign language that are commonly used by 
hearing persons in such situations. But for that case I anyway think it 
is better to define the audio part as the spoken language it is derived 
from, because of its intention to be understandable for hearing persons. 
All other variants I can imagine are even closer to the spoken language 
and should be specified with spoken language tag. If we only want to 
have the audio stream established to hear the background in the signing 
situation, then we should not specify language use of the audio stream.
Even if we know what sign language tag in audio stream would be, it may 
be just as good to leave it undefined.
------------------------------------------------------------------------------------------------------------------------------------------------
So, new proposal:

5.4.  Unusual language indications

    It is possible to specify an unusual indication where the language
    specified may look unexpected for the media type.

    For such cases the following guidance SHOULD be applied for the
   humintlang attributes used in these situations.

    1.    A view of a speaking person in the video stream SHOULD, when it
   has relevance for speech perception, be indicated by a humintlang 
attribute with a Language-Tag
   for a spoken/written language with the "Zxxx" script subtag to indicate
   that the contents is not written.

    2.    Text captions included in the video stream SHOULD be indicated
   by a humintlang attribute with Language-Tag for spoken/written language.

    3.    A Language-Tag for a sign language specified in a humintlang 
attribute for a text stream MAY be interpreted as use of an approximate 
representation of sign language or fingerspelling in the text media 
stream. The use of such representation is rare and usually conveniently 
agreed by other means between the users during an established session. 
Common support of this indication SHOULD NOT be assumed or required.

    4.    A Language-Tag for a sign language specified in a humintlang 
attribute for an audio stream SHOULD NOT be indicated and MAY be ignored 
on reception. Any use of spoken words or spoken language in the audio 
stream SHOULD, when it can be of importance for language communication, 
be indicated by the corresponding Language-Tag for spoken language in a 
humintlang attribute for the audio stream.




Gunnar


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


From nobody Wed Feb 15 02:08:00 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 800CE1294FD for ; Wed, 15 Feb 2017 02:07:53 -0800 (PST)
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=unavailable 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 FZ9plnWTvmiz for ; Wed, 15 Feb 2017 02:07:51 -0800 (PST)
Received: from bin-vsp-out-01.atm.binero.net (bin-mail-out-06.binero.net [195.74.38.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C32671294D8 for ; Wed, 15 Feb 2017 02:07:50 -0800 (PST)
X-Halon-ID: 9523edf9-f366-11e6-a131-005056917a89
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [83.209.158.27]) by bin-vsp-out-01.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Wed, 15 Feb 2017 11:07:39 +0100 (CET)
To: "Phillips, Addison" , Randy Presuhn , "ietf@ietf.org" , "slim@ietf.org" 
References: <20170213161000.665a7a7059d7ee80bb4d670165c8327d.917539e857.wbe@email0 3.godaddy.com>  <4c4ef65a-a907-cf5e-4b2c-835fb55d0146@omnitor.se>  <434a4f06-f034-46ca-9df7-f59059e67e41@alumni.stanford.edu> <843f0cc1-2686-162d-25dc-0075847579bc@omnitor.se> <44474907d69a42a0adb66cdc4933603a@EX13D08UWB002.ant.amazon.com>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: 
Date: Wed, 15 Feb 2017 11:07:46 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <44474907d69a42a0adb66cdc4933603a@EX13D08UWB002.ant.amazon.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [Slim] IETF last call for draft-ietf-slim-negotiating-human-language (Section 5.4)
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Feb 2017 10:07:53 -0000

Addison,

Den 2017-02-14 kl. 21:39, skrev Phillips, Addison:
> I have some allergy to the SHALL language: there is no way to automatically determine conformance. Many language tags represent nonsensical values, due to the nature of language tag composition. Content providers need to use care in selecting the tags that they use and this section is merely pointing out good guidance for tag selection, albeit in a heavy-handed way. BCP47 RFC 5646 Section 4.1 [1] already provides most of this guidance and a reference to that source might be useful here, if only because that document requires it:
>
> 
>     Standards, protocols, and applications that reference this document
>     normatively but apply different rules to the ones given in this
>     section MUST specify how language tag selection varies from the
>     guidelines given here.
> 
>
> I would suggest reducing the SHALL items to SHOULD.
Accepted.
That also opens up for another use we have discussed before but been 
advised to not use. That is to indicate use of written language by 
attaching a script subtag even if the script subtag we use is suppressed 
by BCP 47. We can dro that need however, with the use of the Zxxx script 
subtag for non-written, and clearly include that usage in our 
specification as required from BCP 47.
>
> I'm not sure what #2 really means. Shouldn't text captions be indicated by the written language rather than the spoken language? And I'm not sure what "spoken/written language" means.
#2 was: "

2.    Text captions included in the video stream SHALL be indicated
by a Language-Tag for spoken/written language."

Yes, the intention is to use written language in the video stream. There 
are technologies for that.
Since the language subtags in the IANA registry are combined for spoken 
languages and written languages, I call them Language-Tags for 
spoken/written language.
It would be misleading to say that we use a Language-Tag for a written 
language, because the same tag could in another context mean a spoken 
language.
Since we have the script subtag Zxxx for non-written, we do not need to 
construct an explicit tag for the written language tag, it should be 
sufficient with our specification of the use in our case.

In my latest recent proposal, I still have a very similar wording. Since 
you had problems understanding it, there might still be a need to tune 
it. Can you propose wording?
This is the current proposal:

"   2.    Text captions included in the video stream SHOULD be indicated
   by a humintlang attribute with Language-Tag for spoken/written language.
"

Regards
Gunnar
>
> Regards,
>
> Addison
>
> Addison Phillips
> Principal SDE, I18N Architect (Amazon)
> Chair (W3C I18N WG)
>
> Internationalization is not a feature.
> It is an architecture.
>
> [1] https://tools.ietf.org/html/bcp47#section-4.1
>
> -----Original Message-----
> From: SLIM [mailto:slim-bounces@ietf.org] On Behalf Of Gunnar Hellström
> Sent: Tuesday, February 14, 2017 11:59 AM
> To: Randy Presuhn ; ietf@ietf.org; slim@ietf.org
> Subject: Re: [Slim] IETF last call for draft-ietf-slim-negotiating-human-language (Section 5.4)
>
> Den 2017-02-14 kl. 19:05, skrev Randy Presuhn:
>
>> Hi -
>>
>> On 2/14/2017 9:40 AM, Randall Gellens wrote:
>>> At 11:01 AM +0100 2/14/17, Gunnar Hellström wrote:
>>>
>>>>   My proposal for a reworded section 5.4 is:
>>>>
>>>>   5.4.  Unusual language indications
>>>>
>>>>   It is possible to specify an unusual indication where the language
>>>> specified may look unexpected for the media type.
>>>>
>>>>   For such cases the following guidance SHALL be applied for the
>>>> humintlang attributes used in these situations.
>>>>
>>>>   1.    A view of a speaking person in the video stream SHALL, when it
>>>> has relevance for speech perception, be indicated by a Language-Tag
>>>> for spoken/written language with the "Zxxx" script subtag to
>>>> indicate that the contents is not written.
>>>>
>>>>   2.    Text captions included in the video stream SHALL be indicated
>>>> by a Language-Tag for spoken/written language.
>>>>
>>>>   3.    Any approximate representation of sign language or
>>>> fingerspelling in the text media stream SHALL be indicated by a
>>>> Language-Tag for a sign language in text media.
>>>>
>>>>   4.    When sign language related audio from a person using sign
>>>> language is of importance for language communication, this SHALL be
>>>> indicated by a Language-Tag for a sign language in audio media.
>>> [RG] As I said, I think we should avoid specifying this until we have
>>> deployment experience.
>> ...
>>
>>  From a process perspective, it's far easier to remove constraints as a
>> specification advances than it is to add them.
> I agree. It is often better to specify normatively as far as you can imagine, so that interoperability and good functionality is achieved.
> Stopping halfway and have MAY in the specifications creates uncertainty and less useful specifications.
>
> Furthermore, in this case we succeeded to discuss and sort out the interpretation of the unusual combinations.
> I am very glad that we sorted out the difference between 1 and 2, and they are both real-life cases.
>
> 3 is not at all common, but I have seen products claiming to work for real-time communication with sign representation in text. So it is good to have it settled.
>
> 4. Is a bit more far fetched and may cause some questioning if there are real cases, and where the line should be drawn between indicating a spoken languge in the audio stream and indicating a sign language in the audio stream.
> As I wiew it now, this combination will be very rare, but it is anyway good to be specific and normative about its coding.
>
> Gunnar
>
>> Randy
>>
> --
> -----------------------------------------
> Gunnar Hellström
> Omnitor
> gunnar.hellstrom@omnitor.se
> +46 708 204 288
>
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim

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


From nobody Wed Feb 15 04:33: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 3E52C127735 for ; Wed, 15 Feb 2017 04:33:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 1peBmK5Qo9-k for ; Wed, 15 Feb 2017 04:33:03 -0800 (PST)
Received: from bin-vsp-out-03.atm.binero.net (bin-mail-out-05.binero.net [195.74.38.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 825AC129443 for ; Wed, 15 Feb 2017 04:33:03 -0800 (PST)
X-Halon-ID: e2eb9301-f37a-11e6-9c99-0050569116f7
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [83.209.158.27]) by bin-vsp-out-03.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Wed, 15 Feb 2017 13:32:57 +0100 (CET)
To: ietf@ietf.org, "slim@ietf.org" 
References: <20170213161000.665a7a7059d7ee80bb4d670165c8327d.917539e857.wbe@email0 3.godaddy.com>  <4c4ef65a-a907-cf5e-4b2c-835fb55d0146@omnitor.se>  <434a4f06-f034-46ca-9df7-f59059e67e41@alumni.stanford.edu> <843f0cc1-2686-162d-25dc-0075847579bc@omnitor.se>  <84760193-19e6-1f53-43cc-32b0493a1844@alumni.stanford.edu>  <4f1f3a72-d8a9-4f41-4133-0e6d54aadec8@omnitor.se>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: 
Date: Wed, 15 Feb 2017 13:32:56 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <4f1f3a72-d8a9-4f41-4133-0e6d54aadec8@omnitor.se>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Slim] IETF last call for draft-ietf-slim-negotiating-human-language (Issue 8, section 6, IANA registrations)
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Feb 2017 12:33:06 -0000

in issue 8, I propose:

(Look in the edited draft -06g that I attached some days ago for how the 
proposal appears in the text )


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


8. Include more fields for attribute registration from 4566bis

Section 6 has the form for attribute registration by IANA. There are a 
couple of fields missing that will be important for use of the 
specification in the WebRTC environment.  Include these fields if that 
is allowable according to current IANA procedures and if that does not 
delay the publication of this draft. These fields are needed for use of 
text media in WebRTC.

Change:

In two locations from:
     "Usage Level:  media"

to:

     "Usage Level:  media, dcsa(subprotocol)"

Insert in two locations in the registration forms:
"Mux Category: NORMAL"
---------------------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------------

I checked in current IANA registrations, and found that all SDP 
attribute registrations now include the "Mux Category".

So, I assume that we are obliged to do so also and hope that we can 
agree on that.
As far as I understand the logic, we should specify NORMAL.

I saw no trace yet of registrations of  "Usage Level: dcsa(subprotocol)"

I would like to get advice from someone with insight in the SDP 
attribute registration and the status of the dsca(subprotocol) value on 
how we should proceed in order to get the dsca(subprotocol)  included in 
a smooth way without causing exessive delay.


Regards
Gunnar


From nobody Wed Feb 15 04:45: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 7022512946F for ; Wed, 15 Feb 2017 04:45:20 -0800 (PST)
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=unavailable 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 GVOCxdk7BkOy for ; Wed, 15 Feb 2017 04:45:19 -0800 (PST)
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 30F69126D73 for ; Wed, 15 Feb 2017 04:45:15 -0800 (PST)
X-Halon-ID: 97b43a5c-f37c-11e6-af90-005056917f90
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [83.209.158.27]) by bin-vsp-out-02.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Wed, 15 Feb 2017 13:45:12 +0100 (CET)
To: ietf@ietf.org, "slim@ietf.org" 
References: <20170213161000.665a7a7059d7ee80bb4d670165c8327d.917539e857.wbe@email0 3.godaddy.com>  <4c4ef65a-a907-cf5e-4b2c-835fb55d0146@omnitor.se>  <434a4f06-f034-46ca-9df7-f59059e67e41@alumni.stanford.edu> <843f0cc1-2686-162d-25dc-0075847579bc@omnitor.se>  <84760193-19e6-1f53-43cc-32b0493a1844@alumni.stanford.edu>  <4f1f3a72-d8a9-4f41-4133-0e6d54aadec8@omnitor.se> 
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: <4cfebe3f-1bf9-c5dd-f736-a503a3f608c9@omnitor.se>
Date: Wed, 15 Feb 2017 13:45:12 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
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] IETF last call for draft-ietf-slim-negotiating-human-language (Issue 8, section 6, IANA registrations)
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Feb 2017 12:45:20 -0000

More info below.


Den 2017-02-15 kl. 13:32, skrev Gunnar Hellström:
> in issue 8, I propose:
>
> (Look in the edited draft -06g that I attached some days ago for how 
> the proposal appears in the text )
>
>
> ------------------------------------------------------------------------------------------------------------ 
>
>
> 8. Include more fields for attribute registration from 4566bis
>
> Section 6 has the form for attribute registration by IANA. There are a 
> couple of fields missing that will be important for use of the 
> specification in the WebRTC environment.  Include these fields if that 
> is allowable according to current IANA procedures and if that does not 
> delay the publication of this draft. These fields are needed for use 
> of text media in WebRTC.
>
> Change:
>
> In two locations from:
>     "Usage Level:  media"
>
> to:
>
>     "Usage Level:  media, dcsa(subprotocol)"
>
> Insert in two locations in the registration forms:
> "Mux Category: NORMAL"
> --------------------------------------------------------------------------------------------------------------- 
>
> --------------------------------------------------------------------------------------------------------------- 
>
>
> I checked in current IANA registrations, and found that all SDP 
> attribute registrations now include the "Mux Category".
>
> So, I assume that we are obliged to do so also and hope that we can 
> agree on that.
> As far as I understand the logic, we should specify NORMAL.
>
> I saw no trace yet of registrations of  "Usage Level: dcsa(subprotocol)"
>
> I would like to get advice from someone with insight in the SDP 
> attribute registration and the status of the dsca(subprotocol) value 
> on how we should proceed in order to get the dsca(subprotocol)  
> included in a smooth way without causing exessive delay.
I found in 
https://tools.ietf.org/html/draft-ietf-mmusic-data-channel-sdpneg-11#section-8.3 
that the registration of dcsa(subprotocol)  seems to require a specific 
actual subprotocol. That is further away in time, and if that conclusion 
is right, we need to include MUX Category but exclude "Usage Level: 
dcsa(subprotocol)"  from the registration.
>
>
> Regards
> 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


From nobody Wed Feb 15 05:45: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 9FFE7129612 for ; Wed, 15 Feb 2017 05:45:02 -0800 (PST)
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=unavailable 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 xO8AmYDD1hDl for ; Wed, 15 Feb 2017 05:45:01 -0800 (PST)
Received: from bin-vsp-out-02.atm.binero.net (bin-mail-out-05.binero.net [195.74.38.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DFC61295E8 for ; Wed, 15 Feb 2017 05:44:59 -0800 (PST)
X-Halon-ID: ee58662c-f384-11e6-af90-005056917f90
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [83.209.158.27]) by bin-vsp-out-02.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Wed, 15 Feb 2017 14:44:52 +0100 (CET)
To: Paul Kyzivat , slim@ietf.org, "ietf@ietf.org" 
References: <20170213105355.665a7a7059d7ee80bb4d670165c8327d.1c694c05b8.wbe@email03.godaddy.com> 
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: <324a9954-8b52-598d-e1c8-3c1bc17dea38@omnitor.se>
Date: Wed, 15 Feb 2017 14:44:52 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
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] Last Call:  (Issue 5, section 5.3 )
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Feb 2017 13:45:02 -0000

Den 2017-02-14 kl. 00:44, skrev Paul Kyzivat:

> On 2/13/17 12:53 PM, Doug Ewell wrote:
>
>> Gunnar, who participated extensively in the SLIM WG, appears to be
>> attempting to re-introduce a mechanism to indicate preference of
>> modality which was considered and rejected multiple times by the WG.
>>
>> WG rejection of Gunnar's previous proposals to do this was based on
>> reluctance to try to solve this particular problem in the first version
>> of the spec, not on any of the specific mechanisms proposed to solve the
>> problem. Proposing a new or modified mechanism during IETF LC appears to
>> be an attempt to rehash an argument made, but not won, in the WG.
>>
>> If this concerns a different issue, not merely a different way of
>> approaching it, please accept my apology and explain more clearly how it
>> is different.
You are partly right, but the new proposal concerns more issues and is 
suggested to be a simplified solution to them.

The proposal adds media level influence to the asterisk humintlang 
attribute value parameter. In draft -06 the asterisk is said to be a 
media level parameter. But it does not change any influence on media 
level depending on which media or humintlang attribute you append it to. 
It just has session influence. That clearly indicates that with the 
current definition, the asterisk parameter  is misplaced.

It can also be seen that it has quite vague and unprecise influence on 
the session level.

This is the essential part of section 5.3 where this parameter is defined:

"The mechanism for indicating this preference is that, in an offer, if
    the last character of any of the 'humintlang-recv' or 'humintlang-
    send' values is an asterisk, this indicates a request to not fail the
    call (similar to SIP Accept-Language syntax).  Either way, the called
    party MAY ignore this, e.g., for the emergency services use case, a
    PSAP will likely not fail the call."

So, the lack of the parameter everywhere in the SDP MAY be seen as a 
request to reject the call, but that request may be ignored.

The real effect of this parameter is therefore in fact a preference. In 
order to motivate its existence on the media level, I proposed the 
extension of its meaning with an influence depending on on which 
humintlang attribute(s) it is attached.
Since the lack of the parameter apparently indicates a stronger 
preference for getting the call through, I suggest that the placement of 
an asterisk on a specific humintlang attribute indicates lower 
preference for matching that language/modality/direction versus some 
other language/modality combination specified for the same direction.
The one who want the call rejected if the highest preferred 
language/modality could not be matched is likely less interested in 
providing lower preferenced alternatives, so the session influence can 
be maintained.

By that we both sort out inconsistencies with the use of the asterisk 
and add value to it that will enable much more satisfied users and more 
calls going through.
And the solution is simpler than all earlier proposals and much more 
simple than not acting on the addressed issues now.

My proposed wording is available in issue 5 in my initial mail from Feb 13.


  Regards
Gunnar

>
> Gunnar's comment makes multiple points. You have highlighted one of 
> them and ignored the others.
>
> Even if you reject that one, consider the others. Notably:
>
> - 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.
>
> I accept the WG's decision not to address the "preference" issue. But 
> this attachment to the "ugly child", if not addressed, invites getting 
> IESG LC comments.
>
>     Thanks,
>     Paul
>
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim

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


From nobody Wed Feb 15 08:18: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 C8919129560; Wed, 15 Feb 2017 08:18:18 -0800 (PST)
X-Quarantine-ID: 
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -1.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 gPTxySb73zXm; Wed, 15 Feb 2017 08:18:16 -0800 (PST)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id A453A126579; Wed, 15 Feb 2017 08:18:16 -0800 (PST)
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Wed, 15 Feb 2017 08:10:11 -0800
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <4f1f3a72-d8a9-4f41-4133-0e6d54aadec8@omnitor.se>
References: <20170213161000.665a7a7059d7ee80bb4d670165c8327d.917539e857.wbe@email0 3.godaddy.com>  <4c4ef65a-a907-cf5e-4b2c-835fb55d0146@omnitor.se>  <434a4f06-f034-46ca-9df7-f59059e67e41@alumni.stanford.edu> <843f0cc1-2686-162d-25dc-0075847579bc@omnitor.se>  <84760193-19e6-1f53-43cc-32b0493a1844@alumni.stanford.edu>  <4f1f3a72-d8a9-4f41-4133-0e6d54aadec8@omnitor.se>
X-Mailer: Eudora for Mac OS X
Date: Wed, 15 Feb 2017 08:18:12 -0800
To: Gunnar =?iso-8859-1?Q?Hellstr=F6m?=  , ietf@ietf.org, "slim@ietf.org" 
From: Randall Gellens 
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
Archived-At: 
Subject: Re: [Slim] IETF last call for draft-ietf-slim-negotiating-human-language (Section 5.4)
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Feb 2017 16:18:19 -0000

At 10:41 AM +0100 2/15/17, Gunnar Hellstr=F6m wrote:

>  Den 2017-02-15 kl. 01:39, skrev Randall Gellens:
>>  At 4:21 PM -0800 2/14/17, Randy Presuhn wrote:
>>
>>>   Hi -
>>>
>>>   On 2/14/2017 2:43 PM, Randall Gellens wrote:
>>>>   At 8:59 PM +0100 2/14/17, Gunnar Hellstr=F6m wrote:
>>>>
>>>>>    Den 2017-02-14 kl. 19:05, skrev Randy Presuhn:
>>>>>
>>>>>>    Hi -
>>>>>>
>>>>>>    On 2/14/2017 9:40 AM, Randall Gellens wrote:
>>>>>>>    At 11:01 AM +0100 2/14/17, Gunnar Hellstr=F6m wrote:
>>>>>>>
>>>>>>>>     My proposal for a reworded section 5.4 is:
>>>>>>>>
>>>>>>>>     5.4.  Unusual language indications
>>>>>>>>
>>>>>>>>     It is possible to specify an unusual indication where the langu=
age
>>>>>>>>     specified may look unexpected for the media type.
>>>>>>>>
>>>>>>>>     For such cases the following guidance SHALL be applied for the
>>>>>>>>    humintlang attributes used in these situations.
>>>>>>>>
>>>>>>>>     1.    A view of a speaking person in=20
>>>>>>>> the video stream SHALL, when it
>>>>>>>>    has relevance for speech perception, be indicated by a Language-=
Tag
>>>>>>>>    for spoken/written language with the=20
>>>>>>>> "Zxxx" script subtag to indicate
>>>>>>>>    that the contents is not written.
>>>>>>>>
>>>>>>>>     2.    Text captions included in the video stream SHALL be indic=
ated
>>>>>>>>    by a Language-Tag for spoken/written language.
>>>>>>>>
>>>>>>>>     3.    Any approximate representation of sign language or
>>>>>>>>    fingerspelling in the text media stream SHALL be indicated by a
>>>>>>>>    Language-Tag for a sign language in text media.
>>>>>>>>
>>>>>>>>     4.    When sign language related audio from a person using sign
>>>>>>>>    language is of importance for language communication, this SHALL=
 be
>>>>>>>>    indicated by a Language-Tag for a sign language in audio media.
>>>>>>>
>>>>>>>    [RG] As I said, I think we should avoid specifying this until we =
have
>>>>>>>    deployment experience.
>>>>>>    ...
>>>>>>
>>>>>>    From a process perspective, it's far easier to remove constraints
>>>>>>    as a specification advances than it is to add them.
>>>>>    I agree. It is often better to specify normatively as far as you ca=
n
>>>>>   imagine, so that interoperability and good functionality is achieved=
=2E
>>>>>   Stopping halfway and have MAY in the specifications creates
>>>>>   uncertainty and less useful specifications.
>>>>
>>>>   My reading of what Randy says is the opposite of Gunnar's. In my
>>>>   reading, Randy points out that is it easier to remove the SHOULD NOT =
in
>>>>   the future then it is to change the meaning of the combinations or
>>>>   switch to a different mechanism.
>>>>
>>>>   In my experience, it's better to specify only what we know we need an=
d
>>>>   what we know we understand.  Speculative specifications "as far as yo=
u
>>>>   can imagine" more often lead to interoperability problems, unnecessar=
y
>>>>   complexity, limitations on what's needed in the future, and divergent
>>>>   implementations.
>>>
>>>   I think the difference in your positions comes down to
>>>
>>>     (1) your respective notions of "what we know we need and what we
>>>         know we understand";
>>>
>>>     (2) whether you believe that the interoperability and conformance
>>>         consequences of removing a "SHOULD NOT" could be the same
>>>         as those merely retaining a "MUST" or "SHALL" - this determines
>>>         whether Randy G.'s proposal provides a path for some future
>>>         revision to mandate (if deployment experience substantiates the
>>>         need/understanding) the behavior proposed by Gunnar. That path
>>>         is not at all obvious to me.
>>
>>  The purpose of the draft is to enable the two=20
>> endpoints of a real-time communication session=20
>> to agree which languages and media to use for=20
>> interactive communication.  We have a=20
>> mechanism of adding language tags to media=20
>> stream negotiations.  In most cases, the=20
>> language and media modality are an obvious=20
>> fit.  There are combinations of media and=20
>> language where the meaning is not so obvious,=20
>> specifically, signed language tags with a=20
>> audio or text, and non-signed language tags=20
>> with video.  My proposal is that we say=20
>> offerer SHOULD NOT send such combinations and=20
>> answerer MAY ignore language. This allows=20
>> future specifications for the underlying uses=20
>> Gunnar wants (such as real-time subtitles in=20
>> video and signed equivalents in text).  Such=20
>> future specifications could define a use for=20
>> the language and media combinations and remove=20
>> the SHOULD NOT send and MAY ignore, or could=20
>> define a new mechanism.  I don't think we know=20
>> enough now to dictate what the solution should=20
>> be.
>  We have a fresh example from our own=20
> discussions in the SLIM group how unfortunate=20
> it is to not be sufficiently explicit in the=20
> first edition of a standard. The SDP Lang=20
> attribute in RFC 4566, where you (Randall) say=20
> it is intended for specifying a set of=20
> languages that all must be used in a session,=20
> while I say that it is intended for negotiation=20
> of at least one initial language. By having=20
> that uncertainty in a specification that has=20
> been published makes it very hard to sharpen up=20
> the specification afterwards because it would=20
> possibly make some implementations non=20
> conformant. And it makes potential implementors=20
> hesitant to use the current specifications, as=20
> it was with the SLIM work.

I don't believe the two cases are comparable.=20
The original SDP language attribute was unclear=20
how it was used.  The new attributes specified in=20
the current draft are clearly defined for the set=20
of cases that has been the target solution space=20
all along: allowing the two sides to agree on=20
which language will be used in interactive=20
communications.  You want to extend them for a=20
related solution space, which is additional=20
services to foster communication, such as adding=20
real-time captioning to video.  I think it's=20
better to do that add-on work in a subsequent=20
draft.

>
>  For 5.4.
>
>  I am OK with modifying from my latest proposal, but we need to be specifi=
c.
>  I am also OK with reducing the SHALLs to SHOULDs as Addison requested.
>
>  The situation is not that we lack knowledge.=20
> Here is what we know about the 4 cases of=20
> "unusual" indications:
>
>  1. View of the speaker in video. Very important=20
> for speech perception. Quality requirements are=20
> documented in ITU-T H-series Supplement 1. Of=20
> real use only as a complement to the same=20
> spoken language in audio. Now, when we know=20
> about the Zxxx notation for non-written, we=20
> also have a good way of specifying it precisely.
>  This case was also described in section 5.2 already.

It's already possible to negotiate a video stream.

>
>  2. Text captions in the video stream.
>  This can be either text merged into video and=20
> communicated as true part of the video image,=20
> or it can be a text component of a multimedia=20
> system, as MPEG-4, declared in SDP as m=3Dvideo.
>  It has been used in some videophone products,=20
> but I have not seen it used lately.
>  It is a clearly defined case, and we can=20
> specify coding for it, but we do not at the=20
> moment know if it will be important to specify=20
> it.

I believe this is an additional service that=20
should be specified in a subsequent draft.

>
>  3. Sign language or fingerspelling in the text stream.
>  I have seen a product using it for claimed sign=20
> language conversation. It is also in use in the=20
> simple text form with words in capitals=20
> approximately representing signs between=20
> persons involved in preparation of sign=20
> language productions and translations. But in=20
> that case it is in a session where they agree=20
> in other ways to start using the text stream=20
> for that purpose. So I think we can say that=20
> this is rare, and its use can be agreed by=20
> other means between the users. Still it is a=20
> clearly defined case.

I believe this is an additional service that=20
should be specified in a subsequent draft.

>
>  4. Audio from signing person related to sign=20
> language. This is more vague than the others.=20
> It may be a person signing in video and adding=20
> spoken words in audio to signing, but=20
> influenced by the word order and grammar of=20
> sign language with some ambition to make it=20
> reasonably understandable for both deaf and=20
> hearing participants. There are even some=20
> spoken words created from sign language that=20
> are commonly used by hearing persons in such=20
> situations. But for that case I anyway think it=20
> is better to define the audio part as the=20
> spoken language it is derived from, because of=20
> its intention to be understandable for hearing=20
> persons. All other variants I can imagine are=20
> even closer to the spoken language and should=20
> be specified with spoken language tag. If we=20
> only want to have the audio stream established=20
> to hear the background in the signing=20
> situation, then we should not specify language=20
> use of the audio stream.
>  Even if we know what sign language tag in audio=20
> stream would be, it may be just as good to=20
> leave it undefined.

I believe this is an additional service that=20
should be specified in a subsequent draft.

>=20
> --------------------------------------------------------------------------=
----------------------------------------------------------------------
>  So, new proposal:
>
>  5.4.  Unusual language indications
>
>     It is possible to specify an unusual indication where the language
>     specified may look unexpected for the media type.
>
>     For such cases the following guidance SHOULD be applied for the
>    humintlang attributes used in these situations.
>
>     1.    A view of a speaking person in the video stream SHOULD, when it
>    has relevance for speech perception, be=20
> indicated by a humintlang attribute with a=20
> Language-Tag
>    for a spoken/written language with the "Zxxx" script subtag to indicate
>    that the contents is not written.
>
>     2.    Text captions included in the video stream SHOULD be indicated
>    by a humintlang attribute with Language-Tag for spoken/written language=
=2E
>
>     3.    A Language-Tag for a sign language=20
> specified in a humintlang attribute for a text=20
> stream MAY be interpreted as use of an=20
> approximate representation of sign language or=20
> fingerspelling in the text media stream. The=20
> use of such representation is rare and usually=20
> conveniently agreed by other means between the=20
> users during an established session. Common=20
> support of this indication SHOULD NOT be=20
> assumed or required.
>
>     4.    A Language-Tag for a sign language=20
> specified in a humintlang attribute for an=20
> audio stream SHOULD NOT be indicated and MAY be=20
> ignored on reception. Any use of spoken words=20
> or spoken language in the audio stream SHOULD,=20
> when it can be of importance for language=20
> communication, be indicated by the=20
> corresponding Language-Tag for spoken language=20
> in a humintlang attribute for the audio stream.
>
>
>
>
>  Gunnar
>
>
>  --
>  -----------------------------------------
>  Gunnar Hellstr=F6m
>  Omnitor
>  gunnar.hellstrom@omnitor.se
>  +46 708 204 288


-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Think airlines.  Here a durable competitive advantage has proven
elusive ever since the days of the Wright Brothers.  Indeed, if a
farsighted capitalist had been present at Kitty Hawk, he would have
done his successors a huge favor by shooting Orville down.
        --"Oracle of Omaha," Warren Buffett


From nobody Wed Feb 15 08:27: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 6A02C1298C1; Wed, 15 Feb 2017 08:27:01 -0800 (PST)
X-Quarantine-ID: 
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -1.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 YCQ6-vts2vdl; Wed, 15 Feb 2017 08:26:59 -0800 (PST)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 27EAB129AD4; Wed, 15 Feb 2017 08:26:59 -0800 (PST)
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Wed, 15 Feb 2017 08:18:53 -0800
Mime-Version: 1.0
Message-Id: 
In-Reply-To: 
References: <20170213161000.665a7a7059d7ee80bb4d670165c8327d.917539e857.wbe@email0 3.godaddy.com>  <4c4ef65a-a907-cf5e-4b2c-835fb55d0146@omnitor.se>  <434a4f06-f034-46ca-9df7-f59059e67e41@alumni.stanford.edu> <843f0cc1-2686-162d-25dc-0075847579bc@omnitor.se>  <84760193-19e6-1f53-43cc-32b0493a1844@alumni.stanford.edu>  <4f1f3a72-d8a9-4f41-4133-0e6d54aadec8@omnitor.se> 
X-Mailer: Eudora for Mac OS X
Date: Wed, 15 Feb 2017 08:26:56 -0800
To: Gunnar =?iso-8859-1?Q?Hellstr=F6m?=  , ietf@ietf.org, "slim@ietf.org" 
From: Randall Gellens 
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
Archived-At: 
Subject: Re: [Slim] IETF last call for draft-ietf-slim-negotiating-human-language (Issue 8, section 6, IANA  registrations)
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Feb 2017 16:27:01 -0000

At 1:32 PM +0100 2/15/17, Gunnar Hellstr=F6m wrote:

>  in issue 8, I propose:
>
>  (Look in the edited draft -06g that I attached=20
> some days ago for how the proposal appears in=20
> the text )
>
>
>=20
> --------------------------------------------------------------------------=
----------------------------------
>
>  8. Include more fields for attribute registration from 4566bis
>
>  Section 6 has the form for attribute=20
> registration by IANA. There are a couple of=20
> fields missing that will be important for use=20
> of the specification in the WebRTC environment.=20
> Include these fields if that is allowable=20
> according to current IANA procedures and if=20
> that does not delay the publication of this=20
> draft. These fields are needed for use of text=20
> media in WebRTC.
>
>  Change:
>
>  In two locations from:
>      "Usage Level:  media"
>
>  to:
>
>      "Usage Level:  media, dcsa(subprotocol)"
>
>  Insert in two locations in the registration forms:
>  "Mux Category: NORMAL"
>=20
> --------------------------------------------------------------------------=
-------------------------------------
>=20
> --------------------------------------------------------------------------=
-------------------------------------
>
>  I checked in current IANA registrations, and=20
> found that all SDP attribute registrations now=20
> include the "Mux Category".
>
>  So, I assume that we are obliged to do so also=20
> and hope that we can agree on that.
>  As far as I understand the logic, we should specify NORMAL.

This is not required.  See the IANA registry at=20
http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xhtml.=20
It is governed by RFC 4566.

As I've written twice before, my concern is that=20
this suggestion exceeds a simple editorial=20
change, and therefore may need to be discussed on=20
the WG list with WG consensus before it can be=20
adopted.  These fields can be added to the=20
attribute registration later, according to the=20
rules for the registry=20
(http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xhtml).


>  I saw no trace yet of registrations of  "Usage Level: dcsa(subprotocol)"
>
>  I would like to get advice from someone with=20
> insight in the SDP attribute registration and=20
> the status of the dsca(subprotocol) value on=20
> how we should proceed in order to get the=20
> dsca(subprotocol)  included in a smooth way=20
> without causing exessive delay.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Asking if computers can think is like asking if submarines can swim.


From nobody Wed Feb 15 09:12:55 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 40D721296AA; Wed, 15 Feb 2017 09:12:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.92
X-Spam-Level: 
X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-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 ChWjgJv3xvDS; Wed, 15 Feb 2017 09:12:48 -0800 (PST)
Received: from smtp-fw-4101.amazon.com (smtp-fw-4101.amazon.com [72.21.198.25]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8F12129459; Wed, 15 Feb 2017 09:12:47 -0800 (PST)
X-IronPort-AV: E=Sophos;i="5.35,166,1484006400"; d="scan'208";a="663823921"
Received: from iad6-co-svc-p1-lb1-vlan3.amazon.com (HELO email-inbound-relay-25015.iad12.amazon.com) ([10.124.125.6]) by smtp-border-fw-out-4101.iad4.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA;  15 Feb 2017 17:12:46 +0000
Received: from EX13MTAUWB001.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan2.iad.amazon.com [10.40.159.162]) by email-inbound-relay-25015.iad12.amazon.com (8.14.7/8.14.7) with ESMTP id v1FHC9JI000777 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 15 Feb 2017 17:12:45 GMT
Received: from EX13D08UWB003.ant.amazon.com (10.43.161.186) by EX13MTAUWB001.ant.amazon.com (10.43.161.207) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 15 Feb 2017 17:12:44 +0000
Received: from EX13D08UWB002.ant.amazon.com (10.43.161.168) by EX13D08UWB003.ant.amazon.com (10.43.161.186) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 15 Feb 2017 17:12:44 +0000
Received: from EX13D08UWB002.ant.amazon.com ([10.43.161.168]) by EX13D08UWB002.ant.amazon.com ([10.43.161.168]) with mapi id 15.00.1104.000; Wed, 15 Feb 2017 17:12:44 +0000
From: "Phillips, Addison" 
To: =?iso-8859-1?Q?Gunnar_Hellstr=F6m?= , "Randy Presuhn" , "ietf@ietf.org" , "slim@ietf.org" 
Thread-Topic: [Slim] IETF last call for draft-ietf-slim-negotiating-human-language (Section 5.4)
Thread-Index: AQHShk5MdWFzLzaSL0G26SF4TAiur6FoFQsAgAAxCoCAAIAWgIAAJxpAgAAIijCAAORJAIAAbwXw
Date: Wed, 15 Feb 2017 17:12:44 +0000
Message-ID: 
References: <20170213161000.665a7a7059d7ee80bb4d670165c8327d.917539e857.wbe@email0 3.godaddy.com>  <4c4ef65a-a907-cf5e-4b2c-835fb55d0146@omnitor.se>  <434a4f06-f034-46ca-9df7-f59059e67e41@alumni.stanford.edu> <843f0cc1-2686-162d-25dc-0075847579bc@omnitor.se> <44474907d69a42a0adb66cdc4933603a@EX13D08UWB002.ant.amazon.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.43.162.155]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Precedence: Bulk
Archived-At: 
Subject: Re: [Slim] IETF last call for draft-ietf-slim-negotiating-human-language (Section 5.4)
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Feb 2017 17:12:49 -0000

Gunnar replied:
>=20
> Den 2017-02-14 kl. 21:39, skrev Phillips, Addison:
> > I have some allergy to the SHALL language: there is no way to automatic=
ally
> determine conformance. Many language tags represent nonsensical values, d=
ue
> to the nature of language tag composition. Content providers need to use =
care
> in selecting the tags that they use and this section is merely pointing o=
ut good
> guidance for tag selection, albeit in a heavy-handed way. BCP47 RFC 5646
> Section 4.1 [1] already provides most of this guidance and a reference to=
 that
> source might be useful here, if only because that document requires it:
> >
> > 
> >     Standards, protocols, and applications that reference this document
> >     normatively but apply different rules to the ones given in this
> >     section MUST specify how language tag selection varies from the
> >     guidelines given here.
> > 
> >
> > I would suggest reducing the SHALL items to SHOULD.
> Accepted.
> That also opens up for another use we have discussed before but been advi=
sed
> to not use. That is to indicate use of written language by attaching a sc=
ript
> subtag even if the script subtag we use is suppressed by BCP 47. We can d=
ro that
> need however, with the use of the Zxxx script subtag for non-written, and=
 clearly
> include that usage in our specification as required from BCP 47.

I don't necessarily think that mandating a script subtag as a signal of wri=
tten content (vs. spoken content) is that useful. In most protocols, the wr=
itten nature of the content is indicated by the presence of text. Trying to=
 coerce the language modality via language tags seems complicated, especial=
ly since most language tags are harvested from the original source. Introdu=
cing processes to evaluate and insert or remove script subtags seems unnece=
ssary to me. That said, I have no objection to content using script subtags=
 if they are useful.=20

> >
> > I'm not sure what #2 really means. Shouldn't text captions be indicated=
 by the
> written language rather than the spoken language? And I'm not sure what
> "spoken/written language" means.
> #2 was: "
>=20
> 2.    Text captions included in the video stream SHALL be indicated
> by a Language-Tag for spoken/written language."
>=20
> Yes, the intention is to use written language in the video stream. There =
are
> technologies for that.

I'm aware of that. My concern is that in this case "spoken/written" is appl=
ied to "text captions", which are not spoken be definition? This section is=
 talking about the differences between identifying spoken and written langu=
age. The text captions fall into the written side of the equation, no?

I'd probably prefer to see something like "2. Text captions included in the=
 video stream SHOULD include a Language-Tag to identify the language."

> Since the language subtags in the IANA registry are combined for spoken
> languages and written languages, I call them Language-Tags for spoken/wri=
tten
> language.

The language subtags are for languages--all modalities. My comment here is =
that "spoken/written" adds no information.

> It would be misleading to say that we use a Language-Tag for a written
> language, because the same tag could in another context mean a spoken
> language.

One uses a Language-Tag for indicating the language. When the text is writt=
en, sometimes the user will pick a different language tag (zh-Hant-HK) than=
 they might choose for spoken text (yue-HK, zh-cmn-HK, etc.). Sometimes (ac=
tually, nearly all the time except for special cases) the language tag for =
the spoken and written language is the same tag (en-US, de-CH, ja-JP, etc.)=
. Again, the modality of the language is a separate consideration from the =
language. Nearly always, it is better to use the same tag for both spoken a=
nd written content rather than trying to use the tag to distinguish between=
 them: different Content-Types require different decoders anyway, but it is=
 really useful to say "give me all of the 'en-US' content you have" or "do =
you have content for a user who speaks 'es'"

> Since we have the script subtag Zxxx for non-written, we do not need to
> construct an explicit tag for the written language tag, it should be suff=
icient with
> our specification of the use in our case.

In case it isn't clear aboe, I oppose introducing the 'Zxxx' subtag save fo=
r cases where the non-written nature of the content is super-important to t=
he identification of the language.
>=20
> In my latest recent proposal, I still have a very similar wording. Since =
you had
> problems understanding it, there might still be a need to tune it. Can yo=
u
> propose wording?
> This is the current proposal:
>=20
> "   2.    Text captions included in the video stream SHOULD be indicated
>    by a humintlang attribute with Language-Tag for spoken/written languag=
e.
> "

I did that above. I think it is useful not to over-think it. When I see "Co=
ntent-Type: video/mpeg; Content-Language: en-GB", I rather expect audio con=
tent in English and not written content (although the video stream might al=
so includes pictures of English text such as the titles in a movie). When, =
as in this case, setting up a negotiated language experience, interoperabil=
ity is most aided by matching the customer's language preferences to availa=
ble resources. This is easiest when customers do not get carried away with =
complex language tags (ranges in BCP 47 parlance, e.g. tlh-Cyrl-AQ-fonupa) =
and systems do not have to introspect the language tags, inserting and remo=
ving script subtags to match the various language modes.

Addison


From nobody Wed Feb 15 09:13:55 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 8B020129B08 for ; Wed, 15 Feb 2017 09:13:54 -0800 (PST)
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 MpUth3Fp1xly for ; Wed, 15 Feb 2017 09:13:53 -0800 (PST)
Received: from resqmta-po-11v.sys.comcast.net (resqmta-po-11v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:170]) (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 5778D129AFC for ; Wed, 15 Feb 2017 09:13:53 -0800 (PST)
Received: from resomta-po-08v.sys.comcast.net ([96.114.154.232]) by resqmta-po-11v.sys.comcast.net with SMTP id e36YcfFJb5l5Ne39McNXjR; Wed, 15 Feb 2017 17:13:52 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1487178832; bh=rb3pfyPJj573kMqPTOIIfifqH6gBF1B0gttAqRdB9DE=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=aarA+RB4i2zPmuD/GB/F7rQck1ysUNQWnTkjGDin/s5z1Rsze7Y4xLBjST3MKXaIw TDO7yGjdxOSiAygTdsdxd17I9OklaqPsDALLgThJKNuhFT/JkUMxypj5izZ6RWpKxL AA8tVkaFG0i5TcTx1nM4GHQaNLV9pF7vsnpOanNniqvPTrbfX6txCCTIPSZPgVHwyx wYHXncGZzr956xy3lkAZ8axHfdfcdd+Mk6JxLFlyaK7ii5pFlot8XR1jQZcUJY9q9e YeSaWwEafiegjpU7NENs8SJWopaVAOrFQ4Ini/LdZ6hmc6/Lw6eDlQdn/GX+qCfuVo +cR/Iw7QHh48Q==
Received: from [192.168.1.110] ([73.186.127.100]) by resomta-po-08v.sys.comcast.net with SMTP id e39LcSoPsJE5ze39LciwPW; Wed, 15 Feb 2017 17:13:51 +0000
To: Randall Gellens , slim@ietf.org
References: <20170213105355.665a7a7059d7ee80bb4d670165c8327d.1c694c05b8.wbe@email0 3.godaddy.com>  
From: Paul Kyzivat 
Message-ID: <94034c7f-4ada-b2a8-43fc-18fa369f1e3f@comcast.net>
Date: Wed, 15 Feb 2017 12:13:50 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-CMAE-Envelope: MS4wfDYqwwT2fHdJ+MOZv/uNMl7quC7H+ZIgkFuOo6m6X5mvjQkKYFTjOYy4ClKAOGFpZmJWgYgZ7LUDmcN9hDlrSyOfxQ417ztkutBbcg1Djt200t1Xi5Zd mPqLM9+e0whJAVYkXVZtGqSqUqcajYjq6r6HcSOPw3Pmzrjmk+KGx1P1XydDBcK+17CwovvLQ0lQCvQy4+sLVaJfqtb7SeTSIYE=
Archived-At: 
Subject: Re: [Slim] Last Call:  (Negotiating Human Language in Real-Time Communications) to Proposed Standard
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Feb 2017 17:13:54 -0000

On 2/13/17 7:34 PM, Randall Gellens wrote:

> Hi Paul,
>
> I don't believe the WG has any particular love for the asterisk syntax,
> but felt it was good enough for what's needed, and didn't see any
> benefit from anything else.

So, there is no love for the syntax, and the semantics associated with 
that syntax is at best muddy. It is specifying session level semantics 
as part of a media level attribute. IMO that isn't "good enough", and I 
also don't think "good enough" is the best criterion for advancement.

	Thanks,
	Paul


From nobody Wed Feb 15 09:30:44 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 97EC4129604 for ; Wed, 15 Feb 2017 09:30:42 -0800 (PST)
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 TWYeeEOEK0UX for ; Wed, 15 Feb 2017 09:30:41 -0800 (PST)
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 A8C4F1296B3 for ; Wed, 15 Feb 2017 09:30:39 -0800 (PST)
X-AuditID: 1207440f-141ff70000003517-8f-58a4903e85c4
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 BB.24.13591.E3094A85; Wed, 15 Feb 2017 12:30:38 -0500 (EST)
Received: from [192.168.1.110] (c-73-186-127-100.hsd1.ma.comcast.net [73.186.127.100]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id v1FHUbc0029994 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Wed, 15 Feb 2017 12:30:38 -0500
To: slim@ietf.org
References: <20170213161000.665a7a7059d7ee80bb4d670165c8327d.917539e857.wbe@email0 3.godaddy.com>  <4c4ef65a-a907-cf5e-4b2c-835fb55d0146@omnitor.se>  <434a4f06-f034-46ca-9df7-f59059e67e41@alumni.stanford.edu> <843f0cc1-2686-162d-25dc-0075847579bc@omnitor.se>  <84760193-19e6-1f53-43cc-32b0493a1844@alumni.stanford.edu>  <4f1f3a72-d8a9-4f41-4133-0e6d54aadec8@omnitor.se>  
From: Paul Kyzivat 
Message-ID: 
Date: Wed, 15 Feb 2017 12:30:37 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBIsWRmVeSWpSXmKPExsUixO6iqGs3YUmEQecLK4uZHzrZHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVcXBOF2PBCv6KM+0HWBsYl/F0MXJySAiYSNybO4mli5GLQ0hg B5PEvje3mCGc10wSb8/8ZAepEhaok5j1Zy4TiC0iICjxvWcGE0RRO6vEw5f7wYrYBLQk5hz6 zwJi8wrYS5z69JgZxGYRUJX4sO8VI4gtKpAm8bTxOzNEjaDEyZlPwOo5gc5Y86cdrIZZwFbi ztzdzBC2vMT2t3OYJzDyzULSMgtJ2SwkZQsYmVcxyiXmlObq5iZm5hSnJusWJyfm5aUW6Zro 5WaW6KWmlG5ihAQa/w7GrvUyhxgFOBiVeHhfpC6JEGJNLCuuzD3EKMnBpCTKu94HKMSXlJ9S mZFYnBFfVJqTWnyIUYKDWUmE16YfKMebklhZlVqUD5OS5mBREudVX6LuJySQnliSmp2aWpBa BJOV4eBQkuB90QfUKFiUmp5akZaZU4KQZuLgBBnOAzQ8AKSGt7ggMbc4Mx0if4pRl+PUjdMv mYRY8vLzUqXEeW+BFAmAFGWU5sHNgSWIV4ziQG8J88qB3MkDTC5wk14BLWECWsIatxBkSUki QkqqgZF3VZWFs6jOjmX/rwQ4qlZudvDdVWRf1Ha+Vvnb14hLdR7vKzn2sl2pdORpOh/+P+vt lJ8Vm4tWNa5gPXdV73JPdvj9+ZU6R/u1I4NTeSs/fQl/+MvHNmMdV/InudI57FUr320IXH8s UjnUtLFRhnfv9dvRdv/lZm9eVeb0Ld41Uv5geO2HdiWW4oxEQy3mouJEAKyv+VLrAgAA
Archived-At: 
Subject: Re: [Slim] IETF last call for draft-ietf-slim-negotiating-human-language (Issue 8, section 6, IANA registrations)
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Feb 2017 17:30:42 -0000

On 2/15/17 11:26 AM, Randall Gellens wrote:

>>  I checked in current IANA registrations, and found that all SDP
>> attribute registrations now include the "Mux Category".
>>
>>  So, I assume that we are obliged to do so also and hope that we can
>> agree on that.
>>  As far as I understand the logic, we should specify NORMAL.
>
> This is not required.  See the IANA registry at
> http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xhtml. It
> is governed by RFC 4566.
>
> As I've written twice before, my concern is that this suggestion exceeds
> a simple editorial change, and therefore may need to be discussed on the
> WG list with WG consensus before it can be adopted.  These fields can be
> added to the attribute registration later, according to the rules for
> the registry
> (http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xhtml).

The mux-category is a big deal. There is a document in progress that 
defines the mux-category for all existing attributes. Attributes defined 
after that need to define their mux-category. There is potentially a 
problem with attributes defined while this work is in progress. That 
document for old attributes isn't going to chase after ones defined 
concurrently. I think you will find that if you don't define this then 
it will be caught and requested either by a sdp-directorate review, or 
else the iesg review. So just do it!

>>  I saw no trace yet of registrations of  "Usage Level: dcsa(subprotocol)"
>>
>>  I would like to get advice from someone with insight in the SDP
>> attribute registration and the status of the dsca(subprotocol) value
>> on how we should proceed in order to get the dsca(subprotocol)
>> included in a smooth way without causing exessive delay.

So far there has been *no* interest in defining RTP over SCTP. 
Until/unless that is defined there is no need to define dcsa for this 
attribute.

	Thanks,
	Paul



From nobody Wed Feb 15 12:32:00 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 181DB1297C1 for ; Wed, 15 Feb 2017 12:31:59 -0800 (PST)
X-Quarantine-ID: 
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GCI4hk5yglyd for ; Wed, 15 Feb 2017 12:31:54 -0800 (PST)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 60579129B5E for ; Wed, 15 Feb 2017 12:31:54 -0800 (PST)
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Wed, 15 Feb 2017 12:23:46 -0800
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <94034c7f-4ada-b2a8-43fc-18fa369f1e3f@comcast.net>
References: <20170213105355.665a7a7059d7ee80bb4d670165c8327d.1c694c05b8.wbe@email0 3.godaddy.com>   <94034c7f-4ada-b2a8-43fc-18fa369f1e3f@comcast.net>
X-Mailer: Eudora for Mac OS X
Date: Wed, 15 Feb 2017 12:31:50 -0800
To: Paul Kyzivat , slim@ietf.org
From: Randall Gellens 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
Archived-At: 
Subject: Re: [Slim] Last Call:  (Negotiating Human Language in Real-Time Communications) to Proposed Standard
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Feb 2017 20:31:59 -0000

At 12:13 PM -0500 2/15/17, Paul Kyzivat wrote:

>  On 2/13/17 7:34 PM, Randall Gellens wrote:
>
>>  Hi Paul,
>>
>>  I don't believe the WG has any particular love for the asterisk syntax,
>>  but felt it was good enough for what's needed, and didn't see any
>>  benefit from anything else.
>
>  So, there is no love for the syntax, and the semantics associated 
> with that syntax is at best muddy. It is specifying session level 
> semantics as part of a media level attribute. IMO that isn't "good 
> enough", and I also don't think "good enough" is the best criterion 
> for advancement.

It serves an extremely weak and limited purpose, with no normative 
effects to using it or not.  Honestly, in my view if it was deleted 
from the draft it wouldn't make any difference.  I'm fine leaving it 
in or taking it out, but I do not see any point in introducing new 
mechanisms for such a small purpose, especially at this point in the 
draft's progress.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Those are my principles. If you don't like them I have others.
    --Groucho Marx


From nobody Wed Feb 15 13:36:35 2017
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4281812984A for ; Wed, 15 Feb 2017 13:36:34 -0800 (PST)
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 fDxjf7Z8kuL1 for ; Wed, 15 Feb 2017 13:36:31 -0800 (PST)
Received: from bin-vsp-out-01.atm.binero.net (vsp-unauthed02.binero.net [195.74.38.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53EC0129455 for ; Wed, 15 Feb 2017 13:36:31 -0800 (PST)
X-Halon-ID: ce14895f-f3c6-11e6-a561-005056917a89
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [83.209.158.27]) by bin-vsp-out-01.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Wed, 15 Feb 2017 22:36:26 +0100 (CET)
To: "Phillips, Addison" , Randy Presuhn , "ietf@ietf.org" , "slim@ietf.org" 
References: <20170213161000.665a7a7059d7ee80bb4d670165c8327d.917539e857.wbe@email0 3.godaddy.com>  <4c4ef65a-a907-cf5e-4b2c-835fb55d0146@omnitor.se>  <434a4f06-f034-46ca-9df7-f59059e67e41@alumni.stanford.edu> <843f0cc1-2686-162d-25dc-0075847579bc@omnitor.se> <44474907d69a42a0adb66cdc4933603a@EX13D08UWB002.ant.amazon.com>  
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: 
Date: Wed, 15 Feb 2017 22:36:24 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
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] IETF last call for draft-ietf-slim-negotiating-human-language (Section 5.4)
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Feb 2017 21:36:34 -0000

Addison,

Den 2017-02-15 kl. 18:12, skrev Phillips, Addison:
> Gunnar replied:
>> Den 2017-02-14 kl. 21:39, skrev Phillips, Addison:
>>> I have some allergy to the SHALL language: there is no way to automatically
>> determine conformance. Many language tags represent nonsensical values, due
>> to the nature of language tag composition. Content providers need to use care
>> in selecting the tags that they use and this section is merely pointing out good
>> guidance for tag selection, albeit in a heavy-handed way. BCP47 RFC 5646
>> Section 4.1 [1] already provides most of this guidance and a reference to that
>> source might be useful here, if only because that document requires it:
>>> 
>>>      Standards, protocols, and applications that reference this document
>>>      normatively but apply different rules to the ones given in this
>>>      section MUST specify how language tag selection varies from the
>>>      guidelines given here.
>>> 
>>>
>>> I would suggest reducing the SHALL items to SHOULD.
>> Accepted.
>> That also opens up for another use we have discussed before but been advised
>> to not use. That is to indicate use of written language by attaching a script
>> subtag even if the script subtag we use is suppressed by BCP 47. We can dro that
>> need however, with the use of the Zxxx script subtag for non-written, and clearly
>> include that usage in our specification as required from BCP 47.
> I don't necessarily think that mandating a script subtag as a signal of written content (vs. spoken content) is that useful. In most protocols, the written nature of the content is indicated by the presence of text. Trying to coerce the language modality via language tags seems complicated, especially since most language tags are harvested from the original source. Introducing processes to evaluate and insert or remove script subtags seems unnecessary to me. That said, I have no objection to content using script subtags if they are useful.
In this case we are negotiating use of media streams before they are 
established, so that the connection will be made between best capable 
devices and call participants. There is no indication in the media 
coding parameters available to tell if text will be carried in video.  
So, if we want to be able to specify the three modalities possible in 
video we needto have differentiated notations for them: 1. view of a 
signing person, 2. view of a speaking person, 3. Text.      For 1. the 
signing person, it is simple, because the language subtags are explicit 
in that they indicate sign language. But for the two others I was not 
aware of any useful way before I was informed about the Zxxx script subtag.
Now, the reasoning about the need for these to be possible to 
distinguish caused me to specify that for the view of the signing person 
we use the Zxxx script subtag and for any text we do not need to specify 
any script subtag.
The view of the speaking person is the only very important alternative 
of the four identified "silly states", and that was already included in 
section 5.2. But both Bernard and I wanted to see the "silly states" 
chapter sharpened up and real alternatives sorted out and specified.
>
>>> I'm not sure what #2 really means. Shouldn't text captions be indicated by the
>> written language rather than the spoken language? And I'm not sure what
>> "spoken/written language" means.
>> #2 was: "
>>
>> 2.    Text captions included in the video stream SHALL be indicated
>> by a Language-Tag for spoken/written language."
>>
>> Yes, the intention is to use written language in the video stream. There are
>> technologies for that.
> I'm aware of that. My concern is that in this case "spoken/written" is applied to "text captions", which are not spoken be definition? This section is talking about the differences between identifying spoken and written language. The text captions fall into the written side of the equation, no?
>
> I'd probably prefer to see something like "2. Text captions included in the video stream SHOULD include a Language-Tag to identify the language."
Yes, that is a way to avoid mentioning spoken/written that apparently is 
confusing when the subtag in this case is used for written modality.
>
>> Since the language subtags in the IANA registry are combined for spoken
>> languages and written languages, I call them Language-Tags for spoken/written
>> language.
> The language subtags are for languages--all modalities. My comment here is that "spoken/written" adds no information.
Spoken/written is different from signed that is the "normal" modality 
for video.
>
>> It would be misleading to say that we use a Language-Tag for a written
>> language, because the same tag could in another context mean a spoken
>> language.
> One uses a Language-Tag for indicating the language. When the text is written, sometimes the user will pick a different language tag (zh-Hant-HK) than they might choose for spoken text (yue-HK, zh-cmn-HK, etc.). Sometimes (actually, nearly all the time except for special cases) the language tag for the spoken and written language is the same tag (en-US, de-CH, ja-JP, etc.). Again, the modality of the language is a separate consideration from the language. Nearly always, it is better to use the same tag for both spoken and written content rather than trying to use the tag to distinguish between them: different Content-Types require different decoders anyway, but it is really useful to say "give me all of the 'en-US' content you have" or "do you have content for a user who speaks 'es'"
>
>> Since we have the script subtag Zxxx for non-written, we do not need to
>> construct an explicit tag for the written language tag, it should be sufficient with
>> our specification of the use in our case.
> In case it isn't clear aboe, I oppose introducing the 'Zxxx' subtag save for cases where the non-written nature of the content is super-important to the identification of the language.
There is a possible alternative in RFC 4796, the SDP Content attribute, 
where "speaker" can be identified.  But that does not easily allow for 
describing alternative use of video for sign language or view of a 
speaking person.

So, the alternative to using Zxxx is as I see it to not be able to 
specify text in the video stream. Good interoperability of text in the 
text stream is so much more important so I am prepare to go that way if 
it is needed. Bernards view would be interesting here.
>> In my latest recent proposal, I still have a very similar wording. Since you had
>> problems understanding it, there might still be a need to tune it. Can you
>> propose wording?
>> This is the current proposal:
>>
>> "   2.    Text captions included in the video stream SHOULD be indicated
>>     by a humintlang attribute with Language-Tag for spoken/written language.
>> "
> I did that above. I think it is useful not to over-think it. When I see "Content-Type: video/mpeg; Content-Language: en-GB", I rather expect audio content in English and not written content (although the video stream might also includes pictures of English text such as the titles in a movie). When, as in this case, setting up a negotiated language experience, interoperability is most aided by matching the customer's language preferences to available resources. This is easiest when customers do not get carried away with complex language tags (ranges in BCP 47 parlance, e.g. tlh-Cyrl-AQ-fonupa) and systems do not have to introspect the language tags, inserting and removing script subtags to match the various language modes.
>
> Addison
/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


From nobody Wed Feb 15 15:01:11 2017
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 273541293DA; Wed, 15 Feb 2017 15:01:10 -0800 (PST)
X-Quarantine-ID: <7Lf0T39jQkal>
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 7Lf0T39jQkal; Wed, 15 Feb 2017 15:01:08 -0800 (PST)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 5BFA0129721; Wed, 15 Feb 2017 15:01:08 -0800 (PST)
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Wed, 15 Feb 2017 14:52:59 -0800
Mime-Version: 1.0
Message-Id: 
In-Reply-To: 
References: <20170213161000.665a7a7059d7ee80bb4d670165c8327d.917539e857.wbe@email0 3.godaddy.com>  <4c4ef65a-a907-cf5e-4b2c-835fb55d0146@omnitor.se>  <434a4f06-f034-46ca-9df7-f59059e67e41@alumni.stanford.edu> <843f0cc1-2686-162d-25dc-0075847579bc@omnitor.se> <44474907d69a42a0adb66cdc4933603a@EX13D08UWB002.ant.amazon.com>  
X-Mailer: Eudora for Mac OS X
Date: Wed, 15 Feb 2017 15:01:05 -0800
To: "Phillips, Addison" , Gunnar =?iso-8859-1?Q?Hellstr=F6m?=  , "Randy  Presuhn" , "ietf@ietf.org" , "slim@ietf.org" 
From: Randall Gellens 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
Archived-At: 
Subject: Re: [Slim] IETF last call for draft-ietf-slim-negotiating-human-language (Section 5.4)
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Feb 2017 23:01:10 -0000

Hi Addison,

Please see in-line.

At 5:12 PM +0000 2/15/17, Addison Phillips wrote:

>  Gunnar replied:
>>
>>  Den 2017-02-14 kl. 21:39, skrev Phillips, Addison:
>>  > I have some allergy to the SHALL language: there is no way to 
>> automatically
>>  determine conformance. Many language tags represent nonsensical values, due
>>  to the nature of language tag composition. Content providers need 
>> to use care
>>  in selecting the tags that they use and this section is merely 
>> pointing out good
>>  guidance for tag selection, albeit in a heavy-handed way. BCP47 RFC 5646
>>  Section 4.1 [1] already provides most of this guidance and a 
>> reference to that
>>  source might be useful here, if only because that document requires it:
>>  >
>>  > 
>>  >     Standards, protocols, and applications that reference this document
>>  >     normatively but apply different rules to the ones given in this
>>  >     section MUST specify how language tag selection varies from the
>>  >     guidelines given here.
>>  > 
>>  >
>>  > I would suggest reducing the SHALL items to SHOULD.
>>  Accepted.
>>  That also opens up for another use we have discussed before but been advised
>>  to not use. That is to indicate use of written language by 
>> attaching a script
>>  subtag even if the script subtag we use is suppressed by BCP 47. 
>> We can dro that
>>  need however, with the use of the Zxxx script subtag for 
>> non-written, and clearly
>>  include that usage in our specification as required from BCP 47.
>
>  I don't necessarily think that mandating a script subtag as a 
> signal of written content (vs. spoken content) is that useful. In 
> most protocols, the written nature of the content is indicated by 
> the presence of text. Trying to coerce the language modality via 
> language tags seems complicated, especially since most language 
> tags are harvested from the original source. Introducing processes 
> to evaluate and insert or remove script subtags seems unnecessary 
> to me. That said, I have no objection to content using script 
> subtags if they are useful.
>
>>  >
>>  > I'm not sure what #2 really means. Shouldn't text captions be 
>> indicated by the
>>  written language rather than the spoken language? And I'm not sure what
>>  "spoken/written language" means.
>>  #2 was: "
>>
>>  2.    Text captions included in the video stream SHALL be indicated
>>  by a Language-Tag for spoken/written language."
>>
>>  Yes, the intention is to use written language in the video stream. There are
>>  technologies for that.
>
>  I'm aware of that. My concern is that in this case "spoken/written" 
> is applied to "text captions", which are not spoken be definition? 
> This section is talking about the differences between identifying 
> spoken and written language. The text captions fall into the 
> written side of the equation, no?

Keep in mind that the focus of the draft is enabling language 
negotiation along with media negotiation for interactive 
communications.  In this context, as I noted in previous replies, 
real-time text captions for sign language in video is a service.  A 
mechanism for requesting services needs to be carefully thought out 
in the WG and not added to the current draft at the last minute.

>
>  I'd probably prefer to see something like "2. Text captions 
> included in the video stream SHOULD include a Language-Tag to 
> identify the language."
>
>>  Since the language subtags in the IANA registry are combined for spoken
>>  languages and written languages, I call them Language-Tags for 
>> spoken/written
>>  language.
>
>  The language subtags are for languages--all modalities. My comment 
> here is that "spoken/written" adds no information.
>
>>  It would be misleading to say that we use a Language-Tag for a written
>>  language, because the same tag could in another context mean a spoken
>   > language.
>
>  One uses a Language-Tag for indicating the language. When the text 
> is written, sometimes the user will pick a different language tag 
> (zh-Hant-HK) than they might choose for spoken text (yue-HK, 
> zh-cmn-HK, etc.). Sometimes (actually, nearly all the time except 
> for special cases) the language tag for the spoken and written 
> language is the same tag (en-US, de-CH, ja-JP, etc.). Again, the 
> modality of the language is a separate consideration from the 
> language. Nearly always, it is better to use the same tag for both 
> spoken and written content rather than trying to use the tag to 
> distinguish between them: different Content-Types require different 
> decoders anyway, but it is really useful to say "give me all of the 
> 'en-US' content you have" or "do you have content for a user who 
> speaks 'es'"

Requesting all content available in a specific language is outside 
the scope of the draft, which is enabling language negotiation along 
with media negotiation for interactive communications.  One key 
example is a user placing an emergency call.  The call setup can 
negotiate both language and media for interactive communication 
between the emergency services answering point and the user.

>
>>  Since we have the script subtag Zxxx for non-written, we do not need to
>>  construct an explicit tag for the written language tag, it should 
>> be sufficient with
>>  our specification of the use in our case.
>
>  In case it isn't clear aboe, I oppose introducing the 'Zxxx' subtag 
> save for cases where the non-written nature of the content is 
> super-important to the identification of the language.
>>
>>  In my latest recent proposal, I still have a very similar wording. 
>> Since you had
>>  problems understanding it, there might still be a need to tune it. Can you
>>  propose wording?
>>  This is the current proposal:
>>
>>  "   2.    Text captions included in the video stream SHOULD be indicated
>>     by a humintlang attribute with Language-Tag for spoken/written language.
>>  "
>
>  I did that above. I think it is useful not to over-think it. When I 
> see "Content-Type: video/mpeg; Content-Language: en-GB", I rather 
> expect audio content in English and not written content (although 
> the video stream might also includes pictures of English text such 
> as the titles in a movie). When, as in this case, setting up a 
> negotiated language experience, interoperability is most aided by 
> matching the customer's language preferences to available 
> resources. This is easiest when customers do not get carried away 
> with complex language tags (ranges in BCP 47 parlance, e.g. 
> tlh-Cyrl-AQ-fonupa) and systems do not have to introspect the 
> language tags, inserting and removing script subtags to match the 
> various language modes.
>
>  Addison
>
>  _______________________________________________
>  SLIM mailing list
>  SLIM@ietf.org
>  https://www.ietf.org/mailman/listinfo/slim


-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
The First Amendment is often inconvenient. But that is besides the
point.  Inconvenience does not absolve the government of its
obligation to tolerate speech. --Justice Anthony Kennedy, in 91-155


From nobody Wed Feb 15 15:53: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 0E99E129BF0; Wed, 15 Feb 2017 15:53:07 -0800 (PST)
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 xLOyFDa6h5aL; Wed, 15 Feb 2017 15:53:04 -0800 (PST)
Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2611312995C; Wed, 15 Feb 2017 15:53:04 -0800 (PST)
Received: by mail-ua0-x22e.google.com with SMTP id 96so1162200uaq.3; Wed, 15 Feb 2017 15:53:04 -0800 (PST)
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=aJir4W3O2MZUUnTTSLP66bMdSiGfXn9b7A2Da+LBahg=; b=GCcO4vZZk09fIx6xo0ky+N7euwklMgRlrQ3P2TChCfRmg9oiFooe6OPGH6w6Ddd8+o M3AORq56476ua/w8wwX/FL16a5CBrFOw0/ezAkxoPRjCRLf+qteCg7hVG5xkrCou38GC RruO1iTwVF3qc7i6ZW8SOamNnD8OVVPqYtHWBMFbMOPYZhF0OjMVcIQV895zNzQBBTqn BuSzBfWFPSxx5sQdNZdjb58DxeXakggds5Z41mPFWEzHD1+exgRYJ1HWczR9gTML4Dh5 D3z8NDy3DKHJV/MWhODfXY0/h21iCHFhWL5SORoTHYEnUUv80oiyXxlw4tQ9VphydDyH szbQ==
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=aJir4W3O2MZUUnTTSLP66bMdSiGfXn9b7A2Da+LBahg=; b=lTUpc65DgAaeLA3pBaCAcYRWDvguSiuWp3QFbOiBFs2Yv9A/XZd/ZZBVESYGBFhCk2 sQJiah2XrIau3sCO03TwL701vv3Ghdged7f0z223jlmKxQ3jLUjvMkkvsyu3M0H5x5yX RKHZqu/PVeT/wvNC4eIUKHzwmxTr5eq7W1w+ax6u8W2pihJdRsw/Ec9yl1MyTu2ocLaY OW8EBARJZi9XrxO1FFw7K9v65JlOSrLCTTFINoYOmZDMuhm3QFh1kWSAAttG3hl4EPlb Ro0/Iy/9cpg7ioQF3ZazNgHdQ5gJdN3k4iT1GEiG3q7IXGntSC/AaypiDk0lxe89E6ST H5aw==
X-Gm-Message-State: AMke39lgFxqrzbEaaAVJB7x/hBgpxa8hT8ux5TU0De+8UPOR5lMhiNuwlCaqQQInkHiaiBHIkLZX4/Ckqf8r3g==
X-Received: by 10.176.2.67 with SMTP id 61mr2250549uas.108.1487202783104; Wed, 15 Feb 2017 15:53:03 -0800 (PST)
MIME-Version: 1.0
Received: by 10.176.88.90 with HTTP; Wed, 15 Feb 2017 15:52:42 -0800 (PST)
In-Reply-To: <4f1f3a72-d8a9-4f41-4133-0e6d54aadec8@omnitor.se>
References:  <4c4ef65a-a907-cf5e-4b2c-835fb55d0146@omnitor.se>  <434a4f06-f034-46ca-9df7-f59059e67e41@alumni.stanford.edu> <843f0cc1-2686-162d-25dc-0075847579bc@omnitor.se>  <84760193-19e6-1f53-43cc-32b0493a1844@alumni.stanford.edu>  <4f1f3a72-d8a9-4f41-4133-0e6d54aadec8@omnitor.se>
From: Bernard Aboba 
Date: Wed, 15 Feb 2017 15:52:42 -0800
Message-ID: 
To: =?UTF-8?Q?Gunnar_Hellstr=C3=B6m?= 
Content-Type: multipart/alternative; boundary=001a113dcd7a989c4b05489a6191
Archived-At: 
Cc: "slim@ietf.org" , ietf@ietf.org
Subject: Re: [Slim] IETF last call for draft-ietf-slim-negotiating-human-language (Section 5.4)
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Feb 2017 23:53:07 -0000

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

Gunnar Hellstrom said:

"The SDP Lang attribute in RFC 4566, where you (Randall) say it is intended
for specifying a set of languages that all must be used in a session, while
I say that it is intended for negotiation of at least one initial language.=
"

[BA] At IETF 96 in Berlin, we had a discussion of the history of the SDP
Lang attribute within the MMUSIC WG.

The Lang attribute was originally specified in RFC 2327, which was
published in April 1998, more than four years prior to the publication of
Offer/Answer RFC 3264 (June 2002), and three years prior to publication of
the initial draft-rosenberg-mmusic-sdp-offer-answer-00 (April 26, 2001).

As a result, the Lang attribute could not have been designed for use in
Offer/Answer negotiation, but instead was intended for use in the
declarative SDP of multicast conferencing.  Note that the Lang attribute
was not mentioned in RFC 3264, and noone at the MMUSIC WG session was aware
of a subsequent SIP Offer/Answer implementation of it.









On Wed, Feb 15, 2017 at 1:41 AM, Gunnar Hellstr=C3=B6m <
gunnar.hellstrom@omnitor.se> wrote:

> Den 2017-02-15 kl. 01:39, skrev Randall Gellens:
>
>> At 4:21 PM -0800 2/14/17, Randy Presuhn wrote:
>>
>>  Hi -
>>>
>>>  On 2/14/2017 2:43 PM, Randall Gellens wrote:
>>>
>>>>  At 8:59 PM +0100 2/14/17, Gunnar Hellstr=C3=B6m wrote:
>>>>
>>>>   Den 2017-02-14 kl. 19:05, skrev Randy Presuhn:
>>>>>
>>>>>   Hi -
>>>>>>
>>>>>>   On 2/14/2017 9:40 AM, Randall Gellens wrote:
>>>>>>
>>>>>>>   At 11:01 AM +0100 2/14/17, Gunnar Hellstr=C3=B6m wrote:
>>>>>>>
>>>>>>>    My proposal for a reworded section 5.4 is:
>>>>>>>>
>>>>>>>>    5.4.  Unusual language indications
>>>>>>>>
>>>>>>>>    It is possible to specify an unusual indication where the
>>>>>>>> language
>>>>>>>>    specified may look unexpected for the media type.
>>>>>>>>
>>>>>>>>    For such cases the following guidance SHALL be applied for the
>>>>>>>>   humintlang attributes used in these situations.
>>>>>>>>
>>>>>>>>    1.    A view of a speaking person in the video stream SHALL,
>>>>>>>> when it
>>>>>>>>   has relevance for speech perception, be indicated by a
>>>>>>>> Language-Tag
>>>>>>>>   for spoken/written language with the "Zxxx" script subtag to
>>>>>>>> indicate
>>>>>>>>   that the contents is not written.
>>>>>>>>
>>>>>>>>    2.    Text captions included in the video stream SHALL be
>>>>>>>> indicated
>>>>>>>>   by a Language-Tag for spoken/written language.
>>>>>>>>
>>>>>>>>    3.    Any approximate representation of sign language or
>>>>>>>>   fingerspelling in the text media stream SHALL be indicated by a
>>>>>>>>   Language-Tag for a sign language in text media.
>>>>>>>>
>>>>>>>>    4.    When sign language related audio from a person using sign
>>>>>>>>   language is of importance for language communication, this SHALL
>>>>>>>> be
>>>>>>>>   indicated by a Language-Tag for a sign language in audio media.
>>>>>>>>
>>>>>>>
>>>>>>>   [RG] As I said, I think we should avoid specifying this until we
>>>>>>> have
>>>>>>>   deployment experience.
>>>>>>>
>>>>>>   ...
>>>>>>
>>>>>>   From a process perspective, it's far easier to remove constraints
>>>>>>   as a specification advances than it is to add them.
>>>>>>
>>>>>   I agree. It is often better to specify normatively as far as you ca=
n
>>>>>  imagine, so that interoperability and good functionality is achieved=
.
>>>>>  Stopping halfway and have MAY in the specifications creates
>>>>>  uncertainty and less useful specifications.
>>>>>
>>>>
>>>>  My reading of what Randy says is the opposite of Gunnar's. In my
>>>>  reading, Randy points out that is it easier to remove the SHOULD NOT =
in
>>>>  the future then it is to change the meaning of the combinations or
>>>>  switch to a different mechanism.
>>>>
>>>>  In my experience, it's better to specify only what we know we need an=
d
>>>>  what we know we understand.  Speculative specifications "as far as yo=
u
>>>>  can imagine" more often lead to interoperability problems, unnecessar=
y
>>>>  complexity, limitations on what's needed in the future, and divergent
>>>>  implementations.
>>>>
>>>
>>>  I think the difference in your positions comes down to
>>>
>>>    (1) your respective notions of "what we know we need and what we
>>>        know we understand";
>>>
>>>    (2) whether you believe that the interoperability and conformance
>>>        consequences of removing a "SHOULD NOT" could be the same
>>>        as those merely retaining a "MUST" or "SHALL" - this determines
>>>        whether Randy G.'s proposal provides a path for some future
>>>        revision to mandate (if deployment experience substantiates the
>>>        need/understanding) the behavior proposed by Gunnar. That path
>>>        is not at all obvious to me.
>>>
>>
>> The purpose of the draft is to enable the two endpoints of a real-time
>> communication session to agree which languages and media to use for
>> interactive communication.  We have a mechanism of adding language tags =
to
>> media stream negotiations.  In most cases, the language and media modali=
ty
>> are an obvious fit.  There are combinations of media and language where =
the
>> meaning is not so obvious, specifically, signed language tags with a aud=
io
>> or text, and non-signed language tags with video.  My proposal is that w=
e
>> say offerer SHOULD NOT send such combinations and answerer MAY ignore
>> language. This allows future specifications for the underlying uses Gunn=
ar
>> wants (such as real-time subtitles in video and signed equivalents in
>> text).  Such future specifications could define a use for the language a=
nd
>> media combinations and remove the SHOULD NOT send and MAY ignore, or cou=
ld
>> define a new mechanism.  I don't think we know enough now to dictate wha=
t
>> the solution should be.
>>
> We have a fresh example from our own discussions in the SLIM group how
> unfortunate it is to not be sufficiently explicit in the first edition of=
 a
> standard. The SDP Lang attribute in RFC 4566, where you (Randall) say it =
is
> intended for specifying a set of languages that all must be used in a
> session, while I say that it is intended for negotiation of at least one
> initial language. By having that uncertainty in a specification that has
> been published makes it very hard to sharpen up the specification
> afterwards because it would possibly make some implementations non
> conformant. And it makes potential implementors hesitant to use the curre=
nt
> specifications, as it was with the SLIM work.
>
> For 5.4.
>
> I am OK with modifying from my latest proposal, but we need to be specifi=
c.
> I am also OK with reducing the SHALLs to SHOULDs as Addison requested.
>
> The situation is not that we lack knowledge. Here is what we know about
> the 4 cases of "unusual" indications:
>
> 1. View of the speaker in video. Very important for speech perception.
> Quality requirements are documented in ITU-T H-series Supplement 1. Of re=
al
> use only as a complement to the same spoken language in audio. Now, when =
we
> know about the Zxxx notation for non-written, we also have a good way of
> specifying it precisely.
> This case was also described in section 5.2 already.
>
> 2. Text captions in the video stream.
> This can be either text merged into video and communicated as true part o=
f
> the video image, or it can be a text component of a multimedia system, as
> MPEG-4, declared in SDP as m=3Dvideo.
> It has been used in some videophone products, but I have not seen it used
> lately.
> It is a clearly defined case, and we can specify coding for it, but we do
> not at the moment know if it will be important to specify it.
>
> 3. Sign language or fingerspelling in the text stream.
> I have seen a product using it for claimed sign language conversation. It
> is also in use in the simple text form with words in capitals approximate=
ly
> representing signs between persons involved in preparation of sign langua=
ge
> productions and translations. But in that case it is in a session where
> they agree in other ways to start using the text stream for that purpose.
> So I think we can say that this is rare, and its use can be agreed by oth=
er
> means between the users. Still it is a clearly defined case.
>
> 4. Audio from signing person related to sign language. This is more vague
> than the others.  It may be a person signing in video and adding spoken
> words in audio to signing, but influenced by the word order and grammar o=
f
> sign language with some ambition to make it reasonably understandable for
> both deaf and hearing participants. There are even some spoken words
> created from sign language that are commonly used by hearing persons in
> such situations. But for that case I anyway think it is better to define
> the audio part as the spoken language it is derived from, because of its
> intention to be understandable for hearing persons. All other variants I
> can imagine are even closer to the spoken language and should be specifie=
d
> with spoken language tag. If we only want to have the audio stream
> established to hear the background in the signing situation, then we shou=
ld
> not specify language use of the audio stream.
> Even if we know what sign language tag in audio stream would be, it may b=
e
> just as good to leave it undefined.
> ------------------------------------------------------------
> ------------------------------------------------------------
> ------------------------
> So, new proposal:
>
> 5.4.  Unusual language indications
>
>    It is possible to specify an unusual indication where the language
>    specified may look unexpected for the media type.
>
>    For such cases the following guidance SHOULD be applied for the
>   humintlang attributes used in these situations.
>
>    1.    A view of a speaking person in the video stream SHOULD, when it
>   has relevance for speech perception, be indicated by a humintlang
> attribute with a Language-Tag
>   for a spoken/written language with the "Zxxx" script subtag to indicate
>   that the contents is not written.
>
>    2.    Text captions included in the video stream SHOULD be indicated
>   by a humintlang attribute with Language-Tag for spoken/written language=
.
>
>    3.    A Language-Tag for a sign language specified in a humintlang
> attribute for a text stream MAY be interpreted as use of an approximate
> representation of sign language or fingerspelling in the text media strea=
m.
> The use of such representation is rare and usually conveniently agreed by
> other means between the users during an established session. Common suppo=
rt
> of this indication SHOULD NOT be assumed or required.
>
>    4.    A Language-Tag for a sign language specified in a humintlang
> attribute for an audio stream SHOULD NOT be indicated and MAY be ignored =
on
> reception. Any use of spoken words or spoken language in the audio stream
> SHOULD, when it can be of importance for language communication, be
> indicated by the corresponding Language-Tag for spoken language in a
> humintlang attribute for the audio stream.
>
>
>
>
> Gunnar
>
>
> --
> -----------------------------------------
> Gunnar Hellstr=C3=B6m
> Omnitor
> gunnar.hellstrom@omnitor.se
> +46 708 204 288
>
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim
>

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


Gunnar Hellstrom said:=C2=A0

"The SDP Lang attribute in RFC 4566, where you =
(Randall) say it is intended for specifying a set of languages that all mus=
t be used in a session, while I say that it is intended for negotiation of =
at least one initial language."

[BA] At =
IETF 96 in Berlin, we had a discussion of the history of the SDP Lang attri=
bute within the MMUSIC WG.=C2=A0

The Lang att=
ribute was originally specified in RFC 2327, which was published in April 1=
998, more than four years prior to the publication of Offer/Answer RFC 3264=
 (June 2002), and three years prior to publication of the initial draft-ros=
enberg-mmusic-sdp-offer-answer-00 (April 26, 2001).=C2=A0
=

As a result, the Lang attribute could not have been designed=
 for use in Offer/Answer negotiation, but instead was intended for use in t=
he declarative SDP of multicast conferencing.=C2=A0 Note that the Lang attr=
ibute was not mentioned in RFC 3264, and noone at the MMUSIC WG session was=
 aware of a subsequent SIP Offer/Answer implementation of it.





<=
/span>



On Wed, Feb 15, 2017 at 1:41 AM, Gunnar=
 Hellstr=C3=B6m <gunnar.hellstrom@omnitor.se> wrot=
e:
Den 2017-02-15 kl. 01:39, skrev Randall Gellens:



At 4:21 PM -0800 2/14/17, Randy Presuhn wrote:





=C2=A0Hi -



=C2=A0On 2/14/2017 2:43 PM, Randall Gellens wrote:



=C2=A0At 8:59 PM +0100 2/14/17, Gunnar Hellstr=C3=B6m wrote:





=C2=A0 Den 2017-02-14 kl. 19:05, skrev Randy Presuhn:





=C2=A0 Hi -



=C2=A0 On 2/14/2017 9:40 AM, Randall Gellens wrote:



=C2=A0 At 11:01 AM +0100 2/14/17, Gunnar Hellstr=C3=B6m wrote:





=C2=A0 =C2=A0My proposal for a reworded section 5.4 is:



=C2=A0 =C2=A05.4.=C2=A0 Unusual language indications



=C2=A0 =C2=A0It is possible to specify an unusual indication where the lang=
uage

=C2=A0 =C2=A0specified may look unexpected for the media type.



=C2=A0 =C2=A0For such cases the following guidance SHALL be applied for the=


=C2=A0 humintlang attributes used in these situations.



=C2=A0 =C2=A01.=C2=A0 =C2=A0 A view of a speaking person in the video strea=
m SHALL, when it

=C2=A0 has relevance for speech perception, be indicated by a Language-Tag<=
br>
=C2=A0 for spoken/written language with the "Zxxx" script subtag =
to indicate

=C2=A0 that the contents is not written.



=C2=A0 =C2=A02.=C2=A0 =C2=A0 Text captions included in the video stream SHA=
LL be indicated

=C2=A0 by a Language-Tag for spoken/written language.



=C2=A0 =C2=A03.=C2=A0 =C2=A0 Any approximate representation of sign languag=
e or

=C2=A0 fingerspelling in the text media stream SHALL be indicated by a

=C2=A0 Language-Tag for a sign language in text media.



=C2=A0 =C2=A04.=C2=A0 =C2=A0 When sign language related audio from a person=
 using sign

=C2=A0 language is of importance for language communication, this SHALL be<=
br>
=C2=A0 indicated by a Language-Tag for a sign language in audio media.





=C2=A0 [RG] As I said, I think we should avoid specifying this until we hav=
e

=C2=A0 deployment experience.



=C2=A0 ...



=C2=A0 From a process perspective, it's far easier to remove constraint=
s

=C2=A0 as a specification advances than it is to add them.



=C2=A0 I agree. It is often better to specify normatively as far as you can=


=C2=A0imagine, so that interoperability and good functionality is achieved.=


=C2=A0Stopping halfway and have MAY in the specifications creates

=C2=A0uncertainty and less useful specifications.





=C2=A0My reading of what Randy says is the opposite of Gunnar's. In my<=
br>
=C2=A0reading, Randy points out that is it easier to remove the SHOULD NOT =
in

=C2=A0the future then it is to change the meaning of the combinations or
=C2=A0switch to a different mechanism.



=C2=A0In my experience, it's better to specify only what we know we nee=
d and

=C2=A0what we know we understand.=C2=A0 Speculative specifications "as=
 far as you

=C2=A0can imagine" more often lead to interoperability problems, unnec=
essary

=C2=A0complexity, limitations on what's needed in the future, and diver=
gent

=C2=A0implementations.





=C2=A0I think the difference in your positions comes down to



=C2=A0 =C2=A0(1) your respective notions of "what we know we need and =
what we

=C2=A0 =C2=A0 =C2=A0 =C2=A0know we understand";



=C2=A0 =C2=A0(2) whether you believe that the interoperability and conforma=
nce

=C2=A0 =C2=A0 =C2=A0 =C2=A0consequences of removing a "SHOULD NOT"=
; could be the same

=C2=A0 =C2=A0 =C2=A0 =C2=A0as those merely retaining a "MUST" or =
"SHALL" - this determines

=C2=A0 =C2=A0 =C2=A0 =C2=A0whether Randy G.'s proposal provides a path =
for some future

=C2=A0 =C2=A0 =C2=A0 =C2=A0revision to mandate (if deployment experience su=
bstantiates the

=C2=A0 =C2=A0 =C2=A0 =C2=A0need/understanding) the behavior proposed by Gun=
nar. That path

=C2=A0 =C2=A0 =C2=A0 =C2=A0is not at all obvious to me.





The purpose of the draft is to enable the two endpoints of a real-time comm=
unication session to agree which languages and media to use for interactive=
 communication.=C2=A0 We have a mechanism of adding language tags to media =
stream negotiations.=C2=A0 In most cases, the language and media modality a=
re an obvious fit.=C2=A0 There are combinations of media and language where=
 the meaning is not so obvious, specifically, signed language tags with a a=
udio or text, and non-signed language tags with video.=C2=A0 My proposal is=
 that we say offerer SHOULD NOT send such combinations and answerer MAY ign=
ore language. This allows future specifications for the underlying uses Gun=
nar wants (such as real-time subtitles in video and signed equivalents in t=
ext).=C2=A0 Such future specifications could define a use for the language =
and media combinations and remove the SHOULD NOT send and MAY ignore, or co=
uld define a new mechanism.=C2=A0 I don't think we know enough now to d=
ictate what the solution should be.



We have a fresh example from our own discussions in the SLIM group how unfo=
rtunate it is to not be sufficiently explicit in the first edition of a sta=
ndard. The SDP Lang attribute in RFC 4566, where you (Randall) say it is in=
tended for specifying a set of languages that all must be used in a session=
, while I say that it is intended for negotiation of at least one initial l=
anguage. By having that uncertainty in a specification that has been publis=
hed makes it very hard to sharpen up the specification afterwards because i=
t would possibly make some implementations non conformant. And it makes pot=
ential implementors hesitant to use the current specifications, as it was w=
ith the SLIM work.



For 5.4.



I am OK with modifying from my latest proposal, but we need to be specific.=


I am also OK with reducing the SHALLs to SHOULDs as Addison requested.



The situation is not that we lack knowledge. Here is what we know about the=
 4 cases of "unusual" indications:



1. View of the speaker in video. Very important for speech perception. Qual=
ity requirements are documented in ITU-T H-series Supplement 1. Of real use=
 only as a complement to the same spoken language in audio. Now, when we kn=
ow about the Zxxx notation for non-written, we also have a good way of spec=
ifying it precisely.

This case was also described in section 5.2 already.



2. Text captions in the video stream.

This can be either text merged into video and communicated as true part of =
the video image, or it can be a text component of a multimedia system, as M=
PEG-4, declared in SDP as m=3Dvideo.

It has been used in some videophone products, but I have not seen it used l=
ately.

It is a clearly defined case, and we can specify coding for it, but we do n=
ot at the moment know if it will be important to specify it.



3. Sign language or fingerspelling in the text stream.

I have seen a product using it for claimed sign language conversation. It i=
s also in use in the simple text form with words in capitals approximately =
representing signs between persons involved in preparation of sign language=
 productions and translations. But in that case it is in a session where th=
ey agree in other ways to start using the text stream for that purpose. So =
I think we can say that this is rare, and its use can be agreed by other me=
ans between the users. Still it is a clearly defined case.



4. Audio from signing person related to sign language. This is more vague t=
han the others.=C2=A0 It may be a person signing in video and adding spoken=
 words in audio to signing, but influenced by the word order and grammar of=
 sign language with some ambition to make it reasonably understandable for =
both deaf and hearing participants. There are even some spoken words create=
d from sign language that are commonly used by hearing persons in such situ=
ations. But for that case I anyway think it is better to define the audio p=
art as the spoken language it is derived from, because of its intention to =
be understandable for hearing persons. All other variants I can imagine are=
 even closer to the spoken language and should be specified with spoken lan=
guage tag. If we only want to have the audio stream established to hear the=
 background in the signing situation, then we should not specify language u=
se of the audio stream.

Even if we know what sign language tag in audio stream would be, it may be =
just as good to leave it undefined.

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

So, new proposal:



5.4.=C2=A0 Unusual language indications



=C2=A0 =C2=A0It is possible to specify an unusual indication where the lang=
uage

=C2=A0 =C2=A0specified may look unexpected for the media type.



=C2=A0 =C2=A0For such cases the following guidance SHOULD be applied for th=
e

=C2=A0 humintlang attributes used in these situations.



=C2=A0 =C2=A01.=C2=A0 =C2=A0 A view of a speaking person in the video strea=
m SHOULD, when it

=C2=A0 has relevance for speech perception, be indicated by a humintlang at=
tribute with a Language-Tag

=C2=A0 for a spoken/written language with the "Zxxx" script subta=
g to indicate

=C2=A0 that the contents is not written.



=C2=A0 =C2=A02.=C2=A0 =C2=A0 Text captions included in the video stream SHO=
ULD be indicated

=C2=A0 by a humintlang attribute with Language-Tag for spoken/written langu=
age.



=C2=A0 =C2=A03.=C2=A0 =C2=A0 A Language-Tag for a sign language specified i=
n a humintlang attribute for a text stream MAY be interpreted as use of an =
approximate representation of sign language or fingerspelling in the text m=
edia stream. The use of such representation is rare and usually convenientl=
y agreed by other means between the users during an established session. Co=
mmon support of this indication SHOULD NOT be assumed or required.



=C2=A0 =C2=A04.=C2=A0 =C2=A0 A Language-Tag for a sign language specified i=
n a humintlang attribute for an audio stream SHOULD NOT be indicated and MA=
Y be ignored on reception. Any use of spoken words or spoken language in th=
e audio stream SHOULD, when it can be of importance for language communicat=
ion, be indicated by the corresponding Language-Tag for spoken language in =
a humintlang attribute for the audio stream.









Gunnar





-- 

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

Gunnar Hellstr=C3=B6m

Omnitor

gunnar.hel=
lstrom@omnitor.se

+46 708 204 288



_______________________________________________

SLIM mailing list

SLIM@ietf.org

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





--001a113dcd7a989c4b05489a6191--


From nobody Wed Feb 15 16:26: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 B406E12997C; Wed, 15 Feb 2017 16:26:52 -0800 (PST)
X-Quarantine-ID: 
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -1.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 vHVyhV1HPm8Q; Wed, 15 Feb 2017 16:26:50 -0800 (PST)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 826101296EE; Wed, 15 Feb 2017 16:26:50 -0800 (PST)
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Wed, 15 Feb 2017 16:18:41 -0800
Mime-Version: 1.0
Message-Id: 
In-Reply-To: 
References:  <4c4ef65a-a907-cf5e-4b2c-835fb55d0146@omnitor.se>  <434a4f06-f034-46ca-9df7-f59059e67e41@alumni.stanford.edu> <843f0cc1-2686-162d-25dc-0075847579bc@omnitor.se>  <84760193-19e6-1f53-43cc-32b0493a1844@alumni.stanford.edu>  <4f1f3a72-d8a9-4f41-4133-0e6d54aadec8@omnitor.se> 
X-Mailer: Eudora for Mac OS X
Date: Wed, 15 Feb 2017 16:26:45 -0800
To: Bernard Aboba , Gunnar =?iso-8859-1?Q?Hellstr=F6m?=  
From: Randall Gellens 
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
Archived-At: 
Cc: "slim@ietf.org" , ietf@ietf.org
Subject: Re: [Slim] IETF last call for draft-ietf-slim-negotiating-human-language (Section 5.4)
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Feb 2017 00:26:53 -0000

At 3:52 PM -0800 2/15/17, Bernard Aboba wrote:

>  Gunnar Hellstrom said:
>
>  "The SDP Lang attribute in RFC 4566, where you=20
> (Randall) say it is intended for specifying a=20
> set of languages that all must be used in a=20
> session, while I say that it is intended for=20
> negotiation of at least one initial language."
>
>  [BA] At IETF 96 in Berlin, we had a discussion=20
> of the history of the SDP Lang attribute within=20
> the MMUSIC WG.
>
>  The Lang attribute was originally specified in=20
> RFC 2327, which was published in April 1998,=20
> more than four years prior to the publication=20
> of Offer/Answer RFC 3264 (June 2002), and three=20
> years prior to publication of the initial=20
> draft-rosenberg-mmusic-sdp-offer-answer-00=20
> (April 26, 2001).
>
>  As a result, the Lang attribute could not have=20
> been designed for use in Offer/Answer=20
> negotiation, but instead was intended for use=20
> in the declarative SDP of multicast=20
> conferencing.  Note that the Lang attribute was=20
> not mentioned in RFC 3264, and noone at the=20
> MMUSIC WG session was aware of a subsequent SIP=20
> Offer/Answer implementation of it.

Which is what I was saying: it is descriptive of=20
the media, which is very different from=20
negotiation.  However, this is all moot now.



>  On Wed, Feb 15, 2017 at 1:41 AM, Gunnar=20
> Hellstr=F6m=20
> <gunnar.hellstrom@omnitor.se>=20
> wrote:
>
>  Den 2017-02-15 kl. 01:39, skrev Randall Gellens:
>
>  At 4:21 PM -0800 2/14/17, Randy Presuhn wrote:
>
>   Hi -
>
>   On 2/14/2017 2:43 PM, Randall Gellens wrote:
>
>   At 8:59 PM +0100 2/14/17, Gunnar Hellstr=F6m wrote:
>
>    Den 2017-02-14 kl. 19:05, skrev Randy Presuhn:
>
>    Hi -
>
>    On 2/14/2017 9:40 AM, Randall Gellens wrote:
>
>    At 11:01 AM +0100 2/14/17, Gunnar Hellstr=F6m wrote:
>
>     My proposal for a reworded section 5.4 is:
>
>     5.4.  Unusual language indications
>
>     It is possible to specify an unusual indication where the language
>     specified may look unexpected for the media type.
>
>     For such cases the following guidance SHALL be applied for the
>    humintlang attributes used in these situations.
>
>     1.    A view of a speaking person in the video stream SHALL, when it
>    has relevance for speech perception, be indicated by a Language-Tag
>    for spoken/written language with the "Zxxx" script subtag to indicate
>    that the contents is not written.
>
>     2.    Text captions included in the video stream SHALL be indicated
>    by a Language-Tag for spoken/written language.
>
>     3.    Any approximate representation of sign language or
>    fingerspelling in the text media stream SHALL be indicated by a
>    Language-Tag for a sign language in text media.
>
>     4.    When sign language related audio from a person using sign
>    language is of importance for language communication, this SHALL be
>    indicated by a Language-Tag for a sign language in audio media.
>
>
>    [RG] As I said, I think we should avoid specifying this until we have
>    deployment experience.
>
>    ...
>
>    From a process perspective, it's far easier to remove constraints
>    as a specification advances than it is to add them.
>
>    I agree. It is often better to specify normatively as far as you can
>   imagine, so that interoperability and good functionality is achieved.
>   Stopping halfway and have MAY in the specifications creates
>   uncertainty and less useful specifications.
>
>
>   My reading of what Randy says is the opposite of Gunnar's. In my
>   reading, Randy points out that is it easier to remove the SHOULD NOT in
>   the future then it is to change the meaning of the combinations or
>   switch to a different mechanism.
>
>   In my experience, it's better to specify only what we know we need and
>   what we know we understand.  Speculative specifications "as far as you
>   can imagine" more often lead to interoperability problems, unnecessary
>   complexity, limitations on what's needed in the future, and divergent
>   implementations.
>
>
>   I think the difference in your positions comes down to
>
>     (1) your respective notions of "what we know we need and what we
>         know we understand";
>
>     (2) whether you believe that the interoperability and conformance
>         consequences of removing a "SHOULD NOT" could be the same
>         as those merely retaining a "MUST" or "SHALL" - this determines
>         whether Randy G.'s proposal provides a path for some future
>         revision to mandate (if deployment experience substantiates the
>         need/understanding) the behavior proposed by Gunnar. That path
>         is not at all obvious to me.
>
>
>  The purpose of the draft is to enable the two=20
> endpoints of a real-time communication session=20
> to agree which languages and media to use for=20
> interactive communication.  We have a mechanism=20
> of adding language tags to media stream=20
> negotiations.  In most cases, the language and=20
> media modality are an obvious fit.  There are=20
> combinations of media and language where the=20
> meaning is not so obvious, specifically, signed=20
> language tags with a audio or text, and=20
> non-signed language tags with video.  My=20
> proposal is that we say offerer SHOULD NOT send=20
> such combinations and answerer MAY ignore=20
> language. This allows future specifications for=20
> the underlying uses Gunnar wants (such as=20
> real-time subtitles in video and signed=20
> equivalents in text).  Such future=20
> specifications could define a use for the=20
> language and media combinations and remove the=20
> SHOULD NOT send and MAY ignore, or could define=20
> a new mechanism.  I don't think we know enough=20
> now to dictate what the solution should be.
>
>  We have a fresh example from our own=20
> discussions in the SLIM group how unfortunate=20
> it is to not be sufficiently explicit in the=20
> first edition of a standard. The SDP Lang=20
> attribute in RFC 4566, where you (Randall) say=20
> it is intended for specifying a set of=20
> languages that all must be used in a session,=20
> while I say that it is intended for negotiation=20
> of at least one initial language. By having=20
> that uncertainty in a specification that has=20
> been published makes it very hard to sharpen up=20
> the specification afterwards because it would=20
> possibly make some implementations non=20
> conformant. And it makes potential implementors=20
> hesitant to use the current specifications, as=20
> it was with the SLIM work.
>
>  For 5.4.
>
>  I am OK with modifying from my latest proposal, but we need to be specifi=
c.
>  I am also OK with reducing the SHALLs to SHOULDs as Addison requested.
>
>  The situation is not that we lack knowledge.=20
> Here is what we know about the 4 cases of=20
> "unusual" indications:
>
>  1. View of the speaker in video. Very important=20
> for speech perception. Quality requirements are=20
> documented in ITU-T H-series Supplement 1. Of=20
> real use only as a complement to the same=20
> spoken language in audio. Now, when we know=20
> about the Zxxx notation for non-written, we=20
> also have a good way of specifying it precisely.
>  This case was also described in section 5.2 already.
>
>  2. Text captions in the video stream.
>  This can be either text merged into video and=20
> communicated as true part of the video image,=20
> or it can be a text component of a multimedia=20
> system, as MPEG-4, declared in SDP as m=3Dvideo.
>  It has been used in some videophone products,=20
> but I have not seen it used lately.
>  It is a clearly defined case, and we can=20
> specify coding for it, but we do not at the=20
> moment know if it will be important to specify=20
> it.
>
>  3. Sign language or fingerspelling in the text stream.
>  I have seen a product using it for claimed sign=20
> language conversation. It is also in use in the=20
> simple text form with words in capitals=20
> approximately representing signs between=20
> persons involved in preparation of sign=20
> language productions and translations. But in=20
> that case it is in a session where they agree=20
> in other ways to start using the text stream=20
> for that purpose. So I think we can say that=20
> this is rare, and its use can be agreed by=20
> other means between the users. Still it is a=20
> clearly defined case.
>
>  4. Audio from signing person related to sign=20
> language. This is more vague than the others.=20
> It may be a person signing in video and adding=20
> spoken words in audio to signing, but=20
> influenced by the word order and grammar of=20
> sign language with some ambition to make it=20
> reasonably understandable for both deaf and=20
> hearing participants. There are even some=20
> spoken words created from sign language that=20
> are commonly used by hearing persons in such=20
> situations. But for that case I anyway think it=20
> is better to define the audio part as the=20
> spoken language it is derived from, because of=20
> its intention to be understandable for hearing=20
> persons. All other variants I can imagine are=20
> even closer to the spoken language and should=20
> be specified with spoken language tag. If we=20
> only want to have the audio stream established=20
> to hear the background in the signing=20
> situation, then we should not specify language=20
> use of the audio stream.
>  Even if we know what sign language tag in audio=20
> stream would be, it may be just as good to=20
> leave it undefined.
>=20
> --------------------------------------------------------------------------=
----------------------------------------------------------------------
>  So, new proposal:
>
>  5.4.  Unusual language indications
>
>     It is possible to specify an unusual indication where the language
>     specified may look unexpected for the media type.
>
>     For such cases the following guidance SHOULD be applied for the
>    humintlang attributes used in these situations.
>
>     1.    A view of a speaking person in the video stream SHOULD, when it
>    has relevance for speech perception, be=20
> indicated by a humintlang attribute with a=20
> Language-Tag
>    for a spoken/written language with the "Zxxx" script subtag to indicate
>    that the contents is not written.
>
>     2.    Text captions included in the video stream SHOULD be indicated
>    by a humintlang attribute with Language-Tag for spoken/written language=
=2E
>
>     3.    A Language-Tag for a sign language=20
> specified in a humintlang attribute for a text=20
> stream MAY be interpreted as use of an=20
> approximate representation of sign language or=20
> fingerspelling in the text media stream. The=20
> use of such representation is rare and usually=20
> conveniently agreed by other means between the=20
> users during an established session. Common=20
> support of this indication SHOULD NOT be=20
> assumed or required.
>
>     4.    A Language-Tag for a sign language=20
> specified in a humintlang attribute for an=20
> audio stream SHOULD NOT be indicated and MAY be=20
> ignored on reception. Any use of spoken words=20
> or spoken language in the audio stream SHOULD,=20
> when it can be of importance for language=20
> communication, be indicated by the=20
> corresponding Language-Tag for spoken language=20
> in a humintlang attribute for the audio stream.
>
>
>
>
>  Gunnar
>
>
>  --
>  -----------------------------------------
>  Gunnar Hellstr=F6m
>  Omnitor
>  gunnar.hellstrom@omnitor.se
>  +46 708 204 288
>
>  _______________________________________________
>  SLIM mailing list
>  SLIM@ietf.org
>=20
> https://www.ietf.org/mailman/l=
istinfo/slim


-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Computers are not intelligent.  They only think they are.


From nobody Fri Feb 17 11:07:40 2017
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60824129684 for ; Fri, 17 Feb 2017 11:07:39 -0800 (PST)
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 JV2faIkPIc7D for ; Fri, 17 Feb 2017 11:07:36 -0800 (PST)
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 A2F31129B1C for ; Fri, 17 Feb 2017 11:07:36 -0800 (PST)
Received: by mail-ua0-x22d.google.com with SMTP id t17so27565667uae.3 for ; Fri, 17 Feb 2017 11:07:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to;  bh=6t/QXre0DRSTUv/A+KWqfZ5pQfe+gCQMeAGOtPLB8TU=; b=MAeNYPBvgFHpE8x0I5YFSI5vxvpXaDYZVDIGTfihRJUtwBuxtk7S4rn86Sylfcf1TJ rPmyxT+JEjb15hsaoTYVYpTFzypjY1LPoehv5Oc3ivUhRy+JThojdFmkfruBG3uDDSnA Rob7QykYjH5TrO+NpgH3Suavq9b2+OX8HffTKYiNs5vJewVVO2k7Lgloe7xrJi9F8k8N UYZihlZ4GHKZugGJSq+CATTIBbU1NLGGLJF+GvxCXkRBBqaHRlwghojMnLFzas4uznxU blxfd0/rPQQmHyfKYyv9ce7oqdKoW/e0GYKOsQNhuxROZ0E+DN3/YtgcyGRwQk7eiobY H/JQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=6t/QXre0DRSTUv/A+KWqfZ5pQfe+gCQMeAGOtPLB8TU=; b=OS4M35FQsOyh0dTlqdnQ9sJ5zom0Zd+cjhAlXaa4I1DYirOfvwTQ1wULDtvETKEc3T /dANe4NTFEGJNJduEif5fyGYQ02zCea3QuKd7BSkrcYt+FXjOWyY1RaUOr1UWZxzxkyC BuVD/E8aY/LaVFq3Q7515oCovNL3kR3SB7zPUzO9+w2OcAoSv7kBfivHZ5zHOEhb24zj tb2TQZ+WoVsDT5+7/CLTq58LESvm047mPuClUmxUHF623DzW7U+u6IGeSQjbrLHuQoqc IieMYePFVJDIh27jHGxoeRcNP12yutiFC7JylykgM3MbOpdDaI6N/ieHVSu/ToZJTFDa lqEA==
X-Gm-Message-State: AMke39nlMk9P5ZYu51Whd7/18wJTs2RTpw/KS+wA95tpo6t4gkLTdbquEPmKZS1yGsaeIq8xdSu5Rif7h501SQ==
X-Received: by 10.176.16.87 with SMTP id g23mr4138828uab.54.1487358455588; Fri, 17 Feb 2017 11:07:35 -0800 (PST)
MIME-Version: 1.0
Received: by 10.176.88.90 with HTTP; Fri, 17 Feb 2017 11:07:15 -0800 (PST)
In-Reply-To: 
References:  <148639487237.18865.15552779861032521688.idtracker@ietfa.amsl.com> 
From: Bernard Aboba 
Date: Fri, 17 Feb 2017 11:07:15 -0800
Message-ID: 
To: slim@ietf.org
Content-Type: multipart/alternative; boundary=f403045e1d62662b150548bea028
Archived-At: 
Subject: [Slim] Fwd: [IANA #948015] Last Call:  (Negotiating Human Language in Real-Time Communications) to Proposed Standard
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Feb 2017 19:07:39 -0000

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

---------- Forwarded message ----------
From: Sabrina Tanamal via RT 
Date: Fri, Feb 17, 2017 at 7:50 AM
Subject: [IANA #948015] Last Call:
 (Negotiating Human
Language in Real-Time Communications) to Proposed Standard
To:
Cc: iesg@ietf.org, rg+ietf@randy.pensive.org, Bernard_Aboba@hotmail.com,
nrooney@gsma.com, ben@nostrum.com, alissa@cooperw.in, aamelnikov@fastmail.fm,
bernard.aboba@gmail.com


(BEGIN IANA COMMENTS)

IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of
draft-ietf-slim-negotiating-human-language-06.txt. If any part of this
review is inaccurate, please let us know.

We have a question about one of the actions requested in the IANA
Considerations section of this document.

The IANA Services Operator understands that, upon approval of this
document, there is a single action which we must complete.

In the att-field (media level only) subregistry of the Session Description
Protocol (SDP) Parameters registry located at:

https://www.iana.org/assignments/sdp-parameters/

two new registrations are to be made as follows:

Type: att-field (media level only)
SDP Name: humintlang-recv
MUX Category:
Reference: [ RFC-to-be ]

Type: att-field (media level only)
SDP Name: humintlang-send
MUX Category:
Reference: [ RFC-to-be ]

IANA Services Operator Question --> What should the MUX Category be for
these two new registrations?

Because this registry requires Expert Review [RFC5226] for registration,
we've contacted the IESG-designated expert in a separate ticket to request
approval. Expert review should be completed before your document can be
approved for publication as an RFC.

The IANA Services Operator understands that this is the only action
required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until
the document has been approved for publication as an RFC. This message is
only to confirm what actions will be performed.

Thank you,

Sabrina Tanamal
IANA Services Specialist
PTI

(END IANA COMMENTS)

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



---------- Forwarded messag=
e ----------
From: Sabrina Tanamal via RT<=
/b> <draft=
s-lastcall@iana.org>
Date: Fri, Feb 17, 2017 at 7:50 AMSubject: [IANA #948015] Last Call: <draft-ietf-slim-negotiating-human-l=
anguage-06.txt> (Negotiating Human Language in Real-Time Communications)=
 to Proposed Standard
To: 
Cc: iesg@=
ietf.org, rg+ietf@randy.=
pensive.org, Bernard_Aboba=
@hotmail.com, nrooney@gsma.com,=
 ben@nostrum.com, alissa@cooperw.in, aamelnikov@fastmail.fm, bernard.aboba@gmail.com


(BEGIN IANA COMMENTS)



IESG/Authors/WG Chairs:



The IANA Services Operator has completed its review of draft-ietf-slim-nego=
tiating-human-language-06.txt. If any part of this review is inaccurat=
e, please let us know.



We have a question about one of the actions requested in the IANA Considera=
tions section of this document.



The IANA Services Operator understands that, upon approval of this document=
, there is a single action which we must complete.



In the att-field (media level only) subregistry of the Session Description =
Protocol (SDP) Parameters registry located at:



https://www.iana.org/assignments/sdp-parameters=
/



two new registrations are to be made as follows:



Type: att-field (media level only)

SDP Name: humintlang-recv

MUX Category:

Reference: [ RFC-to-be ]



Type: att-field (media level only)

SDP Name: humintlang-send

MUX Category:

Reference: [ RFC-to-be ]



IANA Services Operator Question --> What should the MUX Category be for =
these two new registrations?



Because this registry requires Expert Review [RFC5226] for registration, we=
've contacted the IESG-designated expert in a separate ticket to reques=
t approval. Expert review should be completed before your document can be a=
pproved for publication as an RFC.



The IANA Services Operator understands that this is the only action require=
d to be completed upon approval of this document.



Note:=C2=A0 The actions requested in this document will not be completed un=
til the document has been approved for publication as an RFC. This message =
is only to confirm what actions will be performed.



Thank you,



Sabrina Tanamal

IANA Services Specialist

PTI



(END IANA COMMENTS)







--f403045e1d62662b150548bea028--


From nobody Fri Feb 17 18:32:36 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 7B19E129449; Fri, 17 Feb 2017 18:32:25 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "Dale Worley" 
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.44.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148738514545.19944.11486737065416495302.idtracker@ietfa.amsl.com>
Date: Fri, 17 Feb 2017 18:32:25 -0800
Archived-At: 
Cc: slim@ietf.org, ietf@ietf.org, draft-ietf-slim-negotiating-human-language.all@ietf.org
Subject: [Slim] Review of draft-ietf-slim-negotiating-human-language-06
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 18 Feb 2017 02:32:25 -0000

Reviewer: Dale Worley
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft.  The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at
.

Document:  draft-ietf-slim-negotiating-human-language-06
Reviewer:  Dale R. Worley
Review Date:  2017-02-17
IETF LC End Date:  2017-02-20
IESG Telechat date:  [unknown]

Summary:
       This draft is basically ready for publication, but has nits
       that should be fixed before publication.

* Technical comments

A. Call failure

If a call fails due to no available language match, in what way(s)
does it fail?  Section 5.3 says

   If such an offer is received, the receiver MAY
   reject the media, ignore the language specified, or attempt to
   interpret the intent

But I suspect it's also allowed for the UAS to fail the call at the
SIP level.  Whether or not that is allowed (or at least envisioned)
should be described.  And what response code(s)/warn-code(s) should
be
used for that?

B. Audio/Video coordination

   5.2.  New 'humintlang-send' and 'humintlang-recv' attributes

   Note that while signed language tags are used with a video stream
to
   indicate sign language, a spoken language tag for a video stream
in
   parallel with an audio stream with the same spoken language tag
   indicates a request for a supplemental video stream to see the
   speaker.

And there's a similar paragraph in 5.4:

>    A spoken language tag for a video stream in conjunction with an
audio
>    stream with the same language might indicate a request for
>    supplemental video to see the speaker.

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 seems to me that a
workable rule is that there is an audio stream and a video stream and
they specify exactly the same language tag in their respective
humintlang attributes.  In that case, it is a request for a spoken
language with simultaneous video of the speaker, and those requests
should be considered satisfied only if both streams can be
established.

* The following three items are adjustments to the design which I'd
like to know have been considered.

C. "humintlang" seems long to me

Given the excessive length of SDP in practice, it seems to me that a
shorter attribute name would be desirable.  E.g., "humlang" as was
used in some previous versions.  Or is there a coordinated usage with
other names in the "hum*lang" pattern?

D. Use the Accept-Language syntax

It seems to me that it would better to use the Accept-Language syntax
for the attribute values.  This allows (1) specifiying the quality of
language experience, allowing clear description of bilingualism, (2)
a
unified method of specifying whether or not arbitrary languages are
acceptable, and (3) abbreviating SDP descriptions.

In a way, the fact that the current proposal seems to require (but
does not directly specify) the coordinated absence/presence of an
asterisk on all of the repetitions of humintlang-send or
humintlang-recv is a warning that the syntax doesn't represent the
semantics as well as it might.

E. Have an attribute to abbreviate the bidirectionally-symmetric case

Note that all examples are bidirectionally symmetric, and the text
says that requests and responses SHOULD be bidirectionally symmetric.
So it would be a very useful abbreviation to define
"humintlang=" to be equivalent to the combination of
"humintlang-send=" and "humintlang-recv=".

Combining proposals C, D, and E, the examples become

      m=audio 49170 RTP/AVP 0
      a=humlang:en

      m=video 51372 RTP/AVP 31 32
      a=humlang:ase,*;q=0.1

      m=audio 49250 RTP/AVP 20
      a=humlang:es,eu;q=0.9,en;q=0.8,*;q=0.1

      m=text 45020 RTP/AVP 103 104
      a=humlang:gr

which requires about half as many characters as they have now.

* Editorial comments and nits

Abstract

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

I don't think the term "stream attribute" is used in RFC 4566.
Instead, it uses "media attribute".

1.  Introduction

   caller and callee know each other or there is contextual or out of
   band information from which the language(s) and media modalities
can

I think this context, it's preferred to hyphenate "out-of-band" to
make it clearly be an adjective.

   This approach has a number of benefits, including that it is
generic
   (applies to all interactive communications negotiated using SDP)
and
   not limited to emergency calls.

I think s/and not limited to/and is not limited to/ reads more
smoothly.

   But it is clearly useful in many other cases.  For
   example, someone calling a company call center or a Public Safety
   Answering Point (PSAP) should be able to indicate if one or more
   specific signed, written, and/or spoken languages are preferred,
the
   callee should be able to indicate its capabilities in this area,
and
   the call proceed using in-common language(s) and media forms.

I think s/preferred, the callee/preferred; the callee/ because the
sentence is the concatenation of two sentences.

Perhaps s/in-common/shared/.

   Including the user's human (natural) language preferences in the
   session establishment negotiation is independent of the use of a
   relay service and is transparent to a voice service provider. 

I think it's even broader than "transparent to a voice service
provider" -- it's transparent to any serivice provider, assuming that
the media are language-neutral.

   In the case of a call to e.g., an airline, the call could be
   automatically handled by a Spanish-speaking agent.

I think s/handled by/routed to/ is the usual usage.

3.  Desired Semantics

   The desired solution is a media attribute (preferably per
direction)
   that may be used within an offer to indicate the preferred
language
   of each (direction of a) media stream, and within an answer to
   indicate the accepted language.

In this one instance, I think you want to use "language(s)" to drive
home that that multiple languages can be specified:  "within an offer
to indicate the preferred language(s)".

   (Negotiating multiple simultaneous languages within a media stream
is
   out of scope, as the complexity of doing so outweighs the
   usefulness.)

You might want to say instead "(Negotiating multiple simultaneous
languages within a media stream is out of scope for this document.)"
to ensure that nobody decides to argue whether "the complexity of
doing so outweighs the usefulness".

4.  The existing 'lang' attribute

   RFC 4566 [RFC4566] specifies an attribute 'lang' which appears
   similar to what is needed here, but is not sufficiently detailed
for
   use here.

"for use here" isn't quite right.  Maybe "is not sufficiently
specific
or flexible to satisfy the requirements".

   In addition, it is not mentioned in [RFC3264]

"it" is somewhat ambiguous here, perhaps change to "the 'lang'
attribute".

5.  Proposed Solution

Perhaps /Proposed Solution/Solution/, since once this draft is
approved, it becomes the solution.

5.2.  New 'humintlang-send' and 'humintlang-recv' attributes

      a=humintlang-send:
      a=humintlang-recv:

This is presented as the generic form of the attributes, but there is
no indication of the posible asterisk.

   The values constitute a list of languages
   in preference order (first is most preferred).

"The values" isn't very clear, because the values are in successive
attributes.  You want to say something like "The sequence of values
in
the occurrences of one of these attributes constitutes ...". 
However,
see the technical comments above.

   When placing an emergency call, and in any other case where the
   language cannot be assumed from context, each media stream in an
   offer primarily intended for human language communication SHOULD
   specify both (or in some cases, one of) the 'humintlang-send' and
   'humintlang-recv' attributes.

Probably s/assumed/inferred/.

Could you be more accurate by
s/or in some cases/or for unidirectional streams/?

5.3.  Advisory vs Required

   The mechanism for indicating this preference is that, in an offer,
if
   the last character of any of the 'humintlang-recv' or 'humintlang-
   send' values is an asterisk, this indicates a request to not fail
the
   call (similar to SIP Accept-Language syntax).  Either way, the
called
   party MAY ignore this, e.g., for the emergency services use case,
a
   PSAP will likely not fail the call.

The construction of this paragraph isn't quite complete.  It says
that
if an asterisk is present, a request shouldn't fail, but it doesn't
say that if no asterisk is present, a request should fail if there is
no language match.  And it's the latter condition that makes the
second sentence meaningful.  So I think you want to insert between
the
two sentences one regarding the absence of an asterisk.

5.5.  Examples

Given that the combined audio/video mechanism is the only
irregularity
in this system, there ought to be an example of it.  E.g.,

   An example of a supplemental video stream with a spoken language
   audio stream:

      m=video 51372 RTP/AVP 31 32
      a=humintlang-send:en
      a=humintlang-recv:en

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

6.  IANA Considerations

      humintlang-value =  Language-Tag [ asterisk ]
                          ; Language-Tag defined in RFC 5646
      asterisk         =  "*"

s/Language-Tag defined in RFC 5646/Language-Tag as defined in RFC
5646/

But perhaps also s/RFC 5646/BCP 47/, which ensures that "humintlang"
tracks the current version of language tags.

Appendix A.  Historic Alternative Proposal: Caller-prefs

   This
   results in a more fragile solution since the media modality and
   language would be negotiated using SIP, and then the specific
media
   formats (which inherently include the modality) would be
negotiated
   at a different level (typically SDP, especially in the emergency
   calling cases), making it easier to have mismatches (such as where
   the media modality negotiated in SIP don't match what was
negotiated
   using SDP).

"the media modality and language would be negotiated using SIP" isn't
quite the right way to say it because SIP isn't explicitly
negotiating
the modality.  Better would be

   ... the language (and by implication the media modality) would be
   negotiated using SIP, and then the specific media (which
inherently
   include the modalities and formats) would be negotiated at a
   different level ...

[END]



From nobody Tue Feb 21 15:29:00 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 885701293DF; Tue, 21 Feb 2017 15:28:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.91
X-Spam-Level: 
X-Spam-Status: No, score=-2.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 v8c4av7skV_0; Tue, 21 Feb 2017 15:28:55 -0800 (PST)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0066.outbound.protection.outlook.com [104.47.2.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71DF21204D9; Tue, 21 Feb 2017 15:28:54 -0800 (PST)
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=6gYsPkN2X4IWhAAmUHZhoKkTQ3QWAJTPSl4GK0E9/dA=; b=iXgGDNAoP7dsubF5/cLUyvW89P9uNSTwtNikM3rWx0pbiGaRlVMFsJNX3esjv7I1B28pWAQ+R8VjYBlHu0DoEiZnNU5AZ7aRZpiY2C3ZpuV7AmlU6glaKFgXONvnmWxwekqRGZMqD7zTQhym6xij7C+48eSthfeY9NqkSTUU4H0=
Received: from HE1PR04MB3113.eurprd04.prod.outlook.com (10.171.196.31) by HE1PR04MB3116.eurprd04.prod.outlook.com (10.171.196.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.919.13; Tue, 21 Feb 2017 23:28:51 +0000
Received: from HE1PR04MB3113.eurprd04.prod.outlook.com ([10.171.196.31]) by HE1PR04MB3113.eurprd04.prod.outlook.com ([10.171.196.31]) with mapi id 15.01.0919.018; Tue, 21 Feb 2017 23:28:51 +0000
From: Natasha Rooney 
To: Dale Worley , "slim@ietf.org" 
Thread-Topic: Review of draft-ietf-slim-negotiating-human-language-06
Thread-Index: AQHSiY9AG5SIuWMvTkWvq4pl7gSV96F0IWOA
Date: Tue, 21 Feb 2017 23:28:50 +0000
Message-ID: 
References: <148738514545.19944.11486737065416495302.idtracker@ietfa.amsl.com>
In-Reply-To: <148738514545.19944.11486737065416495302.idtracker@ietfa.amsl.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-mailer: Apple Mail (2.3259)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=nrooney@gsma.com; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [217.39.120.58]
x-ms-office365-filtering-correlation-id: b1762689-c66c-48c4-64f5-08d45ab164ab
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:HE1PR04MB3116;
x-microsoft-exchange-diagnostics: 1; HE1PR04MB3116; 7:qs5+nnuX0DtYS8RoxUf1I18DpTDPshEzm+uo1/rvUyBm4byHHnWwza8a2l2Qv+p61CRqGXim7FxRw7XIzz4p+qgAEqWcCHo4S1BYT8Kjg4Wqf4vJE9RSqVjwB17D7qKHg+91gfgW1JfRszpq51UH94Y/9W2L3lJO4LDsnCgBS6Uv9kyVUjGcFucOToah0NatAdZ5Pbubvfv0ATkufh3YJ6MASJxz1N8WpB5VKdiGMJwxwZ5JDK/b4SGH+0zy1EK56TQGznWaVP/5jNXTlf1w78tO8vM+VGpIvgpEaP1/ALeiyu8UBTG7TOKbvMoh+Gn2zWtK8p1aJohmhdCrgqg/zw==
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123558025)(20161123560025)(6072148); SRVR:HE1PR04MB3116; BCL:0; PCL:0; RULEID:; SRVR:HE1PR04MB3116; 
x-forefront-prvs: 0225B0D5BC
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(39450400003)(51914003)(189002)(377424004)(199003)(66654002)(24454002)(50986999)(5660300001)(76176999)(36756003)(122556002)(2950100002)(38730400002)(6246003)(53936002)(2906002)(77096006)(606005)(83716003)(5890100001)(6506006)(57306001)(66066001)(102836003)(6486002)(229853002)(6116002)(2501003)(3846002)(6306002)(25786008)(6436002)(82746002)(6512007)(54896002)(99286003)(236005)(54906002)(92566002)(97736004)(189998001)(4326007)(3280700002)(86362001)(3660700001)(68736007)(33656002)(2900100001)(53546006)(50226002)(105586002)(7906003)(106116001)(81166006)(81156014)(7736002)(106356001)(8676002)(8936002)(101416001)(561944003)(230783001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR04MB3116; H:HE1PR04MB3113.eurprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: gsma.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_D80EB5AC8E94475683D02F6FB721A883gsmacom_"
MIME-Version: 1.0
X-OriginatorOrg: gsma.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Feb 2017 23:28:50.8396 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72a4ff82-fec3-469d-aafb-ac8276216699
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR04MB3116
X-MS-Exchange-CrossPremises-AuthAs: Internal
X-MS-Exchange-CrossPremises-AuthMechanism: 04
X-MS-Exchange-CrossPremises-AuthSource: HE1PR04MB3113.eurprd04.prod.outlook.com
X-MS-Exchange-CrossPremises-SCL: 1
X-MS-Exchange-CrossPremises-messagesource: StoreDriver
X-MS-Exchange-CrossPremises-BCC: 
X-MS-Exchange-CrossPremises-originalclientipaddress: 217.39.120.58
X-MS-Exchange-CrossPremises-avstamp-service: 1.0
X-MS-Exchange-CrossPremises-disclaimer-hash: 78ca8040c6722e32c2f5b0a45bf37e74b9409d645a53be96aa19958e0cee0f00
X-MS-Exchange-CrossPremises-antispam-scancontext: DIR:Originating; SFV:NSPM; SKIP:0; 
X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent
X-OrganizationHeadersPreserved: HE1PR04MB3116.eurprd04.prod.outlook.com
Archived-At: 
Cc: "gen-art@ietf.org" , "ietf@ietf.org" , "draft-ietf-slim-negotiating-human-language.all@ietf.org" 
Subject: Re: [Slim] Review of draft-ietf-slim-negotiating-human-language-06
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Feb 2017 23:28:59 -0000

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

SGkgRGFsZSEgTWFueSB0aGFua3MgZm9yIHRoZXNlIGNvbW1lbnRzLCBhcyBvbmUgb2YgdGhlIFNM
SU0gY2hhaXJzIEnigJlsbCB3b3JrIG9uIGdldHRpbmcgc29tZSBhbnN3ZXJzIHRvIHlvdSBvciBJ
4oCZbGwgcmVxdWVzdCB0aGUgYXV0aG9yIG9yIG9uZSBvZiB0aGUgU0xJTSBhY3RpdmUgcGFydGlj
aXBhbnRzIHRvIHJlc3BvbmQuDQoNCkJlcm5hcmQsIFJhbmRhbGwgYW5kIFNMSU0gLSBzZWUgYmVs
b3cgcmUgRGFsZeKAmXMgcG9pbnRzLg0KDQoqKioqIEEuIENhbGwgZmFpbHVyZSAqKioqDQpSYW5k
YWxsIG9yIEJlcm5hcmQgY2FuIHlvdSByZXNwb25kIHRvIHRoaXM/IEkgaW1hZ2luZSB0aGUgVUEg
Y2FsbCBmYWlsdXJlIG1ldGhvZCBpcyBVQSBzcGVjaWZpYywgYnV0IGlmIHRoZXJlIGlzIGEgY2xh
c2ggd2l0aCBTSVAgbGV2ZWwgY2FsbCBmYWlsIHRoZW4gdGhpcyBzaG91bGQgYmUgYWRkcmVzc2Vk
Lg0KDQoqKioqIEIuIEF1ZGlvL1ZpZGVvIGNvb3JkaW5hdGlvbiAqKioqDQpJIGJlbGlldmUgdGhl
IHRoZW9yeSBiZWhpbmQgdGhlIGN1cnJlbnQgZHJhZnQgaXMgdGhhdCB0aGUgc3Bva2VuIGFuZCB2
aWRlbyBzdHJlYW1zIHdpbGwgYmUgZGlmZmVyZW50IGluIHRoZSBjYXNlcyBvZiBzdWNoIHRoaW5n
cyBhcyBzaWduIGxhbmd1YWdlLiBWaWRlbyBjb3VsZCB0aGVyZWZvcmUgYmUgc2lnbiBhbmQgYXVk
aW8gd291bGQgYmUgYSBzcG9rZW4gbGFuZ3VhZ2UuIEnigJltIG5vdCBzdXJlIGlmIHRoZSBzdWdn
ZXN0aW9uIGhlIHNhdGlzZmllcyB0aGlzIGNhc2U/DQoNCioqKiogQy4gImh1bWludGxhbmciIHNl
ZW1zIGxvbmcgdG8gbWUgKioqKg0KQmVybmFyZCAtIEkgZG9u4oCZdCBzZWUgdGhlIGlzc3VlIHdp
dGggc2hvcnRlbmluZyBodW1pbnRsYW5nLCBidXQgdGhlIGdyb3VwIG1pZ2h0LiBJIHN1Z2dlc3Qg
d2UgdGhyb3cgdGhpcyB0byB0aGUgZ3JvdXAgZm9yIGRpc2N1c3Npb24uDQoNCioqKiogRC4gVXNl
IHRoZSBBY2NlcHQtTGFuZ3VhZ2Ugc3ludGF4ICoqKioNClJhbmRhbGwgYW5kIEJlcm5hcmQgLSBp
cyB0aGlzIGFuIGFjY2VwdGFibGUgY2hhbmdlPyBPciBvbmUgd2UgbmVlZCB0byBkaXNjdXNzIGZ1
cnRoZXIuIFNlZW1zIGxpa2UgYSByZWFzb25hYmxlIHJlcXVlc3QsIGJ1dCBhbHNvIGEgbGFyZ2Vy
IGNoYW5nZSwgd2hpY2ggaXMgd2h5IEkgYXNrIQ0KDQoqKioqIEUuIEhhdmUgYW4gYXR0cmlidXRl
IHRvIGFiYnJldmlhdGUgdGhlIGJpZGlyZWN0aW9uYWxseS1zeW1tZXRyaWMgY2FzZSAqKioqDQpJ
IGRvIG5vdCByZW1lbWJlciB1cyBoYXZpbmcgdGhpcyBkaXNjdXNzaW9uIHdpdGhpbiB0aGUgZ3Jv
dXAsIGFsdGhvdWdoIGl0IG1heSBoYXZlIG9jY3VycmVkIGJlZm9yZSBJIGJlY2FtZSBjaGFpci4N
ClJhbmRhbGwsIEJyaWFuIG9yIEJlcm5hcmQgLSBoYXMgdGhpcyBpZGVhIGJlZW4gZGlzY3Vzc2Vk
IGJlZm9yZT8gSWYgc28sIGNhbiBvbmUgb2YgeW91IHJlc3BvbmQgd2l0aCBhbiBleHBsYW5hdGlv
biBhcyB0byB3aHkgd2UgaGF2ZW7igJl0IGRvbmUgdGhpcz8NCg0KKioqKiBFZGl0b3JpYWwgY29t
bWVudHMgYW5kIG5pdHMgKioqKioNClJhbmRhbGwgLSBjYW4geW91IHRha2UgYSBsb29rIHRocm91
Z2ggRGFsZeKAmXMgZWRpdG9yaWFsIGNvbW1lbnRzIGFuZCBzaG91dCBpZiB0aGVyZSBpcyBhbnkg
cHJvYmxlbXMgd2l0aCB0aGVzZSBzdWdnZXN0aW9uczsgaWYgZXZlcnl0aGluZyBpcyBvayBwbGVh
c2UgbWFrZSB0aGUgY2hhbmdlcy4NCg0KVGhhbmtzIGFsbCENCg0KTmF0YXNoYSBSb29uZXkgfCBJ
bnRlcm5ldCBFbmdpbmVlcmluZyBEaXJlY3RvciB8IEludGVybmV0IGFuZCBXZWIgVGVhbSB8IFRl
Y2hub2xvZ3kgfCBHU01BIHwgbnJvb25leUBnc21hLmNvbTxtYWlsdG86bnJvb25leUBnc21hLmNv
bT4gfCArNDQgKDApIDc3MzAgMjE5IDc2NSB8IEB0aGlzTmF0YXNoYSB8IFNreXBlOiBucm9vbmV5
QGdzbS5vcmc8bWFpbHRvOm5yb29uZXlAZ3NtLm9yZz4NCg0KT24gMTggRmViIDIwMTcsIGF0IDAy
OjMyLCBEYWxlIFdvcmxleSA8d29ybGV5QGFyaWFkbmUuY29tPG1haWx0bzp3b3JsZXlAYXJpYWRu
ZS5jb20+PiB3cm90ZToNCg0KUmV2aWV3ZXI6IERhbGUgV29ybGV5DQpSZXZpZXcgcmVzdWx0OiBS
ZWFkeSB3aXRoIE5pdHMNCg0KSSBhbSB0aGUgYXNzaWduZWQgR2VuLUFSVCByZXZpZXdlciBmb3Ig
dGhpcyBkcmFmdC4gIFRoZSBHZW5lcmFsIEFyZWENClJldmlldyBUZWFtIChHZW4tQVJUKSByZXZp
ZXdzIGFsbCBJRVRGIGRvY3VtZW50cyBiZWluZyBwcm9jZXNzZWQNCmJ5IHRoZSBJRVNHIGZvciB0
aGUgSUVURiBDaGFpci4gIFBsZWFzZSB0cmVhdCB0aGVzZSBjb21tZW50cyBqdXN0DQpsaWtlIGFu
eSBvdGhlciBsYXN0IGNhbGwgY29tbWVudHMuDQoNCkZvciBtb3JlIGluZm9ybWF0aW9uLCBwbGVh
c2Ugc2VlIHRoZSBGQVEgYXQNCjxodHRwOi8vd2lraS50b29scy5pZXRmLm9yZy9hcmVhL2dlbi90
cmFjL3dpa2kvR2VuQXJ0ZmFxPi4NCg0KRG9jdW1lbnQ6ICBkcmFmdC1pZXRmLXNsaW0tbmVnb3Rp
YXRpbmctaHVtYW4tbGFuZ3VhZ2UtMDYNClJldmlld2VyOiAgRGFsZSBSLiBXb3JsZXkNClJldmll
dyBEYXRlOiAgMjAxNy0wMi0xNw0KSUVURiBMQyBFbmQgRGF0ZTogIDIwMTctMDItMjANCklFU0cg
VGVsZWNoYXQgZGF0ZTogIFt1bmtub3duXQ0KDQpTdW1tYXJ5Og0KICAgICAgVGhpcyBkcmFmdCBp
cyBiYXNpY2FsbHkgcmVhZHkgZm9yIHB1YmxpY2F0aW9uLCBidXQgaGFzIG5pdHMNCiAgICAgIHRo
YXQgc2hvdWxkIGJlIGZpeGVkIGJlZm9yZSBwdWJsaWNhdGlvbi4NCg0KKiBUZWNobmljYWwgY29t
bWVudHMNCg0KQS4gQ2FsbCBmYWlsdXJlDQoNCklmIGEgY2FsbCBmYWlscyBkdWUgdG8gbm8gYXZh
aWxhYmxlIGxhbmd1YWdlIG1hdGNoLCBpbiB3aGF0IHdheShzKQ0KZG9lcyBpdCBmYWlsPyAgU2Vj
dGlvbiA1LjMgc2F5cw0KDQogIElmIHN1Y2ggYW4gb2ZmZXIgaXMgcmVjZWl2ZWQsIHRoZSByZWNl
aXZlciBNQVkNCiAgcmVqZWN0IHRoZSBtZWRpYSwgaWdub3JlIHRoZSBsYW5ndWFnZSBzcGVjaWZp
ZWQsIG9yIGF0dGVtcHQgdG8NCiAgaW50ZXJwcmV0IHRoZSBpbnRlbnQNCg0KQnV0IEkgc3VzcGVj
dCBpdCdzIGFsc28gYWxsb3dlZCBmb3IgdGhlIFVBUyB0byBmYWlsIHRoZSBjYWxsIGF0IHRoZQ0K
U0lQIGxldmVsLiAgV2hldGhlciBvciBub3QgdGhhdCBpcyBhbGxvd2VkIChvciBhdCBsZWFzdCBl
bnZpc2lvbmVkKQ0Kc2hvdWxkIGJlIGRlc2NyaWJlZC4gIEFuZCB3aGF0IHJlc3BvbnNlIGNvZGUo
cykvd2Fybi1jb2RlKHMpIHNob3VsZA0KYmUNCnVzZWQgZm9yIHRoYXQ/DQoNCkIuIEF1ZGlvL1Zp
ZGVvIGNvb3JkaW5hdGlvbg0KDQogIDUuMi4gIE5ldyAnaHVtaW50bGFuZy1zZW5kJyBhbmQgJ2h1
bWludGxhbmctcmVjdicgYXR0cmlidXRlcw0KDQogIE5vdGUgdGhhdCB3aGlsZSBzaWduZWQgbGFu
Z3VhZ2UgdGFncyBhcmUgdXNlZCB3aXRoIGEgdmlkZW8gc3RyZWFtDQp0bw0KICBpbmRpY2F0ZSBz
aWduIGxhbmd1YWdlLCBhIHNwb2tlbiBsYW5ndWFnZSB0YWcgZm9yIGEgdmlkZW8gc3RyZWFtDQpp
bg0KICBwYXJhbGxlbCB3aXRoIGFuIGF1ZGlvIHN0cmVhbSB3aXRoIHRoZSBzYW1lIHNwb2tlbiBs
YW5ndWFnZSB0YWcNCiAgaW5kaWNhdGVzIGEgcmVxdWVzdCBmb3IgYSBzdXBwbGVtZW50YWwgdmlk
ZW8gc3RyZWFtIHRvIHNlZSB0aGUNCiAgc3BlYWtlci4NCg0KQW5kIHRoZXJlJ3MgYSBzaW1pbGFy
IHBhcmFncmFwaCBpbiA1LjQ6DQoNCiAgQSBzcG9rZW4gbGFuZ3VhZ2UgdGFnIGZvciBhIHZpZGVv
IHN0cmVhbSBpbiBjb25qdW5jdGlvbiB3aXRoIGFuDQphdWRpbw0KICBzdHJlYW0gd2l0aCB0aGUg
c2FtZSBsYW5ndWFnZSBtaWdodCBpbmRpY2F0ZSBhIHJlcXVlc3QgZm9yDQogIHN1cHBsZW1lbnRh
bCB2aWRlbyB0byBzZWUgdGhlIHNwZWFrZXIuDQoNCkkgdGhpbmsgdGhpcyBtZWNoYW5pc20gbmVl
ZHMgdG8gYmUgZGVzY3JpYmVkIG1vcmUgZXhhY3RseSwgYW5kIGluDQpwYXJ0aWN1bGFyLCBpdCBz
aG91bGQgbm90IGRlcGVuZCBvbiB0aGUgVUEgdW5kZXJzdGFuZGluZyB3aGljaA0KbGFuZ3VhZ2Ug
dGFncyBhcmUgc3Bva2VuIGxhbmd1YWdlIHRhZ3MuICBJdCBzZWVtcyB0byBtZSB0aGF0IGENCndv
cmthYmxlIHJ1bGUgaXMgdGhhdCB0aGVyZSBpcyBhbiBhdWRpbyBzdHJlYW0gYW5kIGEgdmlkZW8g
c3RyZWFtIGFuZA0KdGhleSBzcGVjaWZ5IGV4YWN0bHkgdGhlIHNhbWUgbGFuZ3VhZ2UgdGFnIGlu
IHRoZWlyIHJlc3BlY3RpdmUNCmh1bWludGxhbmcgYXR0cmlidXRlcy4gIEluIHRoYXQgY2FzZSwg
aXQgaXMgYSByZXF1ZXN0IGZvciBhIHNwb2tlbg0KbGFuZ3VhZ2Ugd2l0aCBzaW11bHRhbmVvdXMg
dmlkZW8gb2YgdGhlIHNwZWFrZXIsIGFuZCB0aG9zZSByZXF1ZXN0cw0Kc2hvdWxkIGJlIGNvbnNp
ZGVyZWQgc2F0aXNmaWVkIG9ubHkgaWYgYm90aCBzdHJlYW1zIGNhbiBiZQ0KZXN0YWJsaXNoZWQu
DQoNCiogVGhlIGZvbGxvd2luZyB0aHJlZSBpdGVtcyBhcmUgYWRqdXN0bWVudHMgdG8gdGhlIGRl
c2lnbiB3aGljaCBJJ2QNCmxpa2UgdG8ga25vdyBoYXZlIGJlZW4gY29uc2lkZXJlZC4NCg0KQy4g
Imh1bWludGxhbmciIHNlZW1zIGxvbmcgdG8gbWUNCg0KR2l2ZW4gdGhlIGV4Y2Vzc2l2ZSBsZW5n
dGggb2YgU0RQIGluIHByYWN0aWNlLCBpdCBzZWVtcyB0byBtZSB0aGF0IGENCnNob3J0ZXIgYXR0
cmlidXRlIG5hbWUgd291bGQgYmUgZGVzaXJhYmxlLiAgRS5nLiwgImh1bWxhbmciIGFzIHdhcw0K
dXNlZCBpbiBzb21lIHByZXZpb3VzIHZlcnNpb25zLiAgT3IgaXMgdGhlcmUgYSBjb29yZGluYXRl
ZCB1c2FnZSB3aXRoDQpvdGhlciBuYW1lcyBpbiB0aGUgImh1bSpsYW5nIiBwYXR0ZXJuPw0KDQpE
LiBVc2UgdGhlIEFjY2VwdC1MYW5ndWFnZSBzeW50YXgNCg0KSXQgc2VlbXMgdG8gbWUgdGhhdCBp
dCB3b3VsZCBiZXR0ZXIgdG8gdXNlIHRoZSBBY2NlcHQtTGFuZ3VhZ2Ugc3ludGF4DQpmb3IgdGhl
IGF0dHJpYnV0ZSB2YWx1ZXMuICBUaGlzIGFsbG93cyAoMSkgc3BlY2lmaXlpbmcgdGhlIHF1YWxp
dHkgb2YNCmxhbmd1YWdlIGV4cGVyaWVuY2UsIGFsbG93aW5nIGNsZWFyIGRlc2NyaXB0aW9uIG9m
IGJpbGluZ3VhbGlzbSwgKDIpDQphDQp1bmlmaWVkIG1ldGhvZCBvZiBzcGVjaWZ5aW5nIHdoZXRo
ZXIgb3Igbm90IGFyYml0cmFyeSBsYW5ndWFnZXMgYXJlDQphY2NlcHRhYmxlLCBhbmQgKDMpIGFi
YnJldmlhdGluZyBTRFAgZGVzY3JpcHRpb25zLg0KDQpJbiBhIHdheSwgdGhlIGZhY3QgdGhhdCB0
aGUgY3VycmVudCBwcm9wb3NhbCBzZWVtcyB0byByZXF1aXJlIChidXQNCmRvZXMgbm90IGRpcmVj
dGx5IHNwZWNpZnkpIHRoZSBjb29yZGluYXRlZCBhYnNlbmNlL3ByZXNlbmNlIG9mIGFuDQphc3Rl
cmlzayBvbiBhbGwgb2YgdGhlIHJlcGV0aXRpb25zIG9mIGh1bWludGxhbmctc2VuZCBvcg0KaHVt
aW50bGFuZy1yZWN2IGlzIGEgd2FybmluZyB0aGF0IHRoZSBzeW50YXggZG9lc24ndCByZXByZXNl
bnQgdGhlDQpzZW1hbnRpY3MgYXMgd2VsbCBhcyBpdCBtaWdodC4NCg0KRS4gSGF2ZSBhbiBhdHRy
aWJ1dGUgdG8gYWJicmV2aWF0ZSB0aGUgYmlkaXJlY3Rpb25hbGx5LXN5bW1ldHJpYyBjYXNlDQoN
Ck5vdGUgdGhhdCBhbGwgZXhhbXBsZXMgYXJlIGJpZGlyZWN0aW9uYWxseSBzeW1tZXRyaWMsIGFu
ZCB0aGUgdGV4dA0Kc2F5cyB0aGF0IHJlcXVlc3RzIGFuZCByZXNwb25zZXMgU0hPVUxEIGJlIGJp
ZGlyZWN0aW9uYWxseSBzeW1tZXRyaWMuDQpTbyBpdCB3b3VsZCBiZSBhIHZlcnkgdXNlZnVsIGFi
YnJldmlhdGlvbiB0byBkZWZpbmUNCiJodW1pbnRsYW5nPTx2YWx1ZT4iIHRvIGJlIGVxdWl2YWxl
bnQgdG8gdGhlIGNvbWJpbmF0aW9uIG9mDQoiaHVtaW50bGFuZy1zZW5kPTx2YWx1ZT4iIGFuZCAi
aHVtaW50bGFuZy1yZWN2PTx2YWx1ZT4iLg0KDQpDb21iaW5pbmcgcHJvcG9zYWxzIEMsIEQsIGFu
ZCBFLCB0aGUgZXhhbXBsZXMgYmVjb21lDQoNCiAgICAgbT1hdWRpbyA0OTE3MCBSVFAvQVZQIDAN
CiAgICAgYT1odW1sYW5nOmVuDQoNCiAgICAgbT12aWRlbyA1MTM3MiBSVFAvQVZQIDMxIDMyDQog
ICAgIGE9aHVtbGFuZzphc2UsKjtxPTAuMQ0KDQogICAgIG09YXVkaW8gNDkyNTAgUlRQL0FWUCAy
MA0KICAgICBhPWh1bWxhbmc6ZXMsZXU7cT0wLjksZW47cT0wLjgsKjtxPTAuMQ0KDQogICAgIG09
dGV4dCA0NTAyMCBSVFAvQVZQIDEwMyAxMDQNCiAgICAgYT1odW1sYW5nOmdyDQoNCndoaWNoIHJl
cXVpcmVzIGFib3V0IGhhbGYgYXMgbWFueSBjaGFyYWN0ZXJzIGFzIHRoZXkgaGF2ZSBub3cuDQoN
CiogRWRpdG9yaWFsIGNvbW1lbnRzIGFuZCBuaXRzDQoNCkFic3RyYWN0DQoNCiAgVGhpcyBkb2N1
bWVudCBkZXNjcmliZXMgdGhlIG5lZWQgYW5kIGEgc29sdXRpb24gdXNpbmcgbmV3IFNEUA0Kc3Ry
ZWFtDQogIGF0dHJpYnV0ZXMuDQoNCkkgZG9uJ3QgdGhpbmsgdGhlIHRlcm0gInN0cmVhbSBhdHRy
aWJ1dGUiIGlzIHVzZWQgaW4gUkZDIDQ1NjYuDQpJbnN0ZWFkLCBpdCB1c2VzICJtZWRpYSBhdHRy
aWJ1dGUiLg0KDQoxLiAgSW50cm9kdWN0aW9uDQoNCiAgY2FsbGVyIGFuZCBjYWxsZWUga25vdyBl
YWNoIG90aGVyIG9yIHRoZXJlIGlzIGNvbnRleHR1YWwgb3Igb3V0IG9mDQogIGJhbmQgaW5mb3Jt
YXRpb24gZnJvbSB3aGljaCB0aGUgbGFuZ3VhZ2UocykgYW5kIG1lZGlhIG1vZGFsaXRpZXMNCmNh
bg0KDQpJIHRoaW5rIHRoaXMgY29udGV4dCwgaXQncyBwcmVmZXJyZWQgdG8gaHlwaGVuYXRlICJv
dXQtb2YtYmFuZCIgdG8NCm1ha2UgaXQgY2xlYXJseSBiZSBhbiBhZGplY3RpdmUuDQoNCiAgVGhp
cyBhcHByb2FjaCBoYXMgYSBudW1iZXIgb2YgYmVuZWZpdHMsIGluY2x1ZGluZyB0aGF0IGl0IGlz
DQpnZW5lcmljDQogIChhcHBsaWVzIHRvIGFsbCBpbnRlcmFjdGl2ZSBjb21tdW5pY2F0aW9ucyBu
ZWdvdGlhdGVkIHVzaW5nIFNEUCkNCmFuZA0KICBub3QgbGltaXRlZCB0byBlbWVyZ2VuY3kgY2Fs
bHMuDQoNCkkgdGhpbmsgcy9hbmQgbm90IGxpbWl0ZWQgdG8vYW5kIGlzIG5vdCBsaW1pdGVkIHRv
LyByZWFkcyBtb3JlDQpzbW9vdGhseS4NCg0KICBCdXQgaXQgaXMgY2xlYXJseSB1c2VmdWwgaW4g
bWFueSBvdGhlciBjYXNlcy4gIEZvcg0KICBleGFtcGxlLCBzb21lb25lIGNhbGxpbmcgYSBjb21w
YW55IGNhbGwgY2VudGVyIG9yIGEgUHVibGljIFNhZmV0eQ0KICBBbnN3ZXJpbmcgUG9pbnQgKFBT
QVApIHNob3VsZCBiZSBhYmxlIHRvIGluZGljYXRlIGlmIG9uZSBvciBtb3JlDQogIHNwZWNpZmlj
IHNpZ25lZCwgd3JpdHRlbiwgYW5kL29yIHNwb2tlbiBsYW5ndWFnZXMgYXJlIHByZWZlcnJlZCwN
CnRoZQ0KICBjYWxsZWUgc2hvdWxkIGJlIGFibGUgdG8gaW5kaWNhdGUgaXRzIGNhcGFiaWxpdGll
cyBpbiB0aGlzIGFyZWEsDQphbmQNCiAgdGhlIGNhbGwgcHJvY2VlZCB1c2luZyBpbi1jb21tb24g
bGFuZ3VhZ2UocykgYW5kIG1lZGlhIGZvcm1zLg0KDQpJIHRoaW5rIHMvcHJlZmVycmVkLCB0aGUg
Y2FsbGVlL3ByZWZlcnJlZDsgdGhlIGNhbGxlZS8gYmVjYXVzZSB0aGUNCnNlbnRlbmNlIGlzIHRo
ZSBjb25jYXRlbmF0aW9uIG9mIHR3byBzZW50ZW5jZXMuDQoNClBlcmhhcHMgcy9pbi1jb21tb24v
c2hhcmVkLy4NCg0KICBJbmNsdWRpbmcgdGhlIHVzZXIncyBodW1hbiAobmF0dXJhbCkgbGFuZ3Vh
Z2UgcHJlZmVyZW5jZXMgaW4gdGhlDQogIHNlc3Npb24gZXN0YWJsaXNobWVudCBuZWdvdGlhdGlv
biBpcyBpbmRlcGVuZGVudCBvZiB0aGUgdXNlIG9mIGENCiAgcmVsYXkgc2VydmljZSBhbmQgaXMg
dHJhbnNwYXJlbnQgdG8gYSB2b2ljZSBzZXJ2aWNlIHByb3ZpZGVyLg0KDQpJIHRoaW5rIGl0J3Mg
ZXZlbiBicm9hZGVyIHRoYW4gInRyYW5zcGFyZW50IHRvIGEgdm9pY2Ugc2VydmljZQ0KcHJvdmlk
ZXIiIC0tIGl0J3MgdHJhbnNwYXJlbnQgdG8gYW55IHNlcml2aWNlIHByb3ZpZGVyLCBhc3N1bWlu
ZyB0aGF0DQp0aGUgbWVkaWEgYXJlIGxhbmd1YWdlLW5ldXRyYWwuDQoNCiAgSW4gdGhlIGNhc2Ug
b2YgYSBjYWxsIHRvIGUuZy4sIGFuIGFpcmxpbmUsIHRoZSBjYWxsIGNvdWxkIGJlDQogIGF1dG9t
YXRpY2FsbHkgaGFuZGxlZCBieSBhIFNwYW5pc2gtc3BlYWtpbmcgYWdlbnQuDQoNCkkgdGhpbmsg
cy9oYW5kbGVkIGJ5L3JvdXRlZCB0by8gaXMgdGhlIHVzdWFsIHVzYWdlLg0KDQozLiAgRGVzaXJl
ZCBTZW1hbnRpY3MNCg0KICBUaGUgZGVzaXJlZCBzb2x1dGlvbiBpcyBhIG1lZGlhIGF0dHJpYnV0
ZSAocHJlZmVyYWJseSBwZXINCmRpcmVjdGlvbikNCiAgdGhhdCBtYXkgYmUgdXNlZCB3aXRoaW4g
YW4gb2ZmZXIgdG8gaW5kaWNhdGUgdGhlIHByZWZlcnJlZA0KbGFuZ3VhZ2UNCiAgb2YgZWFjaCAo
ZGlyZWN0aW9uIG9mIGEpIG1lZGlhIHN0cmVhbSwgYW5kIHdpdGhpbiBhbiBhbnN3ZXIgdG8NCiAg
aW5kaWNhdGUgdGhlIGFjY2VwdGVkIGxhbmd1YWdlLg0KDQpJbiB0aGlzIG9uZSBpbnN0YW5jZSwg
SSB0aGluayB5b3Ugd2FudCB0byB1c2UgImxhbmd1YWdlKHMpIiB0byBkcml2ZQ0KaG9tZSB0aGF0
IHRoYXQgbXVsdGlwbGUgbGFuZ3VhZ2VzIGNhbiBiZSBzcGVjaWZpZWQ6ICAid2l0aGluIGFuIG9m
ZmVyDQp0byBpbmRpY2F0ZSB0aGUgcHJlZmVycmVkIGxhbmd1YWdlKHMpIi4NCg0KICAoTmVnb3Rp
YXRpbmcgbXVsdGlwbGUgc2ltdWx0YW5lb3VzIGxhbmd1YWdlcyB3aXRoaW4gYSBtZWRpYSBzdHJl
YW0NCmlzDQogIG91dCBvZiBzY29wZSwgYXMgdGhlIGNvbXBsZXhpdHkgb2YgZG9pbmcgc28gb3V0
d2VpZ2hzIHRoZQ0KICB1c2VmdWxuZXNzLikNCg0KWW91IG1pZ2h0IHdhbnQgdG8gc2F5IGluc3Rl
YWQgIihOZWdvdGlhdGluZyBtdWx0aXBsZSBzaW11bHRhbmVvdXMNCmxhbmd1YWdlcyB3aXRoaW4g
YSBtZWRpYSBzdHJlYW0gaXMgb3V0IG9mIHNjb3BlIGZvciB0aGlzIGRvY3VtZW50LikiDQp0byBl
bnN1cmUgdGhhdCBub2JvZHkgZGVjaWRlcyB0byBhcmd1ZSB3aGV0aGVyICJ0aGUgY29tcGxleGl0
eSBvZg0KZG9pbmcgc28gb3V0d2VpZ2hzIHRoZSB1c2VmdWxuZXNzIi4NCg0KNC4gIFRoZSBleGlz
dGluZyAnbGFuZycgYXR0cmlidXRlDQoNCiAgUkZDIDQ1NjYgW1JGQzQ1NjZdIHNwZWNpZmllcyBh
biBhdHRyaWJ1dGUgJ2xhbmcnIHdoaWNoIGFwcGVhcnMNCiAgc2ltaWxhciB0byB3aGF0IGlzIG5l
ZWRlZCBoZXJlLCBidXQgaXMgbm90IHN1ZmZpY2llbnRseSBkZXRhaWxlZA0KZm9yDQogIHVzZSBo
ZXJlLg0KDQoiZm9yIHVzZSBoZXJlIiBpc24ndCBxdWl0ZSByaWdodC4gIE1heWJlICJpcyBub3Qg
c3VmZmljaWVudGx5DQpzcGVjaWZpYw0Kb3IgZmxleGlibGUgdG8gc2F0aXNmeSB0aGUgcmVxdWly
ZW1lbnRzIi4NCg0KICBJbiBhZGRpdGlvbiwgaXQgaXMgbm90IG1lbnRpb25lZCBpbiBbUkZDMzI2
NF0NCg0KIml0IiBpcyBzb21ld2hhdCBhbWJpZ3VvdXMgaGVyZSwgcGVyaGFwcyBjaGFuZ2UgdG8g
InRoZSAnbGFuZycNCmF0dHJpYnV0ZSIuDQoNCjUuICBQcm9wb3NlZCBTb2x1dGlvbg0KDQpQZXJo
YXBzIC9Qcm9wb3NlZCBTb2x1dGlvbi9Tb2x1dGlvbi8sIHNpbmNlIG9uY2UgdGhpcyBkcmFmdCBp
cw0KYXBwcm92ZWQsIGl0IGJlY29tZXMgdGhlIHNvbHV0aW9uLg0KDQo1LjIuICBOZXcgJ2h1bWlu
dGxhbmctc2VuZCcgYW5kICdodW1pbnRsYW5nLXJlY3YnIGF0dHJpYnV0ZXMNCg0KICAgICBhPWh1
bWludGxhbmctc2VuZDo8bGFuZ3VhZ2UgdGFnPg0KICAgICBhPWh1bWludGxhbmctcmVjdjo8bGFu
Z3VhZ2UgdGFnPg0KDQpUaGlzIGlzIHByZXNlbnRlZCBhcyB0aGUgZ2VuZXJpYyBmb3JtIG9mIHRo
ZSBhdHRyaWJ1dGVzLCBidXQgdGhlcmUgaXMNCm5vIGluZGljYXRpb24gb2YgdGhlIHBvc2libGUg
YXN0ZXJpc2suDQoNCiAgVGhlIHZhbHVlcyBjb25zdGl0dXRlIGEgbGlzdCBvZiBsYW5ndWFnZXMN
CiAgaW4gcHJlZmVyZW5jZSBvcmRlciAoZmlyc3QgaXMgbW9zdCBwcmVmZXJyZWQpLg0KDQoiVGhl
IHZhbHVlcyIgaXNuJ3QgdmVyeSBjbGVhciwgYmVjYXVzZSB0aGUgdmFsdWVzIGFyZSBpbiBzdWNj
ZXNzaXZlDQphdHRyaWJ1dGVzLiAgWW91IHdhbnQgdG8gc2F5IHNvbWV0aGluZyBsaWtlICJUaGUg
c2VxdWVuY2Ugb2YgdmFsdWVzDQppbg0KdGhlIG9jY3VycmVuY2VzIG9mIG9uZSBvZiB0aGVzZSBh
dHRyaWJ1dGVzIGNvbnN0aXR1dGVzIC4uLiIuDQpIb3dldmVyLA0Kc2VlIHRoZSB0ZWNobmljYWwg
Y29tbWVudHMgYWJvdmUuDQoNCiAgV2hlbiBwbGFjaW5nIGFuIGVtZXJnZW5jeSBjYWxsLCBhbmQg
aW4gYW55IG90aGVyIGNhc2Ugd2hlcmUgdGhlDQogIGxhbmd1YWdlIGNhbm5vdCBiZSBhc3N1bWVk
IGZyb20gY29udGV4dCwgZWFjaCBtZWRpYSBzdHJlYW0gaW4gYW4NCiAgb2ZmZXIgcHJpbWFyaWx5
IGludGVuZGVkIGZvciBodW1hbiBsYW5ndWFnZSBjb21tdW5pY2F0aW9uIFNIT1VMRA0KICBzcGVj
aWZ5IGJvdGggKG9yIGluIHNvbWUgY2FzZXMsIG9uZSBvZikgdGhlICdodW1pbnRsYW5nLXNlbmQn
IGFuZA0KICAnaHVtaW50bGFuZy1yZWN2JyBhdHRyaWJ1dGVzLg0KDQpQcm9iYWJseSBzL2Fzc3Vt
ZWQvaW5mZXJyZWQvLg0KDQpDb3VsZCB5b3UgYmUgbW9yZSBhY2N1cmF0ZSBieQ0Kcy9vciBpbiBz
b21lIGNhc2VzL29yIGZvciB1bmlkaXJlY3Rpb25hbCBzdHJlYW1zLz8NCg0KNS4zLiAgQWR2aXNv
cnkgdnMgUmVxdWlyZWQNCg0KICBUaGUgbWVjaGFuaXNtIGZvciBpbmRpY2F0aW5nIHRoaXMgcHJl
ZmVyZW5jZSBpcyB0aGF0LCBpbiBhbiBvZmZlciwNCmlmDQogIHRoZSBsYXN0IGNoYXJhY3RlciBv
ZiBhbnkgb2YgdGhlICdodW1pbnRsYW5nLXJlY3YnIG9yICdodW1pbnRsYW5nLQ0KICBzZW5kJyB2
YWx1ZXMgaXMgYW4gYXN0ZXJpc2ssIHRoaXMgaW5kaWNhdGVzIGEgcmVxdWVzdCB0byBub3QgZmFp
bA0KdGhlDQogIGNhbGwgKHNpbWlsYXIgdG8gU0lQIEFjY2VwdC1MYW5ndWFnZSBzeW50YXgpLiAg
RWl0aGVyIHdheSwgdGhlDQpjYWxsZWQNCiAgcGFydHkgTUFZIGlnbm9yZSB0aGlzLCBlLmcuLCBm
b3IgdGhlIGVtZXJnZW5jeSBzZXJ2aWNlcyB1c2UgY2FzZSwNCmENCiAgUFNBUCB3aWxsIGxpa2Vs
eSBub3QgZmFpbCB0aGUgY2FsbC4NCg0KVGhlIGNvbnN0cnVjdGlvbiBvZiB0aGlzIHBhcmFncmFw
aCBpc24ndCBxdWl0ZSBjb21wbGV0ZS4gIEl0IHNheXMNCnRoYXQNCmlmIGFuIGFzdGVyaXNrIGlz
IHByZXNlbnQsIGEgcmVxdWVzdCBzaG91bGRuJ3QgZmFpbCwgYnV0IGl0IGRvZXNuJ3QNCnNheSB0
aGF0IGlmIG5vIGFzdGVyaXNrIGlzIHByZXNlbnQsIGEgcmVxdWVzdCBzaG91bGQgZmFpbCBpZiB0
aGVyZSBpcw0Kbm8gbGFuZ3VhZ2UgbWF0Y2guICBBbmQgaXQncyB0aGUgbGF0dGVyIGNvbmRpdGlv
biB0aGF0IG1ha2VzIHRoZQ0Kc2Vjb25kIHNlbnRlbmNlIG1lYW5pbmdmdWwuICBTbyBJIHRoaW5r
IHlvdSB3YW50IHRvIGluc2VydCBiZXR3ZWVuDQp0aGUNCnR3byBzZW50ZW5jZXMgb25lIHJlZ2Fy
ZGluZyB0aGUgYWJzZW5jZSBvZiBhbiBhc3Rlcmlzay4NCg0KNS41LiAgRXhhbXBsZXMNCg0KR2l2
ZW4gdGhhdCB0aGUgY29tYmluZWQgYXVkaW8vdmlkZW8gbWVjaGFuaXNtIGlzIHRoZSBvbmx5DQpp
cnJlZ3VsYXJpdHkNCmluIHRoaXMgc3lzdGVtLCB0aGVyZSBvdWdodCB0byBiZSBhbiBleGFtcGxl
IG9mIGl0LiAgRS5nLiwNCg0KICBBbiBleGFtcGxlIG9mIGEgc3VwcGxlbWVudGFsIHZpZGVvIHN0
cmVhbSB3aXRoIGEgc3Bva2VuIGxhbmd1YWdlDQogIGF1ZGlvIHN0cmVhbToNCg0KICAgICBtPXZp
ZGVvIDUxMzcyIFJUUC9BVlAgMzEgMzINCiAgICAgYT1odW1pbnRsYW5nLXNlbmQ6ZW4NCiAgICAg
YT1odW1pbnRsYW5nLXJlY3Y6ZW4NCg0KICAgICBtPWF1ZGlvIDQ5MjUwIFJUUC9BVlAgMjANCiAg
ICAgYT1odW1pbnRsYW5nLXNlbmQ6ZW4NCiAgICAgYT1odW1pbnRsYW5nLXJlY3Y6ZW4NCg0KNi4g
IElBTkEgQ29uc2lkZXJhdGlvbnMNCg0KICAgICBodW1pbnRsYW5nLXZhbHVlID0gIExhbmd1YWdl
LVRhZyBbIGFzdGVyaXNrIF0NCiAgICAgICAgICAgICAgICAgICAgICAgICA7IExhbmd1YWdlLVRh
ZyBkZWZpbmVkIGluIFJGQyA1NjQ2DQogICAgIGFzdGVyaXNrICAgICAgICAgPSAgIioiDQoNCnMv
TGFuZ3VhZ2UtVGFnIGRlZmluZWQgaW4gUkZDIDU2NDYvTGFuZ3VhZ2UtVGFnIGFzIGRlZmluZWQg
aW4gUkZDDQo1NjQ2Lw0KDQpCdXQgcGVyaGFwcyBhbHNvIHMvUkZDIDU2NDYvQkNQIDQ3Lywgd2hp
Y2ggZW5zdXJlcyB0aGF0ICJodW1pbnRsYW5nIg0KdHJhY2tzIHRoZSBjdXJyZW50IHZlcnNpb24g
b2YgbGFuZ3VhZ2UgdGFncy4NCg0KQXBwZW5kaXggQS4gIEhpc3RvcmljIEFsdGVybmF0aXZlIFBy
b3Bvc2FsOiBDYWxsZXItcHJlZnMNCg0KICBUaGlzDQogIHJlc3VsdHMgaW4gYSBtb3JlIGZyYWdp
bGUgc29sdXRpb24gc2luY2UgdGhlIG1lZGlhIG1vZGFsaXR5IGFuZA0KICBsYW5ndWFnZSB3b3Vs
ZCBiZSBuZWdvdGlhdGVkIHVzaW5nIFNJUCwgYW5kIHRoZW4gdGhlIHNwZWNpZmljDQptZWRpYQ0K
ICBmb3JtYXRzICh3aGljaCBpbmhlcmVudGx5IGluY2x1ZGUgdGhlIG1vZGFsaXR5KSB3b3VsZCBi
ZQ0KbmVnb3RpYXRlZA0KICBhdCBhIGRpZmZlcmVudCBsZXZlbCAodHlwaWNhbGx5IFNEUCwgZXNw
ZWNpYWxseSBpbiB0aGUgZW1lcmdlbmN5DQogIGNhbGxpbmcgY2FzZXMpLCBtYWtpbmcgaXQgZWFz
aWVyIHRvIGhhdmUgbWlzbWF0Y2hlcyAoc3VjaCBhcyB3aGVyZQ0KICB0aGUgbWVkaWEgbW9kYWxp
dHkgbmVnb3RpYXRlZCBpbiBTSVAgZG9uJ3QgbWF0Y2ggd2hhdCB3YXMNCm5lZ290aWF0ZWQNCiAg
dXNpbmcgU0RQKS4NCg0KInRoZSBtZWRpYSBtb2RhbGl0eSBhbmQgbGFuZ3VhZ2Ugd291bGQgYmUg
bmVnb3RpYXRlZCB1c2luZyBTSVAiIGlzbid0DQpxdWl0ZSB0aGUgcmlnaHQgd2F5IHRvIHNheSBp
dCBiZWNhdXNlIFNJUCBpc24ndCBleHBsaWNpdGx5DQpuZWdvdGlhdGluZw0KdGhlIG1vZGFsaXR5
LiAgQmV0dGVyIHdvdWxkIGJlDQoNCiAgLi4uIHRoZSBsYW5ndWFnZSAoYW5kIGJ5IGltcGxpY2F0
aW9uIHRoZSBtZWRpYSBtb2RhbGl0eSkgd291bGQgYmUNCiAgbmVnb3RpYXRlZCB1c2luZyBTSVAs
IGFuZCB0aGVuIHRoZSBzcGVjaWZpYyBtZWRpYSAod2hpY2gNCmluaGVyZW50bHkNCiAgaW5jbHVk
ZSB0aGUgbW9kYWxpdGllcyBhbmQgZm9ybWF0cykgd291bGQgYmUgbmVnb3RpYXRlZCBhdCBhDQog
IGRpZmZlcmVudCBsZXZlbCAuLi4NCg0KW0VORF0NCg0KDQoNCg0KVGhpcyBlbWFpbCBhbmQgaXRz
IGF0dGFjaG1lbnRzIGFyZSBpbnRlbmRlZCBmb3IgdGhlIGFib3ZlIG5hbWVkIG9ubHkgYW5kIG1h
eSBiZSBjb25maWRlbnRpYWwuIElmIHRoZXkgaGF2ZSBjb21lIHRvIHlvdSBpbiBlcnJvciB5b3Ug
bXVzdCB0YWtlIG5vIGFjdGlvbiBiYXNlZCBvbiB0aGVtLCBub3IgbXVzdCB5b3UgY29weSBvciBz
aG93IHRoZW0gdG8gYW55b25lOyBwbGVhc2UgcmVwbHkgdG8gdGhpcyBlbWFpbCBvciBjYWxsICs0
NCAyMDcgMzU2IDA2MDAgYW5kIGhpZ2hsaWdodCB0aGUgZXJyb3IuDQo=

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

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy
ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGkgRGFsZSEgTWFueSB0aGFua3Mg
Zm9yIHRoZXNlIGNvbW1lbnRzLCBhcyBvbmUgb2YgdGhlIFNMSU0gY2hhaXJzIEnigJlsbCB3b3Jr
IG9uIGdldHRpbmcgc29tZSBhbnN3ZXJzIHRvIHlvdSBvciBJ4oCZbGwgcmVxdWVzdCB0aGUgYXV0
aG9yIG9yIG9uZSBvZiB0aGUgU0xJTSBhY3RpdmUgcGFydGljaXBhbnRzIHRvIHJlc3BvbmQuJm5i
c3A7DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5C
ZXJuYXJkLCBSYW5kYWxsIGFuZCBTTElNIC0gc2VlIGJlbG93IHJlIERhbGXigJlzIHBvaW50cy4m
bmJzcDs8YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0K
PGRpdiBjbGFzcz0iIj4qKioqIEEuIENhbGwgZmFpbHVyZSAqKioqPC9kaXY+DQo8ZGl2IGNsYXNz
PSIiPlJhbmRhbGwgb3IgQmVybmFyZCBjYW4geW91IHJlc3BvbmQgdG8gdGhpcz8gSSBpbWFnaW5l
IHRoZSBVQSBjYWxsIGZhaWx1cmUgbWV0aG9kIGlzIFVBIHNwZWNpZmljLCBidXQgaWYgdGhlcmUg
aXMgYSBjbGFzaCB3aXRoIFNJUCBsZXZlbCBjYWxsIGZhaWwgdGhlbiB0aGlzIHNob3VsZCBiZSBh
ZGRyZXNzZWQuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRp
diBjbGFzcz0iIj4qKioqJm5ic3A7Qi4gQXVkaW8vVmlkZW8gY29vcmRpbmF0aW9uICoqKio8L2Rp
dj4NCjxkaXYgY2xhc3M9IiI+SSBiZWxpZXZlIHRoZSB0aGVvcnkgYmVoaW5kIHRoZSBjdXJyZW50
IGRyYWZ0IGlzIHRoYXQgdGhlIHNwb2tlbiBhbmQgdmlkZW8gc3RyZWFtcyB3aWxsIGJlIGRpZmZl
cmVudCBpbiB0aGUgY2FzZXMgb2Ygc3VjaCB0aGluZ3MgYXMgc2lnbiBsYW5ndWFnZS4gVmlkZW8g
Y291bGQgdGhlcmVmb3JlIGJlIHNpZ24gYW5kIGF1ZGlvIHdvdWxkIGJlIGEgc3Bva2VuIGxhbmd1
YWdlLiBJ4oCZbSBub3Qgc3VyZSBpZiB0aGUgc3VnZ2VzdGlvbg0KIGhlIHNhdGlzZmllcyB0aGlz
IGNhc2U/PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBj
bGFzcz0iIj4qKioqIEMuICZxdW90O2h1bWludGxhbmcmcXVvdDsgc2VlbXMgbG9uZyB0byBtZSAq
KioqPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkJlcm5hcmQgLSBJIGRvbuKAmXQgc2VlIHRoZSBpc3N1
ZSB3aXRoIHNob3J0ZW5pbmcgaHVtaW50bGFuZywgYnV0IHRoZSBncm91cCBtaWdodC4gSSBzdWdn
ZXN0IHdlIHRocm93IHRoaXMgdG8gdGhlIGdyb3VwIGZvciBkaXNjdXNzaW9uLjwvZGl2Pg0KPGRp
diBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+KioqKiBELiBV
c2UgdGhlIEFjY2VwdC1MYW5ndWFnZSBzeW50YXggKioqKjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5S
YW5kYWxsIGFuZCBCZXJuYXJkIC0gaXMgdGhpcyBhbiBhY2NlcHRhYmxlIGNoYW5nZT8gT3Igb25l
IHdlIG5lZWQgdG8gZGlzY3VzcyBmdXJ0aGVyLiBTZWVtcyBsaWtlIGEgcmVhc29uYWJsZSByZXF1
ZXN0LCBidXQgYWxzbyBhIGxhcmdlciBjaGFuZ2UsIHdoaWNoIGlzIHdoeSBJIGFzayE8L2Rpdj4N
CjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPioqKiog
RS4gSGF2ZSBhbiBhdHRyaWJ1dGUgdG8gYWJicmV2aWF0ZSB0aGUgYmlkaXJlY3Rpb25hbGx5LXN5
bW1ldHJpYyBjYXNlICoqKio8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SSBkbyBub3QgcmVtZW1iZXIg
dXMgaGF2aW5nIHRoaXMgZGlzY3Vzc2lvbiB3aXRoaW4gdGhlIGdyb3VwLCBhbHRob3VnaCBpdCBt
YXkgaGF2ZSBvY2N1cnJlZCBiZWZvcmUgSSBiZWNhbWUgY2hhaXIuPC9kaXY+DQo8ZGl2IGNsYXNz
PSIiPlJhbmRhbGwsIEJyaWFuIG9yIEJlcm5hcmQgLSBoYXMgdGhpcyBpZGVhIGJlZW4gZGlzY3Vz
c2VkIGJlZm9yZT8gSWYgc28sIGNhbiBvbmUgb2YgeW91IHJlc3BvbmQgd2l0aCBhbiBleHBsYW5h
dGlvbiBhcyB0byB3aHkgd2UgaGF2ZW7igJl0IGRvbmUgdGhpcz88L2Rpdj4NCjxkaXYgY2xhc3M9
IiI+PGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4qKioqJm5ic3A7RWRpdG9yaWFsIGNvbW1l
bnRzIGFuZCBuaXRzICoqKioqPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlJhbmRhbGwgLSBjYW4geW91
IHRha2UgYSBsb29rIHRocm91Z2ggRGFsZeKAmXMgZWRpdG9yaWFsIGNvbW1lbnRzIGFuZCBzaG91
dCBpZiB0aGVyZSBpcyBhbnkgcHJvYmxlbXMgd2l0aCB0aGVzZSBzdWdnZXN0aW9uczsgaWYgZXZl
cnl0aGluZyBpcyBvayBwbGVhc2UgbWFrZSB0aGUgY2hhbmdlcy48L2Rpdj4NCjxkaXYgY2xhc3M9
IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRoYW5rcyBhbGwhPC9kaXY+
DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1m
YW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZv
bnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFj
aW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVu
dDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dz
OiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRv
OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7Ij4NCjxiciBjbGFzcz0iIj4NCk5hdGFz
aGEgUm9vbmV5IHwgSW50ZXJuZXQgRW5naW5lZXJpbmcmbmJzcDtEaXJlY3RvciB8IEludGVybmV0
IGFuZCBXZWIgVGVhbSB8Jm5ic3A7VGVjaG5vbG9neSB8IEdTTUEgfCZuYnNwOzxhIGhyZWY9Im1h
aWx0bzpucm9vbmV5QGdzbWEuY29tIiBjbGFzcz0iIj5ucm9vbmV5QGdzbWEuY29tPC9hPiZuYnNw
O3wgJiM0Mzs0NCAoMCkgNzczMCAyMTkmbmJzcDs3NjUgfCBAdGhpc05hdGFzaGEgfCBTa3lwZTom
bmJzcDs8YSBocmVmPSJtYWlsdG86bnJvb25leUBnc20ub3JnIiBjbGFzcz0iIj5ucm9vbmV5QGdz
bS5vcmc8L2E+PC9kaXY+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxkaXY+DQo8YmxvY2txdW90
ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gMTggRmViIDIwMTcsIGF0
IDAyOjMyLCBEYWxlIFdvcmxleSAmbHQ7PGEgaHJlZj0ibWFpbHRvOndvcmxleUBhcmlhZG5lLmNv
bSIgY2xhc3M9IiI+d29ybGV5QGFyaWFkbmUuY29tPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIg
Y2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYg
Y2xhc3M9IiI+UmV2aWV3ZXI6IERhbGUgV29ybGV5PGJyIGNsYXNzPSIiPg0KUmV2aWV3IHJlc3Vs
dDogUmVhZHkgd2l0aCBOaXRzPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KSSBhbSB0aGUg
YXNzaWduZWQgR2VuLUFSVCByZXZpZXdlciBmb3IgdGhpcyBkcmFmdC4gJm5ic3A7VGhlIEdlbmVy
YWwgQXJlYTxiciBjbGFzcz0iIj4NClJldmlldyBUZWFtIChHZW4tQVJUKSByZXZpZXdzIGFsbCBJ
RVRGIGRvY3VtZW50cyBiZWluZyBwcm9jZXNzZWQ8YnIgY2xhc3M9IiI+DQpieSB0aGUgSUVTRyBm
b3IgdGhlIElFVEYgQ2hhaXIuICZuYnNwO1BsZWFzZSB0cmVhdCB0aGVzZSBjb21tZW50cyBqdXN0
PGJyIGNsYXNzPSIiPg0KbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLjxiciBjbGFz
cz0iIj4NCjxiciBjbGFzcz0iIj4NCkZvciBtb3JlIGluZm9ybWF0aW9uLCBwbGVhc2Ugc2VlIHRo
ZSBGQVEgYXQ8YnIgY2xhc3M9IiI+DQombHQ7PGEgaHJlZj0iaHR0cDovL3dpa2kudG9vbHMuaWV0
Zi5vcmcvYXJlYS9nZW4vdHJhYy93aWtpL0dlbkFydGZhcSIgY2xhc3M9IiI+aHR0cDovL3dpa2ku
dG9vbHMuaWV0Zi5vcmcvYXJlYS9nZW4vdHJhYy93aWtpL0dlbkFydGZhcTwvYT4mZ3Q7LjxiciBj
bGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkRvY3VtZW50OiAmbmJzcDtkcmFmdC1pZXRmLXNsaW0t
bmVnb3RpYXRpbmctaHVtYW4tbGFuZ3VhZ2UtMDY8YnIgY2xhc3M9IiI+DQpSZXZpZXdlcjogJm5i
c3A7RGFsZSBSLiBXb3JsZXk8YnIgY2xhc3M9IiI+DQpSZXZpZXcgRGF0ZTogJm5ic3A7MjAxNy0w
Mi0xNzxiciBjbGFzcz0iIj4NCklFVEYgTEMgRW5kIERhdGU6ICZuYnNwOzIwMTctMDItMjA8YnIg
Y2xhc3M9IiI+DQpJRVNHIFRlbGVjaGF0IGRhdGU6ICZuYnNwO1t1bmtub3duXTxiciBjbGFzcz0i
Ij4NCjxiciBjbGFzcz0iIj4NClN1bW1hcnk6PGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7VGhpcyBkcmFmdCBpcyBiYXNpY2FsbHkgcmVhZHkgZm9yIHB1
YmxpY2F0aW9uLCBidXQgaGFzIG5pdHM8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDt0aGF0IHNob3VsZCBiZSBmaXhlZCBiZWZvcmUgcHVibGljYXRpb24u
PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KKiBUZWNobmljYWwgY29tbWVudHM8YnIgY2xh
c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpBLiBDYWxsIGZhaWx1cmU8YnIgY2xhc3M9IiI+DQo8YnIg
Y2xhc3M9IiI+DQpJZiBhIGNhbGwgZmFpbHMgZHVlIHRvIG5vIGF2YWlsYWJsZSBsYW5ndWFnZSBt
YXRjaCwgaW4gd2hhdCB3YXkocyk8YnIgY2xhc3M9IiI+DQpkb2VzIGl0IGZhaWw/ICZuYnNwO1Nl
Y3Rpb24gNS4zIHNheXM8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDtJ
ZiBzdWNoIGFuIG9mZmVyIGlzIHJlY2VpdmVkLCB0aGUgcmVjZWl2ZXIgTUFZPGJyIGNsYXNzPSIi
Pg0KJm5ic3A7Jm5ic3A7cmVqZWN0IHRoZSBtZWRpYSwgaWdub3JlIHRoZSBsYW5ndWFnZSBzcGVj
aWZpZWQsIG9yIGF0dGVtcHQgdG88YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDtpbnRlcnByZXQg
dGhlIGludGVudDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkJ1dCBJIHN1c3BlY3QgaXQn
cyBhbHNvIGFsbG93ZWQgZm9yIHRoZSBVQVMgdG8gZmFpbCB0aGUgY2FsbCBhdCB0aGU8YnIgY2xh
c3M9IiI+DQpTSVAgbGV2ZWwuICZuYnNwO1doZXRoZXIgb3Igbm90IHRoYXQgaXMgYWxsb3dlZCAo
b3IgYXQgbGVhc3QgZW52aXNpb25lZCk8YnIgY2xhc3M9IiI+DQpzaG91bGQgYmUgZGVzY3JpYmVk
LiAmbmJzcDtBbmQgd2hhdCByZXNwb25zZSBjb2RlKHMpL3dhcm4tY29kZShzKSBzaG91bGQ8YnIg
Y2xhc3M9IiI+DQpiZTxiciBjbGFzcz0iIj4NCnVzZWQgZm9yIHRoYXQ/PGJyIGNsYXNzPSIiPg0K
PGJyIGNsYXNzPSIiPg0KQi4gQXVkaW8vVmlkZW8gY29vcmRpbmF0aW9uPGJyIGNsYXNzPSIiPg0K
PGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7NS4yLiAmbmJzcDtOZXcgJ2h1bWludGxhbmctc2Vu
ZCcgYW5kICdodW1pbnRsYW5nLXJlY3YnIGF0dHJpYnV0ZXM8YnIgY2xhc3M9IiI+DQo8YnIgY2xh
c3M9IiI+DQombmJzcDsmbmJzcDtOb3RlIHRoYXQgd2hpbGUgc2lnbmVkIGxhbmd1YWdlIHRhZ3Mg
YXJlIHVzZWQgd2l0aCBhIHZpZGVvIHN0cmVhbTxiciBjbGFzcz0iIj4NCnRvPGJyIGNsYXNzPSIi
Pg0KJm5ic3A7Jm5ic3A7aW5kaWNhdGUgc2lnbiBsYW5ndWFnZSwgYSBzcG9rZW4gbGFuZ3VhZ2Ug
dGFnIGZvciBhIHZpZGVvIHN0cmVhbTxiciBjbGFzcz0iIj4NCmluPGJyIGNsYXNzPSIiPg0KJm5i
c3A7Jm5ic3A7cGFyYWxsZWwgd2l0aCBhbiBhdWRpbyBzdHJlYW0gd2l0aCB0aGUgc2FtZSBzcG9r
ZW4gbGFuZ3VhZ2UgdGFnPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7aW5kaWNhdGVzIGEgcmVx
dWVzdCBmb3IgYSBzdXBwbGVtZW50YWwgdmlkZW8gc3RyZWFtIHRvIHNlZSB0aGU8YnIgY2xhc3M9
IiI+DQombmJzcDsmbmJzcDtzcGVha2VyLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkFu
ZCB0aGVyZSdzIGEgc2ltaWxhciBwYXJhZ3JhcGggaW4gNS40OjxiciBjbGFzcz0iIj4NCjxiciBj
bGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPiZuYnNwOyZuYnNwO0Eg
c3Bva2VuIGxhbmd1YWdlIHRhZyBmb3IgYSB2aWRlbyBzdHJlYW0gaW4gY29uanVuY3Rpb24gd2l0
aCBhbjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCmF1ZGlvPGJyIGNsYXNzPSIiPg0KPGJs
b2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+Jm5ic3A7Jm5ic3A7c3RyZWFtIHdpdGggdGhl
IHNhbWUgbGFuZ3VhZ2UgbWlnaHQgaW5kaWNhdGUgYSByZXF1ZXN0IGZvcjxiciBjbGFzcz0iIj4N
CiZuYnNwOyZuYnNwO3N1cHBsZW1lbnRhbCB2aWRlbyB0byBzZWUgdGhlIHNwZWFrZXIuPGJyIGNs
YXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KSSB0aGluayB0aGlzIG1lY2hh
bmlzbSBuZWVkcyB0byBiZSBkZXNjcmliZWQgbW9yZSBleGFjdGx5LCBhbmQgaW48YnIgY2xhc3M9
IiI+DQpwYXJ0aWN1bGFyLCBpdCBzaG91bGQgbm90IGRlcGVuZCBvbiB0aGUgVUEgdW5kZXJzdGFu
ZGluZyB3aGljaDxiciBjbGFzcz0iIj4NCmxhbmd1YWdlIHRhZ3MgYXJlIHNwb2tlbiBsYW5ndWFn
ZSB0YWdzLiAmbmJzcDtJdCBzZWVtcyB0byBtZSB0aGF0IGE8YnIgY2xhc3M9IiI+DQp3b3JrYWJs
ZSBydWxlIGlzIHRoYXQgdGhlcmUgaXMgYW4gYXVkaW8gc3RyZWFtIGFuZCBhIHZpZGVvIHN0cmVh
bSBhbmQ8YnIgY2xhc3M9IiI+DQp0aGV5IHNwZWNpZnkgZXhhY3RseSB0aGUgc2FtZSBsYW5ndWFn
ZSB0YWcgaW4gdGhlaXIgcmVzcGVjdGl2ZTxiciBjbGFzcz0iIj4NCmh1bWludGxhbmcgYXR0cmli
dXRlcy4gJm5ic3A7SW4gdGhhdCBjYXNlLCBpdCBpcyBhIHJlcXVlc3QgZm9yIGEgc3Bva2VuPGJy
IGNsYXNzPSIiPg0KbGFuZ3VhZ2Ugd2l0aCBzaW11bHRhbmVvdXMgdmlkZW8gb2YgdGhlIHNwZWFr
ZXIsIGFuZCB0aG9zZSByZXF1ZXN0czxiciBjbGFzcz0iIj4NCnNob3VsZCBiZSBjb25zaWRlcmVk
IHNhdGlzZmllZCBvbmx5IGlmIGJvdGggc3RyZWFtcyBjYW4gYmU8YnIgY2xhc3M9IiI+DQplc3Rh
Ymxpc2hlZC48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQoqIFRoZSBmb2xsb3dpbmcgdGhy
ZWUgaXRlbXMgYXJlIGFkanVzdG1lbnRzIHRvIHRoZSBkZXNpZ24gd2hpY2ggSSdkPGJyIGNsYXNz
PSIiPg0KbGlrZSB0byBrbm93IGhhdmUgYmVlbiBjb25zaWRlcmVkLjxiciBjbGFzcz0iIj4NCjxi
ciBjbGFzcz0iIj4NCkMuICZxdW90O2h1bWludGxhbmcmcXVvdDsgc2VlbXMgbG9uZyB0byBtZTxi
ciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkdpdmVuIHRoZSBleGNlc3NpdmUgbGVuZ3RoIG9m
IFNEUCBpbiBwcmFjdGljZSwgaXQgc2VlbXMgdG8gbWUgdGhhdCBhPGJyIGNsYXNzPSIiPg0Kc2hv
cnRlciBhdHRyaWJ1dGUgbmFtZSB3b3VsZCBiZSBkZXNpcmFibGUuICZuYnNwO0UuZy4sICZxdW90
O2h1bWxhbmcmcXVvdDsgYXMgd2FzPGJyIGNsYXNzPSIiPg0KdXNlZCBpbiBzb21lIHByZXZpb3Vz
IHZlcnNpb25zLiAmbmJzcDtPciBpcyB0aGVyZSBhIGNvb3JkaW5hdGVkIHVzYWdlIHdpdGg8YnIg
Y2xhc3M9IiI+DQpvdGhlciBuYW1lcyBpbiB0aGUgJnF1b3Q7aHVtKmxhbmcmcXVvdDsgcGF0dGVy
bj88YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpELiBVc2UgdGhlIEFjY2VwdC1MYW5ndWFn
ZSBzeW50YXg8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpJdCBzZWVtcyB0byBtZSB0aGF0
IGl0IHdvdWxkIGJldHRlciB0byB1c2UgdGhlIEFjY2VwdC1MYW5ndWFnZSBzeW50YXg8YnIgY2xh
c3M9IiI+DQpmb3IgdGhlIGF0dHJpYnV0ZSB2YWx1ZXMuICZuYnNwO1RoaXMgYWxsb3dzICgxKSBz
cGVjaWZpeWluZyB0aGUgcXVhbGl0eSBvZjxiciBjbGFzcz0iIj4NCmxhbmd1YWdlIGV4cGVyaWVu
Y2UsIGFsbG93aW5nIGNsZWFyIGRlc2NyaXB0aW9uIG9mIGJpbGluZ3VhbGlzbSwgKDIpPGJyIGNs
YXNzPSIiPg0KYTxiciBjbGFzcz0iIj4NCnVuaWZpZWQgbWV0aG9kIG9mIHNwZWNpZnlpbmcgd2hl
dGhlciBvciBub3QgYXJiaXRyYXJ5IGxhbmd1YWdlcyBhcmU8YnIgY2xhc3M9IiI+DQphY2NlcHRh
YmxlLCBhbmQgKDMpIGFiYnJldmlhdGluZyBTRFAgZGVzY3JpcHRpb25zLjxiciBjbGFzcz0iIj4N
CjxiciBjbGFzcz0iIj4NCkluIGEgd2F5LCB0aGUgZmFjdCB0aGF0IHRoZSBjdXJyZW50IHByb3Bv
c2FsIHNlZW1zIHRvIHJlcXVpcmUgKGJ1dDxiciBjbGFzcz0iIj4NCmRvZXMgbm90IGRpcmVjdGx5
IHNwZWNpZnkpIHRoZSBjb29yZGluYXRlZCBhYnNlbmNlL3ByZXNlbmNlIG9mIGFuPGJyIGNsYXNz
PSIiPg0KYXN0ZXJpc2sgb24gYWxsIG9mIHRoZSByZXBldGl0aW9ucyBvZiBodW1pbnRsYW5nLXNl
bmQgb3I8YnIgY2xhc3M9IiI+DQpodW1pbnRsYW5nLXJlY3YgaXMgYSB3YXJuaW5nIHRoYXQgdGhl
IHN5bnRheCBkb2Vzbid0IHJlcHJlc2VudCB0aGU8YnIgY2xhc3M9IiI+DQpzZW1hbnRpY3MgYXMg
d2VsbCBhcyBpdCBtaWdodC48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpFLiBIYXZlIGFu
IGF0dHJpYnV0ZSB0byBhYmJyZXZpYXRlIHRoZSBiaWRpcmVjdGlvbmFsbHktc3ltbWV0cmljIGNh
c2U8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpOb3RlIHRoYXQgYWxsIGV4YW1wbGVzIGFy
ZSBiaWRpcmVjdGlvbmFsbHkgc3ltbWV0cmljLCBhbmQgdGhlIHRleHQ8YnIgY2xhc3M9IiI+DQpz
YXlzIHRoYXQgcmVxdWVzdHMgYW5kIHJlc3BvbnNlcyBTSE9VTEQgYmUgYmlkaXJlY3Rpb25hbGx5
IHN5bW1ldHJpYy48YnIgY2xhc3M9IiI+DQpTbyBpdCB3b3VsZCBiZSBhIHZlcnkgdXNlZnVsIGFi
YnJldmlhdGlvbiB0byBkZWZpbmU8YnIgY2xhc3M9IiI+DQomcXVvdDtodW1pbnRsYW5nPSZsdDt2
YWx1ZSZndDsmcXVvdDsgdG8gYmUgZXF1aXZhbGVudCB0byB0aGUgY29tYmluYXRpb24gb2Y8YnIg
Y2xhc3M9IiI+DQomcXVvdDtodW1pbnRsYW5nLXNlbmQ9Jmx0O3ZhbHVlJmd0OyZxdW90OyBhbmQg
JnF1b3Q7aHVtaW50bGFuZy1yZWN2PSZsdDt2YWx1ZSZndDsmcXVvdDsuPGJyIGNsYXNzPSIiPg0K
PGJyIGNsYXNzPSIiPg0KQ29tYmluaW5nIHByb3Bvc2FscyBDLCBELCBhbmQgRSwgdGhlIGV4YW1w
bGVzIGJlY29tZTxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwO209YXVkaW8gNDkxNzAgUlRQL0FWUCAwPGJyIGNsYXNzPSIiPg0KJm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7YT1odW1sYW5nOmVuPGJyIGNsYXNzPSIiPg0KPGJyIGNs
YXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7bT12aWRlbyA1MTM3MiBSVFAv
QVZQIDMxIDMyPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7YT1o
dW1sYW5nOmFzZSwqO3E9MC4xPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7bT1hdWRpbyA0OTI1MCBSVFAvQVZQIDIwPGJyIGNsYXNzPSIi
Pg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7YT1odW1sYW5nOmVzLGV1O3E9MC45LGVu
O3E9MC44LCo7cT0wLjE8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDttPXRleHQgNDUwMjAgUlRQL0FWUCAxMDMgMTA0PGJyIGNsYXNzPSIi
Pg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7YT1odW1sYW5nOmdyPGJyIGNsYXNzPSIi
Pg0KPGJyIGNsYXNzPSIiPg0Kd2hpY2ggcmVxdWlyZXMgYWJvdXQgaGFsZiBhcyBtYW55IGNoYXJh
Y3RlcnMgYXMgdGhleSBoYXZlIG5vdy48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQoqIEVk
aXRvcmlhbCBjb21tZW50cyBhbmQgbml0czxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkFi
c3RyYWN0PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7VGhpcyBkb2N1
bWVudCBkZXNjcmliZXMgdGhlIG5lZWQgYW5kIGEgc29sdXRpb24gdXNpbmcgbmV3IFNEUDxiciBj
bGFzcz0iIj4NCnN0cmVhbTxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwO2F0dHJpYnV0ZXMuPGJy
IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KSSBkb24ndCB0aGluayB0aGUgdGVybSAmcXVvdDtz
dHJlYW0gYXR0cmlidXRlJnF1b3Q7IGlzIHVzZWQgaW4gUkZDIDQ1NjYuPGJyIGNsYXNzPSIiPg0K
SW5zdGVhZCwgaXQgdXNlcyAmcXVvdDttZWRpYSBhdHRyaWJ1dGUmcXVvdDsuPGJyIGNsYXNzPSIi
Pg0KPGJyIGNsYXNzPSIiPg0KMS4gJm5ic3A7SW50cm9kdWN0aW9uPGJyIGNsYXNzPSIiPg0KPGJy
IGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Y2FsbGVyIGFuZCBjYWxsZWUga25vdyBlYWNoIG90aGVy
IG9yIHRoZXJlIGlzIGNvbnRleHR1YWwgb3Igb3V0IG9mPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5i
c3A7YmFuZCBpbmZvcm1hdGlvbiBmcm9tIHdoaWNoIHRoZSBsYW5ndWFnZShzKSBhbmQgbWVkaWEg
bW9kYWxpdGllczxiciBjbGFzcz0iIj4NCmNhbjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4N
CkkgdGhpbmsgdGhpcyBjb250ZXh0LCBpdCdzIHByZWZlcnJlZCB0byBoeXBoZW5hdGUgJnF1b3Q7
b3V0LW9mLWJhbmQmcXVvdDsgdG88YnIgY2xhc3M9IiI+DQptYWtlIGl0IGNsZWFybHkgYmUgYW4g
YWRqZWN0aXZlLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwO1RoaXMg
YXBwcm9hY2ggaGFzIGEgbnVtYmVyIG9mIGJlbmVmaXRzLCBpbmNsdWRpbmcgdGhhdCBpdCBpczxi
ciBjbGFzcz0iIj4NCmdlbmVyaWM8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsoYXBwbGllcyB0
byBhbGwgaW50ZXJhY3RpdmUgY29tbXVuaWNhdGlvbnMgbmVnb3RpYXRlZCB1c2luZyBTRFApPGJy
IGNsYXNzPSIiPg0KYW5kPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7bm90IGxpbWl0ZWQgdG8g
ZW1lcmdlbmN5IGNhbGxzLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkkgdGhpbmsgcy9h
bmQgbm90IGxpbWl0ZWQgdG8vYW5kIGlzIG5vdCBsaW1pdGVkIHRvLyByZWFkcyBtb3JlPGJyIGNs
YXNzPSIiPg0Kc21vb3RobHkuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5i
c3A7QnV0IGl0IGlzIGNsZWFybHkgdXNlZnVsIGluIG1hbnkgb3RoZXIgY2FzZXMuICZuYnNwO0Zv
cjxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwO2V4YW1wbGUsIHNvbWVvbmUgY2FsbGluZyBhIGNv
bXBhbnkgY2FsbCBjZW50ZXIgb3IgYSBQdWJsaWMgU2FmZXR5PGJyIGNsYXNzPSIiPg0KJm5ic3A7
Jm5ic3A7QW5zd2VyaW5nIFBvaW50IChQU0FQKSBzaG91bGQgYmUgYWJsZSB0byBpbmRpY2F0ZSBp
ZiBvbmUgb3IgbW9yZTxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwO3NwZWNpZmljIHNpZ25lZCwg
d3JpdHRlbiwgYW5kL29yIHNwb2tlbiBsYW5ndWFnZXMgYXJlIHByZWZlcnJlZCw8YnIgY2xhc3M9
IiI+DQp0aGU8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDtjYWxsZWUgc2hvdWxkIGJlIGFibGUg
dG8gaW5kaWNhdGUgaXRzIGNhcGFiaWxpdGllcyBpbiB0aGlzIGFyZWEsPGJyIGNsYXNzPSIiPg0K
YW5kPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7dGhlIGNhbGwgcHJvY2VlZCB1c2luZyBpbi1j
b21tb24gbGFuZ3VhZ2UocykgYW5kIG1lZGlhIGZvcm1zLjxiciBjbGFzcz0iIj4NCjxiciBjbGFz
cz0iIj4NCkkgdGhpbmsgcy9wcmVmZXJyZWQsIHRoZSBjYWxsZWUvcHJlZmVycmVkOyB0aGUgY2Fs
bGVlLyBiZWNhdXNlIHRoZTxiciBjbGFzcz0iIj4NCnNlbnRlbmNlIGlzIHRoZSBjb25jYXRlbmF0
aW9uIG9mIHR3byBzZW50ZW5jZXMuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KUGVyaGFw
cyBzL2luLWNvbW1vbi9zaGFyZWQvLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCiZuYnNw
OyZuYnNwO0luY2x1ZGluZyB0aGUgdXNlcidzIGh1bWFuIChuYXR1cmFsKSBsYW5ndWFnZSBwcmVm
ZXJlbmNlcyBpbiB0aGU8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDtzZXNzaW9uIGVzdGFibGlz
aG1lbnQgbmVnb3RpYXRpb24gaXMgaW5kZXBlbmRlbnQgb2YgdGhlIHVzZSBvZiBhPGJyIGNsYXNz
PSIiPg0KJm5ic3A7Jm5ic3A7cmVsYXkgc2VydmljZSBhbmQgaXMgdHJhbnNwYXJlbnQgdG8gYSB2
b2ljZSBzZXJ2aWNlIHByb3ZpZGVyLiA8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpJIHRo
aW5rIGl0J3MgZXZlbiBicm9hZGVyIHRoYW4gJnF1b3Q7dHJhbnNwYXJlbnQgdG8gYSB2b2ljZSBz
ZXJ2aWNlPGJyIGNsYXNzPSIiPg0KcHJvdmlkZXImcXVvdDsgLS0gaXQncyB0cmFuc3BhcmVudCB0
byBhbnkgc2VyaXZpY2UgcHJvdmlkZXIsIGFzc3VtaW5nIHRoYXQ8YnIgY2xhc3M9IiI+DQp0aGUg
bWVkaWEgYXJlIGxhbmd1YWdlLW5ldXRyYWwuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0K
Jm5ic3A7Jm5ic3A7SW4gdGhlIGNhc2Ugb2YgYSBjYWxsIHRvIGUuZy4sIGFuIGFpcmxpbmUsIHRo
ZSBjYWxsIGNvdWxkIGJlPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7YXV0b21hdGljYWxseSBo
YW5kbGVkIGJ5IGEgU3BhbmlzaC1zcGVha2luZyBhZ2VudC48YnIgY2xhc3M9IiI+DQo8YnIgY2xh
c3M9IiI+DQpJIHRoaW5rIHMvaGFuZGxlZCBieS9yb3V0ZWQgdG8vIGlzIHRoZSB1c3VhbCB1c2Fn
ZS48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQozLiAmbmJzcDtEZXNpcmVkIFNlbWFudGlj
czxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwO1RoZSBkZXNpcmVkIHNv
bHV0aW9uIGlzIGEgbWVkaWEgYXR0cmlidXRlIChwcmVmZXJhYmx5IHBlcjxiciBjbGFzcz0iIj4N
CmRpcmVjdGlvbik8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDt0aGF0IG1heSBiZSB1c2VkIHdp
dGhpbiBhbiBvZmZlciB0byBpbmRpY2F0ZSB0aGUgcHJlZmVycmVkPGJyIGNsYXNzPSIiPg0KbGFu
Z3VhZ2U8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDtvZiBlYWNoIChkaXJlY3Rpb24gb2YgYSkg
bWVkaWEgc3RyZWFtLCBhbmQgd2l0aGluIGFuIGFuc3dlciB0bzxiciBjbGFzcz0iIj4NCiZuYnNw
OyZuYnNwO2luZGljYXRlIHRoZSBhY2NlcHRlZCBsYW5ndWFnZS48YnIgY2xhc3M9IiI+DQo8YnIg
Y2xhc3M9IiI+DQpJbiB0aGlzIG9uZSBpbnN0YW5jZSwgSSB0aGluayB5b3Ugd2FudCB0byB1c2Ug
JnF1b3Q7bGFuZ3VhZ2UocykmcXVvdDsgdG8gZHJpdmU8YnIgY2xhc3M9IiI+DQpob21lIHRoYXQg
dGhhdCBtdWx0aXBsZSBsYW5ndWFnZXMgY2FuIGJlIHNwZWNpZmllZDogJm5ic3A7JnF1b3Q7d2l0
aGluIGFuIG9mZmVyPGJyIGNsYXNzPSIiPg0KdG8gaW5kaWNhdGUgdGhlIHByZWZlcnJlZCBsYW5n
dWFnZShzKSZxdW90Oy48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDso
TmVnb3RpYXRpbmcgbXVsdGlwbGUgc2ltdWx0YW5lb3VzIGxhbmd1YWdlcyB3aXRoaW4gYSBtZWRp
YSBzdHJlYW08YnIgY2xhc3M9IiI+DQppczxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwO291dCBv
ZiBzY29wZSwgYXMgdGhlIGNvbXBsZXhpdHkgb2YgZG9pbmcgc28gb3V0d2VpZ2hzIHRoZTxiciBj
bGFzcz0iIj4NCiZuYnNwOyZuYnNwO3VzZWZ1bG5lc3MuKTxiciBjbGFzcz0iIj4NCjxiciBjbGFz
cz0iIj4NCllvdSBtaWdodCB3YW50IHRvIHNheSBpbnN0ZWFkICZxdW90OyhOZWdvdGlhdGluZyBt
dWx0aXBsZSBzaW11bHRhbmVvdXM8YnIgY2xhc3M9IiI+DQpsYW5ndWFnZXMgd2l0aGluIGEgbWVk
aWEgc3RyZWFtIGlzIG91dCBvZiBzY29wZSBmb3IgdGhpcyBkb2N1bWVudC4pJnF1b3Q7PGJyIGNs
YXNzPSIiPg0KdG8gZW5zdXJlIHRoYXQgbm9ib2R5IGRlY2lkZXMgdG8gYXJndWUgd2hldGhlciAm
cXVvdDt0aGUgY29tcGxleGl0eSBvZjxiciBjbGFzcz0iIj4NCmRvaW5nIHNvIG91dHdlaWdocyB0
aGUgdXNlZnVsbmVzcyZxdW90Oy48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo0LiAmbmJz
cDtUaGUgZXhpc3RpbmcgJ2xhbmcnIGF0dHJpYnV0ZTxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0i
Ij4NCiZuYnNwOyZuYnNwO1JGQyA0NTY2IFtSRkM0NTY2XSBzcGVjaWZpZXMgYW4gYXR0cmlidXRl
ICdsYW5nJyB3aGljaCBhcHBlYXJzPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7c2ltaWxhciB0
byB3aGF0IGlzIG5lZWRlZCBoZXJlLCBidXQgaXMgbm90IHN1ZmZpY2llbnRseSBkZXRhaWxlZDxi
ciBjbGFzcz0iIj4NCmZvcjxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwO3VzZSBoZXJlLjxiciBj
bGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCiZxdW90O2ZvciB1c2UgaGVyZSZxdW90OyBpc24ndCBx
dWl0ZSByaWdodC4gJm5ic3A7TWF5YmUgJnF1b3Q7aXMgbm90IHN1ZmZpY2llbnRseTxiciBjbGFz
cz0iIj4NCnNwZWNpZmljPGJyIGNsYXNzPSIiPg0Kb3IgZmxleGlibGUgdG8gc2F0aXNmeSB0aGUg
cmVxdWlyZW1lbnRzJnF1b3Q7LjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCiZuYnNwOyZu
YnNwO0luIGFkZGl0aW9uLCBpdCBpcyBub3QgbWVudGlvbmVkIGluIFtSRkMzMjY0XTxiciBjbGFz
cz0iIj4NCjxiciBjbGFzcz0iIj4NCiZxdW90O2l0JnF1b3Q7IGlzIHNvbWV3aGF0IGFtYmlndW91
cyBoZXJlLCBwZXJoYXBzIGNoYW5nZSB0byAmcXVvdDt0aGUgJ2xhbmcnPGJyIGNsYXNzPSIiPg0K
YXR0cmlidXRlJnF1b3Q7LjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjUuICZuYnNwO1By
b3Bvc2VkIFNvbHV0aW9uPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KUGVyaGFwcyAvUHJv
cG9zZWQgU29sdXRpb24vU29sdXRpb24vLCBzaW5jZSBvbmNlIHRoaXMgZHJhZnQgaXM8YnIgY2xh
c3M9IiI+DQphcHByb3ZlZCwgaXQgYmVjb21lcyB0aGUgc29sdXRpb24uPGJyIGNsYXNzPSIiPg0K
PGJyIGNsYXNzPSIiPg0KNS4yLiAmbmJzcDtOZXcgJ2h1bWludGxhbmctc2VuZCcgYW5kICdodW1p
bnRsYW5nLXJlY3YnIGF0dHJpYnV0ZXM8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQombmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDthPWh1bWludGxhbmctc2VuZDombHQ7bGFuZ3VhZ2Ug
dGFnJmd0OzxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2E9aHVt
aW50bGFuZy1yZWN2OiZsdDtsYW5ndWFnZSB0YWcmZ3Q7PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNz
PSIiPg0KVGhpcyBpcyBwcmVzZW50ZWQgYXMgdGhlIGdlbmVyaWMgZm9ybSBvZiB0aGUgYXR0cmli
dXRlcywgYnV0IHRoZXJlIGlzPGJyIGNsYXNzPSIiPg0Kbm8gaW5kaWNhdGlvbiBvZiB0aGUgcG9z
aWJsZSBhc3Rlcmlzay48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDtU
aGUgdmFsdWVzIGNvbnN0aXR1dGUgYSBsaXN0IG9mIGxhbmd1YWdlczxiciBjbGFzcz0iIj4NCiZu
YnNwOyZuYnNwO2luIHByZWZlcmVuY2Ugb3JkZXIgKGZpcnN0IGlzIG1vc3QgcHJlZmVycmVkKS48
YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQomcXVvdDtUaGUgdmFsdWVzJnF1b3Q7IGlzbid0
IHZlcnkgY2xlYXIsIGJlY2F1c2UgdGhlIHZhbHVlcyBhcmUgaW4gc3VjY2Vzc2l2ZTxiciBjbGFz
cz0iIj4NCmF0dHJpYnV0ZXMuICZuYnNwO1lvdSB3YW50IHRvIHNheSBzb21ldGhpbmcgbGlrZSAm
cXVvdDtUaGUgc2VxdWVuY2Ugb2YgdmFsdWVzPGJyIGNsYXNzPSIiPg0KaW48YnIgY2xhc3M9IiI+
DQp0aGUgb2NjdXJyZW5jZXMgb2Ygb25lIG9mIHRoZXNlIGF0dHJpYnV0ZXMgY29uc3RpdHV0ZXMg
Li4uJnF1b3Q7LiA8YnIgY2xhc3M9IiI+DQpIb3dldmVyLDxiciBjbGFzcz0iIj4NCnNlZSB0aGUg
dGVjaG5pY2FsIGNvbW1lbnRzIGFib3ZlLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCiZu
YnNwOyZuYnNwO1doZW4gcGxhY2luZyBhbiBlbWVyZ2VuY3kgY2FsbCwgYW5kIGluIGFueSBvdGhl
ciBjYXNlIHdoZXJlIHRoZTxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwO2xhbmd1YWdlIGNhbm5v
dCBiZSBhc3N1bWVkIGZyb20gY29udGV4dCwgZWFjaCBtZWRpYSBzdHJlYW0gaW4gYW48YnIgY2xh
c3M9IiI+DQombmJzcDsmbmJzcDtvZmZlciBwcmltYXJpbHkgaW50ZW5kZWQgZm9yIGh1bWFuIGxh
bmd1YWdlIGNvbW11bmljYXRpb24gU0hPVUxEPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7c3Bl
Y2lmeSBib3RoIChvciBpbiBzb21lIGNhc2VzLCBvbmUgb2YpIHRoZSAnaHVtaW50bGFuZy1zZW5k
JyBhbmQ8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsnaHVtaW50bGFuZy1yZWN2JyBhdHRyaWJ1
dGVzLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClByb2JhYmx5IHMvYXNzdW1lZC9pbmZl
cnJlZC8uPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KQ291bGQgeW91IGJlIG1vcmUgYWNj
dXJhdGUgYnk8YnIgY2xhc3M9IiI+DQpzL29yIGluIHNvbWUgY2FzZXMvb3IgZm9yIHVuaWRpcmVj
dGlvbmFsIHN0cmVhbXMvPzxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjUuMy4gJm5ic3A7
QWR2aXNvcnkgdnMgUmVxdWlyZWQ8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQombmJzcDsm
bmJzcDtUaGUgbWVjaGFuaXNtIGZvciBpbmRpY2F0aW5nIHRoaXMgcHJlZmVyZW5jZSBpcyB0aGF0
LCBpbiBhbiBvZmZlciw8YnIgY2xhc3M9IiI+DQppZjxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNw
O3RoZSBsYXN0IGNoYXJhY3RlciBvZiBhbnkgb2YgdGhlICdodW1pbnRsYW5nLXJlY3YnIG9yICdo
dW1pbnRsYW5nLTxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwO3NlbmQnIHZhbHVlcyBpcyBhbiBh
c3RlcmlzaywgdGhpcyBpbmRpY2F0ZXMgYSByZXF1ZXN0IHRvIG5vdCBmYWlsPGJyIGNsYXNzPSIi
Pg0KdGhlPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Y2FsbCAoc2ltaWxhciB0byBTSVAgQWNj
ZXB0LUxhbmd1YWdlIHN5bnRheCkuICZuYnNwO0VpdGhlciB3YXksIHRoZTxiciBjbGFzcz0iIj4N
CmNhbGxlZDxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwO3BhcnR5IE1BWSBpZ25vcmUgdGhpcywg
ZS5nLiwgZm9yIHRoZSBlbWVyZ2VuY3kgc2VydmljZXMgdXNlIGNhc2UsPGJyIGNsYXNzPSIiPg0K
YTxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwO1BTQVAgd2lsbCBsaWtlbHkgbm90IGZhaWwgdGhl
IGNhbGwuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KVGhlIGNvbnN0cnVjdGlvbiBvZiB0
aGlzIHBhcmFncmFwaCBpc24ndCBxdWl0ZSBjb21wbGV0ZS4gJm5ic3A7SXQgc2F5czxiciBjbGFz
cz0iIj4NCnRoYXQ8YnIgY2xhc3M9IiI+DQppZiBhbiBhc3RlcmlzayBpcyBwcmVzZW50LCBhIHJl
cXVlc3Qgc2hvdWxkbid0IGZhaWwsIGJ1dCBpdCBkb2Vzbid0PGJyIGNsYXNzPSIiPg0Kc2F5IHRo
YXQgaWYgbm8gYXN0ZXJpc2sgaXMgcHJlc2VudCwgYSByZXF1ZXN0IHNob3VsZCBmYWlsIGlmIHRo
ZXJlIGlzPGJyIGNsYXNzPSIiPg0Kbm8gbGFuZ3VhZ2UgbWF0Y2guICZuYnNwO0FuZCBpdCdzIHRo
ZSBsYXR0ZXIgY29uZGl0aW9uIHRoYXQgbWFrZXMgdGhlPGJyIGNsYXNzPSIiPg0Kc2Vjb25kIHNl
bnRlbmNlIG1lYW5pbmdmdWwuICZuYnNwO1NvIEkgdGhpbmsgeW91IHdhbnQgdG8gaW5zZXJ0IGJl
dHdlZW48YnIgY2xhc3M9IiI+DQp0aGU8YnIgY2xhc3M9IiI+DQp0d28gc2VudGVuY2VzIG9uZSBy
ZWdhcmRpbmcgdGhlIGFic2VuY2Ugb2YgYW4gYXN0ZXJpc2suPGJyIGNsYXNzPSIiPg0KPGJyIGNs
YXNzPSIiPg0KNS41LiAmbmJzcDtFeGFtcGxlczxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4N
CkdpdmVuIHRoYXQgdGhlIGNvbWJpbmVkIGF1ZGlvL3ZpZGVvIG1lY2hhbmlzbSBpcyB0aGUgb25s
eTxiciBjbGFzcz0iIj4NCmlycmVndWxhcml0eTxiciBjbGFzcz0iIj4NCmluIHRoaXMgc3lzdGVt
LCB0aGVyZSBvdWdodCB0byBiZSBhbiBleGFtcGxlIG9mIGl0LiAmbmJzcDtFLmcuLDxiciBjbGFz
cz0iIj4NCjxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwO0FuIGV4YW1wbGUgb2YgYSBzdXBwbGVt
ZW50YWwgdmlkZW8gc3RyZWFtIHdpdGggYSBzcG9rZW4gbGFuZ3VhZ2U8YnIgY2xhc3M9IiI+DQom
bmJzcDsmbmJzcDthdWRpbyBzdHJlYW06PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7bT12aWRlbyA1MTM3MiBSVFAvQVZQIDMxIDMyPGJy
IGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7YT1odW1pbnRsYW5nLXNl
bmQ6ZW48YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDthPWh1bWlu
dGxhbmctcmVjdjplbjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwO209YXVkaW8gNDkyNTAgUlRQL0FWUCAyMDxiciBjbGFzcz0iIj4NCiZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2E9aHVtaW50bGFuZy1zZW5kOmVuPGJyIGNsYXNz
PSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7YT1odW1pbnRsYW5nLXJlY3Y6ZW48
YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo2LiAmbmJzcDtJQU5BIENvbnNpZGVyYXRpb25z
PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7aHVtaW50bGFuZy12YWx1ZSA9ICZuYnNwO0xhbmd1YWdlLVRhZyBbIGFzdGVyaXNrIF08YnIg
Y2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs7IExhbmd1YWdl
LVRhZyBkZWZpbmVkIGluIFJGQyA1NjQ2PGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7YXN0ZXJpc2sgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7PSAmbmJzcDsmcXVvdDsqJnF1b3Q7PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNz
PSIiPg0Kcy9MYW5ndWFnZS1UYWcgZGVmaW5lZCBpbiBSRkMgNTY0Ni9MYW5ndWFnZS1UYWcgYXMg
ZGVmaW5lZCBpbiBSRkM8YnIgY2xhc3M9IiI+DQo1NjQ2LzxiciBjbGFzcz0iIj4NCjxiciBjbGFz
cz0iIj4NCkJ1dCBwZXJoYXBzIGFsc28gcy9SRkMgNTY0Ni9CQ1AgNDcvLCB3aGljaCBlbnN1cmVz
IHRoYXQgJnF1b3Q7aHVtaW50bGFuZyZxdW90OzxiciBjbGFzcz0iIj4NCnRyYWNrcyB0aGUgY3Vy
cmVudCB2ZXJzaW9uIG9mIGxhbmd1YWdlIHRhZ3MuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIi
Pg0KQXBwZW5kaXggQS4gJm5ic3A7SGlzdG9yaWMgQWx0ZXJuYXRpdmUgUHJvcG9zYWw6IENhbGxl
ci1wcmVmczxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwO1RoaXM8YnIg
Y2xhc3M9IiI+DQombmJzcDsmbmJzcDtyZXN1bHRzIGluIGEgbW9yZSBmcmFnaWxlIHNvbHV0aW9u
IHNpbmNlIHRoZSBtZWRpYSBtb2RhbGl0eSBhbmQ8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDts
YW5ndWFnZSB3b3VsZCBiZSBuZWdvdGlhdGVkIHVzaW5nIFNJUCwgYW5kIHRoZW4gdGhlIHNwZWNp
ZmljPGJyIGNsYXNzPSIiPg0KbWVkaWE8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDtmb3JtYXRz
ICh3aGljaCBpbmhlcmVudGx5IGluY2x1ZGUgdGhlIG1vZGFsaXR5KSB3b3VsZCBiZTxiciBjbGFz
cz0iIj4NCm5lZ290aWF0ZWQ8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDthdCBhIGRpZmZlcmVu
dCBsZXZlbCAodHlwaWNhbGx5IFNEUCwgZXNwZWNpYWxseSBpbiB0aGUgZW1lcmdlbmN5PGJyIGNs
YXNzPSIiPg0KJm5ic3A7Jm5ic3A7Y2FsbGluZyBjYXNlcyksIG1ha2luZyBpdCBlYXNpZXIgdG8g
aGF2ZSBtaXNtYXRjaGVzIChzdWNoIGFzIHdoZXJlPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7
dGhlIG1lZGlhIG1vZGFsaXR5IG5lZ290aWF0ZWQgaW4gU0lQIGRvbid0IG1hdGNoIHdoYXQgd2Fz
PGJyIGNsYXNzPSIiPg0KbmVnb3RpYXRlZDxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwO3VzaW5n
IFNEUCkuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJnF1b3Q7dGhlIG1lZGlhIG1vZGFs
aXR5IGFuZCBsYW5ndWFnZSB3b3VsZCBiZSBuZWdvdGlhdGVkIHVzaW5nIFNJUCZxdW90OyBpc24n
dDxiciBjbGFzcz0iIj4NCnF1aXRlIHRoZSByaWdodCB3YXkgdG8gc2F5IGl0IGJlY2F1c2UgU0lQ
IGlzbid0IGV4cGxpY2l0bHk8YnIgY2xhc3M9IiI+DQpuZWdvdGlhdGluZzxiciBjbGFzcz0iIj4N
CnRoZSBtb2RhbGl0eS4gJm5ic3A7QmV0dGVyIHdvdWxkIGJlPGJyIGNsYXNzPSIiPg0KPGJyIGNs
YXNzPSIiPg0KJm5ic3A7Jm5ic3A7Li4uIHRoZSBsYW5ndWFnZSAoYW5kIGJ5IGltcGxpY2F0aW9u
IHRoZSBtZWRpYSBtb2RhbGl0eSkgd291bGQgYmU8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDtu
ZWdvdGlhdGVkIHVzaW5nIFNJUCwgYW5kIHRoZW4gdGhlIHNwZWNpZmljIG1lZGlhICh3aGljaDxi
ciBjbGFzcz0iIj4NCmluaGVyZW50bHk8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDtpbmNsdWRl
IHRoZSBtb2RhbGl0aWVzIGFuZCBmb3JtYXRzKSB3b3VsZCBiZSBuZWdvdGlhdGVkIGF0IGE8YnIg
Y2xhc3M9IiI+DQombmJzcDsmbmJzcDtkaWZmZXJlbnQgbGV2ZWwgLi4uPGJyIGNsYXNzPSIiPg0K
PGJyIGNsYXNzPSIiPg0KW0VORF08YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xh
c3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9
IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCxzYW5zLXNl
cmlmO2ZvbnQtc2l6ZToxMXB4O2NvbG9yOiM5OTk5OTk7Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5
bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCxzYW5zLXNlcmlmO2NvbG9yOiM5OTk5OTk7IG1zby1mYXJl
YXN0LWZvbnQtZmFtaWx5OiBBcmlhbDsgbXNvLWZhcmVhc3QtdGhlbWUtZm9udDogbWlub3ItbGF0
aW47IG1zby1iaWRpLWZvbnQtZmFtaWx5OiAmcXVvdDtBcmlhbCZxdW90OzsgbXNvLWFuc2ktbGFu
Z3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogRU4tR0I7IG1zby1iaWRpLWxhbmd1
YWdlOiBBUi1TQSI+VGhpcw0KIGVtYWlsIGFuZCBpdHMgYXR0YWNobWVudHMgYXJlIGludGVuZGVk
IGZvciB0aGUgYWJvdmUgbmFtZWQgb25seSBhbmQgbWF5IGJlIGNvbmZpZGVudGlhbC4gSWYgdGhl
eSBoYXZlIGNvbWUgdG8geW91IGluIGVycm9yIHlvdSBtdXN0IHRha2Ugbm8gYWN0aW9uIGJhc2Vk
IG9uIHRoZW0sIG5vciBtdXN0IHlvdSBjb3B5IG9yIHNob3cgdGhlbSB0byBhbnlvbmU7IHBsZWFz
ZSByZXBseSB0byB0aGlzIGVtYWlsIG9yIGNhbGwgJiM0Mzs0NCAyMDcgMzU2IDA2MDANCiBhbmQg
aGlnaGxpZ2h0IHRoZSBlcnJvci4gPC9zcGFuPjwvcD4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_D80EB5AC8E94475683D02F6FB721A883gsmacom_--


From nobody Tue Feb 21 17:13:50 2017
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 297D11294A9; Tue, 21 Feb 2017 17:13:44 -0800 (PST)
X-Quarantine-ID: 
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UaO1YlHoDi94; Tue, 21 Feb 2017 17:13:41 -0800 (PST)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 4F5FF129443; Tue, 21 Feb 2017 17:13:41 -0800 (PST)
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Tue, 21 Feb 2017 17:04:27 -0800
Mime-Version: 1.0
Message-Id: 
In-Reply-To: 
References: <148738514545.19944.11486737065416495302.idtracker@ietfa.amsl.com> 
X-Mailer: Eudora for Mac OS X
Date: Tue, 21 Feb 2017 17:13:33 -0800
To: Natasha Rooney , Dale Worley , "slim@ietf.org" 
From: Randall Gellens 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
Archived-At: 
Cc: "gen-art@ietf.org" , "ietf@ietf.org" , "draft-ietf-slim-negotiating-human-language.all@ietf.org" 
Subject: Re: [Slim] Review of draft-ietf-slim-negotiating-human-language-06
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Feb 2017 01:13:44 -0000

I am almost done with my reply.  I wasn't ignoring Dale, I've been 
working on his comments.

At 11:28 PM +0000 2/21/17, Natasha Rooney wrote:

>  Hi Dale! Many thanks for these comments, as one of the SLIM chairs 
> I'll work on getting some answers to you or I'll request the author 
> or one of the SLIM active participants to respond.
>
>  Bernard, Randall and SLIM - see below re Dale's points. 
>
>
>  **** A. Call failure ****
>  Randall or Bernard can you respond to this? I imagine the UA call 
> failure method is UA specific, but if there is a clash with SIP 
> level call fail then this should be addressed.
>
>  **** B. Audio/Video coordination ****
>  I believe the theory behind the current draft is that the spoken 
> and video streams will be different in the cases of such things as 
> sign language. Video could therefore be sign and audio would be a 
> spoken language. I'm not sure if the suggestion he satisfies this 
> case?
>
>  **** C. "humintlang" seems long to me ****
>  Bernard - I don't see the issue with shortening humintlang, but the 
> group might. I suggest we throw this to the group for discussion.
>
>  **** D. Use the Accept-Language syntax ****
>  Randall and Bernard - is this an acceptable change? Or one we need 
> to discuss further. Seems like a reasonable request, but also a 
> larger change, which is why I ask!
>
>  **** E. Have an attribute to abbreviate the 
> bidirectionally-symmetric case ****
>  I do not remember us having this discussion within the group, 
> although it may have occurred before I became chair.
>  Randall, Brian or Bernard - has this idea been discussed before? If 
> so, can one of you respond with an explanation as to why we haven't 
> done this?
>
>  **** Editorial comments and nits *****
>  Randall - can you take a look through Dale's editorial comments and 
> shout if there is any problems with these suggestions; if 
> everything is ok please make the changes.
>
>  Thanks all!
>
>  Natasha Rooney | Internet Engineering Director | Internet and Web 
> Team | Technology | GSMA 
> | nrooney@gsma.com | +44 (0) 7730 219 765 
> | @thisNatasha | Skype: nrooney@gsm.org
>
>>  On 18 Feb 2017, at 02:32, Dale Worley 
>> <worley@ariadne.com> wrote:
>>
>>  Reviewer: Dale Worley
>>  Review result: Ready with Nits
>>
>>  I am the assigned Gen-ART reviewer for this draft.  The General Area
>>  Review Team (Gen-ART) reviews all IETF documents being processed
>>  by the IESG for the IETF Chair.  Please treat these comments just
>>  like any other last call comments.
>>
>>  For more information, please see the FAQ at
>> 
>> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>>
>>  Document:  draft-ietf-slim-negotiating-human-language-06
>>  Reviewer:  Dale R. Worley
>>  Review Date:  2017-02-17
>>  IETF LC End Date:  2017-02-20
>>  IESG Telechat date:  [unknown]
>>
>>  Summary:
>>        This draft is basically ready for publication, but has nits
>>        that should be fixed before publication.
>>
>>  * Technical comments
>>
>>  A. Call failure
>>
>>  If a call fails due to no available language match, in what way(s)
>>  does it fail?  Section 5.3 says
>>
>>    If such an offer is received, the receiver MAY
>>    reject the media, ignore the language specified, or attempt to
>>    interpret the intent
>>
>>  But I suspect it's also allowed for the UAS to fail the call at the
>>  SIP level.  Whether or not that is allowed (or at least envisioned)
>>  should be described.  And what response code(s)/warn-code(s) should
>>  be
>>  used for that?
>>
>>  B. Audio/Video coordination
>>
>>    5.2.  New 'humintlang-send' and 'humintlang-recv' attributes
>>
>>    Note that while signed language tags are used with a video stream
>>  to
>>    indicate sign language, a spoken language tag for a video stream
>>  in
>>    parallel with an audio stream with the same spoken language tag
>>    indicates a request for a supplemental video stream to see the
>>    speaker.
>>
>>  And there's a similar paragraph in 5.4:
>>
>>>    A spoken language tag for a video stream in conjunction with an
>>>
>>  audio
>>
>>>    stream with the same language might indicate a request for
>>>    supplemental video to see the speaker.
>>>
>>
>>  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 seems to me that a
>>  workable rule is that there is an audio stream and a video stream and
>>  they specify exactly the same language tag in their respective
>>  humintlang attributes.  In that case, it is a request for a spoken
>>  language with simultaneous video of the speaker, and those requests
>>  should be considered satisfied only if both streams can be
>>  established.
>>
>>  * The following three items are adjustments to the design which I'd
>>  like to know have been considered.
>>
>>  C. "humintlang" seems long to me
>>
>>  Given the excessive length of SDP in practice, it seems to me that a
>>  shorter attribute name would be desirable.  E.g., "humlang" as was
>>  used in some previous versions.  Or is there a coordinated usage with
>>  other names in the "hum*lang" pattern?
>>
>>  D. Use the Accept-Language syntax
>>
>>  It seems to me that it would better to use the Accept-Language syntax
>>  for the attribute values.  This allows (1) specifiying the quality of
>>  language experience, allowing clear description of bilingualism, (2)
>>  a
>>  unified method of specifying whether or not arbitrary languages are
>>  acceptable, and (3) abbreviating SDP descriptions.
>>
>>  In a way, the fact that the current proposal seems to require (but
>>  does not directly specify) the coordinated absence/presence of an
>>  asterisk on all of the repetitions of humintlang-send or
>>  humintlang-recv is a warning that the syntax doesn't represent the
>>  semantics as well as it might.
>>
>>  E. Have an attribute to abbreviate the bidirectionally-symmetric case
>>
>>  Note that all examples are bidirectionally symmetric, and the text
>>  says that requests and responses SHOULD be bidirectionally symmetric.
>>  So it would be a very useful abbreviation to define
>>  "humintlang=" to be equivalent to the combination of
>>  "humintlang-send=" and "humintlang-recv=".
>>
>>  Combining proposals C, D, and E, the examples become
>>
>>       m=audio 49170 RTP/AVP 0
>>       a=humlang:en
>>
>>       m=video 51372 RTP/AVP 31 32
>>       a=humlang:ase,*;q=0.1
>>
>>       m=audio 49250 RTP/AVP 20
>>       a=humlang:es,eu;q=0.9,en;q=0.8,*;q=0.1
>>
>>       m=text 45020 RTP/AVP 103 104
>>       a=humlang:gr
>>
>>  which requires about half as many characters as they have now.
>>
>>  * Editorial comments and nits
>>
>>  Abstract
>>
>>    This document describes the need and a solution using new SDP
>>  stream
>>    attributes.
>>
>>  I don't think the term "stream attribute" is used in RFC 4566.
>>  Instead, it uses "media attribute".
>>
>>  1.  Introduction
>>
>>    caller and callee know each other or there is contextual or out of
>>    band information from which the language(s) and media modalities
>>  can
>>
>>  I think this context, it's preferred to hyphenate "out-of-band" to
>>  make it clearly be an adjective.
>>
>>    This approach has a number of benefits, including that it is
>>  generic
>>    (applies to all interactive communications negotiated using SDP)
>>  and
>>    not limited to emergency calls.
>>
>>  I think s/and not limited to/and is not limited to/ reads more
>>  smoothly.
>>
>>    But it is clearly useful in many other cases.  For
>>    example, someone calling a company call center or a Public Safety
>>    Answering Point (PSAP) should be able to indicate if one or more
>>    specific signed, written, and/or spoken languages are preferred,
>>  the
>>    callee should be able to indicate its capabilities in this area,
>>  and
>>    the call proceed using in-common language(s) and media forms.
>>
>>  I think s/preferred, the callee/preferred; the callee/ because the
>>  sentence is the concatenation of two sentences.
>>
>>  Perhaps s/in-common/shared/.
>>
>>    Including the user's human (natural) language preferences in the
>>    session establishment negotiation is independent of the use of a
>>    relay service and is transparent to a voice service provider.
>>
>>  I think it's even broader than "transparent to a voice service
>>  provider" -- it's transparent to any serivice provider, assuming that
>>  the media are language-neutral.
>>
>>    In the case of a call to e.g., an airline, the call could be
>>    automatically handled by a Spanish-speaking agent.
>>
>>  I think s/handled by/routed to/ is the usual usage.
>>
>>  3.  Desired Semantics
>>
>>    The desired solution is a media attribute (preferably per
>>  direction)
>>    that may be used within an offer to indicate the preferred
>>  language
>>    of each (direction of a) media stream, and within an answer to
>>    indicate the accepted language.
>>
>>  In this one instance, I think you want to use "language(s)" to drive
>>  home that that multiple languages can be specified:  "within an offer
>>  to indicate the preferred language(s)".
>>
>>    (Negotiating multiple simultaneous languages within a media stream
>>  is
>>    out of scope, as the complexity of doing so outweighs the
>>    usefulness.)
>>
>>  You might want to say instead "(Negotiating multiple simultaneous
>>  languages within a media stream is out of scope for this document.)"
>>  to ensure that nobody decides to argue whether "the complexity of
>>  doing so outweighs the usefulness".
>>
>>  4.  The existing 'lang' attribute
>>
>>    RFC 4566 [RFC4566] specifies an attribute 'lang' which appears
>>    similar to what is needed here, but is not sufficiently detailed
>>  for
>>    use here.
>>
>>  "for use here" isn't quite right.  Maybe "is not sufficiently
>>  specific
>>  or flexible to satisfy the requirements".
>>
>>    In addition, it is not mentioned in [RFC3264]
>>
>>  "it" is somewhat ambiguous here, perhaps change to "the 'lang'
>>  attribute".
>>
>>  5.  Proposed Solution
>>
>>  Perhaps /Proposed Solution/Solution/, since once this draft is
>>  approved, it becomes the solution.
>>
>>  5.2.  New 'humintlang-send' and 'humintlang-recv' attributes
>>
>>       a=humintlang-send:
>>       a=humintlang-recv:
>>
>>  This is presented as the generic form of the attributes, but there is
>>  no indication of the posible asterisk.
>>
>>    The values constitute a list of languages
>>    in preference order (first is most preferred).
>>
>>  "The values" isn't very clear, because the values are in successive
>>  attributes.  You want to say something like "The sequence of values
>>  in
>>  the occurrences of one of these attributes constitutes ...".
>>  However,
>>  see the technical comments above.
>>
>>    When placing an emergency call, and in any other case where the
>>    language cannot be assumed from context, each media stream in an
>>    offer primarily intended for human language communication SHOULD
>>    specify both (or in some cases, one of) the 'humintlang-send' and
>>    'humintlang-recv' attributes.
>>
>>  Probably s/assumed/inferred/.
>>
>>  Could you be more accurate by
>>  s/or in some cases/or for unidirectional streams/?
>>
>>  5.3.  Advisory vs Required
>>
>>    The mechanism for indicating this preference is that, in an offer,
>>  if
>>    the last character of any of the 'humintlang-recv' or 'humintlang-
>>    send' values is an asterisk, this indicates a request to not fail
>>  the
>>    call (similar to SIP Accept-Language syntax).  Either way, the
>>  called
>>    party MAY ignore this, e.g., for the emergency services use case,
>>  a
>>    PSAP will likely not fail the call.
>>
>>  The construction of this paragraph isn't quite complete.  It says
>>  that
>>  if an asterisk is present, a request shouldn't fail, but it doesn't
>>  say that if no asterisk is present, a request should fail if there is
>>  no language match.  And it's the latter condition that makes the
>>  second sentence meaningful.  So I think you want to insert between
>>  the
>>  two sentences one regarding the absence of an asterisk.
>>
>>  5.5.  Examples
>>
>>  Given that the combined audio/video mechanism is the only
>>  irregularity
>>  in this system, there ought to be an example of it.  E.g.,
>>
>>    An example of a supplemental video stream with a spoken language
>>    audio stream:
>>
>>       m=video 51372 RTP/AVP 31 32
>>       a=humintlang-send:en
>>       a=humintlang-recv:en
>>
>>       m=audio 49250 RTP/AVP 20
>>       a=humintlang-send:en
>>       a=humintlang-recv:en
>>
>>  6.  IANA Considerations
>>
>>       humintlang-value =  Language-Tag [ asterisk ]
>>                           ; Language-Tag defined in RFC 5646
>>       asterisk         =  "*"
>>
>>  s/Language-Tag defined in RFC 5646/Language-Tag as defined in RFC
>>  5646/
>>
>>  But perhaps also s/RFC 5646/BCP 47/, which ensures that "humintlang"
>>  tracks the current version of language tags.
>>
>>  Appendix A.  Historic Alternative Proposal: Caller-prefs
>>
>>    This
>>    results in a more fragile solution since the media modality and
>>    language would be negotiated using SIP, and then the specific
>>  media
>>    formats (which inherently include the modality) would be
>>  negotiated
>>    at a different level (typically SDP, especially in the emergency
>>    calling cases), making it easier to have mismatches (such as where
>>    the media modality negotiated in SIP don't match what was
>>  negotiated
>>    using SDP).
>>
>>  "the media modality and language would be negotiated using SIP" isn't
>>  quite the right way to say it because SIP isn't explicitly
>>  negotiating
>>  the modality.  Better would be
>>
>>    ... the language (and by implication the media modality) would be
>>    negotiated using SIP, and then the specific media (which
>>  inherently
>>    include the modalities and formats) would be negotiated at a
>>    different level ...
>>
>>  [END]
>>
>
>  This email and its attachments are intended for the above named 
> only and may be confidential. If they have come to you in error you 
> must take no action based on them, nor must you copy or show them 
> to anyone; please reply to this email or call +44 207 356 0600 and 
> highlight the error.


-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
There's nothing wrong with me.  Maybe there's something wrong with
the universe.       --'Dr. Beverly Crusher' in ST:TNG _Remember Me_.


From nobody Tue Feb 21 17:45:06 2017
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 127401294D2; Tue, 21 Feb 2017 17:45:00 -0800 (PST)
X-Quarantine-ID: <1vzWfK52Lwnm>
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 1vzWfK52Lwnm; Tue, 21 Feb 2017 17:44:58 -0800 (PST)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 3CEBF1294E4; Tue, 21 Feb 2017 17:44:58 -0800 (PST)
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Tue, 21 Feb 2017 17:35:44 -0800
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <148738514545.19944.11486737065416495302.idtracker@ietfa.amsl.com>
References: <148738514545.19944.11486737065416495302.idtracker@ietfa.amsl.com>
X-Mailer: Eudora for Mac OS X
Date: Tue, 21 Feb 2017 17:44:42 -0800
To: "Dale Worley" , 
From: Randall Gellens 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
Archived-At: 
Cc: slim@ietf.org, ietf@ietf.org, draft-ietf-slim-negotiating-human-language.all@ietf.org
Subject: Re: [Slim] Review of draft-ietf-slim-negotiating-human-language-06
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Feb 2017 01:45:00 -0000

Hi Dale,

Thank you for your review, I appreciate it.  Please see inline.

At 6:32 PM -0800 2/17/17, Dale Worley wrote:

>  Reviewer: Dale Worley
>  Review result: Ready with Nits
>
>  I am the assigned Gen-ART reviewer for this draft.  The General Area
>  Review Team (Gen-ART) reviews all IETF documents being processed
>  by the IESG for the IETF Chair.  Please treat these comments just
>  like any other last call comments.
>
>  For more information, please see the FAQ at
>  .
>
>  Document:  draft-ietf-slim-negotiating-human-language-06
>  Reviewer:  Dale R. Worley
>  Review Date:  2017-02-17
>  IETF LC End Date:  2017-02-20
>  IESG Telechat date:  [unknown]
>
>  Summary:
>         This draft is basically ready for publication, but has nits
>         that should be fixed before publication.
>
>  * Technical comments
>
>  A. Call failure
>
>  If a call fails due to no available language match, in what way(s)
>  does it fail?  Section 5.3 says
>
>     If such an offer is received, the receiver MAY
>     reject the media, ignore the language specified, or attempt to
>     interpret the intent
>
>  But I suspect it's also allowed for the UAS to fail the call at the
>  SIP level.  Whether or not that is allowed (or at least envisioned)
>  should be described.  And what response code(s)/warn-code(s) should
>  be
>  used for that?

The text you quote has been deleted.  The draft does not mandate if 
the call should proceed or fail if there is no language match 
possible, although the draft does provide an optional mechanism to 
indicate the caller's preference that the call not fail, and the 
draft does mention that in the emergency services case, the call will 
likely proceed, but that's a matter of policy not protocol.

>
>  B. Audio/Video coordination
>
>     5.2.  New 'humintlang-send' and 'humintlang-recv' attributes
>
>     Note that while signed language tags are used with a video stream
>  to
>     indicate sign language, a spoken language tag for a video stream
>  in
>     parallel with an audio stream with the same spoken language tag
>     indicates a request for a supplemental video stream to see the
>     speaker.
>
>  And there's a similar paragraph in 5.4:
>
>>     A spoken language tag for a video stream in conjunction with an
>  audio
>>     stream with the same language might indicate a request for
>>     supplemental video to see the speaker.
>
>  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 seems to me that a
>  workable rule is that there is an audio stream and a video stream and
>  they specify exactly the same language tag in their respective
>  humintlang attributes.  In that case, it is a request for a spoken
>  language with simultaneous video of the speaker, and those requests
>  should be considered satisfied only if both streams can be
>  established.

The text you quote has been deleted.  A media stream for supplemental 
purposes can be negotiated without a language tag, as normal.

>
>  * The following three items are adjustments to the design which I'd
>  like to know have been considered.
>
>  C. "humintlang" seems long to me
>
>  Given the excessive length of SDP in practice, it seems to me that a
>  shorter attribute name would be desirable.  E.g., "humlang" as was
>  used in some previous versions.  Or is there a coordinated usage with
>  other names in the "hum*lang" pattern?

There is no intent for a coordinated pattern.  The name was chosen 
years ago to avoid potential confusion with the 'lang' attribute.  Is 
it worth reopening the issue to potentially save three characters per 
SDP line with a language?

>
>  D. Use the Accept-Language syntax
>
>  It seems to me that it would better to use the Accept-Language syntax
>  for the attribute values.  This allows (1) specifiying the quality of
>  language experience, allowing clear description of bilingualism, (2)
>  a
>  unified method of specifying whether or not arbitrary languages are
>  acceptable, and (3) abbreviating SDP descriptions.
>
>  In a way, the fact that the current proposal seems to require (but
>  does not directly specify) the coordinated absence/presence of an
>  asterisk on all of the repetitions of humintlang-send or
>  humintlang-recv is a warning that the syntax doesn't represent the
>  semantics as well as it might.

The group considered multiple proposals to permit specifying quality, 
preference, q-values, etc. but decided to keep things simple for this 
draft.  There is no intent to require the use of an asterisk (to 
indicate a preference by the caller to not fail the call).  The 
asterisk is a very mild mechanism with no normative effects.  It 
merely conveys the preference of the caller, and is not binding on 
the answerer.

>  E. Have an attribute to abbreviate the bidirectionally-symmetric case
>
>  Note that all examples are bidirectionally symmetric, and the text
>  says that requests and responses SHOULD be bidirectionally symmetric.
>  So it would be a very useful abbreviation to define
>  "humintlang=" to be equivalent to the combination of
>  "humintlang-send=" and "humintlang-recv=".
>
>  Combining proposals C, D, and E, the examples become
>
>        m=audio 49170 RTP/AVP 0
>        a=humlang:en
>
>        m=video 51372 RTP/AVP 31 32
>        a=humlang:ase,*;q=0.1
>
>        m=audio 49250 RTP/AVP 20
>        a=humlang:es,eu;q=0.9,en;q=0.8,*;q=0.1
>
>        m=text 45020 RTP/AVP 103 104
>        a=humlang:gr
>
>  which requires about half as many characters as they have now.

A third attribute without the "-send" or "-recv" to indicate 
bidirectionality would reduce the characters in the SDP block, at the 
cost of some added complexity (e.g., what if all three appear).  I 
don't believe this has been discussed in the group.

>  * Editorial comments and nits
>
>  Abstract
>
>     This document describes the need and a solution using new SDP
>  stream
>     attributes.
>
>  I don't think the term "stream attribute" is used in RFC 4566.
>  Instead, it uses "media attribute".

Fixed.

>  1.  Introduction
>
>     caller and callee know each other or there is contextual or out of
>     band information from which the language(s) and media modalities
>  can
>
>  I think this context, it's preferred to hyphenate "out-of-band" to
>  make it clearly be an adjective.

>  OK.


>     This approach has a number of benefits, including that it is
>  generic
>     (applies to all interactive communications negotiated using SDP)
>  and
>     not limited to emergency calls.
>
>  I think s/and not limited to/and is not limited to/ reads more
>  smoothly.

There's no harm in the extra "is" so I'm happy to add it.

>     But it is clearly useful in many other cases.  For
>     example, someone calling a company call center or a Public Safety
>     Answering Point (PSAP) should be able to indicate if one or more
>     specific signed, written, and/or spoken languages are preferred,
>  the
>     callee should be able to indicate its capabilities in this area,
>  and
>     the call proceed using in-common language(s) and media forms.
>
>  I think s/preferred, the callee/preferred; the callee/ because the
>  sentence is the concatenation of two sentences.

I reworded the sentence to flow better:

    For example, it is helpful that someone calling a company call center
    or a Public Safety Answering Point (PSAP) be able to indicate
    preferred signed, written, and/or spoken languages, the callee be
    able to indicate its capabilities in this area, and the call proceed
    using the language(s) and media forms supported by both.

>  Perhaps s/in-common/shared/.

Fixed in the rewording above.

>
>     Including the user's human (natural) language preferences in the
>     session establishment negotiation is independent of the use of a
>     relay service and is transparent to a voice service provider.
>
>  I think it's even broader than "transparent to a voice service
>  provider" -- it's transparent to any serivice provider, assuming that
>  the media are language-neutral.

I changed it to read "voice or other service provider".

>
>     In the case of a call to e.g., an airline, the call could be
>     automatically handled by a Spanish-speaking agent.
>
>  I think s/handled by/routed to/ is the usual usage.

We are trying to be careful in the draft to not imply that it is 
discussing call routing.  I'd rather keep the more generic "handled 
by".

>
>  3.  Desired Semantics
>
>     The desired solution is a media attribute (preferably per
>  direction)
>     that may be used within an offer to indicate the preferred
>  language
>     of each (direction of a) media stream, and within an answer to
>     indicate the accepted language.
>
>  In this one instance, I think you want to use "language(s)" to drive
>  home that that multiple languages can be specified:  "within an offer
>  to indicate the preferred language(s)".
>
>     (Negotiating multiple simultaneous languages within a media stream
>  is
>     out of scope, as the complexity of doing so outweighs the
>     usefulness.)
>
>  You might want to say instead "(Negotiating multiple simultaneous
>  languages within a media stream is out of scope for this document.)"
>  to ensure that nobody decides to argue whether "the complexity of
>  doing so outweighs the usefulness".

I agree and deleted "the complexity of doing so outweighs the usefulness".

>
>  4.  The existing 'lang' attribute
>
>     RFC 4566 [RFC4566] specifies an attribute 'lang' which appears
>     similar to what is needed here, but is not sufficiently detailed
>  for
>     use here.
>
>  "for use here" isn't quite right.  Maybe "is not sufficiently
>  specific
>  or flexible to satisfy the requirements".
>
>     In addition, it is not mentioned in [RFC3264]
>
>  "it" is somewhat ambiguous here, perhaps change to "the 'lang'
>  attribute".

OK, accepted both changes.

>
>  5.  Proposed Solution
>
>  Perhaps /Proposed Solution/Solution/, since once this draft is
>  approved, it becomes the solution.

OK.

>
>  5.2.  New 'humintlang-send' and 'humintlang-recv' attributes
>
>        a=humintlang-send:
>        a=humintlang-recv:
>
>  This is presented as the generic form of the attributes, but there is
>  no indication of the posible asterisk.

The syntax has been deleted from 5.2 since it's now in 6.

>
>     The values constitute a list of languages
>     in preference order (first is most preferred).
>
>  "The values" isn't very clear, because the values are in successive
>  attributes.  You want to say something like "The sequence of values
>  in
>  the occurrences of one of these attributes constitutes ...".
>  However,
>  see the technical comments above.

The text was reworded to read:

    The values from all
    instances of the attribute constitute a list of languages in
    preference order (first is most preferred).


>
>     When placing an emergency call, and in any other case where the
>     language cannot be assumed from context, each media stream in an
>     offer primarily intended for human language communication SHOULD
>     specify both (or in some cases, one of) the 'humintlang-send' and
>     'humintlang-recv' attributes.
>
>  Probably s/assumed/inferred/.

I agree.

>
>  Could you be more accurate by
>  s/or in some cases/or for unidirectional streams/?

I agree.

>
>  5.3.  Advisory vs Required
>
>     The mechanism for indicating this preference is that, in an offer,
>  if
>     the last character of any of the 'humintlang-recv' or 'humintlang-
>     send' values is an asterisk, this indicates a request to not fail
>  the
>     call (similar to SIP Accept-Language syntax).  Either way, the
>  called
>     party MAY ignore this, e.g., for the emergency services use case,
>  a
>     PSAP will likely not fail the call.
>
>  The construction of this paragraph isn't quite complete.  It says
>  that
>  if an asterisk is present, a request shouldn't fail, but it doesn't
>  say that if no asterisk is present, a request should fail if there is
>  no language match.  And it's the latter condition that makes the
>  second sentence meaningful.  So I think you want to insert between
>  the
>  two sentences one regarding the absence of an asterisk.

I've reworded the section to read:

    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 character of any of the 'humintlang-recv' or 'humintlang-
    send' values 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 with an asterisk.

>  5.5.  Examples
>
>  Given that the combined audio/video mechanism is the only
>  irregularity
>  in this system, there ought to be an example of it.  E.g.,
>
>     An example of a supplemental video stream with a spoken language
>     audio stream:
>
>        m=video 51372 RTP/AVP 31 32
>        a=humintlang-send:en
>        a=humintlang-recv:en
>
>        m=audio 49250 RTP/AVP 20
>        a=humintlang-send:en
>        a=humintlang-recv:en

If the video stream is supplemental then it doesn't have a language 
(the text that suggested otherwise has been deleted).  But I am 
considering adding more examples.

>
>  6.  IANA Considerations
>
>        humintlang-value =  Language-Tag [ asterisk ]
>                            ; Language-Tag defined in RFC 5646
>        asterisk         =  "*"
>
>  s/Language-Tag defined in RFC 5646/Language-Tag as defined in RFC
>  5646/
>
>  But perhaps also s/RFC 5646/BCP 47/, which ensures that "humintlang"
>  tracks the current version of language tags.

Ok.

>
>  Appendix A.  Historic Alternative Proposal: Caller-prefs
>
>     This
>     results in a more fragile solution since the media modality and
>     language would be negotiated using SIP, and then the specific
>  media
>     formats (which inherently include the modality) would be
>  negotiated
>     at a different level (typically SDP, especially in the emergency
>     calling cases), making it easier to have mismatches (such as where
>     the media modality negotiated in SIP don't match what was
>  negotiated
>     using SDP).
>
>  "the media modality and language would be negotiated using SIP" isn't
>  quite the right way to say it because SIP isn't explicitly
>  negotiating
>  the modality.  Better would be
>
>     ... the language (and by implication the media modality) would be
>     negotiated using SIP, and then the specific media (which
>  inherently
>     include the modalities and formats) would be negotiated at a
>     different level ...

This section has been deleted.

>
>  [END]


-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
I make a fortune from criticizing the policy of the government, and
then hand it over to the government in taxes to keep it going.
                                              --George Bernard Shaw


From nobody Wed Feb 22 02:57:56 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 846BC12968C for ; Wed, 22 Feb 2017 02:57:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 OqI9y1tjrE0T for ; Wed, 22 Feb 2017 02:57:45 -0800 (PST)
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 36C9E129697 for ; Wed, 22 Feb 2017 02:57:45 -0800 (PST)
X-Halon-ID: b8c0bedd-f8ed-11e6-af90-005056917f90
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [77.53.231.21]) by bin-vsp-out-02.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Wed, 22 Feb 2017 11:57:35 +0100 (CET)
To: Randall Gellens , Dale Worley , gen-art@ietf.org
References: <148738514545.19944.11486737065416495302.idtracker@ietfa.amsl.com> 
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: 
Date: Wed, 22 Feb 2017 11:57:36 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: slim@ietf.org, ietf@ietf.org, draft-ietf-slim-negotiating-human-language.all@ietf.org
Subject: Re: [Slim] Review of draft-ietf-slim-negotiating-human-language-06
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Feb 2017 10:57:49 -0000

A few comments inline,


Den 2017-02-22 kl. 02:44, skrev Randall Gellens:
> Hi Dale,
>
> Thank you for your review, I appreciate it.  Please see inline.
>
> At 6:32 PM -0800 2/17/17, Dale Worley wrote:
>
>>  Reviewer: Dale Worley
>>  Review result: Ready with Nits
>>
>>  I am the assigned Gen-ART reviewer for this draft.  The General Area
>>  Review Team (Gen-ART) reviews all IETF documents being processed
>>  by the IESG for the IETF Chair.  Please treat these comments just
>>  like any other last call comments.
>>
>>  For more information, please see the FAQ at
>>  .
>>
>>  Document:  draft-ietf-slim-negotiating-human-language-06
>>  Reviewer:  Dale R. Worley
>>  Review Date:  2017-02-17
>>  IETF LC End Date:  2017-02-20
>>  IESG Telechat date:  [unknown]
>>
>>  Summary:
>>         This draft is basically ready for publication, but has nits
>>         that should be fixed before publication.
>>
>>  * Technical comments
>>
>>  A. Call failure
>>
>>  If a call fails due to no available language match, in what way(s)
>>  does it fail?  Section 5.3 says
>>
>>     If such an offer is received, the receiver MAY
>>     reject the media, ignore the language specified, or attempt to
>>     interpret the intent
>>
>>  But I suspect it's also allowed for the UAS to fail the call at the
>>  SIP level.  Whether or not that is allowed (or at least envisioned)
>>  should be described.  And what response code(s)/warn-code(s) should
>>  be
>>  used for that?
>
> The text you quote has been deleted.  The draft does not mandate if 
> the call should proceed or fail if there is no language match 
> possible, although the draft does provide an optional mechanism to 
> indicate the caller's preference that the call not fail, and the draft 
> does mention that in the emergency services case, the call will likely 
> proceed, but that's a matter of policy not protocol.
You may have a version where it is proposed that the text is deleted. We 
need to see that new text and agree if it was good to delete it.

There are more places in the draft where failing the call is mentioned, 
so the question about how it is failed is relevant anyway. A 603 Decline 
from the proxy would likely be the natural way to fail the call when it 
is because of lack of matching languages. But I do not see any natural 
way for an addressed UA to signal this.

>
>>
>>  B. Audio/Video coordination
>>
>>     5.2.  New 'humintlang-send' and 'humintlang-recv' attributes
>>
>>     Note that while signed language tags are used with a video stream
>>  to
>>     indicate sign language, a spoken language tag for a video stream
>>  in
>>     parallel with an audio stream with the same spoken language tag
>>     indicates a request for a supplemental video stream to see the
>>     speaker.
>>
>>  And there's a similar paragraph in 5.4:
>>
>>>     A spoken language tag for a video stream in conjunction with an
>>  audio
>>>     stream with the same language might indicate a request for
>>>     supplemental video to see the speaker.
>>
>>  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 seems to me that a
>>  workable rule is that there is an audio stream and a video stream and
>>  they specify exactly the same language tag in their respective
>>  humintlang attributes.  In that case, it is a request for a spoken
>>  language with simultaneous video of the speaker, and those requests
>>  should be considered satisfied only if both streams can be
>>  established.
>
> The text you quote has been deleted.  A media stream for supplemental 
> purposes can be negotiated without a language tag, as normal.
>
The text should not be deleted just because it is under discussion.
It is a valid and valuable alternative. At the moment we lack ways to 
indicate if languages are wanted together or seen as separate 
alternatives, and we have said that such detailing can be added in 
future versions or additional specifications if not done now. Therefore 
we had better allow this combination and let the negotiating parties 
sort out what it currently means. The specification just indicates that 
the indicated languages are alternatives, and any number may be selected 
for matching and usage in the session.
I do not think we should require very exactly matching language tags 
between spoken language in audio and corresponding view of the speaker 
in video.
>>
>>  * The following three items are adjustments to the design which I'd
>>  like to know have been considered.
>>
>>  C. "humintlang" seems long to me
>>
>>  Given the excessive length of SDP in practice, it seems to me that a
>>  shorter attribute name would be desirable.  E.g., "humlang" as was
>>  used in some previous versions.  Or is there a coordinated usage with
>>  other names in the "hum*lang" pattern?
>
> There is no intent for a coordinated pattern.  The name was chosen 
> years ago to avoid potential confusion with the 'lang' attribute. Is 
> it worth reopening the issue to potentially save three characters per 
> SDP line with a language?
>
>>
>>  D. Use the Accept-Language syntax
>>
>>  It seems to me that it would better to use the Accept-Language syntax
>>  for the attribute values.  This allows (1) specifiying the quality of
>>  language experience, allowing clear description of bilingualism, (2)
>>  a
>>  unified method of specifying whether or not arbitrary languages are
>>  acceptable, and (3) abbreviating SDP descriptions.
>>
>>  In a way, the fact that the current proposal seems to require (but
>>  does not directly specify) the coordinated absence/presence of an
>>  asterisk on all of the repetitions of humintlang-send or
>>  humintlang-recv is a warning that the syntax doesn't represent the
>>  semantics as well as it might.
>
> The group considered multiple proposals to permit specifying quality, 
> preference, q-values, etc. but decided to keep things simple for this 
> draft.  There is no intent to require the use of an asterisk (to 
> indicate a preference by the caller to not fail the call).  The 
> asterisk is a very mild mechanism with no normative effects.  It 
> merely conveys the preference of the caller, and is not binding on the 
> answerer.
I would never dare to use an sdp without an asterisk. Language matching 
is a tricky thing and human capabilities much wider than the language 
tags can express. If I get a call from a Norwegian user talking 
Norwegian and indicating Norwegian in the humintlang attributes, I want 
to get the call accepted by my device with setting for spoken Swedish, 
because Swedes and Norwegians usually can communicate quite well 
speaking their own languages. I would anyway not have imagined making a 
setting for Norwegian language as a preference in my device.
It will however be an excellent help for me to see the indication of the 
Norwegian, when I get the call, so I can tune my listening.
By setting the asterisk somewhere among the Humintlang attributes, I 
will make sure that I do not lose calls that I could handle.

>
>>  E. Have an attribute to abbreviate the bidirectionally-symmetric case
>>
>>  Note that all examples are bidirectionally symmetric, and the text
>>  says that requests and responses SHOULD be bidirectionally symmetric.
>>  So it would be a very useful abbreviation to define
>>  "humintlang=" to be equivalent to the combination of
>>  "humintlang-send=" and "humintlang-recv=".
>>
>>  Combining proposals C, D, and E, the examples become
>>
>>        m=audio 49170 RTP/AVP 0
>>        a=humlang:en
>>
>>        m=video 51372 RTP/AVP 31 32
>>        a=humlang:ase,*;q=0.1
>>
>>        m=audio 49250 RTP/AVP 20
>>        a=humlang:es,eu;q=0.9,en;q=0.8,*;q=0.1
>>
>>        m=text 45020 RTP/AVP 103 104
>>        a=humlang:gr
>>
>>  which requires about half as many characters as they have now.
>
> A third attribute without the "-send" or "-recv" to indicate 
> bidirectionality would reduce the characters in the SDP block, at the 
> cost of some added complexity (e.g., what if all three appear).  I 
> don't believe this has been discussed in the group.
>
>>  * Editorial comments and nits
>>
>>  Abstract
>>
>>     This document describes the need and a solution using new SDP
>>  stream
>>     attributes.
>>
>>  I don't think the term "stream attribute" is used in RFC 4566.
>>  Instead, it uses "media attribute".
>
> Fixed.
>
>>  1.  Introduction
>>
>>     caller and callee know each other or there is contextual or out of
>>     band information from which the language(s) and media modalities
>>  can
>>
>>  I think this context, it's preferred to hyphenate "out-of-band" to
>>  make it clearly be an adjective.
>
>>  OK.
>
>
>>     This approach has a number of benefits, including that it is
>>  generic
>>     (applies to all interactive communications negotiated using SDP)
>>  and
>>     not limited to emergency calls.
>>
>>  I think s/and not limited to/and is not limited to/ reads more
>>  smoothly.
>
> There's no harm in the extra "is" so I'm happy to add it.
>
>>     But it is clearly useful in many other cases.  For
>>     example, someone calling a company call center or a Public Safety
>>     Answering Point (PSAP) should be able to indicate if one or more
>>     specific signed, written, and/or spoken languages are preferred,
>>  the
>>     callee should be able to indicate its capabilities in this area,
>>  and
>>     the call proceed using in-common language(s) and media forms.
>>
>>  I think s/preferred, the callee/preferred; the callee/ because the
>>  sentence is the concatenation of two sentences.
>
> I reworded the sentence to flow better:
>
>    For example, it is helpful that someone calling a company call center
>    or a Public Safety Answering Point (PSAP) be able to indicate
>    preferred signed, written, and/or spoken languages, the callee be
>    able to indicate its capabilities in this area, and the call proceed
>    using the language(s) and media forms supported by both.
>
>>  Perhaps s/in-common/shared/.
>
> Fixed in the rewording above.
>
>>
>>     Including the user's human (natural) language preferences in the
>>     session establishment negotiation is independent of the use of a
>>     relay service and is transparent to a voice service provider.
>>
>>  I think it's even broader than "transparent to a voice service
>>  provider" -- it's transparent to any serivice provider, assuming that
>>  the media are language-neutral.
>
> I changed it to read "voice or other service provider".
>
>>
>>     In the case of a call to e.g., an airline, the call could be
>>     automatically handled by a Spanish-speaking agent.
>>
>>  I think s/handled by/routed to/ is the usual usage.
>
> We are trying to be careful in the draft to not imply that it is 
> discussing call routing.  I'd rather keep the more generic "handled by".
>
>>
>>  3.  Desired Semantics
>>
>>     The desired solution is a media attribute (preferably per
>>  direction)
>>     that may be used within an offer to indicate the preferred
>>  language
>>     of each (direction of a) media stream, and within an answer to
>>     indicate the accepted language.
>>
>>  In this one instance, I think you want to use "language(s)" to drive
>>  home that that multiple languages can be specified:  "within an offer
>>  to indicate the preferred language(s)".
>>
>>     (Negotiating multiple simultaneous languages within a media stream
>>  is
>>     out of scope, as the complexity of doing so outweighs the
>>     usefulness.)
>>
>>  You might want to say instead "(Negotiating multiple simultaneous
>>  languages within a media stream is out of scope for this document.)"
>>  to ensure that nobody decides to argue whether "the complexity of
>>  doing so outweighs the usefulness".
>
> I agree and deleted "the complexity of doing so outweighs the 
> usefulness".
>
>>
>>  4.  The existing 'lang' attribute
>>
>>     RFC 4566 [RFC4566] specifies an attribute 'lang' which appears
>>     similar to what is needed here, but is not sufficiently detailed
>>  for
>>     use here.
>>
>>  "for use here" isn't quite right.  Maybe "is not sufficiently
>>  specific
>>  or flexible to satisfy the requirements".
>>
>>     In addition, it is not mentioned in [RFC3264]
>>
>>  "it" is somewhat ambiguous here, perhaps change to "the 'lang'
>>  attribute".
>
> OK, accepted both changes.
>
>>
>>  5.  Proposed Solution
>>
>>  Perhaps /Proposed Solution/Solution/, since once this draft is
>>  approved, it becomes the solution.
>
> OK.
>
>>
>>  5.2.  New 'humintlang-send' and 'humintlang-recv' attributes
>>
>>        a=humintlang-send:
>>        a=humintlang-recv:
>>
>>  This is presented as the generic form of the attributes, but there is
>>  no indication of the posible asterisk.
>
> The syntax has been deleted from 5.2 since it's now in 6.
I think it should not be deleted, but instead Dale's comment satisfied.  
That would be more in line with the stye of rfc4566bis.
5.2 shows the complete attributes, and that is good. Chapter 6 only 
shows the syntax of the value.
>
>>
>>     The values constitute a list of languages
>>     in preference order (first is most preferred).
>>
>>  "The values" isn't very clear, because the values are in successive
>>  attributes.  You want to say something like "The sequence of values
>>  in
>>  the occurrences of one of these attributes constitutes ...".
>>  However,
>>  see the technical comments above.
>
> The text was reworded to read:
>
>    The values from all
>    instances of the attribute constitute a list of languages in
>    preference order (first is most preferred).
>
>
>>
>>     When placing an emergency call, and in any other case where the
>>     language cannot be assumed from context, each media stream in an
>>     offer primarily intended for human language communication SHOULD
>>     specify both (or in some cases, one of) the 'humintlang-send' and
>>     'humintlang-recv' attributes.
>>
>>  Probably s/assumed/inferred/.
>
> I agree.
>
>>
>>  Could you be more accurate by
>>  s/or in some cases/or for unidirectional streams/?
>
> I agree.
>
>>
>>  5.3.  Advisory vs Required
>>
>>     The mechanism for indicating this preference is that, in an offer,
>>  if
>>     the last character of any of the 'humintlang-recv' or 'humintlang-
>>     send' values is an asterisk, this indicates a request to not fail
>>  the
>>     call (similar to SIP Accept-Language syntax).  Either way, the
>>  called
>>     party MAY ignore this, e.g., for the emergency services use case,
>>  a
>>     PSAP will likely not fail the call.
>>
>>  The construction of this paragraph isn't quite complete.  It says
>>  that
>>  if an asterisk is present, a request shouldn't fail, but it doesn't
>>  say that if no asterisk is present, a request should fail if there is
>>  no language match.  And it's the latter condition that makes the
>>  second sentence meaningful.  So I think you want to insert between
>>  the
>>  two sentences one regarding the absence of an asterisk.
>
> I've reworded the section to read:
>
>    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 character of any of the 'humintlang-recv' or 'humintlang-
>    send' values 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 with an asterisk.
This still does not meet Dale's comment.
Insert a sentence saying:
"A preference for getting the call denied in case of no language match 
SHOULD be indicated by no asterisk appended on any humintlang attribute 
value in the whole SDP."
>
>>  5.5.  Examples
>>
>>  Given that the combined audio/video mechanism is the only
>>  irregularity
>>  in this system, there ought to be an example of it.  E.g.,
>>
>>     An example of a supplemental video stream with a spoken language
>>     audio stream:
>>
>>        m=video 51372 RTP/AVP 31 32
>>        a=humintlang-send:en
>>        a=humintlang-recv:en
>>
>>        m=audio 49250 RTP/AVP 20
>>        a=humintlang-send:en
>>        a=humintlang-recv:en
>
> If the video stream is supplemental then it doesn't have a language 
> (the text that suggested otherwise has been deleted). But I am 
> considering adding more examples.
I provided a rich set of examples in my LC comments of Feb 13. Please 
consider them as a base even if some need revision if the proposed 
extended meaning of the asterisk is not accepted.
>
>>
>>  6.  IANA Considerations
>>
>>        humintlang-value =  Language-Tag [ asterisk ]
>>                            ; Language-Tag defined in RFC 5646
>>        asterisk         =  "*"
>>
>>  s/Language-Tag defined in RFC 5646/Language-Tag as defined in RFC
>>  5646/
>>
>>  But perhaps also s/RFC 5646/BCP 47/, which ensures that "humintlang"
>>  tracks the current version of language tags.
>
> Ok.
>
>>
>>  Appendix A.  Historic Alternative Proposal: Caller-prefs
>>
>>     This
>>     results in a more fragile solution since the media modality and
>>     language would be negotiated using SIP, and then the specific
>>  media
>>     formats (which inherently include the modality) would be
>>  negotiated
>>     at a different level (typically SDP, especially in the emergency
>>     calling cases), making it easier to have mismatches (such as where
>>     the media modality negotiated in SIP don't match what was
>>  negotiated
>>     using SDP).
>>
>>  "the media modality and language would be negotiated using SIP" isn't
>>  quite the right way to say it because SIP isn't explicitly
>>  negotiating
>>  the modality.  Better would be
>>
>>     ... the language (and by implication the media modality) would be
>>     negotiated using SIP, and then the specific media (which
>>  inherently
>>     include the modalities and formats) would be negotiated at a
>>     different level ...
>
> This section has been deleted.
Did we agree on that?
>
>>
>>  [END]
>
>
Regards
Gunnar

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


From nobody Wed Feb 22 02:59: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 75CC51296DD for ; Wed, 22 Feb 2017 02:59:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.911
X-Spam-Level: 
X-Spam-Status: No, score=-2.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gsmasso.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nbX7TmJsqRqN for ; Wed, 22 Feb 2017 02:59:41 -0800 (PST)
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0088.outbound.protection.outlook.com [104.47.1.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BF4B129697 for ; Wed, 22 Feb 2017 02:59:41 -0800 (PST)
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=rR6o7OT+qZity7VgkYfiC/4gCkApdvX3qhZKfH+uhfE=; b=XFu/njkg+QnLABT0hBI0qI8JGuwcCV/VBp63pUGzWTi9Ovd4ES+VY0mLeSd/HXRN81UxBGlLZk0wU/oZpKlhh5EKY8g6P4KWjXFzZ7tXVauGqYyawP6AHkJFD8rjZbJNiFNeijlFbqA2Q/SKgfcCbTCrYhkrv23CjLBKSCHFpkI=
Received: from HE1PR04MB3113.eurprd04.prod.outlook.com (10.171.196.31) by HE1PR04MB3115.eurprd04.prod.outlook.com (10.171.196.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.919.13; Wed, 22 Feb 2017 10:59:38 +0000
Received: from HE1PR04MB3113.eurprd04.prod.outlook.com ([10.171.196.31]) by HE1PR04MB3113.eurprd04.prod.outlook.com ([10.171.196.31]) with mapi id 15.01.0919.018; Wed, 22 Feb 2017 10:59:38 +0000
From: Natasha Rooney 
To: "slim@ietf.org" 
Thread-Topic: Shortening humintlang
Thread-Index: AQHSjPrCxT1L2lbSdEifVWD6cDQm0w==
Date: Wed, 22 Feb 2017 10:59:38 +0000
Message-ID: <0D2E61DC-1A6D-4B9C-8072-589D702AB54A@gsma.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-mailer: Apple Mail (2.3259)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=nrooney@gsma.com; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [62.189.0.100]
x-ms-office365-filtering-correlation-id: 107e6dd8-0206-4f20-8ad4-08d45b11e57a
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:HE1PR04MB3115;
x-microsoft-exchange-diagnostics: 1; HE1PR04MB3115; 7:52m0NIgKDMrs/1w6synxMaHhZCm0ENbi1QqMgiY+JwToiXQPeMHIVeDsRSKjhKFIv1O44qdYcKZNkjNHjzIOBuk+IwnQNwszYjgivgo10rKf4sRdkjFr43CgsNCFELe9D20W9tmyQuvctBS61BGREyhJvCNHQrcb3qxrNU3QnXtg3+uEfN/qhunST+jydSWrM5yY7KlnuFCJ9FKpNvnp/yaQ9x4Gb4/s0555T2IlX+iVK59vDlegz41Cil19FpWgPiEiYjUlISVKyIEj9tdBa+wAzt4mlGghKwuAPhR5yTZDMlexxUAdeh6Npjj0zLUQVMUM6ye6TPZRlNDvjLThBw==
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123558025)(20161123560025)(6072148); SRVR:HE1PR04MB3115; BCL:0; PCL:0; RULEID:; SRVR:HE1PR04MB3115; 
x-forefront-prvs: 022649CC2C
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(39450400003)(53754006)(199003)(189002)(6512007)(5640700003)(5890100001)(6436002)(83716003)(92566002)(3660700001)(77096006)(3280700002)(236005)(8676002)(2906002)(99286003)(2900100001)(6486002)(54896002)(2501003)(50226002)(1730700003)(25786008)(86362001)(81166006)(8936002)(189998001)(97736004)(3480700004)(81156014)(68736007)(66066001)(221733001)(6506006)(6116002)(53936002)(106356001)(2351001)(57306001)(110136004)(6916009)(38730400002)(102836003)(7736002)(3846002)(106116001)(105586002)(101416001)(5660300001)(50986999)(7116003)(122556002)(33656002)(450100001)(82746002)(36756003)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR04MB3115; H:HE1PR04MB3113.eurprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: gsma.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_0D2E61DC1A6D4B9C8072589D702AB54Agsmacom_"
MIME-Version: 1.0
X-OriginatorOrg: gsma.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Feb 2017 10:59:38.7416 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72a4ff82-fec3-469d-aafb-ac8276216699
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR04MB3115
X-MS-Exchange-CrossPremises-AuthAs: Internal
X-MS-Exchange-CrossPremises-AuthMechanism: 04
X-MS-Exchange-CrossPremises-AuthSource: HE1PR04MB3113.eurprd04.prod.outlook.com
X-MS-Exchange-CrossPremises-SCL: 1
X-MS-Exchange-CrossPremises-messagesource: StoreDriver
X-MS-Exchange-CrossPremises-BCC: 
X-MS-Exchange-CrossPremises-originalclientipaddress: 62.189.0.100
X-MS-Exchange-CrossPremises-avstamp-service: 1.0
X-MS-Exchange-CrossPremises-disclaimer-hash: 78ca8040c6722e32c2f5b0a45bf37e74b9409d645a53be96aa19958e0cee0f00
X-MS-Exchange-CrossPremises-antispam-scancontext: DIR:Originating; SFV:NSPM; SKIP:0; 
X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent
X-OrganizationHeadersPreserved: HE1PR04MB3115.eurprd04.prod.outlook.com
Archived-At: 
Subject: [Slim] Shortening humintlang
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Feb 2017 10:59:43 -0000

--_000_0D2E61DC1A6D4B9C8072589D702AB54Agsmacom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi all,

We had this request from the Gen-ART reviewer for raft-ietf-slim-negotiatin=
g-human-language-06:

C. "humintlang" seems long to me

Given the excessive length of SDP in practice, it seems to me that a
shorter attribute name would be desirable.  E.g., "humlang" as was
used in some previous versions.  Or is there a coordinated usage with
other names in the "hum*lang" pattern?

Wdyt?

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


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

--_000_0D2E61DC1A6D4B9C8072589D702AB54Agsmacom_
Content-Type: text/html; charset="us-ascii"
Content-ID: <27B4AA1A4F9A59478DD32F905A377680@eurprd04.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable






Hi all,






We had this request from the Gen-ART reviewer for raft=
-ietf-slim-negotiating-human-language-06:







C. "humintlang" seems long to me



Given the excessive length of SDP in practice, it seems to me that a

shorter attribute name would be desirable.  E.g., "humlang" =
as was

used in some previous versions.  Or is there a coordinated usage with<=
br class=3D"">
other names in the "hum*lang" pattern?







Wdyt?







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








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




--_000_0D2E61DC1A6D4B9C8072589D702AB54Agsmacom_--


From nobody Wed Feb 22 03:18:05 2017
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EFB01296DC for ; Wed, 22 Feb 2017 03:18:03 -0800 (PST)
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 AksL8ojtSL66 for ; Wed, 22 Feb 2017 03:18:00 -0800 (PST)
Received: from bin-vsp-out-03.atm.binero.net (bin-mail-out-06.binero.net [195.74.38.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56C5B12968C for ; Wed, 22 Feb 2017 03:18:00 -0800 (PST)
X-Halon-ID: 9050ba60-f8f0-11e6-9c99-0050569116f7
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [77.53.231.21]) by bin-vsp-out-03.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Wed, 22 Feb 2017 12:17:57 +0100 (CET)
To: Natasha Rooney , "slim@ietf.org" 
References: <0D2E61DC-1A6D-4B9C-8072-589D702AB54A@gsma.com>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: <6ff2e293-5f36-bb44-3108-3c0937eb58da@omnitor.se>
Date: Wed, 22 Feb 2017 12:17:55 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <0D2E61DC-1A6D-4B9C-8072-589D702AB54A@gsma.com>
Content-Type: multipart/alternative; boundary="------------876C741D267EF138B15738B5"
Archived-At: 
Subject: Re: [Slim] Shortening humintlang
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Feb 2017 11:18:03 -0000

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

Den 2017-02-22 kl. 11:59, skrev Natasha Rooney:
> Hi all,
>
> We had this request from the Gen-ART reviewer 
> for raft-ietf-slim-negotiating-human-language-06:
>
> C. "humintlang" seems long to me
>
> Given the excessive length of SDP in practice, it seems to me that a
> shorter attribute name would be desirable.  E.g., "humlang" as was
> used in some previous versions.  Or is there a coordinated usage with
> other names in the "hum*lang" pattern?
>
> Wdyt?
I have also had thoughts in the same direction.  Especially when we 
quite late decided to have only one language tag value per attribute, 
the consumption of characters for SDP increased dramatically.
It is a good habit to have attribute names that are real words, but we 
have problems inventing such names for this case.

The "hum" part is in fact redundant.  So, maybe Intlang-send and 
Intlang-recv    for Interactive-language  would be an acceptable 
shortening of the names.

The proposal to return to the Accept-Language syntax, with the 
possibility to list all languages in one media and direction on one line 
would save us meven more, and should also be considered, I think.

Think about an outgoing call from a clever multi-language call-center 
with capability in 15 languages, both spoken and written.

/Gunnar
>
> Natasha Rooney | Internet Engineering Director | Internet and Web Team 
> | Technology | GSMA | nrooney@gsma.com  | +44 
> (0) 7730 219 765 | @thisNatasha | Skype: nrooney@gsm.org 
> 
>
> This email and its attachments are intended for the above named only 
> and may be confidential. If they have come to you in error you must 
> take no action based on them, nor must you copy or show them to 
> anyone; please reply to this email or call +44 207 356 0600 and 
> highlight the error.
>
>
>
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim

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


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


  
    
  
  
    Den 2017-02-22 kl. 11:59, skrev Natasha Rooney:

    

      
      Hi all,
      


      

      
We had this request from the Gen-ART reviewer
        for raft-ietf-slim-negotiating-human-language-06:

      


      

      
C. "humintlang" seems long to me

        

        Given the excessive length of SDP in practice, it seems to me
        that a

        shorter attribute name would be desirable.  E.g., "humlang" as
        was

        used in some previous versions.  Or is there a coordinated usage
        with

        other names in the "hum*lang" pattern?

      


      

      
Wdyt?

      

    

    I have also had thoughts in the same direction.  Especially when we
    quite late decided to have only one language tag value per
    attribute, the consumption of characters for SDP increased
    dramatically.  

    It is a good habit to have attribute names that are real words, but
    we have problems inventing such names for this case. 

    

    The "hum" part is in fact redundant.  So, maybe Intlang-send and
    Intlang-recv    for Interactive-language  would be an acceptable
    shortening of the names.

    

    The proposal to return to the Accept-Language syntax, with the
    possibility to list all languages in one media and direction on one
    line would save us meven more, and should also be considered, I
    think.    

    

    Think about an outgoing call from a clever multi-language
    call-center with capability in 15 languages, both spoken and
    written.  

    

    /Gunnar 

    

      

        

          

            

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

        

        

      

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

      

      

      

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


    

    

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

  


--------------876C741D267EF138B15738B5--


From nobody Wed Feb 22 07:27:18 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 E9572129A1B for ; Wed, 22 Feb 2017 07:27:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U32AWARUBQqH for ; Wed, 22 Feb 2017 07:27:15 -0800 (PST)
Received: from mail-qt0-x241.google.com (mail-qt0-x241.google.com [IPv6:2607:f8b0:400d:c0d::241]) (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 0689F129A0C for ; Wed, 22 Feb 2017 07:27:15 -0800 (PST)
Received: by mail-qt0-x241.google.com with SMTP id n37so786372qtb.3 for ; Wed, 22 Feb 2017 07:27:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=bNNEa45nnJKIXNvbemcUFZVu7DfAWJS7+/eYz+Gqf8w=; b=zh+8aP7/mA8V1gg6SOGqceDg8+E0UeNL1KndIqYj/3Ryr/b/1E/grsSKHz4iGYOiBp 9QfqAKks7Vp2Dgfz+PqHycoxuzIa7pUAiWpU+DG/pk1U+AKfX9Z3I+ApVTHf3C+4BCP4 APFhyAJit1+SnPshgU6Lw/BwZD7JOAwlPW+mf9+yac5VLX24+3ArjPmYVc5ONQdvuqKB 3K/WAQ12zYskqkR86KJzo26tG/kR9ZZpPC8ygPqyDMq4ZxdRjF/pxHt26M4v2dZAfPIs x4RShDZSN7Vnv4GJr97sMYUYvoL1fhLwLgNjb9tl4bAUvJeRmIApuOhW3LhZ7HIKJG1n 3QUg==
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 :message-id:references:to; bh=bNNEa45nnJKIXNvbemcUFZVu7DfAWJS7+/eYz+Gqf8w=; b=HXDV9noa63y8ZrOGCwC5wI/enHd39BLhnuT+53T1X+uQ1wrMuZzu7I0ZIJwBvlPbuL qVX+o9X5JpMuPiCeSmHijEjWF2NCyFblrauXoQhHpV2k7PZ6O/F4Mc/4Zd4+kTvcmT/S juFxOEVbEb15/C6i4nip1RbQ99VBjYA+1p91WA1dhw0K9vxYjs0mqYAO+Uyjrg1yVVuf zphgeruAb70VkrQkKnBkZtinuTGt9H5N1580OucuO6EtAkgd3CmmI4LsYebTrC2D/0Kw E+uI1dBleI05NpobY4y575jA4BcwFiWNxF/v+gL9gwOUo8SsNxbQk/iVKZFLSvAx42NB 51Lg==
X-Gm-Message-State: AMke39nT8X1z38lAYOSfNLFqO3dTbJ6UwpxJazAUST3HT4Ghy0jyuk0a1yiYsYCCaEt5vQ==
X-Received: by 10.200.45.135 with SMTP id p7mr11072176qta.141.1487777234076; Wed, 22 Feb 2017 07:27:14 -0800 (PST)
Received: from [10.96.43.71] ([156.154.81.54]) by smtp.gmail.com with ESMTPSA id 13sm855712qtn.57.2017.02.22.07.27.13 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 22 Feb 2017 07:27:13 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_B174ECC3-7C8D-453D-9AA3-CBF485DAA69F"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Brian Rosen 
In-Reply-To: <6ff2e293-5f36-bb44-3108-3c0937eb58da@omnitor.se>
Date: Wed, 22 Feb 2017 10:27:12 -0500
Message-Id: 
References: <0D2E61DC-1A6D-4B9C-8072-589D702AB54A@gsma.com> <6ff2e293-5f36-bb44-3108-3c0937eb58da@omnitor.se>
To: =?utf-8?Q?Gunnar_Hellstr=C3=B6m?= 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: "slim@ietf.org" , Natasha Rooney 
Subject: Re: [Slim] Shortening humintlang
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Feb 2017 15:27:17 -0000

--Apple-Mail=_B174ECC3-7C8D-453D-9AA3-CBF485DAA69F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

I don=92t have any problem shortening the name, but I do think retaining =
=93human=94 is important because we have always had problems confusing =
the =93Accept-Language=94 header.

How about =91hlang'?  Or 'hilang' if you must. =20

Brian


> On Feb 22, 2017, at 6:17 AM, Gunnar Hellstr=F6m =
 wrote:
>=20
> Den 2017-02-22 kl. 11:59, skrev Natasha Rooney:
>> Hi all,
>>=20
>> We had this request from the Gen-ART reviewer for =
raft-ietf-slim-negotiating-human-language-06:
>>=20
>> C. "humintlang" seems long to me
>>=20
>> Given the excessive length of SDP in practice, it seems to me that a
>> shorter attribute name would be desirable.  E.g., "humlang" as was
>> used in some previous versions.  Or is there a coordinated usage with
>> other names in the "hum*lang" pattern?
>>=20
>> Wdyt?
> I have also had thoughts in the same direction.  Especially when we =
quite late decided to have only one language tag value per attribute, =
the consumption of characters for SDP increased dramatically. =20
> It is a good habit to have attribute names that are real words, but we =
have problems inventing such names for this case.=20
>=20
> The "hum" part is in fact redundant.  So, maybe Intlang-send and =
Intlang-recv    for Interactive-language  would be an acceptable =
shortening of the names.
>=20
> The proposal to return to the Accept-Language syntax, with the =
possibility to list all languages in one media and direction on one line =
would save us meven more, and should also be considered, I     think.   =20=

>=20
> Think about an outgoing call from a clever multi-language call-center =
with capability in 15 languages, both spoken and written. =20
>=20
> /Gunnar=20
>>=20
>> Natasha Rooney | Internet Engineering Director | Internet and Web =
Team | Technology | GSMA | nrooney@gsma.com  | =
+44 (0) 7730 219 765 | @thisNatasha | Skype: nrooney@gsm.org =

>> This email and its attachments are intended for the above named only =
and may be confidential. If they have come to you in error you must take =
no action based on them, nor must you copy or show them to anyone; =
please reply to this email or call +44 207 356 0600 and highlight the =
error.
>>=20
>>=20
>>=20
>> _______________________________________________
>> SLIM mailing list
>> SLIM@ietf.org 
>> https://www.ietf.org/mailman/listinfo/slim =

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


--Apple-Mail=_B174ECC3-7C8D-453D-9AA3-CBF485DAA69F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

I don=92t have any problem shortening the name, but I do =
think retaining =93human=94 is important because we have always had =
problems confusing the =93Accept-Language=94 header.

How about =91hlang'?  Or 'hilang' =
if you must.  

Brian


On Feb 22, 2017, at 6:17 AM, Gunnar Hellstr=F6m <gunnar.hellstrom@omnitor.se> wrote:


 =20
    
 =20
  

    Den 2017-02-22 kl. 11:59, skrev Natasha Rooney:

    

      
      Hi all,
      


      

      
We had this request from the Gen-ART reviewer
        for raft-ietf-slim-negotiating-human-language-06:

      


      

      
C. "humintlang" seems long to me

        

        Given the excessive length of SDP in practice, it seems to me
        that a

        shorter attribute name would be desirable.  E.g., "humlang" =
as
        was

        used in some previous versions.  Or is there a coordinated =
usage
        with

        other names in the "hum*lang" pattern?

      


      

      
Wdyt?

      

    

    I have also had thoughts in the same direction.  Especially =
when we
    quite late decided to have only one language tag value per
    attribute, the consumption of characters for SDP increased
    dramatically.  

    It is a good habit to have attribute names that are real words, but
    we have problems inventing such names for this case. 

    

    The "hum" part is in fact redundant.  So, maybe Intlang-send =
and
    Intlang-recv    for Interactive-language  would be an =
acceptable
    shortening of the names.

    

    The proposal to return to the Accept-Language syntax, with the
    possibility to list all languages in one media and direction on one
    line would save us meven more, and should also be considered, I
    think.    

    

    Think about an outgoing call from a clever multi-language
    call-center with capability in 15 languages, both spoken and
    written.  

    

    /Gunnar 

    

      

        

          

            

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

        

        

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

      

      

      

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


    

    

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

  


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

=

--Apple-Mail=_B174ECC3-7C8D-453D-9AA3-CBF485DAA69F--


From nobody Wed Feb 22 08:34: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 CB18A1295DB for ; Wed, 22 Feb 2017 08:34:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.786
X-Spam-Level: 
X-Spam-Status: No, score=-8.786 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-1.887] 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 Ar2hsLM0iLSY for ; Wed, 22 Feb 2017 08:34:49 -0800 (PST)
Received: from smtp-fw-9102.amazon.com (smtp-fw-9102.amazon.com [207.171.184.29]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 473331294FD for ; Wed, 22 Feb 2017 08:34:49 -0800 (PST)
X-IronPort-AV: E=Sophos;i="5.35,195,1484006400";  d="scan'208,217";a="537522638"
Received: from sea19-co-svc-lb5-vlan2.sea.amazon.com (HELO email-inbound-relay-6011.iad6.amazon.com) ([10.47.22.162]) by smtp-border-fw-out-9102.sea19.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA;  22 Feb 2017 16:34:36 +0000
Received: from EX13MTAUWB001.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan2.iad.amazon.com [10.40.159.162]) by email-inbound-relay-6011.iad6.amazon.com (8.14.7/8.14.7) with ESMTP id v1MGYSr3030197 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 22 Feb 2017 16:34:32 GMT
Received: from EX13D08UWB004.ant.amazon.com (10.43.161.232) by EX13MTAUWB001.ant.amazon.com (10.43.161.207) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 22 Feb 2017 16:34:31 +0000
Received: from EX13D08UWB002.ant.amazon.com (10.43.161.168) by EX13D08UWB004.ant.amazon.com (10.43.161.232) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 22 Feb 2017 16:34:31 +0000
Received: from EX13D08UWB002.ant.amazon.com ([10.43.161.168]) by EX13D08UWB002.ant.amazon.com ([10.43.161.168]) with mapi id 15.00.1104.000; Wed, 22 Feb 2017 16:34:31 +0000
From: "Phillips, Addison" 
To: Brian Rosen , =?iso-8859-1?Q?Gunnar_Hellstr=F6m?= 
Thread-Topic: [Slim] Shortening humintlang
Thread-Index: AQHSjPrCxT1L2lbSdEifVWD6cDQm06F04KuAgABFpgCAABIi0A==
Date: Wed, 22 Feb 2017 16:34:31 +0000
Message-ID: <2697072ec7a54ddbb972520b8303ec6f@EX13D08UWB002.ant.amazon.com>
References: <0D2E61DC-1A6D-4B9C-8072-589D702AB54A@gsma.com> <6ff2e293-5f36-bb44-3108-3c0937eb58da@omnitor.se> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.43.160.56]
Content-Type: multipart/alternative; boundary="_000_2697072ec7a54ddbb972520b8303ec6fEX13D08UWB002antamazonc_"
MIME-Version: 1.0
Precedence: Bulk
Archived-At: 
Cc: "slim@ietf.org" , Natasha Rooney 
Subject: Re: [Slim] Shortening humintlang
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Feb 2017 16:34:51 -0000

--_000_2697072ec7a54ddbb972520b8303ec6fEX13D08UWB002antamazonc_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Why is the "human" part an important distinguisher? Accept-Language refers =
to the same type of language: natural language content. While our machines =
are getting better about generating and responding to natural languages, th=
e point of these interfaces is always human interaction. Why not just 'lang=
'? It's short and it's consistent with usage elsewhere.


Addison Phillips
Principal SDE, I18N Architect (Amazon)
Chair (W3C I18N WG)

Internationalization is not a feature.
It is an architecture.



From: SLIM [mailto:slim-bounces@ietf.org] On Behalf Of Brian Rosen
Sent: Wednesday, February 22, 2017 7:27 AM
To: Gunnar Hellstr=F6m 
Cc: slim@ietf.org; Natasha Rooney 
Subject: Re: [Slim] Shortening humintlang

I don't have any problem shortening the name, but I do think retaining "hum=
an" is important because we have always had problems confusing the "Accept-=
Language" header.

How about 'hlang'?  Or 'hilang' if you must.

Brian


On Feb 22, 2017, at 6:17 AM, Gunnar Hellstr=F6m > wrote:

Den 2017-02-22 kl. 11:59, skrev Natasha Rooney:

Hi all,

We had this request from the Gen-ART reviewer for raft-ietf-slim-negotiatin=
g-human-language-06:

C. "humintlang" seems long to me

Given the excessive length of SDP in practice, it seems to me that a
shorter attribute name would be desirable.  E.g., "humlang" as was
used in some previous versions.  Or is there a coordinated usage with
other names in the "hum*lang" pattern?

Wdyt?
I have also had thoughts in the same direction.  Especially when we quite l=
ate decided to have only one language tag value per attribute, the consumpt=
ion of characters for SDP increased dramatically.
It is a good habit to have attribute names that are real words, but we have=
 problems inventing such names for this case.

The "hum" part is in fact redundant.  So, maybe Intlang-send and Intlang-re=
cv    for Interactive-language  would be an acceptable shortening of the na=
mes.

The proposal to return to the Accept-Language syntax, with the possibility =
to list all languages in one media and direction on one line would save us =
meven more, and should also be considered, I think.

Think about an outgoing call from a clever multi-language call-center with =
capability in 15 languages, both spoken and written.

/Gunnar


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

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




_______________________________________________

SLIM mailing list

SLIM@ietf.org

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



--

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

Gunnar Hellstr=F6m

Omnitor

gunnar.hellstrom@omnitor.se

+46 708 204 288
_______________________________________________
SLIM mailing list
SLIM@ietf.org
https://www.ietf.org/mailman/listinfo/slim


--_000_2697072ec7a54ddbb972520b8303ec6fEX13D08UWB002antamazonc_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Why is the “human” part a=
n important distinguisher? Accept-Language refers to the same type of langu=
age: natural language content. While our machines are getting
 better about generating and responding to natural languages, the point of =
these interfaces is always human interaction. Why not just ‘lang̵=
7;? It’s short and it’s consistent with usage elsewhere.


 


 


Addison Phil=
lips


Principal SD=
E, I18N Architect (Amazon)


Chair (W3C I=
18N WG)


 <=
/o:p>


Internationa=
lization is not a feature.


It is an arc=
hitecture.


 


 


 








From: SLIM [mailto:slim-bounces@ietf=
.org]
On Behalf Of Brian Rosen

Sent: Wednesday, February 22, 2017 7:27 AM

To: Gunnar Hellstr=F6m <gunnar.hellstrom@omnitor.se>

Cc: slim@ietf.org; Natasha Rooney <nrooney@gsma.com>

Subject: Re: [Slim] Shortening humintlang






 


I don’t have any problem shortening the name, =
but I do think retaining “human” is important because we have a=
lways had problems confusing the “Accept-Language” header.=





 






How about ‘hlang'?  Or 'hilang' if you mu=
st.  






 






Brian






 






 








On Feb 22, 2017, at 6:17 AM, Gunnar Hellstr=F6m <=
gunnar.hellstrom@omnitor.se<=
/a>> wrote:




 






Den 2017-02-22 kl. 11:59, skrev Natasha Rooney:








Hi all, 




 






We had this request from the Gen-ART reviewer for&nb=
sp;raft-ietf-slim-negotiating-human-language-06:






 






C. "humintlang" seems long to me



Given the excessive length of SDP in practice, it seems to me that a

shorter attribute name would be desirable.  E.g., "humlang" =
as was

used in some previous versions.  Or is there a coordinated usage with<=
br>
other names in the "hum*lang" pattern?






 






Wdyt?






I have also had thoughts in the same direction. =
; Especially when we quite late decided to have only one language tag value=
 per attribute, the consumption of characters for SDP increased dramaticall=
y. 


It is a good habit to have attribute names that are real words, but we have=
 problems inventing such names for this case.




The "hum" part is in fact redundant.  So, maybe Intlang-send=
 and Intlang-recv    for Interactive-language  would be an a=
cceptable shortening of the names.



The proposal to return to the Accept-Language syntax, with the possibility =
to list all languages in one media and direction on one line would save us =
meven more, and should also be considered, I think.   




Think about an outgoing call from a clever multi-language call-center with =
capability in 15 languages, both spoken and written. 




/Gunnar 









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












_______________________________________________


SLIM mailing list


SLIM@ietf.org


https://www.iet=
f.org/mailman/listinfo/slim











-- 


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


Gunnar Hellstr=F6m


Omnitor


gunnar.hellstrom@omnito=
r.se


+46 708 204 288




_______________________________________________

SLIM mailing list

SLIM@ietf.org

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








 










--_000_2697072ec7a54ddbb972520b8303ec6fEX13D08UWB002antamazonc_--


From nobody Wed Feb 22 08:43: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 93A8B129484 for ; Wed, 22 Feb 2017 08:43:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gw7MFNOhoWnF for ; Wed, 22 Feb 2017 08:43:33 -0800 (PST)
Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::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 6C09612940A for ; Wed, 22 Feb 2017 08:43:33 -0800 (PST)
Received: by mail-qk0-x236.google.com with SMTP id s186so7960812qkb.1 for ; Wed, 22 Feb 2017 08:43:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=Mye8znh6pDJPhWhKtPAQtFTprhRLkyCuJ0Ccr+jsB5A=; b=FvGtO6FBUcuaHmCw/I3sSPW03nf7UYZPzWza9NM3D34xSwWia7OVhukS3IHgNeplNg DqCyJW0hRJrW/pGec5gm1KtHt6aD3k5dZdN96qU33QYvm1aEcFw7thG7lt9iWaXQnNmz 41M7OO99P1abjj8UNSPsHDv1jvALl7EybwSPdE8EjDEXHKoKPkJj894rHhEvXHXj/t6v EC1QXiNKdUxKdMmCL4bFptSzhQg01h6UOMBf4lRI6gsyrsj+Xd0NaFWwR71ebz8d6/oE 5jSyeI84Kk0+2u7lQuRSEx6cy0nkk4nQAD9hrxvIXOyeAszg+jVhJKUfmDR/vvaIPeLd aVKQ==
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 :message-id:references:to; bh=Mye8znh6pDJPhWhKtPAQtFTprhRLkyCuJ0Ccr+jsB5A=; b=QstuLs3c8/HYh80TRzh5RXmVA3I9oi3Xsm2ZIYJX1ZEVZ/lpZMiZC4lfdag/VU997E bioyxve9pZkyswOWcG28kOIBV3mNwOf/Z3PNzrDofIiUUezE3NCDCYvzizC80+zWwH6f rUyoPdwLidfWCXLfcIeA+P/8opNWI9s4tD7d3jIGGdlrJBa7aIKXbBWaJmn34HpIJQgp CD3yfiNg6p6GFFC9aNDVuqmlzXQWwv2vPuSKVPEODGNumDRXSXFAs2scR+XH1v5EVvSF GxireLRklleNoeYVeBTs08LjwyuFZFUoQrJq6TVABhUQ+sanzVgbVymn8aOaJrZ8pEO6 xrDw==
X-Gm-Message-State: AMke39l6hMMahHELPxBbgbYBreUByC5LiJ5mvfhx1Xeb6z5bta4KjYa3+BrVeJwrGNNwVw==
X-Received: by 10.233.222.197 with SMTP id s188mr29008220qkf.311.1487781812395;  Wed, 22 Feb 2017 08:43:32 -0800 (PST)
Received: from [10.96.43.71] ([156.154.81.54]) by smtp.gmail.com with ESMTPSA id x7sm999726qtc.18.2017.02.22.08.43.31 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 22 Feb 2017 08:43:31 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_67699CBB-BBCE-44EE-A204-A0AB054C7C5B"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Brian Rosen 
In-Reply-To: <2697072ec7a54ddbb972520b8303ec6f@EX13D08UWB002.ant.amazon.com>
Date: Wed, 22 Feb 2017 11:43:30 -0500
Message-Id: 
References: <0D2E61DC-1A6D-4B9C-8072-589D702AB54A@gsma.com> <6ff2e293-5f36-bb44-3108-3c0937eb58da@omnitor.se>  <2697072ec7a54ddbb972520b8303ec6f@EX13D08UWB002.ant.amazon.com>
To: "Phillips, Addison" 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: "slim@ietf.org" , Natasha Rooney , =?utf-8?Q?Gunnar_Hellstr=C3=B6m?= 
Subject: Re: [Slim] Shortening humintlang
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Feb 2017 16:43:35 -0000

--Apple-Mail=_67699CBB-BBCE-44EE-A204-A0AB054C7C5B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Accept-Language is the language used in the SIP/HTTP exchange, not the =
language used in the media exchange.  We=E2=80=99re trying to =
differentiate.  This has actually caused a lot of confusion, so it=E2=80=99=
s not theoretical.

We could use =E2=80=9Cmedlang=E2=80=9D, but I rather like =E2=80=9Chlang=E2=
=80=9D better.

We should acknowledge that this is a protocol discussion.  Humans =
don=E2=80=99t see either element.  It could be =E2=80=9Cfubar=E2=80=9D =
and work for the protocol exchange.

Brian

> On Feb 22, 2017, at 11:34 AM, Phillips, Addison  =
wrote:
>=20
> Why is the =E2=80=9Chuman=E2=80=9D part an important distinguisher? =
Accept-Language refers to the same type of language: natural language =
content. While our machines are getting better about generating and =
responding to natural languages, the point of these interfaces is always =
human interaction. Why not just =E2=80=98lang=E2=80=99? It=E2=80=99s =
short and it=E2=80=99s consistent with usage elsewhere.
> =20
> =20
> Addison Phillips
> Principal SDE, I18N Architect (Amazon)
> Chair (W3C I18N WG)
> =20
> Internationalization is not a feature.
> It is an architecture.
> =20
> =20
> =20
> From: SLIM [mailto:slim-bounces@ietf.org] On Behalf Of Brian Rosen
> Sent: Wednesday, February 22, 2017 7:27 AM
> To: Gunnar Hellstr=C3=B6m 
> Cc: slim@ietf.org; Natasha Rooney 
> Subject: Re: [Slim] Shortening humintlang
> =20
> I don=E2=80=99t have any problem shortening the name, but I do think =
retaining =E2=80=9Chuman=E2=80=9D is important because we have always =
had problems confusing the =E2=80=9CAccept-Language=E2=80=9D header.
> =20
> How about =E2=80=98hlang'?  Or 'hilang' if you must. =20
> =20
> Brian
> =20
> =20
> On Feb 22, 2017, at 6:17 AM, Gunnar Hellstr=C3=B6m =
> =
wrote:
> =20
> Den 2017-02-22 kl. 11:59, skrev Natasha Rooney:
>=20
> Hi all,=20
> =20
> We had this request from the Gen-ART reviewer for =
raft-ietf-slim-negotiating-human-language-06:
> =20
> C. "humintlang" seems long to me
>=20
> Given the excessive length of SDP in practice, it seems to me that a
> shorter attribute name would be desirable.  E.g., "humlang" as was
> used in some previous versions.  Or is there a coordinated usage with
> other names in the "hum*lang" pattern?
> =20
> Wdyt?
> I have also had thoughts in the same direction.  Especially when we =
quite late decided to have only one language tag value per attribute, =
the consumption of characters for SDP increased dramatically. =20
> It is a good habit to have attribute names that are real words, but we =
have problems inventing such names for this case.=20
>=20
> The "hum" part is in fact redundant.  So, maybe Intlang-send and =
Intlang-recv    for Interactive-language  would be an acceptable =
shortening of the names.
>=20
> The proposal to return to the Accept-Language syntax, with the =
possibility to list all languages in one media and direction on one line =
would save us meven more, and should also be considered, I think.   =20
>=20
> Think about an outgoing call from a clever multi-language call-center =
with capability in 15 languages, both spoken and written. =20
>=20
> /Gunnar=20
>=20
>=20
> Natasha Rooney | Internet Engineering Director | Internet and Web Team =
| Technology | GSMA | nrooney@gsma.com  | +44 =
(0) 7730 219 765 | @thisNatasha | Skype: nrooney@gsm.org =

> =20
> This email and its attachments are intended for the above named only =
and may be confidential. If they have come to you in error you must take =
no action based on them, nor must you copy or show them to anyone; =
please reply to this email or call +44 207 356 0600 and highlight the =
error.
>=20
>=20
>=20
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org 
> https://www.ietf.org/mailman/listinfo/slim =

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


--Apple-Mail=_67699CBB-BBCE-44EE-A204-A0AB054C7C5B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Accept-Language is the language used in the SIP/HTTP =
exchange, not the language used in the media exchange.  We=E2=80=99re=
 trying to differentiate.  This has actually caused a lot of =
confusion, so it=E2=80=99s not theoretical.

We could use =E2=80=9Cmedlang=E2=80=9D, =
but I rather like =E2=80=9Chlang=E2=80=9D better.
We should acknowledge that this is a =
protocol discussion.  Humans don=E2=80=99t see either element. =
 It could be =E2=80=9Cfubar=E2=80=9D and work for the protocol =
exchange.

Brian

On Feb 22, 2017, at 11:34 AM, =
Phillips, Addison <addison@lab126.com> wrote:

Why is the =E2=80=9Chuman=E2=80=9D part an =
important distinguisher? Accept-Language refers to the same type of =
language: natural language content. While our machines are getting =
better about generating and responding to natural languages, the point =
of these interfaces is always human interaction. Why not just =
=E2=80=98lang=E2=80=99? It=E2=80=99s short and it=E2=80=99s consistent =
with usage elsewhere.
 
 
Addison Phillips
Principal SDE, I18N =
Architect (Amazon)
Chair (W3C I18N =
WG)
 
Internationalization is =
not a feature.
It is an =
architecture.
 
 
 
From: SLIM [mailto:slim-bounces@ietf.org] On Behalf =
Of Brian Rosen
Sent: Wednesday, February 22, =
2017 7:27 AM
To: Gunnar Hellstr=C3=B6m =
<gunnar.hellstrom@omnitor.se>
Cc: slim@ietf.org; Natasha =
Rooney <nrooney@gsma.com>
Subject: Re: [Slim] Shortening =
humintlang
 
I don=E2=80=99t have any problem =
shortening the name, but I do think retaining =E2=80=9Chuman=E2=80=9D is =
important because we have always had problems confusing the =
=E2=80=9CAccept-Language=E2=80=9D header.
 
How about =E2=80=98hlang'?  Or 'hilang' if you =
must.  
 
Brian
 
 
On =
Feb 22, 2017, at 6:17 AM, Gunnar Hellstr=C3=B6m <gunnar.hellstrom@omnitor.se> wrote:
 
Den 2017-02-22 kl. 11:59, skrev Natasha =
Rooney:

Hi =
all, 
 
We had this request from the Gen-ART =
reviewer for raft-ietf-slim-negotiating-human-language-06:
 
C. "humintlang" seems long to me

Given the excessive length of SDP in practice, =
it seems to me that a
shorter attribute name would be =
desirable.  E.g., "humlang" as was
used in some =
previous versions.  Or is there a coordinated usage with
other names in the "hum*lang" pattern?
 
Wdyt?
I have also had thoughts in the same direction.  =
Especially when we quite late decided to have only one language tag =
value per attribute, the consumption of characters for SDP increased =
dramatically.  
It is a good habit to have attribute names that are real =
words, but we have problems inventing such names for this case. 

The "hum" part is in fact redundant.  So, maybe =
Intlang-send and Intlang-recv    for =
Interactive-language  would be an acceptable shortening of the =
names.

The proposal to return to the =
Accept-Language syntax, with the possibility to list all languages in =
one media and direction on one line would save us meven more, and should =
also be considered, I think.    

Think about an outgoing call from a clever multi-language =
call-center with capability in 15 languages, both spoken and =
written.  

/Gunnar 


Natasha Rooney | Internet =
Engineering Director | Internet and Web Team | Technology | =
GSMA | nrooney@gsma.com | +44 =
(0) 7730 219 765 | @thisNatasha | Skype: nrooney@gsm.org
 
This email and its =
attachments are intended for the above named only and may be =
confidential. If they have come to you in error you must take no action =
based on them, nor must you copy or show them to anyone; please reply to =
this email or call +44 207 356 0600 and highlight the error.



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


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

=

--Apple-Mail=_67699CBB-BBCE-44EE-A204-A0AB054C7C5B--


From nobody Wed Feb 22 12:05: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 ABB44129AD9; Wed, 22 Feb 2017 12:05:15 -0800 (PST)
X-Quarantine-ID: 
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CF_QuydnYirC; Wed, 22 Feb 2017 12:05:13 -0800 (PST)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id BFD0A129A70; Wed, 22 Feb 2017 12:05:12 -0800 (PST)
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Wed, 22 Feb 2017 11:55:50 -0800
Mime-Version: 1.0
Message-Id: 
In-Reply-To: 
References: <148738514545.19944.11486737065416495302.idtracker@ietfa.amsl.com>  
X-Mailer: Eudora for Mac OS X
Date: Wed, 22 Feb 2017 12:05:09 -0800
To: Gunnar =?iso-8859-1?Q?Hellstr=F6m?=  , Dale Worley , gen-art@ietf.org
From: Randall Gellens 
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
Archived-At: 
Cc: slim@ietf.org, ietf@ietf.org, draft-ietf-slim-negotiating-human-language.all@ietf.org
Subject: Re: [Slim] Review of draft-ietf-slim-negotiating-human-language-06
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Feb 2017 20:05:15 -0000

At 11:57 AM +0100 2/22/17, Gunnar Hellstr=F6m wrote:

>  A few comments inline,
>
>
>  Den 2017-02-22 kl. 02:44, skrev Randall Gellens:
>>  Hi Dale,
>>
>>  Thank you for your review, I appreciate it.  Please see inline.
>>
>>  At 6:32 PM -0800 2/17/17, Dale Worley wrote:
>>
>>>   Reviewer: Dale Worley
>>>   Review result: Ready with Nits
>>>
>>>   I am the assigned Gen-ART reviewer for this draft.  The General Area
>>>   Review Team (Gen-ART) reviews all IETF documents being processed
>>>   by the IESG for the IETF Chair.  Please treat these comments just
>>>   like any other last call comments.
>>>
>>>   For more information, please see the FAQ at
>>>   .
>>>
>>>   Document:  draft-ietf-slim-negotiating-human-language-06
>>>   Reviewer:  Dale R. Worley
>>>   Review Date:  2017-02-17
>>>   IETF LC End Date:  2017-02-20
>>>   IESG Telechat date:  [unknown]
>>>
>>>   Summary:
>>>          This draft is basically ready for publication, but has nits
>>>          that should be fixed before publication.
>>>
>>>   * Technical comments
>>>
>>>   A. Call failure
>>>
>>>   If a call fails due to no available language match, in what way(s)
>>>   does it fail?  Section 5.3 says
>>>
>>>      If such an offer is received, the receiver MAY
>>>      reject the media, ignore the language specified, or attempt to
>>>      interpret the intent
>>>
>>>   But I suspect it's also allowed for the UAS to fail the call at the
>>>   SIP level.  Whether or not that is allowed (or at least envisioned)
>>>   should be described.  And what response code(s)/warn-code(s) should
>>>   be
>>>   used for that?
>>
>>  The text you quote has been deleted.  The=20
>> draft does not mandate if the call should=20
>> proceed or fail if there is no language match=20
>> possible, although the draft does provide an=20
>> optional mechanism to indicate the caller's=20
>> preference that the call not fail, and the=20
>> draft does mention that in the emergency=20
>> services case, the call will likely proceed,=20
>> but that's a matter of policy not protocol.
>  You may have a version where it is proposed=20
> that the text is deleted. We need to see that=20
> new text and agree if it was good to delete it.

I will be uploading the updated draft shortly.=20
The only question is if I upload it before or=20
after adding any extra examples.

>
>  There are more places in the draft where=20
> failing the call is mentioned, so the question=20
> about how it is failed is relevant anyway. A=20
> 603 Decline from the proxy would likely be the=20
> natural way to fail the call when it is because=20
> of lack of matching languages. But I do not see=20
> any natural way for an addressed UA to signal=20
> this.

I do not believe the draft needs to mandate how a call is rejected.

>
>>
>>>
>>>   B. Audio/Video coordination
>>>
>>>      5.2.  New 'humintlang-send' and 'humintlang-recv' attributes
>>>
>>>      Note that while signed language tags are used with a video stream
>>>   to
>>>      indicate sign language, a spoken language tag for a video stream
>>>   in
>>>      parallel with an audio stream with the same spoken language tag
>>>      indicates a request for a supplemental video stream to see the
>>>      speaker.
>>>
>>>   And there's a similar paragraph in 5.4:
>>>
>>>>      A spoken language tag for a video stream in conjunction with an
>>>   audio
>>>>      stream with the same language might indicate a request for
>>>>      supplemental video to see the speaker.
>>>
>>>   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 seems to me that a
>>>   workable rule is that there is an audio stream and a video stream and
>>>   they specify exactly the same language tag in their respective
>>>   humintlang attributes.  In that case, it is a request for a spoken
>>>   language with simultaneous video of the speaker, and those requests
>>>   should be considered satisfied only if both streams can be
>>>   established.
>>
>>  The text you quote has been deleted.  A media=20
>> stream for supplemental purposes can be=20
>> negotiated without a language tag, as normal.
>>
>  The text should not be deleted just because it is under discussion.

It was controversial and not needed, hence it was=20
deleted.  The WG expressed a goal of publishing a=20
simple document to have something that can be=20
deployed.

>  It is a valid and valuable alternative. At the=20
> moment we lack ways to indicate if languages=20
> are wanted together or seen as separate=20
> alternatives, and we have said that such=20
> detailing can be added in future versions or=20
> additional specifications if not done now.=20
> Therefore we had better allow this combination=20
> and let the negotiating parties sort out what=20
> it currently means. The specification just=20
> indicates that the indicated languages are=20
> alternatives, and any number may be selected=20
> for matching and usage in the session.
>  I do not think we should require very exactly=20
> matching language tags between spoken language=20
> in audio and corresponding view of the speaker=20
> in video.

We are not requiring this.  On the contrary, a=20
video stream without a language attribute=20
indicates it is used for supplemental purposes,=20
not interactive language.  If we need more=20
capabilities, this can be done in the future.

>>>
>>>   * The following three items are adjustments to the design which I'd
>>>   like to know have been considered.
>>>
>>>   C. "humintlang" seems long to me
>>>
>>>   Given the excessive length of SDP in practice, it seems to me that a
>>>   shorter attribute name would be desirable.  E.g., "humlang" as was
>>>   used in some previous versions.  Or is there a coordinated usage with
>>>   other names in the "hum*lang" pattern?
>>
>>  There is no intent for a coordinated pattern.=20
>> The name was chosen years ago to avoid=20
>> potential confusion with the 'lang' attribute.=20
>> Is it worth reopening the issue to potentially=20
>> save three characters per SDP line with a=20
>> language?
>>
>>>
>>>   D. Use the Accept-Language syntax
>>>
>>>   It seems to me that it would better to use the Accept-Language syntax
>>>   for the attribute values.  This allows (1) specifiying the quality of
>>>   language experience, allowing clear description of bilingualism, (2)
>>>   a
>>>   unified method of specifying whether or not arbitrary languages are
>>>   acceptable, and (3) abbreviating SDP descriptions.
>>>
>>>   In a way, the fact that the current proposal seems to require (but
>>>   does not directly specify) the coordinated absence/presence of an
>>>   asterisk on all of the repetitions of humintlang-send or
>>>   humintlang-recv is a warning that the syntax doesn't represent the
>>>   semantics as well as it might.
>>
>>  The group considered multiple proposals to=20
>> permit specifying quality, preference,=20
>> q-values, etc. but decided to keep things=20
>> simple for this draft.  There is no intent to=20
>> require the use of an asterisk (to indicate a=20
>> preference by the caller to not fail the=20
>> call).  The asterisk is a very mild mechanism=20
>> with no normative effects.  It merely conveys=20
>> the preference of the caller, and is not=20
>> binding on the answerer.
>  I would never dare to use an sdp without an=20
> asterisk. Language matching is a tricky thing=20
> and human capabilities much wider than the=20
> language tags can express. If I get a call from=20
> a Norwegian user talking Norwegian and=20
> indicating Norwegian in the humintlang=20
> attributes, I want to get the call accepted by=20
> my device with setting for spoken Swedish,=20
> because Swedes and Norwegians usually can=20
> communicate quite well speaking their own=20
> languages. I would anyway not have imagined=20
> making a setting for Norwegian language as a=20
> preference in my device.
>  It will however be an excellent help for me to=20
> see the indication of the Norwegian, when I get=20
> the call, so I can tune my listening.
>  By setting the asterisk somewhere among the=20
> Humintlang attributes, I will make sure that I=20
> do not lose calls that I could handle.
>
>>
>>>   E. Have an attribute to abbreviate the bidirectionally-symmetric case
>>>
>>>   Note that all examples are bidirectionally symmetric, and the text
>>>   says that requests and responses SHOULD be bidirectionally symmetric.
>>>   So it would be a very useful abbreviation to define
>>>   "humintlang=3D" to be equivalent to the combination of
>>>   "humintlang-send=3D" and "humintlang-recv=3D".
>>>
>>>   Combining proposals C, D, and E, the examples become
>>>
>>>         m=3Daudio 49170 RTP/AVP 0
>>>         a=3Dhumlang:en
>>>
>>>         m=3Dvideo 51372 RTP/AVP 31 32
>>>         a=3Dhumlang:ase,*;q=3D0.1
>>>
>>>         m=3Daudio 49250 RTP/AVP 20
>>>         a=3Dhumlang:es,eu;q=3D0.9,en;q=3D0.8,*;q=3D0.1
>>>
>>>         m=3Dtext 45020 RTP/AVP 103 104
>>>         a=3Dhumlang:gr
>>>
>>>   which requires about half as many characters as they have now.
>>
>>  A third attribute without the "-send" or=20
>> "-recv" to indicate bidirectionality would=20
>> reduce the characters in the SDP block, at the=20
>> cost of some added complexity (e.g., what if=20
>> all three appear).  I don't believe this has=20
>> been discussed in the group.
>>
>>>   * Editorial comments and nits
>>>
>>>   Abstract
>>>
>>>      This document describes the need and a solution using new SDP
>>>   stream
>>>      attributes.
>>>
>>>   I don't think the term "stream attribute" is used in RFC 4566.
>>>   Instead, it uses "media attribute".
>>
>>  Fixed.
>>
>>>   1.  Introduction
>>>
>>>      caller and callee know each other or there is contextual or out of
>>>      band information from which the language(s) and media modalities
>>>   can
>>>
>>>   I think this context, it's preferred to hyphenate "out-of-band" to
>>>   make it clearly be an adjective.
>>
>>>   OK.
>>
>>
>>>      This approach has a number of benefits, including that it is
>>>   generic
>>>      (applies to all interactive communications negotiated using SDP)
>>>   and
>>>      not limited to emergency calls.
>>>
>>>   I think s/and not limited to/and is not limited to/ reads more
>>>   smoothly.
>>
>>  There's no harm in the extra "is" so I'm happy to add it.
>>
>>>      But it is clearly useful in many other cases.  For
>>>      example, someone calling a company call center or a Public Safety
>>>      Answering Point (PSAP) should be able to indicate if one or more
>>>      specific signed, written, and/or spoken languages are preferred,
>>>   the
>>>      callee should be able to indicate its capabilities in this area,
>>>   and
>>>      the call proceed using in-common language(s) and media forms.
>>>
>>>   I think s/preferred, the callee/preferred; the callee/ because the
>>>   sentence is the concatenation of two sentences.
>>
>>  I reworded the sentence to flow better:
>>
>>     For example, it is helpful that someone calling a company call center
>>     or a Public Safety Answering Point (PSAP) be able to indicate
>>     preferred signed, written, and/or spoken languages, the callee be
>>     able to indicate its capabilities in this area, and the call proceed
>>     using the language(s) and media forms supported by both.
>>
>>>   Perhaps s/in-common/shared/.
>>
>>  Fixed in the rewording above.
>>
>>>
>>>      Including the user's human (natural) language preferences in the
>>>      session establishment negotiation is independent of the use of a
>>>      relay service and is transparent to a voice service provider.
>>>
>>>   I think it's even broader than "transparent to a voice service
>>>   provider" -- it's transparent to any serivice provider, assuming that
>>>   the media are language-neutral.
>>
>>  I changed it to read "voice or other service provider".
>>
>>>
>>>      In the case of a call to e.g., an airline, the call could be
>>>      automatically handled by a Spanish-speaking agent.
>>>
>>>   I think s/handled by/routed to/ is the usual usage.
>>
>>  We are trying to be careful in the draft to=20
>> not imply that it is discussing call routing.=20
>> I'd rather keep the more generic "handled by".
>>
>>>
>>>   3.  Desired Semantics
>>>
>>>      The desired solution is a media attribute (preferably per
>>>   direction)
>>>      that may be used within an offer to indicate the preferred
>>>   language
>>>      of each (direction of a) media stream, and within an answer to
>>>      indicate the accepted language.
>>>
>>>   In this one instance, I think you want to use "language(s)" to drive
>>>   home that that multiple languages can be specified:  "within an offer
>>>   to indicate the preferred language(s)".
>>>
>>>      (Negotiating multiple simultaneous languages within a media stream
>>>   is
>>>      out of scope, as the complexity of doing so outweighs the
>>>      usefulness.)
>>>
>>>   You might want to say instead "(Negotiating multiple simultaneous
>>>   languages within a media stream is out of scope for this document.)"
>>>   to ensure that nobody decides to argue whether "the complexity of
>>>   doing so outweighs the usefulness".
>>
>>  I agree and deleted "the complexity of doing so outweighs the usefulness=
".
>>
>>>
>>>   4.  The existing 'lang' attribute
>>>
>>>      RFC 4566 [RFC4566] specifies an attribute 'lang' which appears
>>>      similar to what is needed here, but is not sufficiently detailed
>>>   for
>>>      use here.
>>>
>>>   "for use here" isn't quite right.  Maybe "is not sufficiently
>>>   specific
>>>   or flexible to satisfy the requirements".
>>>
>>>      In addition, it is not mentioned in [RFC3264]
>>>
>>>   "it" is somewhat ambiguous here, perhaps change to "the 'lang'
>>>   attribute".
>>
>>  OK, accepted both changes.
>>
>>>
>>>   5.  Proposed Solution
>>>
>>>   Perhaps /Proposed Solution/Solution/, since once this draft is
>>>   approved, it becomes the solution.
>>
>>  OK.
>>
>>>
>>>   5.2.  New 'humintlang-send' and 'humintlang-recv' attributes
>>>
>>>         a=3Dhumintlang-send:
>>>         a=3Dhumintlang-recv:
>>>
>>>   This is presented as the generic form of the attributes, but there is
>>>   no indication of the posible asterisk.
>>
>>  The syntax has been deleted from 5.2 since it's now in 6.
>  I think it should not be deleted, but instead=20
> Dale's comment satisfied.  That would be more=20
> in line with the stye of rfc4566bis.
>  5.2 shows the complete attributes, and that is=20
> good. Chapter 6 only shows the syntax of the=20
> value.

Having the syntax in two places is a stylistic matter.

>>
>>>
>>>      The values constitute a list of languages
>>>      in preference order (first is most preferred).
>>>
>>>   "The values" isn't very clear, because the values are in successive
>>>   attributes.  You want to say something like "The sequence of values
>>>   in
>>>   the occurrences of one of these attributes constitutes ...".
>>>   However,
>>>   see the technical comments above.
>>
>>  The text was reworded to read:
>>
>>     The values from all
>>     instances of the attribute constitute a list of languages in
>>     preference order (first is most preferred).
>>
>>>
>>>      When placing an emergency call, and in any other case where the
>>>      language cannot be assumed from context, each media stream in an
>>>      offer primarily intended for human language communication SHOULD
>>>      specify both (or in some cases, one of) the 'humintlang-send' and
>>>      'humintlang-recv' attributes.
>>>
>>>   Probably s/assumed/inferred/.
>>
>>  I agree.
>>
>>>
>>>   Could you be more accurate by
>>>   s/or in some cases/or for unidirectional streams/?
>>
>>  I agree.
>>
>>>
>>>   5.3.  Advisory vs Required
>>>
>>>      The mechanism for indicating this preference is that, in an offer,
>>>   if
>>>      the last character of any of the 'humintlang-recv' or 'humintlang-
>>>      send' values is an asterisk, this indicates a request to not fail
>>>   the
>>>      call (similar to SIP Accept-Language syntax).  Either way, the
>>>   called
>>>      party MAY ignore this, e.g., for the emergency services use case,
>>>   a
>>>      PSAP will likely not fail the call.
>>>
>>>   The construction of this paragraph isn't quite complete.  It says
>>>   that
>>>   if an asterisk is present, a request shouldn't fail, but it doesn't
>>>   say that if no asterisk is present, a request should fail if there is
>>>   no language match.  And it's the latter condition that makes the
>>>   second sentence meaningful.  So I think you want to insert between
>>>   the
>>>   two sentences one regarding the absence of an asterisk.
>>
>>  I've reworded the section to read:
>>
>>     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 character of any of the 'humintlang-recv' or 'humintlang-
>>     send' values 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 with an asterisk.
>  This still does not meet Dale's comment.
>  Insert a sentence saying:
>  "A preference for getting the call denied in=20
> case of no language match SHOULD be indicated=20
> by no asterisk appended on any humintlang=20
> attribute value in the whole SDP."

I don't think that's needed, and it's a strangely=20
constructed normative directive.  How can a=20
preference have a SHOULD?

>>
>>>   5.5.  Examples
>>>
>>>   Given that the combined audio/video mechanism is the only
>>>   irregularity
>>>   in this system, there ought to be an example of it.  E.g.,
>>>
>>>      An example of a supplemental video stream with a spoken language
>>>      audio stream:
>>>
>>>         m=3Dvideo 51372 RTP/AVP 31 32
>>>         a=3Dhumintlang-send:en
>>>         a=3Dhumintlang-recv:en
>>>
>>>         m=3Daudio 49250 RTP/AVP 20
>>>         a=3Dhumintlang-send:en
>>>         a=3Dhumintlang-recv:en
>>
>>  If the video stream is supplemental then it=20
>> doesn't have a language (the text that=20
>> suggested otherwise has been deleted). But I=20
>> am considering adding more examples.
>  I provided a rich set of examples in my LC=20
> comments of Feb 13. Please consider them as a=20
> base even if some need revision if the proposed=20
> extended meaning of the asterisk is not=20
> accepted.

Thank you for submitting them; I am considering them.

>>
>>>
>>>   6.  IANA Considerations
>>>
>>>         humintlang-value =3D  Language-Tag [ asterisk ]
>>>                             ; Language-Tag defined in RFC 5646
>>>         asterisk         =3D  "*"
>>>
>>>   s/Language-Tag defined in RFC 5646/Language-Tag as defined in RFC
>>>   5646/
>>>
>>>   But perhaps also s/RFC 5646/BCP 47/, which ensures that "humintlang"
>>>   tracks the current version of language tags.
>>
>>  Ok.
>>
>>>
>>>   Appendix A.  Historic Alternative Proposal: Caller-prefs
>>>
>>>      This
>>>      results in a more fragile solution since the media modality and
>>>      language would be negotiated using SIP, and then the specific
>>>   media
>>>      formats (which inherently include the modality) would be
>>>   negotiated
>>>      at a different level (typically SDP, especially in the emergency
>>>      calling cases), making it easier to have mismatches (such as where
>>>      the media modality negotiated in SIP don't match what was
>>>   negotiated
>>>      using SDP).
>>>
>>>   "the media modality and language would be negotiated using SIP" isn't
>>>   quite the right way to say it because SIP isn't explicitly
>>>   negotiating
>>>   the modality.  Better would be
>>>
>>>      ... the language (and by implication the media modality) would be
>>>      negotiated using SIP, and then the specific media (which
>>>   inherently
>>>      include the modalities and formats) would be negotiated at a
>>>      different level ...
>>
>>  This section has been deleted.
>  Did we agree on that?

It was suggested in earlier comments to delete it=20
as it is clearly not needed (it's an informative=20
appendix detailing a historical alternative that=20
was not pursued).


>>
>>>
>>>   [END]
>>
>>
>  Regards
>  Gunnar
>
>  --
>  -----------------------------------------
>  Gunnar Hellstr=F6m
>  Omnitor
>  gunnar.hellstrom@omnitor.se
>  +46 708 204 288


-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
    The highlight of the annual Computer Bowl occurred when Bill Gates,
who was a judge, posed the following question to the contestants:
    "What contest, held via Usenet, is dedicated to examples of weird,
obscure, bizarre, and really bad programming?"
    After a moment of silence, Jean-Louis Gassee (ex-honcho at Apple)
hit his buzzer and answered "Windows."
                                          --Recounted by Adam C. Engst


From nobody Wed Feb 22 12:10:44 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 1393B129ABE; Wed, 22 Feb 2017 12:10:43 -0800 (PST)
X-Quarantine-ID: <1YyZcYODmjIa>
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 1YyZcYODmjIa; Wed, 22 Feb 2017 12:10:41 -0800 (PST)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id C5F9D129A98; Wed, 22 Feb 2017 12:10:41 -0800 (PST)
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Wed, 22 Feb 2017 12:01:20 -0800
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <87h93mut8q.fsf@hobgoblin.ariadne.com>
References: <87h93mut8q.fsf@hobgoblin.ariadne.com>
X-Mailer: Eudora for Mac OS X
Date: Wed, 22 Feb 2017 12:10:38 -0800
To: worley@ariadne.com (Dale R. Worley), Gunnar =?iso-8859-1?Q?Hellstr=F6m?=  , slim@ietf.org
From: Randall Gellens 
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
Archived-At: 
Cc: gen-art@ietf.org, rg+ietf@randy.pensive.org, ietf@ietf.org, draft-ietf-slim-negotiating-human-language.all@ietf.org
Subject: Re: [Slim] Review of draft-ietf-slim-negotiating-human-language-06
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Feb 2017 20:10:43 -0000

At 10:42 AM -0500 2/22/17, Dale R. Worley wrote:

>  Gunnar Hellstr=F6m  writes:
>>>>   A. Call failure
>>>>
>>>>   If a call fails due to no available language match, in what way(s)
>>>>   does it fail?  Section 5.3 says
>>>>
>>>>      If such an offer is received, the receiver MAY
>>>>      reject the media, ignore the language specified, or attempt to
>>>>      interpret the intent
>>>>
>>>>   But I suspect it's also allowed for the UAS to fail the call at the
>>>>   SIP level.  Whether or not that is allowed (or at least envisioned)
>>>>   should be described.  And what response code(s)/warn-code(s) should
>>>>   be used for that?
>>>
>>>  The text you quote has been deleted.  The draft does not mandate if
>>>  the call should proceed or fail if there is no language match
>>>  possible, although the draft does provide an optional mechanism to
>>>  indicate the caller's preference that the call not fail, and the draft
>>>  does mention that in the emergency services case, the call will likely
>>>  proceed, but that's a matter of policy not protocol.
>>
>>  You may have a version where it is proposed that the text is deleted. We
>>  need to see that new text and agree if it was good to delete it.
>>
>>  There are more places in the draft where failing the call is mentioned,
>>  so the question about how it is failed is relevant anyway. A 603 Decline
>>  from the proxy would likely be the natural way to fail the call when it
>>  is because of lack of matching languages. But I do not see any natural
>>  way for an addressed UA to signal this.
>
>  I would argue strongly against using a 6xx response, as the defined
>  effect of those is to make the call fail all the way back to the
>  caller, rather than allowing alternative forks of the call to possibly
>  succeed.  The way to handle a call that *this* proxy can't route due to
>  language incompatibility is a 4xx response.
>
>  My question wasn't for the draft to be prescriptive on this issue (and
>  that seems to align with what the WG/authors intend), but to provide
>  implementation advice, best practices as it were -- There are a lot 4xx
>  responses available, and if you don't read their descriptions carefully,
>  it can be easy to choose one with the wrong semantics.  E.g., a 415
>  response is "Unsupported Media Type", but it's not for unsupported media
>  in the *session* (i.e., the SDP), it's for unsupported media in the
>  *INVITE body* (i.e., you can't process application/sdp).
>
>  OK, here it is:  RFC 3261 section 13.3.1.3:
>
>     A UAS rejecting an offer contained in an INVITE SHOULD return a 488
>     (Not Acceptable Here) response.  Such a response SHOULD include a
>     Warning header field value explaining why the offer was rejected.
>
>  section 21.4.26:
>
>  21.4.26 488 Not Acceptable Here
>
>     The response has the same meaning as 606 (Not Acceptable), but only
>     applies to the specific resource addressed by the Request-URI and the
>     request may succeed elsewhere.
>
>     A message body containing a description of media capabilities MAY be
>     present in the response, which is formatted according to the Accept
>     header field in the INVITE (or application/sdp if not present), the
>     same as a message body in a 200 (OK) response to an OPTIONS request.
>
>  and section 21.6.4:
>
>  21.6.4 606 Not Acceptable
>
>     The user's agent was contacted successfully but some aspects of the
>     session description such as the requested media, bandwidth, or
>     addressing style were not acceptable.
>
>     A 606 (Not Acceptable) response means that the user wishes to
>     communicate, but cannot adequately support the session described.
>     The 606 (Not Acceptable) response MAY contain a list of reasons in a
>     Warning header field describing why the session described cannot be
>     supported.  Warning reason codes are listed in Section 20.43.
>
>  And my memory was correct; a Warning header is appropriate in a 488
>  response.  Section 20.43 gives the details; it looks like a warn-code in
>  the range 390-398 is appropriate, or perhaps 300-329.  It seems like the
>  choice should be either 308 or 390, the first available codes in those
>  ranges.  And the ideal message text would contain the list of compatible
>  languages:
>
>      Warning: 308 proxy.example.com "Supported languages are: es, en"
>
>  The registration would be something like:
>
>      308 Incompatible language specification:  No requested      [this RFC=
]
>          language is supported and offerer requested failure.
>          The text should include the list of supported languages.

Thanks, Dale.  It seems that it would be useful=20
for the draft to suggest (not require) that a=20
session rejected due to lack of=20
mutually-supported languages use 488 or 606, and=20
also include a Warning header field with the=20
suggested 308 code that the draft would register.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
We are what we repeatedly do. Excellence, then, is not an act but a habit.
                                --Aristotle


From nobody Wed Feb 22 14:30:33 2017
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A40B129C0F for ; Wed, 22 Feb 2017 14:30:30 -0800 (PST)
X-Quarantine-ID: <5Xsyh-Y4jg2T>
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 5Xsyh-Y4jg2T for ; Wed, 22 Feb 2017 14:30:28 -0800 (PST)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 7087E129C0B for ; Wed, 22 Feb 2017 14:30:28 -0800 (PST)
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Wed, 22 Feb 2017 14:21:04 -0800
Mime-Version: 1.0
Message-Id: 
In-Reply-To: 
References: <0D2E61DC-1A6D-4B9C-8072-589D702AB54A@gsma.com> <6ff2e293-5f36-bb44-3108-3c0937eb58da@omnitor.se>  <2697072ec7a54ddbb972520b8303ec6f@EX13D08UWB002.ant.amazon.com> 
X-Mailer: Eudora for Mac OS X
Date: Wed, 22 Feb 2017 14:30:23 -0800
To: Brian Rosen , "Phillips, Addison" 
From: Randall Gellens 
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
Archived-At: 
Cc: "slim@ietf.org" , Natasha Rooney , Gunnar =?iso-8859-1?Q?Hellstr=F6m?= 
Subject: Re: [Slim] Shortening humintlang
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Feb 2017 22:30:30 -0000

I'm fine with using "hlang-send" and=20
"hlang-recv".  I suppose we could get extreme and=20
use "hlang-s" and "hlang-r" if want to push it.

At 11:43 AM -0500 2/22/17, Brian Rosen wrote:

>  Accept-Language is the language used in the=20
> SIP/HTTP exchange, not the language used in the=20
> media exchange.  We're trying to differentiate.=20
>  This has actually caused a lot of confusion,=20
> so it's not theoretical.
>
>  We could use "medlang", but I rather like "hlang" better.
>
>  We should acknowledge that this is a protocol=20
> discussion.  Humans don't see either element.=20
>  It could be "fubar" and work for the protocol=20
> exchange.
>
>  Brian
>
>>  On Feb 22, 2017, at 11:34 AM, Phillips,=20
>> Addison=20
>> <addison@lab126.com>=20
>> wrote:
>>
>>  Why is the "human" part an important=20
>> distinguisher? Accept-Language refers to the=20
>> same type of language: natural language=20
>> content. While our machines are getting better=20
>> about generating and responding to natural=20
>> languages, the point of these interfaces is=20
>> always human interaction. Why not just 'lang'?=20
>> It's short and it's consistent with usage=20
>> elsewhere.
>>
>>
>>  Addison Phillips
>>  Principal SDE, I18N Architect (Amazon)
>>  Chair (W3C I18N WG)
>>
>>  Internationalization is not a feature.
>>  It is an architecture.
>>
>>
>>
>>  From: SLIM=20
>> [mailto:slim-bounces@ietf.org] On=20
>> Behalf Of Brian Rosen
>>  Sent: Wednesday, February 22, 2017 7:27 AM
>>  To: Gunnar Hellstr=F6m=20
>> <gunnar.hellstrom@omnitor.se>
>>  Cc: slim@ietf.org;=20
>> Natasha Rooney=20
>> <nrooney@gsma.com>
>>  Subject: Re: [Slim] Shortening humintlang
>>
>>  I don't have any problem shortening the name,=20
>> but I do think retaining "human" is important=20
>> because we have always had problems confusing=20
>> the "Accept-Language" header.
>>
>>  How about 'hlang'?  Or 'hilang' if you must.
>>
>>  Brian
>>
>>
>>
>>  On Feb 22, 2017, at 6:17 AM, Gunnar Hellstr=F6m=20
>> <gunnar.hellstrom@omnitor.se>=20
>> wrote:
>>
>>  Den 2017-02-22 kl. 11:59, skrev Natasha Rooney:
>>
>>  Hi all,
>>
>>  We had this request from the Gen-ART reviewer=20
>> for raft-ietf-slim-negotiating-human-language-06:
>>
>>  C. "humintlang" seems long to me
>>
>>  Given the excessive length of SDP in practice, it seems to me that a
>>  shorter attribute name would be desirable.  E.g., "humlang" as was
>>  used in some previous versions.  Or is there a coordinated usage with
>>  other names in the "hum*lang" pattern?
>>
>>  Wdyt?
>>
>>  I have also had thoughts in the same=20
>> direction.  Especially when we quite late=20
>> decided to have only one language tag value=20
>> per attribute, the consumption of characters=20
>> for SDP increased dramatically.  
>>  It is a good habit to have attribute names=20
>> that are real words, but we have problems=20
>> inventing such names for this case. 
>>
>>  The "hum" part is in fact redundant.  So,=20
>> maybe Intlang-send and Intlang-recv    for=20
>> Interactive-language  would be an acceptable=20
>> shortening of the names.
>>
>>  The proposal to return to the Accept-Language=20
>> syntax, with the possibility to list all=20
>> languages in one media and direction on one=20
>> line would save us meven more, and should also=20
>> be considered, I think.    
>>
>>  Think about an outgoing call from a clever=20
>> multi-language call-center with capability in=20
>> 15 languages, both spoken and written.  
>>
>>  /Gunnar 
>>
>>
>>  Natasha Rooney | Internet Engineering Director=20
>> | Internet and Web Team | Technology | GSMA=20
>> | nrooney@gsma.com |=20
>> +44 (0) 7730 219 765 | @thisNatasha |=20
>> Skype: nrooney@gsm.org
>>
>>  This email and its attachments are intended=20
>> for the above named only and may be=20
>> confidential. If they have come to you in=20
>> error you must take no action based on them,=20
>> nor must you copy or show them to anyone;=20
>> please reply to this email or call +44 207 356=20
>> 0600 and highlight the error.
>>
>>
>>
>>  _______________________________________________
>>  SLIM mailing list
>>  SLIM@ietf.org
>>=20
>> https://www.ietf.org/mailman/=
listinfo/slim
>>
>>
>>
>>  --
>>  -----------------------------------------
>>  Gunnar Hellstr=F6m
>>  Omnitor
>>  gunnar.hellstrom@omnitor.se
>>  +46 708 204 288
>>  _______________________________________________
>>  SLIM mailing list
>>  SLIM@ietf.org
>>=20
>> https://www.ietf.org/mailman/=
listinfo/slim
>>
>
>
>  _______________________________________________
>  SLIM mailing list
>  SLIM@ietf.org
>  https://www.ietf.org/mailman/listinfo/slim


-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
People are not homeless if they're sleeping in the streets of
their own hometowns.       --Dan Quayle (U.S. Vice-President)


From nobody Wed Feb 22 14:33:32 2017
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F316E129BE2 for ; Wed, 22 Feb 2017 14:33:30 -0800 (PST)
X-Quarantine-ID: <7yUwcYuPFq5F>
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 7yUwcYuPFq5F for ; Wed, 22 Feb 2017 14:33:29 -0800 (PST)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 234A8129BE5 for ; Wed, 22 Feb 2017 14:33:29 -0800 (PST)
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Wed, 22 Feb 2017 14:24:06 -0800
Mime-Version: 1.0
Message-Id: 
In-Reply-To: 
References: <20170213161000.665a7a7059d7ee80bb4d670165c8327d.917539e857.wbe@email0 3.godaddy.com>  <4c4ef65a-a907-cf5e-4b2c-835fb55d0146@omnitor.se>  <434a4f06-f034-46ca-9df7-f59059e67e41@alumni.stanford.edu> <843f0cc1-2686-162d-25dc-0075847579bc@omnitor.se>  <84760193-19e6-1f53-43cc-32b0493a1844@alumni.stanford.edu>  <4f1f3a72-d8a9-4f41-4133-0e6d54aadec8@omnitor.se>   
X-Mailer: Eudora for Mac OS X
Date: Wed, 22 Feb 2017 14:33:24 -0800
To: Paul Kyzivat , slim@ietf.org
From: Randall Gellens 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
Archived-At: 
Subject: Re: [Slim] IETF last call for draft-ietf-slim-negotiating-human-language (Issue 8, section 6, IANA registrations)
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Feb 2017 22:33:31 -0000

At 12:30 PM -0500 2/15/17, Paul Kyzivat wrote:

>  On 2/15/17 11:26 AM, Randall Gellens wrote:
>
>>>   I checked in current IANA registrations, and found that all SDP
>>>  attribute registrations now include the "Mux Category".
>>>
>>>   So, I assume that we are obliged to do so also and hope that we can
>>>  agree on that.
>>>   As far as I understand the logic, we should specify NORMAL.
>>
>>  This is not required.  See the IANA registry at
>>  http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xhtml. It
>>  is governed by RFC 4566.
>>
>>  As I've written twice before, my concern is that this suggestion exceeds
>>  a simple editorial change, and therefore may need to be discussed on the
>>  WG list with WG consensus before it can be adopted.  These fields can be
>>  added to the attribute registration later, according to the rules for
>>  the registry
>>  (http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xhtml).
>
>  The mux-category is a big deal. There is a document in progress 
> that defines the mux-category for all existing attributes. 
> Attributes defined after that need to define their mux-category. 
> There is potentially a problem with attributes defined while this 
> work is in progress. That document for old attributes isn't going 
> to chase after ones defined concurrently. I think you will find 
> that if you don't define this then it will be caught and requested 
> either by a sdp-directorate review, or else the iesg review. So 
> just do it!

After reading through draft-ietf-mmusic-sdp-mux-attributes, I agree 
and have added "MUX Category:  normal" to both attributes.


>>>   I saw no trace yet of registrations of  "Usage Level: dcsa(subprotocol)"
>>>
>>>   I would like to get advice from someone with insight in the SDP
>>>  attribute registration and the status of the dsca(subprotocol) value
>>>  on how we should proceed in order to get the dsca(subprotocol)
>>>  included in a smooth way without causing exessive delay.
>
>  So far there has been *no* interest in defining RTP over SCTP. 
> Until/unless that is defined there is no need to define dcsa for 
> this attribute.
>
>  	Thanks,
>  	Paul
>
>
>  _______________________________________________
>  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: ---------------
Children are natural mimics who act like their parents despite every
effort to teach them good manners.


From nobody Wed Feb 22 20:06:41 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 A741012A01D; Wed, 22 Feb 2017 20:06:36 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.45.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148782279664.31054.8793649134696520241.idtracker@ietfa.amsl.com>
Date: Wed, 22 Feb 2017 20:06:36 -0800
Archived-At: 
Cc: slim@ietf.org
Subject: [Slim] I-D Action: draft-ietf-slim-negotiating-human-language-07.txt
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Feb 2017 04:06:37 -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-07.txt
	Pages           : 17
	Date            : 2017-02-22

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

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


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

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-slim-negotiating-human-language-07

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


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

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


From nobody Wed Feb 22 20:16: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 E7B5812956C for ; Wed, 22 Feb 2017 20:16:01 -0800 (PST)
X-Quarantine-ID: 
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wQhz29CBCnCo for ; Wed, 22 Feb 2017 20:16:00 -0800 (PST)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id CE7C1129566 for ; Wed, 22 Feb 2017 20:16:00 -0800 (PST)
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Wed, 22 Feb 2017 20:06:35 -0800
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <148782279664.31054.8793649134696520241.idtracker@ietfa.amsl.com>
References: <148782279664.31054.8793649134696520241.idtracker@ietfa.amsl.com>
X-Mailer: Eudora for Mac OS X
Date: Wed, 22 Feb 2017 20:15:58 -0800
To: slim@ietf.org, Natasha Rooney , Bernard Aboba 
From: Randall Gellens 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
Archived-At: 
Subject: Re: [Slim] I-D Action: draft-ietf-slim-negotiating-human-language-07.txt
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Feb 2017 04:16:02 -0000

Version -07 addresses all comments except for the unresolved issue of 
renaming the two attributes which is currently being discussed on the 
list, and adding a new attribute for bidirectionality.

Per Dale's suggestion, the draft adds advice that if a call is 
rejected due to no languages in common, SIP response code 488 (Not 
Acceptable Here) or 606 (Not Acceptable) be used, along with a 
Warning header field indicating the supported languages.  The draft 
registers a new entry in the warn-code sub-registry of SIP parameters 
for this purpose.  The draft also has an expanded set of examples.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Ninety percent of the politicians give the other ten percent a bad name.
                                                      --Henry Kissinger


From nobody Thu Feb 23 09:38: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 69D1A1294CF; Thu, 23 Feb 2017 09:38:07 -0800 (PST)
X-Quarantine-ID: <86We3dWaumE3>
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 86We3dWaumE3; Thu, 23 Feb 2017 09:38:05 -0800 (PST)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 86AFB12A202; Thu, 23 Feb 2017 09:38:05 -0800 (PST)
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Thu, 23 Feb 2017 09:28:32 -0800
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <87fuj4syy6.fsf@hobgoblin.ariadne.com>
References: <87fuj4syy6.fsf@hobgoblin.ariadne.com>
X-Mailer: Eudora for Mac OS X
Date: Thu, 23 Feb 2017 09:35:19 -0800
To: worley@ariadne.com (Dale R. Worley)
From: Randall Gellens 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
Archived-At: 
Cc: slim@ietf.org, ietf@ietf.org, gen-art@ietf.org, gunnar.hellstrom@omnitor.se, draft-ietf-slim-negotiating-human-language.all@ietf.org, rg+ietf@randy.pensive.org
Subject: Re: [Slim] Review of draft-ietf-slim-negotiating-human-language-06
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Feb 2017 17:38:07 -0000

At 10:34 AM -0500 2/23/17, Dale R. Worley wrote:

>  Randall Gellens  writes:
>>  Thanks, Dale.  It seems that it would be useful
>>  for the draft to suggest (not require) that a
>>  session rejected due to lack of
>>  mutually-supported languages use 488 or 606, and
>>  also include a Warning header field with the
>>  suggested 308 code that the draft would register.
>
>  It seems to me that specifying how to reject the call is one of those
>  "SHOULD" things.  Of course, the document would have to register 308 as
>  a warn-code.

The update I posted yesterday does register a new warn-code.  I'm not 
sure we need to use SHOULD instead of explicit advice for the SIP 
response code.  I doubt implementers would ignore the explicit advice 
yet would honor a SHOULD.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
An elephant is a mouse with an operating system.


From nobody Fri Feb 24 00:07:00 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 BB7E812999E for ; Fri, 24 Feb 2017 00:06:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 d1aPRyPBOyep for ; Fri, 24 Feb 2017 00:06:57 -0800 (PST)
Received: from bin-vsp-out-02.atm.binero.net (bin-mail-out-05.binero.net [195.74.38.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D203B129637 for ; Fri, 24 Feb 2017 00:06:56 -0800 (PST)
X-Halon-ID: 312b51de-fa68-11e6-af92-005056917f90
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [77.53.231.21]) by bin-vsp-out-02.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Fri, 24 Feb 2017 09:06:48 +0100 (CET)
To: Randall Gellens , Paul Kyzivat , slim@ietf.org, "ietf@ietf.org" 
References: <20170213161000.665a7a7059d7ee80bb4d670165c8327d.917539e857.wbe@email0 3.godaddy.com>  <4c4ef65a-a907-cf5e-4b2c-835fb55d0146@omnitor.se>  <434a4f06-f034-46ca-9df7-f59059e67e41@alumni.stanford.edu> <843f0cc1-2686-162d-25dc-0075847579bc@omnitor.se>  <84760193-19e6-1f53-43cc-32b0493a1844@alumni.stanford.edu>  <4f1f3a72-d8a9-4f41-4133-0e6d54aadec8@omnitor.se>    
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: <69f9c707-345c-e90f-ba24-54173c311d72@omnitor.se>
Date: Fri, 24 Feb 2017 09:06:49 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Slim] IETF last call for draft-ietf-slim-negotiating-human-language (Issue 8, section 6, IANA registrations)
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Feb 2017 08:06:58 -0000

Den 2017-02-22 kl. 23:33, skrev Randall Gellens:
>
> After reading through draft-ietf-mmusic-sdp-mux-attributes, I agree 
> and have added "MUX Category:  normal" to both attributes.
NORMAL    with capitals seems to be the form to register.  please change 
in the draft.

Regards
Gunnar

-- 


From nobody Fri Feb 24 02:39:35 2017
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65903129678 for ; Fri, 24 Feb 2017 02:39:34 -0800 (PST)
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 tjK05nGeZOrQ for ; Fri, 24 Feb 2017 02:39:30 -0800 (PST)
Received: from bin-vsp-out-01.atm.binero.net (vsp-unauthed02.binero.net [195.74.38.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7A17129560 for ; Fri, 24 Feb 2017 02:39:29 -0800 (PST)
X-Halon-ID: 82c344a0-fa7d-11e6-ad4a-005056917a89
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [77.53.231.21]) by bin-vsp-out-01.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Fri, 24 Feb 2017 11:39:22 +0100 (CET)
To: Brian Rosen , "Phillips, Addison" 
References: <0D2E61DC-1A6D-4B9C-8072-589D702AB54A@gsma.com> <6ff2e293-5f36-bb44-3108-3c0937eb58da@omnitor.se>  <2697072ec7a54ddbb972520b8303ec6f@EX13D08UWB002.ant.amazon.com> 
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: <68b2f215-66f4-4207-7609-86015b8ce83a@omnitor.se>
Date: Fri, 24 Feb 2017 11:39:22 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------741BCE5BFA704D78E87C8172"
Archived-At: 
Cc: "slim@ietf.org" , Natasha Rooney 
Subject: Re: [Slim] Shortening humintlang
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Feb 2017 10:39:34 -0000

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

Den 2017-02-22 kl. 17:43, skrev Brian Rosen:
> Accept-Language is the language used in the SIP/HTTP exchange, not the 
> language used in the media exchange.  We’re trying to differentiate. 
>  This has actually caused a lot of confusion, so it’s not theoretical.
>
> We could use “medlang”, but I rather like “hlang” better.
I agree that "hlang" would be a good improvement over "humintlang", and 
I want to see that change done.  We cannot invent a term that is 
explicit and short. "Human" is implied by all usage of BCP 47, 
"Interactive" is our focus, but I do not think that we should forbid use 
outside that application area, we just do not do any special definitions 
for stored and streamed use. So why not let 
"human-interactive-language-" be represented by the short "hlang-".

To have a name for both directions and other names for each separate 
direction,  "hlang", "hlang-send", "hlang-recv" would cause a bit more 
complicated parsing and complicated definition about how combinations of 
these for the same media should be handled. Maybe most such combinations 
would be unusual and unimportant, but the effect of finding them in SDP 
would need to be defined. Still, we would gain in simplicity in 
indication for the dominating symmetrical cases. I am quite sure we have 
discussed this option before and decided to not go that way, but I can 
accept a change-of-minds if so desired.


/Gunnar



>
> We should acknowledge that this is a protocol discussion.  Humans 
> don’t see either element.  It could be “fubar” and work for the 
> protocol exchange.
>
> Brian
>
>> On Feb 22, 2017, at 11:34 AM, Phillips, Addison > > wrote:
>>
>> Why is the “human” part an important distinguisher? Accept-Language 
>> refers to the same type of language: natural language content. While 
>> our machines are getting better about generating and responding to 
>> natural languages, the point of these interfaces is always human 
>> interaction. Why not just ‘lang’? It’s short and it’s consistent with 
>> usage elsewhere.
>> Addison Phillips
>> Principal SDE, I18N Architect (Amazon)
>> Chair (W3C I18N WG)
>> Internationalization is not a feature.
>> It is an architecture.
>> *From:*SLIM [mailto:slim-bounces@ietf.org]*On Behalf Of*Brian Rosen
>> *Sent:*Wednesday, February 22, 2017 7:27 AM
>> *To:*Gunnar Hellström > >
>> *Cc:*slim@ietf.org ; Natasha Rooney 
>> >
>> *Subject:*Re: [Slim] Shortening humintlang
>> I don’t have any problem shortening the name, but I do think 
>> retaining “human” is important because we have always had problems 
>> confusing the “Accept-Language” header.
>> How about ‘hlang'?  Or 'hilang' if you must.
>> Brian
>>
>>     On Feb 22, 2017, at 6:17 AM, Gunnar Hellström
>>     >     > wrote:
>>     Den 2017-02-22 kl. 11:59, skrev Natasha Rooney:
>>
>>         Hi all,
>>         We had this request from the Gen-ART reviewer
>>         for raft-ietf-slim-negotiating-human-language-06:
>>         C. "humintlang" seems long to me
>>
>>         Given the excessive length of SDP in practice, it seems to me
>>         that a
>>         shorter attribute name would be desirable.  E.g., "humlang"
>>         as was
>>         used in some previous versions.  Or is there a coordinated
>>         usage with
>>         other names in the "hum*lang" pattern?
>>         Wdyt?
>>
>>     I have also had thoughts in the same direction. Especially when
>>     we quite late decided to have only one language tag value per
>>     attribute, the consumption of characters for SDP increased
>>     dramatically.
>>     It is a good habit to have attribute names that are real words,
>>     but we have problems inventing such names for this case.
>>
>>     The "hum" part is in fact redundant.  So, maybe Intlang-send and
>>     Intlang-recv    for Interactive-language  would be an acceptable
>>     shortening of the names.
>>
>>     The proposal to return to the Accept-Language syntax, with the
>>     possibility to list all languages in one media and direction on
>>     one line would save us meven more, and should also be considered,
>>     I think.
>>
>>     Think about an outgoing call from a clever multi-language
>>     call-center with capability in 15 languages, both spoken and
>>     written.
>>
>>     /Gunnar
>>
>>
>>         Natasha Rooney | Internet Engineering Director | Internet and
>>         Web Team | Technology | GSMA | nrooney@gsma.com
>>          | +44 (0) 7730 219 765 |
>>         @thisNatasha | Skype: nrooney@gsm.org 
>>         This email and its attachments are intended for the above
>>         named only and may be confidential. If they have come to you
>>         in error you must take no action based on them, nor must you
>>         copy or show them to anyone; please reply to this email or
>>         call +44 207 356 0600 and highlight the error.
>>
>>
>>
>>         _______________________________________________
>>
>>         SLIM mailing list
>>
>>         SLIM@ietf.org 
>>
>>         https://www.ietf.org/mailman/listinfo/slim
>>
>>
>>
>>     -- 
>>
>>     -----------------------------------------
>>
>>     Gunnar Hellström
>>
>>     Omnitor
>>
>>     gunnar.hellstrom@omnitor.se 
>>
>>     +46 708 204 288
>>
>>     _______________________________________________
>>     SLIM mailing list
>>     SLIM@ietf.org 
>>     https://www.ietf.org/mailman/listinfo/slim
>>
>
>
>
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim

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


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


  
    
  
  
    Den 2017-02-22 kl. 17:43, skrev Brian Rosen:

    

      
      Accept-Language is the language used in the SIP/HTTP exchange, not
      the language used in the media exchange.  We’re trying to
      differentiate.  This has actually caused a lot of confusion, so
      it’s not theoretical.
      


      

      
We could use “medlang”, but I rather like “hlang”
        better.

    

    I agree that "hlang" would be a good improvement over "humintlang",
    and I want to see that change done.  We cannot invent a term that is
    explicit and short. "Human" is implied by all usage of BCP 47,
    "Interactive" is our focus, but I do not think that we should forbid
    use outside that application area, we just do not do any special
    definitions for stored and streamed use. So why not let
    "human-interactive-language-" be represented by the short "hlang-".

    

    To have a name for both directions and other names for each separate
    direction,  "hlang", "hlang-send", "hlang-recv" would cause a bit
    more complicated parsing and complicated definition about how
    combinations of these for the same media should be handled. Maybe
    most such combinations would be unusual and unimportant, but the
    effect of finding them in SDP would need to be defined. Still, we
    would gain in simplicity in indication for the dominating
    symmetrical cases. I am quite sure we have discussed this option
    before and decided to not go that way, but I can accept a
    change-of-minds if so desired.

    

    

    /Gunnar

       

    

    

    

      


      

      
We should acknowledge that this is a protocol
        discussion.  Humans don’t see either element.  It could be
        “fubar” and work for the protocol exchange.

      


      

      
Brian

      


        

          

            
On Feb 22, 2017, at 11:34 AM, Phillips,
              Addison <addison@lab126.com>
              wrote:

            

            

              

                
Why
                    is the “human” part an important distinguisher?
                    Accept-Language refers to the same type of language:
                    natural language content. While our machines are
                    getting better about generating and responding to
                    natural languages, the point of these interfaces is
                    always human interaction. Why not just ‘lang’? It’s
                    short and it’s consistent with usage elsewhere.

                
 

                
 

                
Addison Phillips

                
Principal SDE, I18N Architect
                    (Amazon)

                
Chair (W3C I18N WG)

                
 

                
Internationalization is not a
                    feature.

                
It is an architecture.

                
 

                
 

                
 

                

                  

                    

                      
From: SLIM [mailto:slim-bounces@ietf.org] On Behalf Of Brian
                          Rosen

                          Sent: Wednesday,
                          February 22, 2017 7:27 AM

                          To: Gunnar
                          Hellström <gunnar.hellstrom@omnitor.se>

                          Cc: slim@ietf.org;
                          Natasha Rooney <nrooney@gsma.com>

                          Subject: Re:
                          [Slim] Shortening humintlang

                    

                  

                  
 

                  
I
                    don’t have any problem shortening the name, but I do
                    think retaining “human” is important because we have
                    always had problems confusing the “Accept-Language”
                    header.

                  

                    
 

                  

                  

                    
How about ‘hlang'?  Or 'hilang' if you
                      must.  

                  

                  

                    
 

                  

                  

                    
Brian

                  

                  

                    
 

                  

                  

                    
 

                    

                      

                        

                          
On Feb 22, 2017, at
                            6:17 AM, Gunnar Hellström <gunnar.hellstrom@omnitor.se>
                            wrote:

                        

                        
 

                        

                          

                            
Den 2017-02-22
                              kl. 11:59, skrev Natasha Rooney:

                              

                              

                            

                              
Hi all, 

                              

                                
 

                              

                              

                                
We had
                                  this request from the Gen-ART reviewer
for raft-ietf-slim-negotiating-human-language-06:

                              

                              

                                
 

                              

                              

                                
C.
                                  "humintlang" seems long to me

                                  

                                  Given the excessive length of SDP in
                                  practice, it seems to me that a

                                  shorter attribute name would be
                                  desirable.  E.g., "humlang" as was

                                  used in some previous versions.  Or is
                                  there a coordinated usage with

                                  other names in the "hum*lang" pattern?

                              

                              

                                
 

                              

                              

                                
Wdyt?

                              

                            

                            
I have also had
                              thoughts in the same direction. 
                              Especially when we quite late decided to
                              have only one language tag value per
                              attribute, the consumption of characters
                              for SDP increased dramatically.  

                              It is a good habit to have attribute names
                              that are real words, but we have problems
                              inventing such names for this case. 

                              

                              The "hum" part is in fact redundant.  So,
                              maybe Intlang-send and Intlang-recv    for
                              Interactive-language  would be an
                              acceptable shortening of the names.

                              

                              The proposal to return to the
                              Accept-Language syntax, with the
                              possibility to list all languages in one
                              media and direction on one line would save
                              us meven more, and should also be
                              considered, I think.    

                              

                              Think about an outgoing call from a clever
                              multi-language call-center with capability
                              in 15 languages, both spoken and written.  

                              

                              /Gunnar 

                              

                              

                            

                              

                                

                                  

                                    


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

                                  

                                

                                
 

                              

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

                              


                                

                                

                                

                              
_______________________________________________

                              
SLIM mailing list

                              
SLIM@ietf.org

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

                            

                            


                              

                              

                            
-- 

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

                            
Gunnar Hellström

                            
Omnitor

                            
gunnar.hellstrom@omnitor.se

                            
+46 708 204 288

                          

                          
_______________________________________________

                            SLIM mailing list

                            SLIM@ietf.org

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

                        

                      

                    

                  

                

              

            

          

        

        

      

      

      

      

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


    

    

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

  


--------------741BCE5BFA704D78E87C8172--


From nobody Fri Feb 24 08:21:55 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 92BD41299AD; Fri, 24 Feb 2017 08:21:54 -0800 (PST)
X-Quarantine-ID: 
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LqOrIWPZWg07; Fri, 24 Feb 2017 08:21:53 -0800 (PST)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id AFB75128AC9; Fri, 24 Feb 2017 08:21:53 -0800 (PST)
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Fri, 24 Feb 2017 08:12:12 -0800
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <69f9c707-345c-e90f-ba24-54173c311d72@omnitor.se>
References: <20170213161000.665a7a7059d7ee80bb4d670165c8327d.917539e857.wbe@email0 3.godaddy.com>  <4c4ef65a-a907-cf5e-4b2c-835fb55d0146@omnitor.se>  <434a4f06-f034-46ca-9df7-f59059e67e41@alumni.stanford.edu> <843f0cc1-2686-162d-25dc-0075847579bc@omnitor.se>  <84760193-19e6-1f53-43cc-32b0493a1844@alumni.stanford.edu>  <4f1f3a72-d8a9-4f41-4133-0e6d54aadec8@omnitor.se>     <69f9c707-345c-e90f-ba24-54173c311d72@omnitor.se>
X-Mailer: Eudora for Mac OS X
Date: Fri, 24 Feb 2017 08:18:08 -0800
To: Gunnar =?iso-8859-1?Q?Hellstr=F6m?=  , Paul Kyzivat , slim@ietf.org, "ietf@ietf.org" 
From: Randall Gellens 
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
Archived-At: 
Subject: Re: [Slim] IETF last call for draft-ietf-slim-negotiating-human-language (Issue 8, section 6, IANA  registrations)
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Feb 2017 16:21:54 -0000

At 9:06 AM +0100 2/24/17, Gunnar Hellstr=F6m wrote:

>  Den 2017-02-22 kl. 23:33, skrev Randall Gellens:
>>
>>  After reading through=20
>> draft-ietf-mmusic-sdp-mux-attributes, I agree=20
>> and have added "MUX Category:  normal" to both=20
>> attributes.
>  NORMAL    with capitals seems to be the form to=20
> register.  please change in the draft.

OK

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
[P]olitics, as a practice, whatever its professions, has always been
the systematic organization of hatreds.
                                    --American historian Henry Adams


From nobody Fri Feb 24 08:35: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 07287126BF6 for ; Fri, 24 Feb 2017 08:35:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 IdFd1MQ_sFNy for ; Fri, 24 Feb 2017 08:35:07 -0800 (PST)
Received: from bin-vsp-out-02.atm.binero.net (vsp-unauthed02.binero.net [195.74.38.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB62C12706D for ; Fri, 24 Feb 2017 08:35:06 -0800 (PST)
X-Halon-ID: 2d62f039-faaf-11e6-af92-005056917f90
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [77.53.231.21]) by bin-vsp-out-02.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Fri, 24 Feb 2017 17:34:56 +0100 (CET)
To: Randall Gellens , slim@ietf.org, Natasha Rooney , Bernard Aboba 
References: <148782279664.31054.8793649134696520241.idtracker@ietfa.amsl.com> 
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: <49fd730e-6e90-1a49-eae8-80f8b1285a76@omnitor.se>
Date: Fri, 24 Feb 2017 17:35:00 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
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] I-D Action: draft-ietf-slim-negotiating-human-language-07.txt
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Feb 2017 16:35:11 -0000

Den 2017-02-23 kl. 05:15, skrev Randall Gellens:
> Version -07 addresses all comments except for the unresolved issue of 
> renaming the two attributes which is currently being discussed on the 
> list, and adding a new attribute for bidirectionality.
>
> Per Dale's suggestion, the draft adds advice that if a call is 
> rejected due to no languages in common, SIP response code 488 (Not 
> Acceptable Here) or 606 (Not Acceptable) be used, along with a Warning 
> header field indicating the supported languages.  The draft registers 
> a new entry in the warn-code sub-registry of SIP parameters for this 
> purpose.  The draft also has an expanded set of examples.
>
Good progress. Good to see the enriched examples chapter 5.5.
I have a few comments on version -07:

1.  Section  4. second line
------------old text----------------------
but is not sufficiently sufficiently
------------new text--------------------------
but is not sufficiently
----------end of change 1-----------------
Motivation: New typo in version -07

2. Section 5.2, first line
----------------old text-----------------
This document defines two new media-level ..
----------------new text----------------------
This document defines two media-level ...
----------------end of change 2----------------
Motivation: It was commented that when the draft is published, this is 
not new anymore.
There are three more occasions of "new" in the document that may be 
modified as well.

3.  5.2 second paragraph
-------------------old text--------------------------------
In an offer, the 'humintlang-send' values indicates the language(s)
    the offerer is willing to use when sending using the media, and the
    'humintlang-recv' values indicates the language(s) the offerer is
    willing to use when receiving using the media.
-----------------new text---------------------------------
In an offer, the 'humintlang-send' values indicate the language(s)
the offerer is willing to select from for use when sending using the
media, and the 'humintlang-recv' values indicate the language(s) the
offerer is willing to receive one of in the media stream.
----------------end of change----------------------------------
Motivation 1:) change from "indicates" to "indicate" in two places to 
match the new use of plural "values".
Motivation 2:) Be sure to indicate that we only intend to negotiate one 
language per media and direction, so that we do not end up as 
unspecified regarding number of matches required as the sdp "lang" 
attribute is.

4.  5.2 Second paragraph
-----------------old text-----------------------
When a media is intended
    for use in one direction only
----------------new text---------------------
When a media is intended
    for use for language communication in one direction only
----------------end of change---------------------------
Motivation: Deletion of a note in this sentence made it less obvious 
that we are only talking about directions of use of language 
communication, and not about establishing asymmetric media connections. 
Therefore add this clarification.

5.  5.2 Deleted paragraph 6 before "Clients acting on behalf..."
----------reinsert modified paragraph----------------------------
While signed language tags are used with a video stream to
indicate sign language, a spoken language tag for a video stream
indicates a request or offer to see the speaker, when that is of
importance for language perception.
-------------end of change-------------------------------------------
Motivation: There was in the LC mail exchange a discussion about 
sharpening up the specification of use of "unusual combinations".
There was no agreement to delete them all. The one described in this 
paragraph is the main one that has widespread use and needs to be 
clearly specified for use by a large number of hard-of-hearing and deaf 
users.

6.  5.2 Sixth paragraph
--------------------current text--------------------
(or for unidirectional streams, one of)
------------------new text ------------------------
(or for asymmetrical use of languages, one of)
-----------------end of change----------------------
Motivation: We are not primarily talking about enabled transmission 
directions of the streams, but about language use in the streams. We do 
not want to limit the media stream directions just because we do not 
specify an initial language to use for that direction. There are other 
usage of media, and there may even be occasional use of language in the 
direction, just not worth mentioning as an initial and preferred use. 
The suggested change should make that clear.

7.   5.3 Next to last paragraph
------------------old text------------------------------
a list of supported languages.
-------------------new text-------------------------
a list of supported languages, media and directions.
-------------------end of change----------------
Motivation: It is not sufficient to know which languages are supported, 
it is also essential to know in which media they are supported and in 
which directions. (media could be replaced with modality, but the media 
can become ambigous then, so use media here to be brief.

8.      5.3, last line
--------------old text----------------------------------
  Supported languages are: es, en"
--------------new text-------------------------------
  Supported languages are: es, en transmission in audio; es, en 
reception in audio"
----------------------------------------------------------
Motivation: Same as for 7.

9.  5.4 Undefined combinations
----------------------------old text--------------------------------------
    The behavior when specifying a non-signed language tag for a video
    media stream, or a signed language tag for an audio or text media
    stream, is not defined.
---------------------------new text-----------------------------------------
There is no way specified for indicating use of text based language in a 
video media stream.
There is no meaning assigned to specification of  sign language in an 
audio or text media stream.
--------------------------end of change-------------------------------
Motivation: Seeing the speaker in video is an important combination 
reinserted above in section 5.2.
This section therefore needed rewording to not include that combination.


10.     6.2 Last sentence
-----------------current text---------------------
Supported languages are: [list of supported languages]."
-----------------new text------------------------
Supported languages and media and transmission directions are:[list of 
supported languages and media and transmission directions.]"
-----------------end of change--------------------------
Motivation: Same as for 7.

11.  6.1 MUX Category
----------old text in two locations-------------------
MUX Category:  normal
---------new text in same two locations--------------
Mux Category:  NORMAL
---------end of change-----------------
Motivation: Follow RFC 4566bis and IANA habits regarding use of capitals

12.  5.3
-------------old text-----------------
5.3 No Language in Common
-------------new text----------------
5.3 Preference parameter
------------end of change 1 in 5.3---------------

-------------old text-in 5.3, second 
paragraph-------------------------------
The mechanism for indicating this preference is that, in an offer, if
the last character of any of the 'humintlang-recv' or 'humintlang-
send' values is an asterisk, this indicates a request to not fail the call.
--------------------------new text-------------------------------
The mechanism for indicating this preference is that, in an offer, if
    the last character of any of the 'humintlang-recv' or 'humintlang-
    send' values is an asterisk, this indicates a request to not fail 
the call.
The asterisk should be attached to attributes with languages of lower
preference to be matched if such difference can be specified. Thereby
the location of the asterisk can be used to support the decision on
which languages to use in the call.
---------------------------end of change 2 in 
5.3--------------------------------------
Motivation: There has not yet been any conclusion for my proposal no 5 
in the IETF LC comments of Feb 12.
This is a dramatically reduced version that may be easier to accept at 
this stage, still covering one of the missing functionalities in the draft.
The asterisk is used as a preference parameter in the attributes. 
Thereby the proposed title change on 5.3
With this additional rule about where the asterisk(s) are placed, the 
answering parties get good clues about the preferences between 
alternatives presented by the offeror. The chance to set up calls with 
satisfied users increase dramatically compared to letting the answering 
party select by chance between alternatives.

Regards

Gunnar

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


From nobody Fri Feb 24 16:33:04 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 2078D1295F9 for ; Fri, 24 Feb 2017 16:33:03 -0800 (PST)
X-Quarantine-ID: 
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qMVASdxVEqew for ; Fri, 24 Feb 2017 16:33:01 -0800 (PST)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 20D8E12952F for ; Fri, 24 Feb 2017 16:33:01 -0800 (PST)
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Fri, 24 Feb 2017 16:23:15 -0800
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <49fd730e-6e90-1a49-eae8-80f8b1285a76@omnitor.se>
References: <148782279664.31054.8793649134696520241.idtracker@ietfa.amsl.com>  <49fd730e-6e90-1a49-eae8-80f8b1285a76@omnitor.se>
X-Mailer: Eudora for Mac OS X
Date: Fri, 24 Feb 2017 16:32:55 -0800
To: Gunnar =?iso-8859-1?Q?Hellstr=F6m?=  , slim@ietf.org, Natasha Rooney , Bernard Aboba 
From: Randall Gellens 
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
Archived-At: 
Subject: Re: [Slim] I-D Action: draft-ietf-slim-negotiating-human-language-07.txt
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 25 Feb 2017 00:33:03 -0000

At 5:35 PM +0100 2/24/17, Gunnar Hellstr=F6m wrote:

>  Den 2017-02-23 kl. 05:15, skrev Randall Gellens:
>>  Version -07 addresses all comments except for=20
>> the unresolved issue of renaming the two=20
>> attributes which is currently being discussed=20
>> on the list, and adding a new attribute for=20
>> bidirectionality.
>>
>>  Per Dale's suggestion, the draft adds advice=20
>> that if a call is rejected due to no languages=20
>> in common, SIP response code 488 (Not=20
>> Acceptable Here) or 606 (Not Acceptable) be=20
>> used, along with a Warning header field=20
>> indicating the supported languages.  The draft=20
>> registers a new entry in the warn-code=20
>> sub-registry of SIP parameters for this=20
>> purpose.  The draft also has an expanded set=20
>> of examples.
>>
>  Good progress. Good to see the enriched examples chapter 5.5.
>  I have a few comments on version -07:
>
>  1.  Section  4. second line
>  ------------old text----------------------
>  but is not sufficiently sufficiently
>  ------------new text--------------------------
>  but is not sufficiently
>  ----------end of change 1-----------------
>  Motivation: New typo in version -07

Thanks.

>
>  2. Section 5.2, first line
>  ----------------old text-----------------
>  This document defines two new media-level ..
>  ----------------new text----------------------
>  This document defines two media-level ...
>  ----------------end of change 2----------------
>  Motivation: It was commented that when the=20
> draft is published, this is not new anymore.
>  There are three more occasions of "new" in the=20
> document that may be modified as well.

OK.

>
>  3.  5.2 second paragraph
>  -------------------old text--------------------------------
>  In an offer, the 'humintlang-send' values indicates the language(s)
>     the offerer is willing to use when sending using the media, and the
>     'humintlang-recv' values indicates the language(s) the offerer is
>     willing to use when receiving using the media.
>  -----------------new text---------------------------------
>  In an offer, the 'humintlang-send' values indicate the language(s)
>  the offerer is willing to select from for use when sending using the
>  media, and the 'humintlang-recv' values indicate the language(s) the
>  offerer is willing to receive one of in the media stream.
>  ----------------end of change----------------------------------
>  Motivation 1:) change from "indicates" to=20
> "indicate" in two places to match the new use=20
> of plural "values".
>  Motivation 2:) Be sure to indicate that we only=20
> intend to negotiate one language per media and=20
> direction, so that we do not end up as=20
> unspecified regarding number of matches=20
> required as the sdp "lang" attribute is.

Reworded.

>
>  4.  5.2 Second paragraph
>  -----------------old text-----------------------
>  When a media is intended
>     for use in one direction only
>  ----------------new text---------------------
>  When a media is intended
>     for use for language communication in one direction only
>  ----------------end of change---------------------------
>  Motivation: Deletion of a note in this sentence=20
> made it less obvious that we are only talking=20
> about directions of use of language=20
> communication, and not about establishing=20
> asymmetric media connections. Therefore add=20
> this clarification.

Reworded.

>
>  5.  5.2 Deleted paragraph 6 before "Clients acting on behalf..."
>  ----------reinsert modified paragraph----------------------------
>  While signed language tags are used with a video stream to
>  indicate sign language, a spoken language tag for a video stream
>  indicates a request or offer to see the speaker, when that is of
>  importance for language perception.
>  -------------end of change-------------------------------------------
>  Motivation: There was in the LC mail exchange a=20
> discussion about sharpening up the=20
> specification of use of "unusual combinations".
>  There was no agreement to delete them all. The=20
> one described in this paragraph is the main one=20
> that has widespread use and needs to be clearly=20
> specified for use by a large number of=20
> hard-of-hearing and deaf users.

The text as it is now does not prohibit anything=20
and explicitly mentions negotiating supplemental=20
video by omitting language attributes on a video=20
media.

>
>  6.  5.2 Sixth paragraph
>  --------------------current text--------------------
>  (or for unidirectional streams, one of)
>  ------------------new text ------------------------
>  (or for asymmetrical use of languages, one of)
>  -----------------end of change----------------------
>  Motivation: We are not primarily talking about=20
> enabled transmission directions of the streams,=20
> but about language use in the streams. We do=20
> not want to limit the media stream directions=20
> just because we do not specify an initial=20
> language to use for that direction. There are=20
> other usage of media, and there may even be=20
> occasional use of language in the direction,=20
> just not worth mentioning as an initial and=20
> preferred use. The suggested change should make=20
> that clear.
>
>  7.   5.3 Next to last paragraph
>  ------------------old text------------------------------
>  a list of supported languages.
>  -------------------new text-------------------------
>  a list of supported languages, media and directions.
>  -------------------end of change----------------
>  Motivation: It is not sufficient to know which=20
> languages are supported, it is also essential=20
> to know in which media they are supported and=20
> in which directions. (media could be replaced=20
> with modality, but the media can become=20
> ambigous then, so use media here to be brief.

I don't know that we can require this, but I'll=20
add SHOULD kist supported languages and media.=20
Demanding direction as well might be too unwieldy.

>
>  8.      5.3, last line
>  --------------old text----------------------------------
>   Supported languages are: es, en"
>  --------------new text-------------------------------
>   Supported languages are: es, en transmission=20
> in audio; es, en reception in audio"
>  ----------------------------------------------------------
>  Motivation: Same as for 7.

=46ixed as above.

>
>  9.  5.4 Undefined combinations
>  ----------------------------old text-------------------------------------=
-
>     The behavior when specifying a non-signed language tag for a video
>     media stream, or a signed language tag for an audio or text media
>     stream, is not defined.
>  ---------------------------new text--------------------------------------=
---
>  There is no way specified for indicating use of=20
> text based language in a video media stream.
>  There is no meaning assigned to specification=20
> of  sign language in an audio or text media=20
> stream.
>  --------------------------end of change-------------------------------
>  Motivation: Seeing the speaker in video is an=20
> important combination reinserted above in=20
> section 5.2.
>  This section therefore needed rewording to not include that combination.

The draft explicitly mentions video for supplemental purposes.

>
>
>  10.     6.2 Last sentence
>  -----------------current text---------------------
>  Supported languages are: [list of supported languages]."
>  -----------------new text------------------------
>  Supported languages and media and transmission=20
> directions are:[list of supported languages and=20
> media and transmission directions.]"
>  -----------------end of change--------------------------
>  Motivation: Same as for 7.

=46ixed as above.

>
>  11.  6.1 MUX Category
>  ----------old text in two locations-------------------
>  MUX Category:  normal
>  ---------new text in same two locations--------------
>  Mux Category:  NORMAL
>  ---------end of change-----------------
>  Motivation: Follow RFC 4566bis and IANA habits regarding use of capitals

=46ixed.

>
>  12.  5.3
>  -------------old text-----------------
>  5.3 No Language in Common
>  -------------new text----------------
>  5.3 Preference parameter
>  ------------end of change 1 in 5.3---------------

The section is more than just the asterisk, it=20
also advises use of specific SIP response codes=20
if the call is failed.


>
>  -------------old text-in 5.3, second paragraph---------------------------=
----
>  The mechanism for indicating this preference is that, in an offer, if
>  the last character of any of the 'humintlang-recv' or 'humintlang-
>  send' values is an asterisk, this indicates a request to not fail the cal=
l.
>  --------------------------new text-------------------------------
>  The mechanism for indicating this preference is that, in an offer, if
>     the last character of any of the 'humintlang-recv' or 'humintlang-
>     send' values is an asterisk, this indicates=20
> a request to not fail the call.
>  The asterisk should be attached to attributes with languages of lower
>  preference to be matched if such difference can be specified. Thereby
>  the location of the asterisk can be used to support the decision on
>  which languages to use in the call.
>  ---------------------------end of change 2 in=20
> 5.3--------------------------------------
>  Motivation: There has not yet been any=20
> conclusion for my proposal no 5 in the IETF LC=20
> comments of Feb 12.
>  This is a dramatically reduced version that may=20
> be easier to accept at this stage, still=20
> covering one of the missing functionalities in=20
> the draft.
>  The asterisk is used as a preference parameter=20
> in the attributes. Thereby the proposed title=20
> change on 5.3
>  With this additional rule about where the=20
> asterisk(s) are placed, the answering parties=20
> get good clues about the preferences between=20
> alternatives presented by the offeror. The=20
> chance to set up calls with satisfied users=20
> increase dramatically compared to letting the=20
> answering party select by chance between=20
> alternatives.

Making the asterisk a purely-advisory hint as to=20
the least-preferred media/language combination=20
seems harmless enough, as it would not be=20
required to support it; however, I'm not sure it=20
provides any benefit: if an offer contains some=20
set of media with language, and the answerer can=20
support all of them, should the answerer only=20
include in its answer those without an asterisk?=20
It seems simpler for the answerer to include=20
everything in the offer that it can support.


-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
The great Chinese philosopher Confucius wrote, "When words lose their
meaning, the universe crumbles."  Theologically and cosmologically, I'm
not sure about that.  I am sure that when our government is
characterized as "amoral, godless and secularist," our public schools
as "failures" and our judges as "tyrants," simplistic solutions
promoted by demagogues will seem appropriate.
-- Barry Lynn,
   Executive Director of
   Americans United for Separation of Church and State


From nobody Fri Feb 24 17:09: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 3C92D12962F for ; Fri, 24 Feb 2017 17:09:28 -0800 (PST)
X-Quarantine-ID: 
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -1.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 dBqgdOchncTl for ; Fri, 24 Feb 2017 17:09:26 -0800 (PST)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id ECB2312962A for ; Fri, 24 Feb 2017 17:09:25 -0800 (PST)
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Fri, 24 Feb 2017 16:59:39 -0800
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <68b2f215-66f4-4207-7609-86015b8ce83a@omnitor.se>
References: <0D2E61DC-1A6D-4B9C-8072-589D702AB54A@gsma.com> <6ff2e293-5f36-bb44-3108-3c0937eb58da@omnitor.se>  <2697072ec7a54ddbb972520b8303ec6f@EX13D08UWB002.ant.amazon.com>  <68b2f215-66f4-4207-7609-86015b8ce83a@omnitor.se>
X-Mailer: Eudora for Mac OS X
Date: Fri, 24 Feb 2017 17:09:20 -0800
To: Gunnar =?iso-8859-1?Q?Hellstr=F6m?=  , Brian Rosen , "Phillips, Addison" 
From: Randall Gellens 
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
Archived-At: 
Cc: "slim@ietf.org" , Natasha Rooney 
Subject: Re: [Slim] Shortening humintlang
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 25 Feb 2017 01:09:28 -0000

We seem to have agreement to shorten the names=20
from "humintlang-" to "hang-". Several people are=20
in favor, no one is opposed.   I will make this=20
change in the draft.

At 11:39 AM +0100 2/24/17, Gunnar Hellstr=F6m wrote:

>  Den 2017-02-22 kl. 17:43, skrev Brian Rosen:
>
>>  Accept-Language is the language used in the=20
>> SIP/HTTP exchange, not the language used in=20
>> the media exchange. We're trying to=20
>> differentiate. This has actually caused a lot=20
>> of confusion, so it's not theoretical.
>>
>>  We could use "medlang", but I rather like "hlang" better.
>>
>  I agree that "hlang" would be a good=20
> improvement over "humintlang", and I want to=20
> see that change done. We cannot invent a term=20
> that is explicit and short. "Human" is implied=20
> by all usage of BCP 47, "Interactive" is our=20
> focus, but I do not think that we should forbid=20
> use outside that application area, we just do=20
> not do any special definitions for stored and=20
> streamed use. So why not let=20
> "human-interactive-language-" be represented by=20
> the short "hlang-".
>
>  To have a name for both directions and other=20
> names for each separate direction, "hlang",=20
> "hlang-send", "hlang-recv" would cause a bit=20
> more complicated parsing and complicated=20
> definition about how combinations of these for=20
> the same media should be handled. Maybe most=20
> such combinations would be unusual and=20
> unimportant, but the effect of finding them in=20
> SDP would need to be defined. Still, we would=20
> gain in simplicity in indication for the=20
> dominating symmetrical cases. I am quite sure=20
> we have discussed this option before and=20
> decided to not go that way, but I can accept a=20
> change-of-minds if so desired.
>
>
>  /Gunnar
>
>
>>
>>  We should acknowledge that this is a protocol=20
>> discussion. Humans don't see either element.=20
>> It could be "fubar" and work for the protocol=20
>> exchange.
>>
>>  Brian
>>
>>>  On Feb 22, 2017, at 11:34 AM, Phillips,=20
>>> Addison=20
>>> <addison@lab126.com>=20
>>> wrote:
>>>
>>>  Why is the "human" part an important=20
>>> distinguisher? Accept-Language refers to the=20
>>> same type of language: natural language=20
>>> content. While our machines are getting=20
>>> better about generating and responding to=20
>>> natural languages, the point of these=20
>>> interfaces is always human interaction. Why=20
>>> not just 'lang'? It's short and it's=20
>>> consistent with usage elsewhere.
>>>  Addison Phillips
>>>  Principal SDE, I18N Architect (Amazon)
>>>  Chair (W3C I18N WG)
>>>  Internationalization is not a feature.
>>>  It is an architecture.
>>>  From: SLIM=20
>>> [mailto:slim-bounces@ietf.org]=20
>>> On Behalf Of Brian Rosen
>>>  Sent: Wednesday, February 22, 2017 7:27 AM
>>>  To: Gunnar Hellstr=F6m=20
>>> <gunnar.hellstrom@omnitor.se>
>>>  Cc: slim@ietf.org;=20
>>> Natasha Rooney=20
>>> <nrooney@gsma.com>
>>>  Subject: Re: [Slim] Shortening humintlang
>>>  I don't have any problem shortening the name,=20
>>> but I do think retaining "human" is important=20
>>> because we have always had problems confusing=20
>>> the "Accept-Language" header.
>>>  How about 'hlang'? Or 'hilang' if you must.
>>>  Brian
>>>
>>>  On Feb 22, 2017, at 6:17 AM, Gunnar Hellstr=F6m=20
>>> <gunnar.hellstrom@omnitor.se>=20
>>> wrote:
>>>  Den 2017-02-22 kl. 11:59, skrev Natasha Rooney:
>>>
>>>  Hi all,
>>>  We had this request from the Gen-ART reviewer=20
>>> for=20
>>> raft-ietf-slim-negotiating-human-language-06:
>>>  C. "humintlang" seems long to me
>>>
>>>  Given the excessive length of SDP in practice, it seems to me that a
>>>  shorter attribute name would be desirable. E.g., "humlang" as was
>>>  used in some previous versions. Or is there a coordinated usage with
>>>  other names in the "hum*lang" pattern?
>>>  Wdyt?
>>>
>>>  I have also had thoughts in the same=20
>>> direction. Especially when we quite late=20
>>> decided to have only one language tag value=20
>>> per attribute, the consumption of characters=20
>>> for SDP increased dramatically.
>>>  It is a good habit to have attribute names=20
>>> that are real words, but we have problems=20
>>> inventing such names for this case.
>>>
>>>  The "hum" part is in fact redundant. So,=20
>>> maybe Intlang-send and Intlang-recv for=20
>>> Interactive-language would be an acceptable=20
>>> shortening of the names.
>>>
>>>  The proposal to return to the Accept-Language=20
>>> syntax, with the possibility to list all=20
>>> languages in one media and direction on one=20
>>> line would save us meven more, and should=20
>>> also be considered, I think.
>>>
>>>  Think about an outgoing call from a clever=20
>>> multi-language call-center with capability in=20
>>> 15 languages, both spoken and written.
>>>
>>>  /Gunnar
>>>
>>>
>>>  Natasha Rooney | Internet Engineering=20
>>> Director | Internet and Web Team | Technology=20
>>> | GSMA |=20
>>> nrooney@gsma.com |=20
>>> +44 (0) 7730 219 765 | @thisNatasha | Skype:=20
>>> nrooney@gsm.org
>>>  This email and its attachments are intended=20
>>> for the above named only and may be=20
>>> confidential. If they have come to you in=20
>>> error you must take no action based on them,=20
>>> nor must you copy or show them to anyone;=20
>>> please reply to this email or call +44 207=20
>>> 356 0600 and highlight the error.
>>>
>>>
>>>
>>>  _______________________________________________
>>>  SLIM mailing list
>>>  SLIM@ietf.org
>>>=20
>>> https://www.ietf.org/mailman=
/listinfo/slim
>>>
>>>
>>>
>>>  --
>>>  -----------------------------------------
>>>  Gunnar Hellstr=F6m
>>>  Omnitor
>>>  gunnar.hellstrom@omnitor.se
>>>  +46 708 204 288
>>>  _______________________________________________
>>>  SLIM mailing list
>>>  SLIM@ietf.org
>>>=20
>>> https://www.ietf.org/mailman=
/listinfo/slim
>>>
>>
>>
>>
>>  _______________________________________________
>>  SLIM mailing list
>>  SLIM@ietf.org
>>=20
>> https://www.ietf.org/mailman/=
listinfo/slim
>>
>
>  --
>  -----------------------------------------
>  Gunnar Hellstr=F6m
>  Omnitor
>  gunnar.hellstrom@omnitor.se
>  +46 708 204 288
>
>  _______________________________________________
>  SLIM mailing list
>  SLIM@ietf.org
>  https://www.ietf.org/mailman/listinfo/slim


-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
[Some] billionaires [are] coming together under the leadership of Warren
Buffet and Bill Gates to donate their fortunes to worthy causes.... But
the billionaires with the strongest sense of class solidarity have an-
other plan for their disposable income: activating their lobbyists in
Washington, building grassroots movements to march on their behalf,
and using their media properties to run experiments on human credulity.
--From the essay "Service Disobedience" by Thomas Frank in the February
2011 Harper's Magazine column "Easy Chair."


From nobody Sat Feb 25 02:05:06 2017
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F40A2129CAF for ; Sat, 25 Feb 2017 02:05:04 -0800 (PST)
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 prlD0HAShff0 for ; Sat, 25 Feb 2017 02:05:02 -0800 (PST)
Received: from bin-vsp-out-03.atm.binero.net (vsp-unauthed02.binero.net [195.74.38.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B5CA129C7C for ; Sat, 25 Feb 2017 02:05:01 -0800 (PST)
X-Halon-ID: dc694e54-fb41-11e6-9c99-0050569116f7
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [77.53.231.21]) by bin-vsp-out-03.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Sat, 25 Feb 2017 11:04:56 +0100 (CET)
To: Randall Gellens , slim@ietf.org, Natasha Rooney , Bernard Aboba 
References: <148782279664.31054.8793649134696520241.idtracker@ietfa.amsl.com>  <49fd730e-6e90-1a49-eae8-80f8b1285a76@omnitor.se> 
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: <83152ba7-c3fb-25d8-f97d-59c7840cad56@omnitor.se>
Date: Sat, 25 Feb 2017 11:04:53 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
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] I-D Action: draft-ietf-slim-negotiating-human-language-07.txt
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 25 Feb 2017 10:05:05 -0000

Randall,

Fine, I find that we have only issues 5, 6 and 12 still to discuss.

You did not answer issue 6, use of asymmetrical language rather than 
unidirectional media. I assume you accepted it.

On 5, the request to reinsert wording about seeing the speaker in video, 
it is still a huge difference in specifying a preference to see the 
speaker for language perception reasons, versus only specifying that I 
want a video stream for supplementary purposes. With the current wording 
in version -07, section 5.3 says that that combination is undefined. 
Nothing in the LC discussion indicated that it should be undefined. Why 
did you suddenly want to delete it? It is useful. Please reinsert with 
the wording changes I propose.

On 12, the meaning of the placement of the asterisk, you ask:
"Making the asterisk a purely-advisory hint as to the least-preferred 
media/language combination seems harmless enough, as it would not be 
required to support it; however, I'm not sure it provides any benefit: 
if an offer contains some set of media with language, and the answerer 
can support all of them, should the answerer only include in its answer 
those without an asterisk? It seems simpler for the answerer to include 
everything in the offer that it can support."

The answering party should aim at answering with one of the languages 
that is without the asterisk in the offer. Only if the answering party 
does not have capability in a language without an asterisk, one with 
asterisk should be selected. Thereby you get the best opportunity to 
start the call in a language combination that satisfies both users.

Example: A hard-of-hearing user can just barely conduct spoken calls 
with persons she knows. From others it is much more reliable to get 
text.  She calls and declares:

m=audio
a=huml-send:en
a=huml-recv:en*
m=text
a=huml-recv:en

The answering party with text capabilities sees that matching text for 
sending is higher preferred than talking, and thus  responds:

m=audio
a=huml-recv:en
m=text
a=huml-send:en

The answering party sends the initial greeting in text and the call 
continues smoothly in well managed langauage/modality combinations.

Another called party may not have text capabilities, and may therefore 
select the less favoured alternative with using speech both ways, answering:

m=audio
a=huml-recv:en
a=huml-send:en
m=text 0

The answering party starts taking and the parties try as well as 
possible to manage the call in this less preferred combination that may 
be less reliable.

If the placement of the asterisk had no special meaning as it is in 
version -07, it is a high risk that the answering party in the first 
example would select to answer with spoken language that would be 
unreliably received. Time and effort would be spent by speech to make 
the answering party switch to sending text instead of talking in order 
to arrange for a more reliable call situation.

If instead the caller only indicated the most favoured combinations,

m=audio
a=huml-send:en
m=text
a=huml-recv:en

Then the answering parties without text capability would not dare to try 
to answer, and a reasonably successful call would be missed.

Many other similar realistic examples can be created, where placement of 
the asterisk(s) would be a sufficient indication of lower preference for 
language match among alternatives that would make call establishment 
successful and smooth in many more cases than without this indication 
opportunity.

Do you want more examples?

Please accept proposal 12.

Regards

Gunnar







Den 2017-02-25 kl. 01:32, skrev Randall Gellens:
> At 5:35 PM +0100 2/24/17, Gunnar Hellström wrote:
>
>>  Den 2017-02-23 kl. 05:15, skrev Randall Gellens:
>>>  Version -07 addresses all comments except for the unresolved issue 
>>> of renaming the two attributes which is currently being discussed on 
>>> the list, and adding a new attribute for bidirectionality.
>>>
>>>  Per Dale's suggestion, the draft adds advice that if a call is 
>>> rejected due to no languages in common, SIP response code 488 (Not 
>>> Acceptable Here) or 606 (Not Acceptable) be used, along with a 
>>> Warning header field indicating the supported languages.  The draft 
>>> registers a new entry in the warn-code sub-registry of SIP 
>>> parameters for this purpose.  The draft also has an expanded set of 
>>> examples.
>>>
>>  Good progress. Good to see the enriched examples chapter 5.5.
>>  I have a few comments on version -07:
>>
>>  1.  Section  4. second line
>>  ------------old text----------------------
>>  but is not sufficiently sufficiently
>>  ------------new text--------------------------
>>  but is not sufficiently
>>  ----------end of change 1-----------------
>>  Motivation: New typo in version -07
>
> Thanks.
>
>>
>>  2. Section 5.2, first line
>>  ----------------old text-----------------
>>  This document defines two new media-level ..
>>  ----------------new text----------------------
>>  This document defines two media-level ...
>>  ----------------end of change 2----------------
>>  Motivation: It was commented that when the draft is published, this 
>> is not new anymore.
>>  There are three more occasions of "new" in the document that may be 
>> modified as well.
>
> OK.
>
>>
>>  3.  5.2 second paragraph
>>  -------------------old text--------------------------------
>>  In an offer, the 'humintlang-send' values indicates the language(s)
>>     the offerer is willing to use when sending using the media, and the
>>     'humintlang-recv' values indicates the language(s) the offerer is
>>     willing to use when receiving using the media.
>>  -----------------new text---------------------------------
>>  In an offer, the 'humintlang-send' values indicate the language(s)
>>  the offerer is willing to select from for use when sending using the
>>  media, and the 'humintlang-recv' values indicate the language(s) the
>>  offerer is willing to receive one of in the media stream.
>>  ----------------end of change----------------------------------
>>  Motivation 1:) change from "indicates" to "indicate" in two places 
>> to match the new use of plural "values".
>>  Motivation 2:) Be sure to indicate that we only intend to negotiate 
>> one language per media and direction, so that we do not end up as 
>> unspecified regarding number of matches required as the sdp "lang" 
>> attribute is.
>
> Reworded.
>
>>
>>  4.  5.2 Second paragraph
>>  -----------------old text-----------------------
>>  When a media is intended
>>     for use in one direction only
>>  ----------------new text---------------------
>>  When a media is intended
>>     for use for language communication in one direction only
>>  ----------------end of change---------------------------
>>  Motivation: Deletion of a note in this sentence made it less obvious 
>> that we are only talking about directions of use of language 
>> communication, and not about establishing asymmetric media 
>> connections. Therefore add this clarification.
>
> Reworded.
>
>>
>>  5.  5.2 Deleted paragraph 6 before "Clients acting on behalf..."
>>  ----------reinsert modified paragraph----------------------------
>>  While signed language tags are used with a video stream to
>>  indicate sign language, a spoken language tag for a video stream
>>  indicates a request or offer to see the speaker, when that is of
>>  importance for language perception.
>>  -------------end of change-------------------------------------------
>>  Motivation: There was in the LC mail exchange a discussion about 
>> sharpening up the specification of use of "unusual combinations".
>>  There was no agreement to delete them all. The one described in this 
>> paragraph is the main one that has widespread use and needs to be 
>> clearly specified for use by a large number of hard-of-hearing and 
>> deaf users.
>
> The text as it is now does not prohibit anything and explicitly 
> mentions negotiating supplemental video by omitting language 
> attributes on a video media.
>
>>
>>  6.  5.2 Sixth paragraph
>>  --------------------current text--------------------
>>  (or for unidirectional streams, one of)
>>  ------------------new text ------------------------
>>  (or for asymmetrical use of languages, one of)
>>  -----------------end of change----------------------
>>  Motivation: We are not primarily talking about enabled transmission 
>> directions of the streams, but about language use in the streams. We 
>> do not want to limit the media stream directions just because we do 
>> not specify an initial language to use for that direction. There are 
>> other usage of media, and there may even be occasional use of 
>> language in the direction, just not worth mentioning as an initial 
>> and preferred use. The suggested change should make that clear.
>>
>>  7.   5.3 Next to last paragraph
>>  ------------------old text------------------------------
>>  a list of supported languages.
>>  -------------------new text-------------------------
>>  a list of supported languages, media and directions.
>>  -------------------end of change----------------
>>  Motivation: It is not sufficient to know which languages are 
>> supported, it is also essential to know in which media they are 
>> supported and in which directions. (media could be replaced with 
>> modality, but the media can become ambigous then, so use media here 
>> to be brief.
>
> I don't know that we can require this, but I'll add SHOULD kist 
> supported languages and media. Demanding direction as well might be 
> too unwieldy.
>
>>
>>  8.      5.3, last line
>>  --------------old text----------------------------------
>>   Supported languages are: es, en"
>>  --------------new text-------------------------------
>>   Supported languages are: es, en transmission in audio; es, en 
>> reception in audio"
>>  ----------------------------------------------------------
>>  Motivation: Same as for 7.
>
> Fixed as above.
>
>>
>>  9.  5.4 Undefined combinations
>>  ----------------------------old 
>> text--------------------------------------
>>     The behavior when specifying a non-signed language tag for a video
>>     media stream, or a signed language tag for an audio or text media
>>     stream, is not defined.
>>  ---------------------------new 
>> text-----------------------------------------
>>  There is no way specified for indicating use of text based language 
>> in a video media stream.
>>  There is no meaning assigned to specification of  sign language in 
>> an audio or text media stream.
>>  --------------------------end of change-------------------------------
>>  Motivation: Seeing the speaker in video is an important combination 
>> reinserted above in section 5.2.
>>  This section therefore needed rewording to not include that 
>> combination.
>
> The draft explicitly mentions video for supplemental purposes.
>
>>
>>
>>  10.     6.2 Last sentence
>>  -----------------current text---------------------
>>  Supported languages are: [list of supported languages]."
>>  -----------------new text------------------------
>>  Supported languages and media and transmission directions are:[list 
>> of supported languages and media and transmission directions.]"
>>  -----------------end of change--------------------------
>>  Motivation: Same as for 7.
>
> Fixed as above.
>
>>
>>  11.  6.1 MUX Category
>>  ----------old text in two locations-------------------
>>  MUX Category:  normal
>>  ---------new text in same two locations--------------
>>  Mux Category:  NORMAL
>>  ---------end of change-----------------
>>  Motivation: Follow RFC 4566bis and IANA habits regarding use of 
>> capitals
>
> Fixed.
>
>>
>>  12.  5.3
>>  -------------old text-----------------
>>  5.3 No Language in Common
>>  -------------new text----------------
>>  5.3 Preference parameter
>>  ------------end of change 1 in 5.3---------------
>
> The section is more than just the asterisk, it also advises use of 
> specific SIP response codes if the call is failed.
>
>
>>
>>  -------------old text-in 5.3, second 
>> paragraph-------------------------------
>>  The mechanism for indicating this preference is that, in an offer, if
>>  the last character of any of the 'humintlang-recv' or 'humintlang-
>>  send' values is an asterisk, this indicates a request to not fail 
>> the call.
>>  --------------------------new text-------------------------------
>>  The mechanism for indicating this preference is that, in an offer, if
>>     the last character of any of the 'humintlang-recv' or 'humintlang-
>>     send' values is an asterisk, this indicates a request to not fail 
>> the call.
>>  The asterisk should be attached to attributes with languages of lower
>>  preference to be matched if such difference can be specified. Thereby
>>  the location of the asterisk can be used to support the decision on
>>  which languages to use in the call.
>>  ---------------------------end of change 2 in 
>> 5.3--------------------------------------
>>  Motivation: There has not yet been any conclusion for my proposal no 
>> 5 in the IETF LC comments of Feb 12.
>>  This is a dramatically reduced version that may be easier to accept 
>> at this stage, still covering one of the missing functionalities in 
>> the draft.
>>  The asterisk is used as a preference parameter in the attributes. 
>> Thereby the proposed title change on 5.3
>>  With this additional rule about where the asterisk(s) are placed, 
>> the answering parties get good clues about the preferences between 
>> alternatives presented by the offeror. The chance to set up calls 
>> with satisfied users increase dramatically compared to letting the 
>> answering party select by chance between alternatives.
>
> Making the asterisk a purely-advisory hint as to the least-preferred 
> media/language combination seems harmless enough, as it would not be 
> required to support it; however, I'm not sure it provides any benefit: 
> if an offer contains some set of media with language, and the answerer 
> can support all of them, should the answerer only include in its 
> answer those without an asterisk? It seems simpler for the answerer to 
> include everything in the offer that it can support.
>
>

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


From nobody Sat Feb 25 11:58: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 ABC3B1294AB for ; Sat, 25 Feb 2017 11:58:23 -0800 (PST)
X-Quarantine-ID: 
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -1.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 WXeQ_wtN99YP for ; Sat, 25 Feb 2017 11:58:21 -0800 (PST)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 4A9CB126B6D for ; Sat, 25 Feb 2017 11:58:21 -0800 (PST)
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Sat, 25 Feb 2017 11:48:27 -0800
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <83152ba7-c3fb-25d8-f97d-59c7840cad56@omnitor.se>
References: <148782279664.31054.8793649134696520241.idtracker@ietfa.amsl.com>  <49fd730e-6e90-1a49-eae8-80f8b1285a76@omnitor.se>  <83152ba7-c3fb-25d8-f97d-59c7840cad56@omnitor.se>
X-Mailer: Eudora for Mac OS X
Date: Sat, 25 Feb 2017 11:58:17 -0800
To: Gunnar =?iso-8859-1?Q?Hellstr=F6m?=  , slim@ietf.org, Natasha Rooney , Bernard Aboba 
From: Randall Gellens 
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
Archived-At: 
Subject: Re: [Slim] I-D Action: draft-ietf-slim-negotiating-human-language-07.txt
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 25 Feb 2017 19:58:24 -0000

Hi Gunnar,

At 11:04 AM +0100 2/25/17, Gunnar Hellstr=F6m wrote:

>  Fine, I find that we have only issues 5, 6 and 12 still to discuss.
>
>  You did not answer issue 6, use of asymmetrical=20
> language rather than unidirectional media. I=20
> assume you accepted it.

Yes, I thought I had indicated that, sorry if I didn't.

>
>  On 5, the request to reinsert wording about=20
> seeing the speaker in video, it is still a huge=20
> difference in specifying a preference to see=20
> the speaker for language perception reasons,=20
> versus only specifying that I want a video=20
> stream for supplementary purposes. With the=20
> current wording in version -07, section 5.3=20
> says that that combination is undefined.=20
> Nothing in the LC discussion indicated that it=20
> should be undefined. Why did you suddenly want=20
> to delete it? It is useful. Please reinsert=20
> with the wording changes I propose.

The email discussion led me to believe that the=20
text was controversial.  We need to get the draft=20
finished, so it's better to delete controversial=20
text than to spend months fighting about it.

>
>  On 12, the meaning of the placement of the asterisk, you ask:
>  "Making the asterisk a purely-advisory hint as=20
> to the least-preferred media/language=20
> combination seems harmless enough, as it would=20
> not be required to support it; however, I'm not=20
> sure it provides any benefit: if an offer=20
> contains some set of media with language, and=20
> the answerer can support all of them, should=20
> the answerer only include in its answer those=20
> without an asterisk? It seems simpler for the=20
> answerer to include everything in the offer=20
> that it can support."
>
>  The answering party should aim at answering=20
> with one of the languages that is without the=20
> asterisk in the offer. Only if the answering=20
> party does not have capability in a language=20
> without an asterisk, one with asterisk should=20
> be selected. Thereby you get the best=20
> opportunity to start the call in a language=20
> combination that satisfies both users.
>
>  Example: A hard-of-hearing user can just barely=20
> conduct spoken calls with persons she knows.=20
> From others it is much more reliable to get=20
> text.  She calls and declares:
>
>  m=3Daudio
>  a=3Dhuml-send:en
>  a=3Dhuml-recv:en*
>  m=3Dtext
>  a=3Dhuml-recv:en
>
>  The answering party with text capabilities sees=20
> that matching text for sending is higher=20
> preferred than talking, and thus  responds:
>
>  m=3Daudio
>  a=3Dhuml-recv:en
>  m=3Dtext
>  a=3Dhuml-send:en
>
>  The answering party sends the initial greeting=20
> in text and the call continues smoothly in well=20
> managed langauage/modality combinations.
>
>  Another called party may not have text=20
> capabilities, and may therefore select the less=20
> favoured alternative with using speech both=20
> ways, answering:
>
>  m=3Daudio
>  a=3Dhuml-recv:en
>  a=3Dhuml-send:en
>  m=3Dtext 0
>
>  The answering party starts taking and the=20
> parties try as well as possible to manage the=20
> call in this less preferred combination that=20
> may be less reliable.
>
>  If the placement of the asterisk had no special=20
> meaning as it is in version -07, it is a high=20
> risk that the answering party in the first=20
> example would select to answer with spoken=20
> language that would be unreliably received.=20
> Time and effort would be spent by speech to=20
> make the answering party switch to sending text=20
> instead of talking in order to arrange for a=20
> more reliable call situation.
>
>  If instead the caller only indicated the most favoured combinations,
>
>  m=3Daudio
>  a=3Dhuml-send:en
>  m=3Dtext
>  a=3Dhuml-recv:en
>
>  Then the answering parties without text=20
> capability would not dare to try to answer, and=20
> a reasonably successful call would be missed.
>
>  Many other similar realistic examples can be=20
> created, where placement of the asterisk(s)=20
> would be a sufficient indication of lower=20
> preference for language match among=20
> alternatives that would make call establishment=20
> successful and smooth in many more cases than=20
> without this indication opportunity.
>
>  Do you want more examples?
>
>  Please accept proposal 12.

This convinces me that we cannot accept the=20
proposed text, as it would introduce complexity=20
that the WG explicitly decided to not pursue in=20
this draft.  In the examples you provided, it=20
seems better for the answerer to include all=20
media and languages from the offer that it can=20
support.  This is much simpler, has only trivial=20
drawbacks (extra media negotiated that might not=20
be used), and is what the WG agreed to.

--Randy

>  Den 2017-02-25 kl. 01:32, skrev Randall Gellens:
>>  At 5:35 PM +0100 2/24/17, Gunnar Hellstr=F6m wrote:
>>
>>>   Den 2017-02-23 kl. 05:15, skrev Randall Gellens:
>>>>   Version -07 addresses all comments except=20
>>>> for the unresolved issue of renaming the two=20
>>>> attributes which is currently being=20
>>>> discussed on the list, and adding a new=20
>>>> attribute for bidirectionality.
>>>>
>>>>   Per Dale's suggestion, the draft adds=20
>>>> advice that if a call is rejected due to no=20
>>>> languages in common, SIP response code 488=20
>>>> (Not Acceptable Here) or 606 (Not=20
>>>> Acceptable) be used, along with a Warning=20
>>>> header field indicating the supported=20
>>>> languages.  The draft registers a new entry=20
>>>> in the warn-code sub-registry of SIP=20
>>>> parameters for this purpose.  The draft also=20
>>>> has an expanded set of examples.
>>>>
>>>   Good progress. Good to see the enriched examples chapter 5.5.
>>>   I have a few comments on version -07:
>>>
>>>   1.  Section  4. second line
>>>   ------------old text----------------------
>>>   but is not sufficiently sufficiently
>>>   ------------new text--------------------------
>>>   but is not sufficiently
>>>   ----------end of change 1-----------------
>>>   Motivation: New typo in version -07
>>
>>  Thanks.
>>
>>>
>>>   2. Section 5.2, first line
>>>   ----------------old text-----------------
>>>   This document defines two new media-level ..
>>>   ----------------new text----------------------
>>>   This document defines two media-level ...
>>>   ----------------end of change 2----------------
>>>   Motivation: It was commented that when the=20
>>> draft is published, this is not new anymore.
>>>   There are three more occasions of "new" in=20
>>> the document that may be modified as well.
>>
>>  OK.
>>
>>>
>>>   3.  5.2 second paragraph
>>>   -------------------old text--------------------------------
>>>   In an offer, the 'humintlang-send' values indicates the language(s)
>>>      the offerer is willing to use when sending using the media, and the
>>>      'humintlang-recv' values indicates the language(s) the offerer is
>>>      willing to use when receiving using the media.
>>>   -----------------new text---------------------------------
>>>   In an offer, the 'humintlang-send' values indicate the language(s)
>>>   the offerer is willing to select from for use when sending using the
>>>   media, and the 'humintlang-recv' values indicate the language(s) the
>>>   offerer is willing to receive one of in the media stream.
>>>   ----------------end of change----------------------------------
>>>   Motivation 1:) change from "indicates" to=20
>>> "indicate" in two places to match the new use=20
>>> of plural "values".
>>>   Motivation 2:) Be sure to indicate that we=20
>>> only intend to negotiate one language per=20
>>> media and direction, so that we do not end up=20
>>> as unspecified regarding number of matches=20
>>> required as the sdp "lang" attribute is.
>>
>>  Reworded.
>>
>>>
>>>   4.  5.2 Second paragraph
>>>   -----------------old text-----------------------
>>>   When a media is intended
>>>      for use in one direction only
>>>   ----------------new text---------------------
>>>   When a media is intended
>>>      for use for language communication in one direction only
>>>   ----------------end of change---------------------------
>>>   Motivation: Deletion of a note in this=20
>>> sentence made it less obvious that we are=20
>>> only talking about directions of use of=20
>>> language communication, and not about=20
>>> establishing asymmetric media connections.=20
>>> Therefore add this clarification.
>>
>>  Reworded.
>>
>>>
>>>   5.  5.2 Deleted paragraph 6 before "Clients acting on behalf..."
>>>   ----------reinsert modified paragraph----------------------------
>>>   While signed language tags are used with a video stream to
>>>   indicate sign language, a spoken language tag for a video stream
>>>   indicates a request or offer to see the speaker, when that is of
>>>   importance for language perception.
>>>   -------------end of change-------------------------------------------
>>>   Motivation: There was in the LC mail=20
>>> exchange a discussion about sharpening up the=20
>>> specification of use of "unusual=20
>>> combinations".
>>>   There was no agreement to delete them all.=20
>>> The one described in this paragraph is the=20
>>> main one that has widespread use and needs to=20
>>> be clearly specified for use by a large=20
>>> number of hard-of-hearing and deaf users.
>>
>>  The text as it is now does not prohibit=20
>> anything and explicitly mentions negotiating=20
>> supplemental video by omitting language=20
>> attributes on a video media.
>>
>>>
>>>   6.  5.2 Sixth paragraph
>>>   --------------------current text--------------------
>>>   (or for unidirectional streams, one of)
>>>   ------------------new text ------------------------
>>>   (or for asymmetrical use of languages, one of)
>>>   -----------------end of change----------------------
>>>   Motivation: We are not primarily talking=20
>>> about enabled transmission directions of the=20
>>> streams, but about language use in the=20
>>> streams. We do not want to limit the media=20
>>> stream directions just because we do not=20
>>> specify an initial language to use for that=20
>>> direction. There are other usage of media,=20
>>> and there may even be occasional use of=20
>>> language in the direction, just not worth=20
>>> mentioning as an initial and preferred use.=20
>>> The suggested change should make that clear.
>>>
>>>   7.   5.3 Next to last paragraph
>>>   ------------------old text------------------------------
>>>   a list of supported languages.
>>>   -------------------new text-------------------------
>>>   a list of supported languages, media and directions.
>>>   -------------------end of change----------------
>>>   Motivation: It is not sufficient to know=20
>>> which languages are supported, it is also=20
>>> essential to know in which media they are=20
>>> supported and in which directions. (media=20
>>> could be replaced with modality, but the=20
>>> media can become ambigous then, so use media=20
>>> here to be brief.
>>
>>  I don't know that we can require this, but=20
>> I'll add SHOULD kist supported languages and=20
>> media. Demanding direction as well might be=20
>> too unwieldy.
>>
>>>
>>>   8.      5.3, last line
>>>   --------------old text----------------------------------
>>>    Supported languages are: es, en"
>>>   --------------new text-------------------------------
>>>    Supported languages are: es, en=20
>>> transmission in audio; es, en reception in=20
>>> audio"
>>>   ----------------------------------------------------------
>>>   Motivation: Same as for 7.
>>
>>  Fixed as above.
>>
>>>
>>>   9.  5.4 Undefined combinations
>>>   ----------------------------old text----------------------------------=
----
>>>      The behavior when specifying a non-signed language tag for a video
>>>      media stream, or a signed language tag for an audio or text media
>>>      stream, is not defined.
>>>   ---------------------------new=20
>>> text-----------------------------------------
>>>   There is no way specified for indicating use=20
>>> of text based language in a video media=20
>>> stream.
>>>   There is no meaning assigned to=20
>>> specification of  sign language in an audio=20
>>> or text media stream.
>>>   --------------------------end of change-------------------------------
>>>   Motivation: Seeing the speaker in video is=20
>>> an important combination reinserted above in=20
>>> section 5.2.
>>>   This section therefore needed rewording to not include that combinatio=
n.
>>
>>  The draft explicitly mentions video for supplemental purposes.
>>
>>>
>>>
>>>   10.     6.2 Last sentence
>>>   -----------------current text---------------------
>>>   Supported languages are: [list of supported languages]."
>>>   -----------------new text------------------------
>>>   Supported languages and media and=20
>>> transmission directions are:[list of=20
>>> supported languages and media and=20
>>> transmission directions.]"
>>>   -----------------end of change--------------------------
>>>   Motivation: Same as for 7.
>>
>>  Fixed as above.
>>
>>>
>>>   11.  6.1 MUX Category
>>>   ----------old text in two locations-------------------
>>>   MUX Category:  normal
>>>   ---------new text in same two locations--------------
>>>   Mux Category:  NORMAL
>>>   ---------end of change-----------------
>>>   Motivation: Follow RFC 4566bis and IANA habits regarding use of capita=
ls
>>
>>  Fixed.
>>
>>>
>>>   12.  5.3
>>>   -------------old text-----------------
>>>   5.3 No Language in Common
>>>   -------------new text----------------
>>>   5.3 Preference parameter
>>>   ------------end of change 1 in 5.3---------------
>>
>>  The section is more than just the asterisk, it=20
>> also advises use of specific SIP response=20
>> codes if the call is failed.
>>
>>>
>>>   -------------old text-in 5.3, second=20
>>> paragraph-------------------------------
>>>   The mechanism for indicating this preference is that, in an offer, if
>>>   the last character of any of the 'humintlang-recv' or 'humintlang-
>>>   send' values is an asterisk, this indicates=20
>>> a request to not fail the call.
>>>   --------------------------new text-------------------------------
>>>   The mechanism for indicating this preference is that, in an offer, if
>>>      the last character of any of the 'humintlang-recv' or 'humintlang-
>>>      send' values is an asterisk, this=20
>>> indicates a request to not fail the call.
>>>   The asterisk should be attached to attributes with languages of lower
>>>   preference to be matched if such difference can be specified. Thereby
>>>   the location of the asterisk can be used to support the decision on
>>>   which languages to use in the call.
>>>   ---------------------------end of change 2=20
>>> in 5.3--------------------------------------
>>>   Motivation: There has not yet been any=20
>>> conclusion for my proposal no 5 in the IETF=20
>>> LC comments of Feb 12.
>>>   This is a dramatically reduced version that=20
>>> may be easier to accept at this stage, still=20
>>> covering one of the missing functionalities=20
>>> in the draft.
>>>   The asterisk is used as a preference=20
>>> parameter in the attributes. Thereby the=20
>>> proposed title change on 5.3
>>>   With this additional rule about where the=20
>>> asterisk(s) are placed, the answering parties=20
>>> get good clues about the preferences between=20
>>> alternatives presented by the offeror. The=20
>>> chance to set up calls with satisfied users=20
>>> increase dramatically compared to letting the=20
>>> answering party select by chance between=20
>>> alternatives.
>>
>>  Making the asterisk a purely-advisory hint as=20
>> to the least-preferred media/language=20
>> combination seems harmless enough, as it would=20
>> not be required to support it; however, I'm=20
>> not sure it provides any benefit: if an offer=20
>> contains some set of media with language, and=20
>> the answerer can support all of them, should=20
>> the answerer only include in its answer those=20
>> without an asterisk? It seems simpler for the=20
>> answerer to include everything in the offer=20
>> that it can support.
>>
>
>  --
>  -----------------------------------------
>  Gunnar Hellstr=F6m
>  Omnitor
>  gunnar.hellstrom@omnitor.se
>  +46 708 204 288


-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
(If you can't hear me, it's because I'm in parentheses)


From nobody Sat Feb 25 22:46: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 46E5012989D for ; Sat, 25 Feb 2017 22:46:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 sf6OqXWX5POD for ; Sat, 25 Feb 2017 22:46:11 -0800 (PST)
Received: from bin-vsp-out-01.atm.binero.net (bin-mail-out-06.binero.net [195.74.38.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83681129630 for ; Sat, 25 Feb 2017 22:46:10 -0800 (PST)
X-Halon-ID: 3eb5b963-fbef-11e6-ad4a-005056917a89
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [77.53.231.21]) by bin-vsp-out-01.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Sun, 26 Feb 2017 07:46:02 +0100 (CET)
To: Randall Gellens , slim@ietf.org, Natasha Rooney , Bernard Aboba 
References: <148782279664.31054.8793649134696520241.idtracker@ietfa.amsl.com>  <49fd730e-6e90-1a49-eae8-80f8b1285a76@omnitor.se>  <83152ba7-c3fb-25d8-f97d-59c7840cad56@omnitor.se> 
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: <4b36f347-955e-e2b9-12f2-f426d47d3d33@omnitor.se>
Date: Sun, 26 Feb 2017 07:46:01 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
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] I-D Action: draft-ietf-slim-negotiating-human-language-07.txt
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 26 Feb 2017 06:46:13 -0000

Den 2017-02-25 kl. 20:58, skrev Randall Gellens:
> Hi Gunnar,
>
> At 11:04 AM +0100 2/25/17, Gunnar Hellström wrote:
>
>>  Fine, I find that we have only issues 5, 6 and 12 still to discuss.
>>
>>  You did not answer issue 6, use of asymmetrical language rather than 
>> unidirectional media. I assume you accepted it.
>
> Yes, I thought I had indicated that, sorry if I didn't.
Good.
>
>>
>>  On 5, the request to reinsert wording about seeing the speaker in 
>> video, it is still a huge difference in specifying a preference to 
>> see the speaker for language perception reasons, versus only 
>> specifying that I want a video stream for supplementary purposes. 
>> With the current wording in version -07, section 5.3 says that that 
>> combination is undefined. Nothing in the LC discussion indicated that 
>> it should be undefined. Why did you suddenly want to delete it? It is 
>> useful. Please reinsert with the wording changes I propose.
>
> The email discussion led me to believe that the text was 
> controversial.  We need to get the draft finished, so it's better to 
> delete controversial text than to spend months fighting about it.
The comments were first about the uncertainty about how the "silly 
states" were to be interpreted.
We described them all but decided to only keep the view of the speaker 
because it is a real and useful case.
The idea to differentiate spoken and written cases by script tags caused 
discussions and was dropped. The remaining real case with the view of 
the speaker was mentioned twice in the draft, so it was recommended that 
one of them should be deleted, but not both.
>
>>
>>  On 12, the meaning of the placement of the asterisk, you ask:
>>  "Making the asterisk a purely-advisory hint as to the 
>> least-preferred media/language combination seems harmless enough, as 
>> it would not be required to support it; however, I'm not sure it 
>> provides any benefit: if an offer contains some set of media with 
>> language, and the answerer can support all of them, should the 
>> answerer only include in its answer those without an asterisk? It 
>> seems simpler for the answerer to include everything in the offer 
>> that it can support."
>>
>>  The answering party should aim at answering with one of the 
>> languages that is without the asterisk in the offer. Only if the 
>> answering party does not have capability in a language without an 
>> asterisk, one with asterisk should be selected. Thereby you get the 
>> best opportunity to start the call in a language combination that 
>> satisfies both users.
>>
>>  Example: A hard-of-hearing user can just barely conduct spoken calls 
>> with persons she knows. From others it is much more reliable to get 
>> text.  She calls and declares:
>>
>>  m=audio
>>  a=huml-send:en
>>  a=huml-recv:en*
>>  m=text
>>  a=huml-recv:en
>>
>>  The answering party with text capabilities sees that matching text 
>> for sending is higher preferred than talking, and thus responds:
>>
>>  m=audio
>>  a=huml-recv:en
>>  m=text
>>  a=huml-send:en
>>
>>  The answering party sends the initial greeting in text and the call 
>> continues smoothly in well managed langauage/modality combinations.
>>
>>  Another called party may not have text capabilities, and may 
>> therefore select the less favoured alternative with using speech both 
>> ways, answering:
>>
>>  m=audio
>>  a=huml-recv:en
>>  a=huml-send:en
>>  m=text 0
>>
>>  The answering party starts taking and the parties try as well as 
>> possible to manage the call in this less preferred combination that 
>> may be less reliable.
>>
>>  If the placement of the asterisk had no special meaning as it is in 
>> version -07, it is a high risk that the answering party in the first 
>> example would select to answer with spoken language that would be 
>> unreliably received. Time and effort would be spent by speech to make 
>> the answering party switch to sending text instead of talking in 
>> order to arrange for a more reliable call situation.
>>
>>  If instead the caller only indicated the most favoured combinations,
>>
>>  m=audio
>>  a=huml-send:en
>>  m=text
>>  a=huml-recv:en
>>
>>  Then the answering parties without text capability would not dare to 
>> try to answer, and a reasonably successful call would be missed.
>>
>>  Many other similar realistic examples can be created, where 
>> placement of the asterisk(s) would be a sufficient indication of 
>> lower preference for language match among alternatives that would 
>> make call establishment successful and smooth in many more cases than 
>> without this indication opportunity.
>>
>>  Do you want more examples?
>>
>>  Please accept proposal 12.
>
> This convinces me that we cannot accept the proposed text, as it would 
> introduce complexity that the WG explicitly decided to not pursue in 
> this draft.  In the examples you provided, it seems better for the 
> answerer to include all media and languages from the offer that it can 
> support.  This is much simpler, has only trivial drawbacks (extra 
> media negotiated that might not be used), and is what the WG agreed to.
Yes, you could let the answer SDP contain one common language per media 
and direction, but the answering human need guidance on which language 
is best suited to start the conversation. Therefore the placement of the 
asterisk is used to hint the answering party how to start the call.

The first example above can be modified to:

  Example: A hard-of-hearing user can just barely conduct spoken calls 
with persons she knows. From others it is much more reliable to get 
text.  She calls and declares:

  m=audio
  a=huml-send:en
  a=huml-recv:en*
  m=text
  a=huml-recv:en

  The answering party with capabilities for both written and spoken 
English sees that matching text for sending is higher preferred than 
talking and sends the answer indicating the capabilities:

  m=audio
  a=huml-recv:en
a=huml-send:en
  m=text
  a=huml-send:en

  The answering party makes use of the hint that the caller prefers to 
receive written text and therefore sends the initial greeting in text 
and the call continues smoothly in well managed langauage/modality 
combinations.

----------
There is no complexity left in this solution, it helps to motivate why 
we have the asterisk on media level, and it helps to successful call 
initiations, so I think it should be acceptable.

Gunnar

>
> --Randy
>
>>  Den 2017-02-25 kl. 01:32, skrev Randall Gellens:
>>>  At 5:35 PM +0100 2/24/17, Gunnar Hellström wrote:
>>>
>>>>   Den 2017-02-23 kl. 05:15, skrev Randall Gellens:
>>>>>   Version -07 addresses all comments except for the unresolved 
>>>>> issue of renaming the two attributes which is currently being 
>>>>> discussed on the list, and adding a new attribute for 
>>>>> bidirectionality.
>>>>>
>>>>>   Per Dale's suggestion, the draft adds advice that if a call is 
>>>>> rejected due to no languages in common, SIP response code 488 (Not 
>>>>> Acceptable Here) or 606 (Not Acceptable) be used, along with a 
>>>>> Warning header field indicating the supported languages.  The 
>>>>> draft registers a new entry in the warn-code sub-registry of SIP 
>>>>> parameters for this purpose.  The draft also has an expanded set 
>>>>> of examples.
>>>>>
>>>>   Good progress. Good to see the enriched examples chapter 5.5.
>>>>   I have a few comments on version -07:
>>>>
>>>>   1.  Section  4. second line
>>>>   ------------old text----------------------
>>>>   but is not sufficiently sufficiently
>>>>   ------------new text--------------------------
>>>>   but is not sufficiently
>>>>   ----------end of change 1-----------------
>>>>   Motivation: New typo in version -07
>>>
>>>  Thanks.
>>>
>>>>
>>>>   2. Section 5.2, first line
>>>>   ----------------old text-----------------
>>>>   This document defines two new media-level ..
>>>>   ----------------new text----------------------
>>>>   This document defines two media-level ...
>>>>   ----------------end of change 2----------------
>>>>   Motivation: It was commented that when the draft is published, 
>>>> this is not new anymore.
>>>>   There are three more occasions of "new" in the document that may 
>>>> be modified as well.
>>>
>>>  OK.
>>>
>>>>
>>>>   3.  5.2 second paragraph
>>>>   -------------------old text--------------------------------
>>>>   In an offer, the 'humintlang-send' values indicates the language(s)
>>>>      the offerer is willing to use when sending using the media, 
>>>> and the
>>>>      'humintlang-recv' values indicates the language(s) the offerer is
>>>>      willing to use when receiving using the media.
>>>>   -----------------new text---------------------------------
>>>>   In an offer, the 'humintlang-send' values indicate the language(s)
>>>>   the offerer is willing to select from for use when sending using the
>>>>   media, and the 'humintlang-recv' values indicate the language(s) the
>>>>   offerer is willing to receive one of in the media stream.
>>>>   ----------------end of change----------------------------------
>>>>   Motivation 1:) change from "indicates" to "indicate" in two 
>>>> places to match the new use of plural "values".
>>>>   Motivation 2:) Be sure to indicate that we only intend to 
>>>> negotiate one language per media and direction, so that we do not 
>>>> end up as unspecified regarding number of matches required as the 
>>>> sdp "lang" attribute is.
>>>
>>>  Reworded.
>>>
>>>>
>>>>   4.  5.2 Second paragraph
>>>>   -----------------old text-----------------------
>>>>   When a media is intended
>>>>      for use in one direction only
>>>>   ----------------new text---------------------
>>>>   When a media is intended
>>>>      for use for language communication in one direction only
>>>>   ----------------end of change---------------------------
>>>>   Motivation: Deletion of a note in this sentence made it less 
>>>> obvious that we are only talking about directions of use of 
>>>> language communication, and not about establishing asymmetric media 
>>>> connections. Therefore add this clarification.
>>>
>>>  Reworded.
>>>
>>>>
>>>>   5.  5.2 Deleted paragraph 6 before "Clients acting on behalf..."
>>>>   ----------reinsert modified paragraph----------------------------
>>>>   While signed language tags are used with a video stream to
>>>>   indicate sign language, a spoken language tag for a video stream
>>>>   indicates a request or offer to see the speaker, when that is of
>>>>   importance for language perception.
>>>>   -------------end of 
>>>> change-------------------------------------------
>>>>   Motivation: There was in the LC mail exchange a discussion about 
>>>> sharpening up the specification of use of "unusual combinations".
>>>>   There was no agreement to delete them all. The one described in 
>>>> this paragraph is the main one that has widespread use and needs to 
>>>> be clearly specified for use by a large number of hard-of-hearing 
>>>> and deaf users.
>>>
>>>  The text as it is now does not prohibit anything and explicitly 
>>> mentions negotiating supplemental video by omitting language 
>>> attributes on a video media.
>>>
>>>>
>>>>   6.  5.2 Sixth paragraph
>>>>   --------------------current text--------------------
>>>>   (or for unidirectional streams, one of)
>>>>   ------------------new text ------------------------
>>>>   (or for asymmetrical use of languages, one of)
>>>>   -----------------end of change----------------------
>>>>   Motivation: We are not primarily talking about enabled 
>>>> transmission directions of the streams, but about language use in 
>>>> the streams. We do not want to limit the media stream directions 
>>>> just because we do not specify an initial language to use for that 
>>>> direction. There are other usage of media, and there may even be 
>>>> occasional use of language in the direction, just not worth 
>>>> mentioning as an initial and preferred use. The suggested change 
>>>> should make that clear.
>>>>
>>>>   7.   5.3 Next to last paragraph
>>>>   ------------------old text------------------------------
>>>>   a list of supported languages.
>>>>   -------------------new text-------------------------
>>>>   a list of supported languages, media and directions.
>>>>   -------------------end of change----------------
>>>>   Motivation: It is not sufficient to know which languages are 
>>>> supported, it is also essential to know in which media they are 
>>>> supported and in which directions. (media could be replaced with 
>>>> modality, but the media can become ambigous then, so use media here 
>>>> to be brief.
>>>
>>>  I don't know that we can require this, but I'll add SHOULD kist 
>>> supported languages and media. Demanding direction as well might be 
>>> too unwieldy.
>>>
>>>>
>>>>   8.      5.3, last line
>>>>   --------------old text----------------------------------
>>>>    Supported languages are: es, en"
>>>>   --------------new text-------------------------------
>>>>    Supported languages are: es, en transmission in audio; es, en 
>>>> reception in audio"
>>>>   ----------------------------------------------------------
>>>>   Motivation: Same as for 7.
>>>
>>>  Fixed as above.
>>>
>>>>
>>>>   9.  5.4 Undefined combinations
>>>>   ----------------------------old 
>>>> text--------------------------------------
>>>>      The behavior when specifying a non-signed language tag for a 
>>>> video
>>>>      media stream, or a signed language tag for an audio or text media
>>>>      stream, is not defined.
>>>>   ---------------------------new 
>>>> text-----------------------------------------
>>>>   There is no way specified for indicating use of text based 
>>>> language in a video media stream.
>>>>   There is no meaning assigned to specification of  sign language 
>>>> in an audio or text media stream.
>>>>   --------------------------end of 
>>>> change-------------------------------
>>>>   Motivation: Seeing the speaker in video is an important 
>>>> combination reinserted above in section 5.2.
>>>>   This section therefore needed rewording to not include that 
>>>> combination.
>>>
>>>  The draft explicitly mentions video for supplemental purposes.
>>>
>>>>
>>>>
>>>>   10.     6.2 Last sentence
>>>>   -----------------current text---------------------
>>>>   Supported languages are: [list of supported languages]."
>>>>   -----------------new text------------------------
>>>>   Supported languages and media and transmission directions 
>>>> are:[list of supported languages and media and transmission 
>>>> directions.]"
>>>>   -----------------end of change--------------------------
>>>>   Motivation: Same as for 7.
>>>
>>>  Fixed as above.
>>>
>>>>
>>>>   11.  6.1 MUX Category
>>>>   ----------old text in two locations-------------------
>>>>   MUX Category:  normal
>>>>   ---------new text in same two locations--------------
>>>>   Mux Category:  NORMAL
>>>>   ---------end of change-----------------
>>>>   Motivation: Follow RFC 4566bis and IANA habits regarding use of 
>>>> capitals
>>>
>>>  Fixed.
>>>
>>>>
>>>>   12.  5.3
>>>>   -------------old text-----------------
>>>>   5.3 No Language in Common
>>>>   -------------new text----------------
>>>>   5.3 Preference parameter
>>>>   ------------end of change 1 in 5.3---------------
>>>
>>>  The section is more than just the asterisk, it also advises use of 
>>> specific SIP response codes if the call is failed.
>>>
>>>>
>>>>   -------------old text-in 5.3, second 
>>>> paragraph-------------------------------
>>>>   The mechanism for indicating this preference is that, in an 
>>>> offer, if
>>>>   the last character of any of the 'humintlang-recv' or 'humintlang-
>>>>   send' values is an asterisk, this indicates a request to not fail 
>>>> the call.
>>>>   --------------------------new text-------------------------------
>>>>   The mechanism for indicating this preference is that, in an 
>>>> offer, if
>>>>      the last character of any of the 'humintlang-recv' or 
>>>> 'humintlang-
>>>>      send' values is an asterisk, this indicates a request to not 
>>>> fail the call.
>>>>   The asterisk should be attached to attributes with languages of 
>>>> lower
>>>>   preference to be matched if such difference can be specified. 
>>>> Thereby
>>>>   the location of the asterisk can be used to support the decision on
>>>>   which languages to use in the call.
>>>>   ---------------------------end of change 2 in 
>>>> 5.3--------------------------------------
>>>>   Motivation: There has not yet been any conclusion for my proposal 
>>>> no 5 in the IETF LC comments of Feb 12.
>>>>   This is a dramatically reduced version that may be easier to 
>>>> accept at this stage, still covering one of the missing 
>>>> functionalities in the draft.
>>>>   The asterisk is used as a preference parameter in the attributes. 
>>>> Thereby the proposed title change on 5.3
>>>>   With this additional rule about where the asterisk(s) are placed, 
>>>> the answering parties get good clues about the preferences between 
>>>> alternatives presented by the offeror. The chance to set up calls 
>>>> with satisfied users increase dramatically compared to letting the 
>>>> answering party select by chance between alternatives.
>>>
>>>  Making the asterisk a purely-advisory hint as to the 
>>> least-preferred media/language combination seems harmless enough, as 
>>> it would not be required to support it; however, I'm not sure it 
>>> provides any benefit: if an offer contains some set of media with 
>>> language, and the answerer can support all of them, should the 
>>> answerer only include in its answer those without an asterisk? It 
>>> seems simpler for the answerer to include everything in the offer 
>>> that it can support.
>>>
>>
>>  --
>>  -----------------------------------------
>>  Gunnar Hellström
>>  Omnitor
>>  gunnar.hellstrom@omnitor.se
>>  +46 708 204 288
>
>

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


From nobody Sat Feb 25 23:38:49 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 8B68B12949B for ; Sat, 25 Feb 2017 23:38:47 -0800 (PST)
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 D98ffoffikvQ for ; Sat, 25 Feb 2017 23:38:44 -0800 (PST)
Received: from bin-vsp-out-02.atm.binero.net (vsp-unauthed02.binero.net [195.74.38.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 076DE128824 for ; Sat, 25 Feb 2017 23:38:43 -0800 (PST)
X-Halon-ID: 934995dc-fbf6-11e6-af93-005056917f90
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [77.53.231.21]) by bin-vsp-out-02.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Sun, 26 Feb 2017 08:38:32 +0100 (CET)
To: Randall Gellens , slim@ietf.org, Bernard Aboba 
References: <148782279664.31054.8793649134696520241.idtracker@ietfa.amsl.com>  <49fd730e-6e90-1a49-eae8-80f8b1285a76@omnitor.se>  <83152ba7-c3fb-25d8-f97d-59c7840cad56@omnitor.se>  <4b36f347-955e-e2b9-12f2-f426d47d3d33@omnitor.se>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: <59d7939c-d4c5-b74a-e960-3234f0524b39@omnitor.se>
Date: Sun, 26 Feb 2017 08:38:36 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <4b36f347-955e-e2b9-12f2-f426d47d3d33@omnitor.se>
Content-Type: multipart/alternative; boundary="------------8005CD009E584E2CB2A29C6F"
Archived-At: 
Subject: Re: [Slim] I-D Action: draft-ietf-slim-negotiating-human-language-07.txt
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 26 Feb 2017 07:38:47 -0000

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

Randall,

One more clarification for issue 12 - the asterisk placement as a 
preference hint:

You say:

" it seems better for the answerer to include all media and languages 
from the offer that it can support. "

You are right. I misread this paragraph in section 5.2:
"   In an answer, 'humintlang-send' is the language the answerer will
    send (which in most cases is one of the languages in the offer's
    'humintlang-recv'), and 'humintlang-recv' is the language the
    answerer expects to receive (which in most cases is one of the
    languages in the offer's 'humintlang-send')."

That gave me the impression that I need to answer with only one language 
per direction in the whole SDP.

But in the first paragraph of 5.2, it is said: "to negotiate
    which human language is used*in each interactive media stream*. "

So, we are allowed to include more than one language per direction in 
the SDP, but the users are not expected to use more than one language 
per direction, at least initially in the call.

(that makes the wording "will send" and "expects to receive" in the 
cited paragraph a bit misleading, because as you point out, some of them 
might never be used. "is prepared to send" and "can accept to receive" 
might better correspond to what it means. Ending the sentence with "per 
media steram" might also help to remind the reader about the semantics. 
I leave to you to change these if you want.)

/Gunnar

Den 2017-02-26 kl. 07:46, skrev Gunnar Hellström:
> Den 2017-02-25 kl. 20:58, skrev Randall Gellens:
>> Hi Gunnar,
>>
>> At 11:04 AM +0100 2/25/17, Gunnar Hellström wrote:
>>
>>>  Fine, I find that we have only issues 5, 6 and 12 still to discuss.
>>>
>>>  You did not answer issue 6, use of asymmetrical language rather 
>>> than unidirectional media. I assume you accepted it.
>>
>> Yes, I thought I had indicated that, sorry if I didn't.
> Good.
>>
>>>
>>>  On 5, the request to reinsert wording about seeing the speaker in 
>>> video, it is still a huge difference in specifying a preference to 
>>> see the speaker for language perception reasons, versus only 
>>> specifying that I want a video stream for supplementary purposes. 
>>> With the current wording in version -07, section 5.3 says that that 
>>> combination is undefined. Nothing in the LC discussion indicated 
>>> that it should be undefined. Why did you suddenly want to delete it? 
>>> It is useful. Please reinsert with the wording changes I propose.
>>
>> The email discussion led me to believe that the text was 
>> controversial.  We need to get the draft finished, so it's better to 
>> delete controversial text than to spend months fighting about it.
> The comments were first about the uncertainty about how the "silly 
> states" were to be interpreted.
> We described them all but decided to only keep the view of the speaker 
> because it is a real and useful case.
> The idea to differentiate spoken and written cases by script tags 
> caused discussions and was dropped. The remaining real case with the 
> view of the speaker was mentioned twice in the draft, so it was 
> recommended that one of them should be deleted, but not both.
>>
>>>
>>>  On 12, the meaning of the placement of the asterisk, you ask:
>>>  "Making the asterisk a purely-advisory hint as to the 
>>> least-preferred media/language combination seems harmless enough, as 
>>> it would not be required to support it; however, I'm not sure it 
>>> provides any benefit: if an offer contains some set of media with 
>>> language, and the answerer can support all of them, should the 
>>> answerer only include in its answer those without an asterisk? It 
>>> seems simpler for the answerer to include everything in the offer 
>>> that it can support."
>>>
>>>  The answering party should aim at answering with one of the 
>>> languages that is without the asterisk in the offer. Only if the 
>>> answering party does not have capability in a language without an 
>>> asterisk, one with asterisk should be selected. Thereby you get the 
>>> best opportunity to start the call in a language combination that 
>>> satisfies both users.
>>>
>>>  Example: A hard-of-hearing user can just barely conduct spoken 
>>> calls with persons she knows. From others it is much more reliable 
>>> to get text.  She calls and declares:
>>>
>>>  m=audio
>>>  a=huml-send:en
>>>  a=huml-recv:en*
>>>  m=text
>>>  a=huml-recv:en
>>>
>>>  The answering party with text capabilities sees that matching text 
>>> for sending is higher preferred than talking, and thus responds:
>>>
>>>  m=audio
>>>  a=huml-recv:en
>>>  m=text
>>>  a=huml-send:en
>>>
>>>  The answering party sends the initial greeting in text and the call 
>>> continues smoothly in well managed langauage/modality combinations.
>>>
>>>  Another called party may not have text capabilities, and may 
>>> therefore select the less favoured alternative with using speech 
>>> both ways, answering:
>>>
>>>  m=audio
>>>  a=huml-recv:en
>>>  a=huml-send:en
>>>  m=text 0
>>>
>>>  The answering party starts taking and the parties try as well as 
>>> possible to manage the call in this less preferred combination that 
>>> may be less reliable.
>>>
>>>  If the placement of the asterisk had no special meaning as it is in 
>>> version -07, it is a high risk that the answering party in the first 
>>> example would select to answer with spoken language that would be 
>>> unreliably received. Time and effort would be spent by speech to 
>>> make the answering party switch to sending text instead of talking 
>>> in order to arrange for a more reliable call situation.
>>>
>>>  If instead the caller only indicated the most favoured combinations,
>>>
>>>  m=audio
>>>  a=huml-send:en
>>>  m=text
>>>  a=huml-recv:en
>>>
>>>  Then the answering parties without text capability would not dare 
>>> to try to answer, and a reasonably successful call would be missed.
>>>
>>>  Many other similar realistic examples can be created, where 
>>> placement of the asterisk(s) would be a sufficient indication of 
>>> lower preference for language match among alternatives that would 
>>> make call establishment successful and smooth in many more cases 
>>> than without this indication opportunity.
>>>
>>>  Do you want more examples?
>>>
>>>  Please accept proposal 12.
>>
>> This convinces me that we cannot accept the proposed text, as it 
>> would introduce complexity that the WG explicitly decided to not 
>> pursue in this draft.  In the examples you provided, it seems better 
>> for the answerer to include all media and languages from the offer 
>> that it can support.  This is much simpler, has only trivial 
>> drawbacks (extra media negotiated that might not be used), and is 
>> what the WG agreed to.
> Yes, you could let the answer SDP contain one common language per 
> media and direction, but the answering human need guidance on which 
> language is best suited to start the conversation. Therefore the 
> placement of the asterisk is used to hint the answering party how to 
> start the call.
>
> The first example above can be modified to:
>
>  Example: A hard-of-hearing user can just barely conduct spoken calls 
> with persons she knows. From others it is much more reliable to get 
> text.  She calls and declares:
>
>  m=audio
>  a=huml-send:en
>  a=huml-recv:en*
>  m=text
>  a=huml-recv:en
>
>  The answering party with capabilities for both written and spoken 
> English sees that matching text for sending is higher preferred than 
> talking and sends the answer indicating the capabilities:
>
>  m=audio
>  a=huml-recv:en
> a=huml-send:en
>  m=text
>  a=huml-send:en
>
>  The answering party makes use of the hint that the caller prefers to 
> receive written text and therefore sends the initial greeting in text 
> and the call continues smoothly in well managed langauage/modality 
> combinations.
>
> ----------
> There is no complexity left in this solution, it helps to motivate why 
> we have the asterisk on media level, and it helps to successful call 
> initiations, so I think it should be acceptable.
>
> Gunnar
>
>>
>> --Randy
>>
>>>  Den 2017-02-25 kl. 01:32, skrev Randall Gellens:
>>>>  At 5:35 PM +0100 2/24/17, Gunnar Hellström wrote:
>>>>
>>>>>   Den 2017-02-23 kl. 05:15, skrev Randall Gellens:
>>>>>>   Version -07 addresses all comments except for the unresolved 
>>>>>> issue of renaming the two attributes which is currently being 
>>>>>> discussed on the list, and adding a new attribute for 
>>>>>> bidirectionality.
>>>>>>
>>>>>>   Per Dale's suggestion, the draft adds advice that if a call is 
>>>>>> rejected due to no languages in common, SIP response code 488 
>>>>>> (Not Acceptable Here) or 606 (Not Acceptable) be used, along with 
>>>>>> a Warning header field indicating the supported languages.  The 
>>>>>> draft registers a new entry in the warn-code sub-registry of SIP 
>>>>>> parameters for this purpose.  The draft also has an expanded set 
>>>>>> of examples.
>>>>>>
>>>>>   Good progress. Good to see the enriched examples chapter 5.5.
>>>>>   I have a few comments on version -07:
>>>>>
>>>>>   1.  Section  4. second line
>>>>>   ------------old text----------------------
>>>>>   but is not sufficiently sufficiently
>>>>>   ------------new text--------------------------
>>>>>   but is not sufficiently
>>>>>   ----------end of change 1-----------------
>>>>>   Motivation: New typo in version -07
>>>>
>>>>  Thanks.
>>>>
>>>>>
>>>>>   2. Section 5.2, first line
>>>>>   ----------------old text-----------------
>>>>>   This document defines two new media-level ..
>>>>>   ----------------new text----------------------
>>>>>   This document defines two media-level ...
>>>>>   ----------------end of change 2----------------
>>>>>   Motivation: It was commented that when the draft is published, 
>>>>> this is not new anymore.
>>>>>   There are three more occasions of "new" in the document that may 
>>>>> be modified as well.
>>>>
>>>>  OK.
>>>>
>>>>>
>>>>>   3.  5.2 second paragraph
>>>>>   -------------------old text--------------------------------
>>>>>   In an offer, the 'humintlang-send' values indicates the language(s)
>>>>>      the offerer is willing to use when sending using the media, 
>>>>> and the
>>>>>      'humintlang-recv' values indicates the language(s) the 
>>>>> offerer is
>>>>>      willing to use when receiving using the media.
>>>>>   -----------------new text---------------------------------
>>>>>   In an offer, the 'humintlang-send' values indicate the language(s)
>>>>>   the offerer is willing to select from for use when sending using 
>>>>> the
>>>>>   media, and the 'humintlang-recv' values indicate the language(s) 
>>>>> the
>>>>>   offerer is willing to receive one of in the media stream.
>>>>>   ----------------end of change----------------------------------
>>>>>   Motivation 1:) change from "indicates" to "indicate" in two 
>>>>> places to match the new use of plural "values".
>>>>>   Motivation 2:) Be sure to indicate that we only intend to 
>>>>> negotiate one language per media and direction, so that we do not 
>>>>> end up as unspecified regarding number of matches required as the 
>>>>> sdp "lang" attribute is.
>>>>
>>>>  Reworded.
>>>>
>>>>>
>>>>>   4.  5.2 Second paragraph
>>>>>   -----------------old text-----------------------
>>>>>   When a media is intended
>>>>>      for use in one direction only
>>>>>   ----------------new text---------------------
>>>>>   When a media is intended
>>>>>      for use for language communication in one direction only
>>>>>   ----------------end of change---------------------------
>>>>>   Motivation: Deletion of a note in this sentence made it less 
>>>>> obvious that we are only talking about directions of use of 
>>>>> language communication, and not about establishing asymmetric 
>>>>> media connections. Therefore add this clarification.
>>>>
>>>>  Reworded.
>>>>
>>>>>
>>>>>   5.  5.2 Deleted paragraph 6 before "Clients acting on behalf..."
>>>>>   ----------reinsert modified paragraph----------------------------
>>>>>   While signed language tags are used with a video stream to
>>>>>   indicate sign language, a spoken language tag for a video stream
>>>>>   indicates a request or offer to see the speaker, when that is of
>>>>>   importance for language perception.
>>>>>   -------------end of 
>>>>> change-------------------------------------------
>>>>>   Motivation: There was in the LC mail exchange a discussion about 
>>>>> sharpening up the specification of use of "unusual combinations".
>>>>>   There was no agreement to delete them all. The one described in 
>>>>> this paragraph is the main one that has widespread use and needs 
>>>>> to be clearly specified for use by a large number of 
>>>>> hard-of-hearing and deaf users.
>>>>
>>>>  The text as it is now does not prohibit anything and explicitly 
>>>> mentions negotiating supplemental video by omitting language 
>>>> attributes on a video media.
>>>>
>>>>>
>>>>>   6.  5.2 Sixth paragraph
>>>>>   --------------------current text--------------------
>>>>>   (or for unidirectional streams, one of)
>>>>>   ------------------new text ------------------------
>>>>>   (or for asymmetrical use of languages, one of)
>>>>>   -----------------end of change----------------------
>>>>>   Motivation: We are not primarily talking about enabled 
>>>>> transmission directions of the streams, but about language use in 
>>>>> the streams. We do not want to limit the media stream directions 
>>>>> just because we do not specify an initial language to use for that 
>>>>> direction. There are other usage of media, and there may even be 
>>>>> occasional use of language in the direction, just not worth 
>>>>> mentioning as an initial and preferred use. The suggested change 
>>>>> should make that clear.
>>>>>
>>>>>   7.   5.3 Next to last paragraph
>>>>>   ------------------old text------------------------------
>>>>>   a list of supported languages.
>>>>>   -------------------new text-------------------------
>>>>>   a list of supported languages, media and directions.
>>>>>   -------------------end of change----------------
>>>>>   Motivation: It is not sufficient to know which languages are 
>>>>> supported, it is also essential to know in which media they are 
>>>>> supported and in which directions. (media could be replaced with 
>>>>> modality, but the media can become ambigous then, so use media 
>>>>> here to be brief.
>>>>
>>>>  I don't know that we can require this, but I'll add SHOULD kist 
>>>> supported languages and media. Demanding direction as well might be 
>>>> too unwieldy.
>>>>
>>>>>
>>>>>   8.      5.3, last line
>>>>>   --------------old text----------------------------------
>>>>>    Supported languages are: es, en"
>>>>>   --------------new text-------------------------------
>>>>>    Supported languages are: es, en transmission in audio; es, en 
>>>>> reception in audio"
>>>>> ----------------------------------------------------------
>>>>>   Motivation: Same as for 7.
>>>>
>>>>  Fixed as above.
>>>>
>>>>>
>>>>>   9.  5.4 Undefined combinations
>>>>>   ----------------------------old 
>>>>> text--------------------------------------
>>>>>      The behavior when specifying a non-signed language tag for a 
>>>>> video
>>>>>      media stream, or a signed language tag for an audio or text 
>>>>> media
>>>>>      stream, is not defined.
>>>>>   ---------------------------new 
>>>>> text-----------------------------------------
>>>>>   There is no way specified for indicating use of text based 
>>>>> language in a video media stream.
>>>>>   There is no meaning assigned to specification of  sign language 
>>>>> in an audio or text media stream.
>>>>>   --------------------------end of 
>>>>> change-------------------------------
>>>>>   Motivation: Seeing the speaker in video is an important 
>>>>> combination reinserted above in section 5.2.
>>>>>   This section therefore needed rewording to not include that 
>>>>> combination.
>>>>
>>>>  The draft explicitly mentions video for supplemental purposes.
>>>>
>>>>>
>>>>>
>>>>>   10.     6.2 Last sentence
>>>>>   -----------------current text---------------------
>>>>>   Supported languages are: [list of supported languages]."
>>>>>   -----------------new text------------------------
>>>>>   Supported languages and media and transmission directions 
>>>>> are:[list of supported languages and media and transmission 
>>>>> directions.]"
>>>>>   -----------------end of change--------------------------
>>>>>   Motivation: Same as for 7.
>>>>
>>>>  Fixed as above.
>>>>
>>>>>
>>>>>   11.  6.1 MUX Category
>>>>>   ----------old text in two locations-------------------
>>>>>   MUX Category:  normal
>>>>>   ---------new text in same two locations--------------
>>>>>   Mux Category:  NORMAL
>>>>>   ---------end of change-----------------
>>>>>   Motivation: Follow RFC 4566bis and IANA habits regarding use of 
>>>>> capitals
>>>>
>>>>  Fixed.
>>>>
>>>>>
>>>>>   12.  5.3
>>>>>   -------------old text-----------------
>>>>>   5.3 No Language in Common
>>>>>   -------------new text----------------
>>>>>   5.3 Preference parameter
>>>>>   ------------end of change 1 in 5.3---------------
>>>>
>>>>  The section is more than just the asterisk, it also advises use of 
>>>> specific SIP response codes if the call is failed.
>>>>
>>>>>
>>>>>   -------------old text-in 5.3, second 
>>>>> paragraph-------------------------------
>>>>>   The mechanism for indicating this preference is that, in an 
>>>>> offer, if
>>>>>   the last character of any of the 'humintlang-recv' or 'humintlang-
>>>>>   send' values is an asterisk, this indicates a request to not 
>>>>> fail the call.
>>>>>   --------------------------new text-------------------------------
>>>>>   The mechanism for indicating this preference is that, in an 
>>>>> offer, if
>>>>>      the last character of any of the 'humintlang-recv' or 
>>>>> 'humintlang-
>>>>>      send' values is an asterisk, this indicates a request to not 
>>>>> fail the call.
>>>>>   The asterisk should be attached to attributes with languages of 
>>>>> lower
>>>>>   preference to be matched if such difference can be specified. 
>>>>> Thereby
>>>>>   the location of the asterisk can be used to support the decision on
>>>>>   which languages to use in the call.
>>>>>   ---------------------------end of change 2 in 
>>>>> 5.3--------------------------------------
>>>>>   Motivation: There has not yet been any conclusion for my 
>>>>> proposal no 5 in the IETF LC comments of Feb 12.
>>>>>   This is a dramatically reduced version that may be easier to 
>>>>> accept at this stage, still covering one of the missing 
>>>>> functionalities in the draft.
>>>>>   The asterisk is used as a preference parameter in the 
>>>>> attributes. Thereby the proposed title change on 5.3
>>>>>   With this additional rule about where the asterisk(s) are 
>>>>> placed, the answering parties get good clues about the preferences 
>>>>> between alternatives presented by the offeror. The chance to set 
>>>>> up calls with satisfied users increase dramatically compared to 
>>>>> letting the answering party select by chance between alternatives.
>>>>
>>>>  Making the asterisk a purely-advisory hint as to the 
>>>> least-preferred media/language combination seems harmless enough, 
>>>> as it would not be required to support it; however, I'm not sure it 
>>>> provides any benefit: if an offer contains some set of media with 
>>>> language, and the answerer can support all of them, should the 
>>>> answerer only include in its answer those without an asterisk? It 
>>>> seems simpler for the answerer to include everything in the offer 
>>>> that it can support.
>>>>
>>>
>>>  --
>>>  -----------------------------------------
>>>  Gunnar Hellström
>>>  Omnitor
>>>  gunnar.hellstrom@omnitor.se
>>>  +46 708 204 288
>>
>>
>

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


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


  
    
  
  
    
Randall,

    

    
One more clarification for issue 12 - the asterisk placement as a
      preference hint:

    
You say:

    
" it seems better for the answerer to include all media and
      languages from the offer that it can support. "

    
You are right. I misread this paragraph in section 5.2:

      "   In an answer, 'humintlang-send' is the language the answerer
      will

         send (which in most cases is one of the languages in the
      offer's

         'humintlang-recv'), and 'humintlang-recv' is the language the

         answerer expects to receive (which in most cases is one of the

         languages in the offer's 'humintlang-send')."

    
That gave me the impression that I need to answer with only one
      language per direction in the whole SDP.

    
But in the first paragraph of 5.2, it is said: "to negotiate

         which human language is used in each interactive media
        stream. "

    
So, we are allowed to include more than one language per
      direction in the SDP, but the users are not expected to use more
      than one language per direction, at least initially in the call. 

    

    
(that makes the wording "will send" and "expects to receive" in
      the cited paragraph a bit misleading, because as you point out,
      some of them might never be used. "is prepared to send" and "can
      accept to receive" might better correspond to what it means. 
      Ending the sentence with "per media steram" might also help to
      remind the reader about the semantics. I leave to you to change
      these if you want.)

    

    
/Gunnar

    

    
Den 2017-02-26 kl. 07:46, skrev Gunnar
      Hellström:

    

    
Den 2017-02-25 kl. 20:58, skrev Randall Gellens:
      

      
Hi Gunnar,
        

        

        At 11:04 AM +0100 2/25/17, Gunnar Hellström wrote:
        

        

        
 Fine, I find that we have only issues
          5, 6 and 12 still to discuss.
          

          

           You did not answer issue 6, use of asymmetrical language
          rather than unidirectional media. I assume you accepted it.
          

        

        

        Yes, I thought I had indicated that, sorry if I didn't.
        

      

      Good.
      

      

        

        

          

           On 5, the request to reinsert wording about seeing the
          speaker in video, it is still a huge difference in specifying
          a preference to see the speaker for language perception
          reasons, versus only specifying that I want a video stream for
          supplementary purposes. With the current wording in version
          -07, section 5.3 says that that combination is undefined.
          Nothing in the LC discussion indicated that it should be
          undefined. Why did you suddenly want to delete it? It is
          useful. Please reinsert with the wording changes I propose.
          

        

        

        The email discussion led me to believe that the text was
        controversial.  We need to get the draft finished, so it's
        better to delete controversial text than to spend months
        fighting about it.
        

      

      The comments were first about the uncertainty about how the "silly
      states" were to be interpreted.
      

      We described them all but decided to only keep the view of the
      speaker because it is a real and useful case.
      

      The idea to differentiate spoken and written cases by script tags
      caused discussions and was dropped. The remaining real case with
      the view of the speaker was mentioned twice in the draft, so it
      was recommended that one of them should be deleted, but not both.
      

      

        

        

          

           On 12, the meaning of the placement of the asterisk, you ask:
          

           "Making the asterisk a purely-advisory hint as to the
          least-preferred media/language combination seems harmless
          enough, as it would not be required to support it; however,
          I'm not sure it provides any benefit: if an offer contains
          some set of media with language, and the answerer can support
          all of them, should the answerer only include in its answer
          those without an asterisk? It seems simpler for the answerer
          to include everything in the offer that it can support."
          

          

           The answering party should aim at answering with one of the
          languages that is without the asterisk in the offer. Only if
          the answering party does not have capability in a language
          without an asterisk, one with asterisk should be selected.
          Thereby you get the best opportunity to start the call in a
          language combination that satisfies both users.
          

          

           Example: A hard-of-hearing user can just barely conduct
          spoken calls with persons she knows. From others it is much
          more reliable to get text.  She calls and declares:
          

          

           m=audio
          

           a=huml-send:en
          

           a=huml-recv:en*
          

           m=text
          

           a=huml-recv:en
          

          

           The answering party with text capabilities sees that matching
          text for sending is higher preferred than talking, and thus
          responds:
          

          

           m=audio
          

           a=huml-recv:en
          

           m=text
          

           a=huml-send:en
          

          

           The answering party sends the initial greeting in text and
          the call continues smoothly in well managed langauage/modality
          combinations.
          

          

           Another called party may not have text capabilities, and may
          therefore select the less favoured alternative with using
          speech both ways, answering:
          

          

           m=audio
          

           a=huml-recv:en
          

           a=huml-send:en
          

           m=text 0
          

          

           The answering party starts taking and the parties try as well
          as possible to manage the call in this less preferred
          combination that may be less reliable.
          

          

           If the placement of the asterisk had no special meaning as it
          is in version -07, it is a high risk that the answering party
          in the first example would select to answer with spoken
          language that would be unreliably received. Time and effort
          would be spent by speech to make the answering party switch to
          sending text instead of talking in order to arrange for a more
          reliable call situation.
          

          

           If instead the caller only indicated the most favoured
          combinations,
          

          

           m=audio
          

           a=huml-send:en
          

           m=text
          

           a=huml-recv:en
          

          

           Then the answering parties without text capability would not
          dare to try to answer, and a reasonably successful call would
          be missed.
          

          

           Many other similar realistic examples can be created, where
          placement of the asterisk(s) would be a sufficient indication
          of lower preference for language match among alternatives that
          would make call establishment successful and smooth in many
          more cases than without this indication opportunity.
          

          

           Do you want more examples?
          

          

           Please accept proposal 12.
          

        

        

        This convinces me that we cannot accept the proposed text, as it
        would introduce complexity that the WG explicitly decided to not
        pursue in this draft.  In the examples you provided, it seems
        better for the answerer to include all media and languages from
        the offer that it can support.  This is much simpler, has only
        trivial drawbacks (extra media negotiated that might not be
        used), and is what the WG agreed to.
        

      

      Yes, you could let the answer SDP contain one common language per
      media and direction, but the answering human need guidance on
      which language is best suited to start the conversation. Therefore
      the placement of the asterisk is used to hint the answering party
      how to start the call.
      

      

      The first example above can be modified to:
      

      

       Example: A hard-of-hearing user can just barely conduct spoken
      calls with persons she knows. From others it is much more reliable
      to get text.  She calls and declares:
      

      

       m=audio
      

       a=huml-send:en
      

       a=huml-recv:en*
      

       m=text
      

       a=huml-recv:en
      

      

       The answering party with capabilities for both written and spoken
      English sees that matching text for sending is higher preferred
      than talking and sends the answer indicating the capabilities:
      

      

       m=audio
      

       a=huml-recv:en
      

      a=huml-send:en
      

       m=text
      

       a=huml-send:en
      

      

       The answering party makes use of the hint that the caller prefers
      to receive written text and therefore sends the initial greeting
      in text and the call continues smoothly in well managed
      langauage/modality combinations.
      

      

      ----------
      

      There is no complexity left in this solution, it helps to motivate
      why we have the asterisk on media level, and it helps to
      successful call initiations, so I think it should be acceptable.
      

      

      Gunnar
      

      

      

        

        --Randy
        

        

        
 Den 2017-02-25 kl. 01:32, skrev Randall
          Gellens:
          

          
 At 5:35 PM +0100 2/24/17, Gunnar
            Hellström wrote:
            

            

            
  Den 2017-02-23 kl. 05:15, skrev
              Randall Gellens:
              

              
  Version -07 addresses all
                comments except for the unresolved issue of renaming the
                two attributes which is currently being discussed on the
                list, and adding a new attribute for bidirectionality.
                

                

                  Per Dale's suggestion, the draft adds advice that if a
                call is rejected due to no languages in common, SIP
                response code 488 (Not Acceptable Here) or 606 (Not
                Acceptable) be used, along with a Warning header field
                indicating the supported languages.  The draft registers
                a new entry in the warn-code sub-registry of SIP
                parameters for this purpose.  The draft also has an
                expanded set of examples.
                

                

              

                Good progress. Good to see the enriched examples chapter
              5.5.
              

                I have a few comments on version -07:
              

              

                1.  Section  4. second line
              

                ------------old text----------------------
              

                but is not sufficiently sufficiently
              

                ------------new text--------------------------
              

                but is not sufficiently
              

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

                Motivation: New typo in version -07
              

            

            

             Thanks.
            

            

            

              

                2. Section 5.2, first line
              

                ----------------old text-----------------
              

                This document defines two new media-level ..
              

                ----------------new text----------------------
              

                This document defines two media-level ...
              

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

                Motivation: It was commented that when the draft is
              published, this is not new anymore.
              

                There are three more occasions of "new" in the document
              that may be modified as well.
              

            

            

             OK.
            

            

            

              

                3.  5.2 second paragraph
              

                -------------------old
              text--------------------------------
              

                In an offer, the 'humintlang-send' values indicates the
              language(s)
              

                   the offerer is willing to use when sending using the
              media, and the
              

                   'humintlang-recv' values indicates the language(s)
              the offerer is
              

                   willing to use when receiving using the media.
              

                -----------------new
              text---------------------------------
              

                In an offer, the 'humintlang-send' values indicate the
              language(s)
              

                the offerer is willing to select from for use when
              sending using the
              

                media, and the 'humintlang-recv' values indicate the
              language(s) the
              

                offerer is willing to receive one of in the media
              stream.
              

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

                Motivation 1:) change from "indicates" to "indicate" in
              two places to match the new use of plural "values".
              

                Motivation 2:) Be sure to indicate that we only intend
              to negotiate one language per media and direction, so that
              we do not end up as unspecified regarding number of
              matches required as the sdp "lang" attribute is.
              

            

            

             Reworded.
            

            

            

              

                4.  5.2 Second paragraph
              

                -----------------old text-----------------------
              

                When a media is intended
              

                   for use in one direction only
              

                ----------------new text---------------------
              

                When a media is intended
              

                   for use for language communication in one direction
              only
              

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

                Motivation: Deletion of a note in this sentence made it
              less obvious that we are only talking about directions of
              use of language communication, and not about establishing
              asymmetric media connections. Therefore add this
              clarification.
              

            

            

             Reworded.
            

            

            

              

                5.  5.2 Deleted paragraph 6 before "Clients acting on
              behalf..."
              

                ----------reinsert modified
              paragraph----------------------------
              

                While signed language tags are used with a video stream
              to
              

                indicate sign language, a spoken language tag for a
              video stream
              

                indicates a request or offer to see the speaker, when
              that is of
              

                importance for language perception.
              

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

                Motivation: There was in the LC mail exchange a
              discussion about sharpening up the specification of use of
              "unusual combinations".
              

                There was no agreement to delete them all. The one
              described in this paragraph is the main one that has
              widespread use and needs to be clearly specified for use
              by a large number of hard-of-hearing and deaf users.
              

            

            

             The text as it is now does not prohibit anything and
            explicitly mentions negotiating supplemental video by
            omitting language attributes on a video media.
            

            

            

              

                6.  5.2 Sixth paragraph
              

                --------------------current text--------------------
              

                (or for unidirectional streams, one of)
              

                ------------------new text ------------------------
              

                (or for asymmetrical use of languages, one of)
              

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

                Motivation: We are not primarily talking about enabled
              transmission directions of the streams, but about language
              use in the streams. We do not want to limit the media
              stream directions just because we do not specify an
              initial language to use for that direction. There are
              other usage of media, and there may even be occasional use
              of language in the direction, just not worth mentioning as
              an initial and preferred use. The suggested change should
              make that clear.
              

              

                7.   5.3 Next to last paragraph
              

                ------------------old text------------------------------
              

                a list of supported languages.
              

                -------------------new text-------------------------
              

                a list of supported languages, media and directions.
              

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

                Motivation: It is not sufficient to know which languages
              are supported, it is also essential to know in which media
              they are supported and in which directions. (media could
              be replaced with modality, but the media can become
              ambigous then, so use media here to be brief.
              

            

            

             I don't know that we can require this, but I'll add SHOULD
            kist supported languages and media. Demanding direction as
            well might be too unwieldy.
            

            

            

              

                8.      5.3, last line
              

                --------------old text----------------------------------
              

                 Supported languages are: es, en"
              

                --------------new text-------------------------------
              

                 Supported languages are: es, en transmission in audio;
              es, en reception in audio"
              

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

                Motivation: Same as for 7.
              

            

            

             Fixed as above.
            

            

            

              

                9.  5.4 Undefined combinations
              

                ----------------------------old
              text--------------------------------------
              

                   The behavior when specifying a non-signed language
              tag for a video
              

                   media stream, or a signed language tag for an audio
              or text media
              

                   stream, is not defined.
              

                ---------------------------new
              text-----------------------------------------
              

                There is no way specified for indicating use of text
              based language in a video media stream.
              

                There is no meaning assigned to specification of  sign
              language in an audio or text media stream.
              

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

                Motivation: Seeing the speaker in video is an important
              combination reinserted above in section 5.2.
              

                This section therefore needed rewording to not include
              that combination.
              

            

            

             The draft explicitly mentions video for supplemental
            purposes.
            

            

            

              

              

                10.     6.2 Last sentence
              

                -----------------current text---------------------
              

                Supported languages are: [list of supported languages]."
              

                -----------------new text------------------------
              

                Supported languages and media and transmission
              directions are:[list of supported languages and media and
              transmission directions.]"
              

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

                Motivation: Same as for 7.
              

            

            

             Fixed as above.
            

            

            

              

                11.  6.1 MUX Category
              

                ----------old text in two locations-------------------
              

                MUX Category:  normal
              

                ---------new text in same two locations--------------
              

                Mux Category:  NORMAL
              

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

                Motivation: Follow RFC 4566bis and IANA habits regarding
              use of capitals
              

            

            

             Fixed.
            

            

            

              

                12.  5.3
              

                -------------old text-----------------
              

                5.3 No Language in Common
              

                -------------new text----------------
              

                5.3 Preference parameter
              

                ------------end of change 1 in 5.3---------------
              

            

            

             The section is more than just the asterisk, it also advises
            use of specific SIP response codes if the call is failed.
            

            

            

              

                -------------old text-in 5.3, second
              paragraph-------------------------------
              

                The mechanism for indicating this preference is that, in
              an offer, if
              

                the last character of any of the 'humintlang-recv' or
              'humintlang-
              

                send' values is an asterisk, this indicates a request to
              not fail the call.
              

                --------------------------new
              text-------------------------------
              

                The mechanism for indicating this preference is that, in
              an offer, if
              

                   the last character of any of the 'humintlang-recv' or
              'humintlang-
              

                   send' values is an asterisk, this indicates a request
              to not fail the call.
              

                The asterisk should be attached to attributes with
              languages of lower
              

                preference to be matched if such difference can be
              specified. Thereby
              

                the location of the asterisk can be used to support the
              decision on
              

                which languages to use in the call.
              

                ---------------------------end of change 2 in
              5.3--------------------------------------
              

                Motivation: There has not yet been any conclusion for my
              proposal no 5 in the IETF LC comments of Feb 12.
              

                This is a dramatically reduced version that may be
              easier to accept at this stage, still covering one of the
              missing functionalities in the draft.
              

                The asterisk is used as a preference parameter in the
              attributes. Thereby the proposed title change on 5.3
              

                With this additional rule about where the asterisk(s)
              are placed, the answering parties get good clues about the
              preferences between alternatives presented by the offeror.
              The chance to set up calls with satisfied users increase
              dramatically compared to letting the answering party
              select by chance between alternatives.
              

            

            

             Making the asterisk a purely-advisory hint as to the
            least-preferred media/language combination seems harmless
            enough, as it would not be required to support it; however,
            I'm not sure it provides any benefit: if an offer contains
            some set of media with language, and the answerer can
            support all of them, should the answerer only include in its
            answer those without an asterisk? It seems simpler for the
            answerer to include everything in the offer that it can
            support.
            

            

          

          

           --
          

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

           Gunnar Hellström
          

           Omnitor
          

           gunnar.hellstrom@omnitor.se
          

           +46 708 204 288
          

        

        

        

      

      

    

    

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

  


--------------8005CD009E584E2CB2A29C6F--


From nobody Sun Feb 26 16:56: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 5C81112957F for ; Sun, 26 Feb 2017 16:56:52 -0800 (PST)
X-Quarantine-ID: 
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -1.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 B8VxuCP3T-HV for ; Sun, 26 Feb 2017 16:56:50 -0800 (PST)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 3B4D6129488 for ; Sun, 26 Feb 2017 16:56:50 -0800 (PST)
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Sun, 26 Feb 2017 16:46:43 -0800
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <4b36f347-955e-e2b9-12f2-f426d47d3d33@omnitor.se>
References: <148782279664.31054.8793649134696520241.idtracker@ietfa.amsl.com>  <49fd730e-6e90-1a49-eae8-80f8b1285a76@omnitor.se>  <83152ba7-c3fb-25d8-f97d-59c7840cad56@omnitor.se>  <4b36f347-955e-e2b9-12f2-f426d47d3d33@omnitor.se>
X-Mailer: Eudora for Mac OS X
Date: Sun, 26 Feb 2017 16:55:59 -0800
To: Gunnar =?iso-8859-1?Q?Hellstr=F6m?=  , slim@ietf.org, Natasha Rooney , Bernard Aboba 
From: Randall Gellens 
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
Archived-At: 
Subject: Re: [Slim] I-D Action: draft-ietf-slim-negotiating-human-language-07.txt
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Feb 2017 00:56:52 -0000

At 7:46 AM +0100 2/26/17, Gunnar Hellstr=F6m wrote:

>  Den 2017-02-25 kl. 20:58, skrev Randall Gellens:
>>  Hi Gunnar,
>>
>>  At 11:04 AM +0100 2/25/17, Gunnar Hellstr=F6m wrote:
>>
>>>   Fine, I find that we have only issues 5, 6 and 12 still to discuss.
>>>
>>>   You did not answer issue 6, use of=20
>>> asymmetrical language rather than=20
>>> unidirectional media. I assume you accepted=20
>>> it.
>>
>>  Yes, I thought I had indicated that, sorry if I didn't.
>  Good.
>>
>>>
>>>   On 5, the request to reinsert wording about=20
>>> seeing the speaker in video, it is still a=20
>>> huge difference in specifying a preference to=20
>>> see the speaker for language perception=20
>>> reasons, versus only specifying that I want a=20
>>> video stream for supplementary purposes. With=20
>>> the current wording in version -07, section=20
>>> 5.3 says that that combination is undefined.=20
>>> Nothing in the LC discussion indicated that=20
>>> it should be undefined. Why did you suddenly=20
>>> want to delete it? It is useful. Please=20
>>> reinsert with the wording changes I propose.
>>
>>  The email discussion led me to believe that=20
>> the text was controversial.  We need to get=20
>> the draft finished, so it's better to delete=20
>> controversial text than to spend months=20
>> fighting about it.
>  The comments were first about the uncertainty=20
> about how the "silly states" were to be=20
> interpreted.
>  We described them all but decided to only keep=20
> the view of the speaker because it is a real=20
> and useful case.
>  The idea to differentiate spoken and written=20
> cases by script tags caused discussions and was=20
> dropped. The remaining real case with the view=20
> of the speaker was mentioned twice in the=20
> draft, so it was recommended that one of them=20
> should be deleted, but not both.

OK, I'll restore the text in section 5.2:

    Note that while signed language tags are used with a video stream to
    indicate sign language, a spoken language tag for a video stream in
    parallel with an audio stream with the same spoken language tag
    indicates a request for a supplemental video stream to see the
    speaker.

And modify section 5.4 to exclude this case:

    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.


>>
>>>
>>>   On 12, the meaning of the placement of the asterisk, you ask:
>>>   "Making the asterisk a purely-advisory hint=20
>>> as to the least-preferred media/language=20
>>> combination seems harmless enough, as it=20
>>> would not be required to support it; however,=20
>>> I'm not sure it provides any benefit: if an=20
>>> offer contains some set of media with=20
>>> language, and the answerer can support all of=20
>>> them, should the answerer only include in its=20
>>> answer those without an asterisk? It seems=20
>>> simpler for the answerer to include=20
>>> everything in the offer that it can support."
>>>
>>>   The answering party should aim at answering=20
>>> with one of the languages that is without the=20
>>> asterisk in the offer. Only if the answering=20
>>> party does not have capability in a language=20
>>> without an asterisk, one with asterisk should=20
>>> be selected. Thereby you get the best=20
>>> opportunity to start the call in a language=20
>>> combination that satisfies both users.
>>>
>>>   Example: A hard-of-hearing user can just=20
>>> barely conduct spoken calls with persons she=20
>>> knows. From others it is much more reliable=20
>>> to get text.  She calls and declares:
>>>
>>>   m=3Daudio
>>>   a=3Dhuml-send:en
>>>   a=3Dhuml-recv:en*
>>>   m=3Dtext
>>>   a=3Dhuml-recv:en
>>>
>>>   The answering party with text capabilities=20
>>> sees that matching text for sending is higher=20
>>> preferred than talking, and thus responds:
>>>
>>>   m=3Daudio
>>>   a=3Dhuml-recv:en
>>>   m=3Dtext
>>>   a=3Dhuml-send:en
>>>
>>>   The answering party sends the initial=20
>>> greeting in text and the call continues=20
>>> smoothly in well managed langauage/modality=20
>>> combinations.
>>>
>>>   Another called party may not have text=20
>>> capabilities, and may therefore select the=20
>>> less favoured alternative with using speech=20
>>> both ways, answering:
>>>
>>>   m=3Daudio
>>>   a=3Dhuml-recv:en
>>>   a=3Dhuml-send:en
>>>   m=3Dtext 0
>>>
>>>   The answering party starts taking and the=20
>>> parties try as well as possible to manage the=20
>>> call in this less preferred combination that=20
>>> may be less reliable.
>>>
>>>   If the placement of the asterisk had no=20
>>> special meaning as it is in version -07, it=20
>>> is a high risk that the answering party in=20
>>> the first example would select to answer with=20
>>> spoken language that would be unreliably=20
>>> received. Time and effort would be spent by=20
>>> speech to make the answering party switch to=20
>>> sending text instead of talking in order to=20
>>> arrange for a more reliable call situation.
>>>
>>>   If instead the caller only indicated the most favoured combinations,
>>>
>>>   m=3Daudio
>>>   a=3Dhuml-send:en
>>>   m=3Dtext
>>>   a=3Dhuml-recv:en
>>>
>>>   Then the answering parties without text=20
>>> capability would not dare to try to answer,=20
>>> and a reasonably successful call would be=20
>>> missed.
>>>
>>>   Many other similar realistic examples can be=20
>>> created, where placement of the asterisk(s)=20
>>> would be a sufficient indication of lower=20
>>> preference for language match among=20
>>> alternatives that would make call=20
>>> establishment successful and smooth in many=20
>>> more cases than without this indication=20
>>> opportunity.
>>>
>>>   Do you want more examples?
>>>
>>>   Please accept proposal 12.
>>
>>  This convinces me that we cannot accept the=20
>> proposed text, as it would introduce=20
>> complexity that the WG explicitly decided to=20
>> not pursue in this draft.  In the examples you=20
>> provided, it seems better for the answerer to=20
>> include all media and languages from the offer=20
>> that it can support.  This is much simpler,=20
>> has only trivial drawbacks (extra media=20
>> negotiated that might not be used), and is=20
>> what the WG agreed to.
>  Yes, you could let the answer SDP contain one=20
> common language per media and direction, but=20
> the answering human need guidance on which=20
> language is best suited to start the=20
> conversation. Therefore the placement of the=20
> asterisk is used to hint the answering party=20
> how to start the call.

I believe the WG discussed proposals to provide=20
information to the humans regarding the languages=20
and media that were negotiated, and decided it is=20
out of scope of the draft as an implementation=20
issue, not a protocol issue.

>
>  The first example above can be modified to:
>
>   Example: A hard-of-hearing user can just=20
> barely conduct spoken calls with persons she=20
> knows. From others it is much more reliable to=20
> get text.  She calls and declares:
>
>   m=3Daudio
>   a=3Dhuml-send:en
>   a=3Dhuml-recv:en*
>   m=3Dtext
>   a=3Dhuml-recv:en
>
>   The answering party with capabilities for both=20
> written and spoken English sees that matching=20
> text for sending is higher preferred than=20
> talking and sends the answer indicating the=20
> capabilities:
>
>   m=3Daudio
>   a=3Dhuml-recv:en
>  a=3Dhuml-send:en
>   m=3Dtext
>   a=3Dhuml-send:en
>
>   The answering party makes use of the hint that=20
> the caller prefers to receive written text and=20
> therefore sends the initial greeting in text=20
> and the call continues smoothly in well managed=20
> langauage/modality combinations.
>
>  ----------
>  There is no complexity left in this solution,=20
> it helps to motivate why we have the asterisk=20
> on media level, and it helps to successful call=20
> initiations, so I think it should be acceptable.

My suggestion is that you write this idea as a=20
new draft offering implementation guidance, and=20
ask the WG to adopt it as either Informational or=20
BCP.  It doesn't affect the protocol in the=20
current draft, but provides guidance on how to=20
use the protocol in both an offer and an answer=20
and potentially in the UI.



>>
>>>   Den 2017-02-25 kl. 01:32, skrev Randall Gellens:
>>>>   At 5:35 PM +0100 2/24/17, Gunnar Hellstr=F6m wrote:
>>>>
>>>>>    Den 2017-02-23 kl. 05:15, skrev Randall Gellens:
>>>>>>    Version -07 addresses all comments=20
>>>>>> except for the unresolved issue of=20
>>>>>> renaming the two attributes which is=20
>>>>>> currently being discussed on the list, and=20
>>>>>> adding a new attribute for=20
>>>>>> bidirectionality.
>>>>>>
>>>>>>    Per Dale's suggestion, the draft adds=20
>>>>>> advice that if a call is rejected due to=20
>>>>>> no languages in common, SIP response code=20
>>>>>> 488 (Not Acceptable Here) or 606 (Not=20
>>>>>> Acceptable) be used, along with a Warning=20
>>>>>> header field indicating the supported=20
>>>>>> languages.  The draft registers a new=20
>>>>>> entry in the warn-code sub-registry of SIP=20
>>>>>> parameters for this purpose.  The draft=20
>>>>>> also has an expanded set of examples.
>>>>>>
>>>>>    Good progress. Good to see the enriched examples chapter 5.5.
>>>>>    I have a few comments on version -07:
>>>>>
>>>>>    1.  Section  4. second line
>>>>>    ------------old text----------------------
>>>>>    but is not sufficiently sufficiently
>>>>>    ------------new text--------------------------
>>>>>    but is not sufficiently
>>>>>    ----------end of change 1-----------------
>>>>>    Motivation: New typo in version -07
>>>>
>>>>   Thanks.
>>>>
>>>>>
>>>>>    2. Section 5.2, first line
>>>>>    ----------------old text-----------------
>>>>>    This document defines two new media-level ..
>>>>>    ----------------new text----------------------
>>>>>    This document defines two media-level ...
>>>>>    ----------------end of change 2----------------
>>>>>    Motivation: It was commented that when=20
>>>>> the draft is published, this is not new=20
>>>>> anymore.
>>>>>    There are three more occasions of "new"=20
>>>>> in the document that may be modified as=20
>>>>> well.
>>>>
>>>>   OK.
>>>>
>>>>>
>>>>>    3.  5.2 second paragraph
>>>>>    -------------------old text--------------------------------
>>>>>    In an offer, the 'humintlang-send' values indicates the language(s)
>>>>>       the offerer is willing to use when sending using the media, and =
the
>>>>>       'humintlang-recv' values indicates the language(s) the offerer i=
s
>>>>>       willing to use when receiving using the media.
>>>>>    -----------------new text---------------------------------
>>>>>    In an offer, the 'humintlang-send' values indicate the language(s)
>>>>>    the offerer is willing to select from for use when sending using th=
e
>>>>>    media, and the 'humintlang-recv' values indicate the language(s) th=
e
>>>>>    offerer is willing to receive one of in the media stream.
>>>>>    ----------------end of change----------------------------------
>>>>>    Motivation 1:) change from "indicates" to=20
>>>>> "indicate" in two places to match the new=20
>>>>> use of plural "values".
>>>>>    Motivation 2:) Be sure to indicate that=20
>>>>> we only intend to negotiate one language=20
>>>>> per media and direction, so that we do not=20
>>>>> end up as unspecified regarding number of=20
>>>>> matches required as the sdp "lang"=20
>>>>> attribute is.
>>>>
>>>>   Reworded.
>>>>
>>>>>
>>>>>    4.  5.2 Second paragraph
>>>>>    -----------------old text-----------------------
>>>>>    When a media is intended
>>>>>       for use in one direction only
>>>>>    ----------------new text---------------------
>>>>>    When a media is intended
>>>>>       for use for language communication in one direction only
>>>>>    ----------------end of change---------------------------
>>>>>    Motivation: Deletion of a note in this=20
>>>>> sentence made it less obvious that we are=20
>>>>> only talking about directions of use of=20
>>>>> language communication, and not about=20
>>>>> establishing asymmetric media connections.=20
>>>>> Therefore add this clarification.
>>>>
>>>>   Reworded.
>>>>
>>>>>
>>>>>    5.  5.2 Deleted paragraph 6 before "Clients acting on behalf..."
>>>>>    ----------reinsert modified paragraph----------------------------
>>>>>    While signed language tags are used with a video stream to
>>>>>    indicate sign language, a spoken language tag for a video stream
>>>>>    indicates a request or offer to see the speaker, when that is of
>>>>>    importance for language perception.
>>>>>    -------------end of change-----------------------------------------=
--
>>>>>    Motivation: There was in the LC mail=20
>>>>> exchange a discussion about sharpening up=20
>>>>> the specification of use of "unusual=20
>>>>> combinations".
>>>>>    There was no agreement to delete them=20
>>>>> all. The one described in this paragraph is=20
>>>>> the main one that has widespread use and=20
>>>>> needs to be clearly specified for use by a=20
>>>>> large number of hard-of-hearing and deaf=20
>>>>> users.
>>>>
>>>>   The text as it is now does not prohibit=20
>>>> anything and explicitly mentions negotiating=20
>>>> supplemental video by omitting language=20
>>>> attributes on a video media.
>>>>
>>>>>
>>>>>    6.  5.2 Sixth paragraph
>>>>>    --------------------current text--------------------
>>>>>    (or for unidirectional streams, one of)
>>>>>    ------------------new text ------------------------
>>>>>    (or for asymmetrical use of languages, one of)
>>>>>    -----------------end of change----------------------
>>>>>    Motivation: We are not primarily talking=20
>>>>> about enabled transmission directions of=20
>>>>> the streams, but about language use in the=20
>>>>> streams. We do not want to limit the media=20
>>>>> stream directions just because we do not=20
>>>>> specify an initial language to use for that=20
>>>>> direction. There are other usage of media,=20
>>>>> and there may even be occasional use of=20
>>>>> language in the direction, just not worth=20
>>>>> mentioning as an initial and preferred use.=20
>>>>> The suggested change should make that clear.
>>>>>
>>>>>    7.   5.3 Next to last paragraph
>>>>>    ------------------old text------------------------------
>>>>>    a list of supported languages.
>>>>>    -------------------new text-------------------------
>>>>>    a list of supported languages, media and directions.
>>>>>    -------------------end of change----------------
>>>>>    Motivation: It is not sufficient to know=20
>>>>> which languages are supported, it is also=20
>>>>> essential to know in which media they are=20
>>>>> supported and in which directions. (media=20
>>>>> could be replaced with modality, but the=20
>>>>> media can become ambigous then, so use=20
>>>>> media here to be brief.
>>>>
>>>>   I don't know that we can require this, but=20
>>>> I'll add SHOULD kist supported languages and=20
>>>> media. Demanding direction as well might be=20
>>>> too unwieldy.
>>>>
>>>>>
>>>>>    8.      5.3, last line
>>>>>    --------------old text----------------------------------
>>>>>     Supported languages are: es, en"
>>>>>    --------------new text-------------------------------
>>>>>     Supported languages are: es, en=20
>>>>> transmission in audio; es, en reception in=20
>>>>> audio"
>>>>>    ----------------------------------------------------------
>>>>>    Motivation: Same as for 7.
>>>>
>>>>   Fixed as above.
>>>>
>>>>>
>>>>>    9.  5.4 Undefined combinations
>>>>>    ----------------------------old=20
>>>>> text--------------------------------------
>>>>>       The behavior when specifying a non-signed language tag for a vid=
eo
>>>>>       media stream, or a signed language tag for an audio or text medi=
a
>>>>>       stream, is not defined.
>>>>>    ---------------------------new=20
>>>>> text-----------------------------------------
>>>>>    There is no way specified for indicating=20
>>>>> use of text based language in a video media=20
>>>>> stream.
>>>>>    There is no meaning assigned to=20
>>>>> specification of  sign language in an audio=20
>>>>> or text media stream.
>>>>>    --------------------------end of change----------------------------=
---
>>>>>    Motivation: Seeing the speaker in video=20
>>>>> is an important combination reinserted=20
>>>>> above in section 5.2.
>>>>>    This section therefore needed rewording=20
>>>>> to not include that combination.
>>>>
>>>>   The draft explicitly mentions video for supplemental purposes.
>>>>
>>>>>
>>>>>
>>>>>    10.     6.2 Last sentence
>>>>>    -----------------current text---------------------
>>>>>    Supported languages are: [list of supported languages]."
>>>>>    -----------------new text------------------------
>>>>>    Supported languages and media and=20
>>>>> transmission directions are:[list of=20
>>>>> supported languages and media and=20
>>>>> transmission directions.]"
>>>>>    -----------------end of change--------------------------
>>>>>    Motivation: Same as for 7.
>>>>
>>>>   Fixed as above.
>>>>
>>>>>
>>>>>    11.  6.1 MUX Category
>>>>>    ----------old text in two locations-------------------
>>>>>    MUX Category:  normal
>>>>>    ---------new text in same two locations--------------
>>>>>    Mux Category:  NORMAL
>>>>>    ---------end of change-----------------
>>>>>    Motivation: Follow RFC 4566bis and IANA=20
>>>>> habits regarding use of capitals
>>>>
>>>>   Fixed.
>>>>
>>>>>
>>>>>    12.  5.3
>>>>>    -------------old text-----------------
>>>>>    5.3 No Language in Common
>>>>>    -------------new text----------------
>>>>>    5.3 Preference parameter
>>>>>    ------------end of change 1 in 5.3---------------
>>>>
>>>>   The section is more than just the asterisk,=20
>>>> it also advises use of specific SIP response=20
>>>> codes if the call is failed.
>>>>
>>>>>
>>>>>    -------------old text-in 5.3, second=20
>>>>> paragraph-------------------------------
>>>>>    The mechanism for indicating this preference is that, in an offer, =
if
>>>>>    the last character of any of the 'humintlang-recv' or 'humintlang-
>>>>>    send' values is an asterisk, this=20
>>>>> indicates a request to not fail the call.
>>>>>    --------------------------new text-------------------------------
>>>>>    The mechanism for indicating this preference is that, in an offer, =
if
>>>>>       the last character of any of the 'humintlang-recv' or 'humintlan=
g-
>>>>>       send' values is an asterisk, this=20
>>>>> indicates a request to not fail the call.
>>>>>    The asterisk should be attached to attributes with languages of low=
er
>>>>>    preference to be matched if such difference can be specified. There=
by
>>>>>    the location of the asterisk can be used to support the decision on
>>>>>    which languages to use in the call.
>>>>>    ---------------------------end of change=20
>>>>> 2 in=20
>>>>> 5.3--------------------------------------
>>>>>    Motivation: There has not yet been any=20
>>>>> conclusion for my proposal no 5 in the IETF=20
>>>>> LC comments of Feb 12.
>>>>>    This is a dramatically reduced version=20
>>>>> that may be easier to accept at this stage,=20
>>>>> still covering one of the missing=20
>>>>> functionalities in the draft.
>>>>>    The asterisk is used as a preference=20
>>>>> parameter in the attributes. Thereby the=20
>>>>> proposed title change on 5.3
>>>>>    With this additional rule about where the=20
>>>>> asterisk(s) are placed, the answering=20
>>>>> parties get good clues about the=20
>>>>> preferences between alternatives presented=20
>>>>> by the offeror. The chance to set up calls=20
>>>>> with satisfied users increase dramatically=20
>>>>> compared to letting the answering party=20
>>>>> select by chance between alternatives.
>>>>
>>>>   Making the asterisk a purely-advisory hint=20
>>>> as to the least-preferred media/language=20
>>>> combination seems harmless enough, as it=20
>>>> would not be required to support it;=20
>>>> however, I'm not sure it provides any=20
>>>> benefit: if an offer contains some set of=20
>>>> media with language, and the answerer can=20
>>>> support all of them, should the answerer=20
>>>> only include in its answer those without an=20
>>>> asterisk? It seems simpler for the answerer=20
>>>> to include everything in the offer that it=20
>>>> can support.
>>>>
>>>
>>>   --
>>>   -----------------------------------------
>>>   Gunnar Hellstr=F6m
>>>   Omnitor
>>>   gunnar.hellstrom@omnitor.se
>>>   +46 708 204 288
>>
>>
>
>  --
>  -----------------------------------------
>  Gunnar Hellstr=F6m
>  Omnitor
>  gunnar.hellstrom@omnitor.se
>  +46 708 204 288


-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Tell the pretty ones they're smart, and tell the smart ones they're pretty.
                                       --Mae West's advice on handling men


From nobody Sun Feb 26 17:03:52 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 B8640129488; Sun, 26 Feb 2017 17:03:51 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.46.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148815743175.2888.5910196139640584790.idtracker@ietfa.amsl.com>
Date: Sun, 26 Feb 2017 17:03:51 -0800
Archived-At: 
Cc: slim@ietf.org
Subject: [Slim] I-D Action: draft-ietf-slim-negotiating-human-language-08.txt
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Feb 2017 01:03:51 -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-08.txt
	Pages           : 17
	Date            : 2017-02-26

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's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-slim-negotiating-human-language-08

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


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 Feb 26 17:08: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 A6338129545 for ; Sun, 26 Feb 2017 17:08:50 -0800 (PST)
X-Quarantine-ID: 
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -1.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 rLqa0As_gikU for ; Sun, 26 Feb 2017 17:08:49 -0800 (PST)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 1851A129544 for ; Sun, 26 Feb 2017 17:08:49 -0800 (PST)
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Sun, 26 Feb 2017 16:58:42 -0800
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <59d7939c-d4c5-b74a-e960-3234f0524b39@omnitor.se>
References: <148782279664.31054.8793649134696520241.idtracker@ietfa.amsl.com>  <49fd730e-6e90-1a49-eae8-80f8b1285a76@omnitor.se>  <83152ba7-c3fb-25d8-f97d-59c7840cad56@omnitor.se>  <4b36f347-955e-e2b9-12f2-f426d47d3d33@omnitor.se> <59d7939c-d4c5-b74a-e960-3234f0524b39@omnitor.se>
X-Mailer: Eudora for Mac OS X
Date: Sun, 26 Feb 2017 17:01:10 -0800
To: Gunnar =?iso-8859-1?Q?Hellstr=F6m?=  , slim@ietf.org, Bernard Aboba 
From: Randall Gellens 
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
Archived-At: 
Subject: Re: [Slim] I-D Action: draft-ietf-slim-negotiating-human-language-07.txt
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Feb 2017 01:08:50 -0000

At 8:38 AM +0100 2/26/17, Gunnar Hellstr=F6m wrote:

>  Randall,
>
>  One more clarification for issue 12 - the=20
> asterisk placement as a preference hint:
>
>  You say:
>
>  " it seems better for the answerer to include=20
> all media and languages from the offer that it=20
> can support. "
>
>  You are right. I misread this paragraph in section 5.2:
>  " In an answer, 'humintlang-send' is the language the answerer will
>  send (which in most cases is one of the languages in the offer's
>  'humintlang-recv'), and 'humintlang-recv' is the language the
>  answerer expects to receive (which in most cases is one of the
>  languages in the offer's 'humintlang-send')."
>
>  That gave me the impression that I need to=20
> answer with only one language per direction in=20
> the whole SDP.

It's per media.


>  But in the first paragraph of 5.2, it is said: "to negotiate
>  which human language is used in each interactive media stream. "
>
>  So, we are allowed to include more than one=20
> language per direction in the SDP, but the=20
> users are not expected to use more than one=20
> language per direction, at least initially in=20
> the call.

There's nothing in the protocol that says=20
anything about people using more than one media=20
in each direction.


>  (that makes the wording "will send" and=20
> "expects to receive" in the cited paragraph a=20
> bit misleading, because as you point out, some=20
> of them might never be used. "is prepared to=20
> send" and "can accept to receive" might better=20
> correspond to what it means. Ending the=20
> sentence with "per media steram" might also=20
> help to remind the reader about the semantics.=20
> I leave to you to change these if you want.)

OK, I'm happy to add the additional clarification.  The paragraph now reads:

    In an answer, 'hlang-send' is the language the answerer will send
    when using the media (which in most cases is one of the languages in
    the offer's 'hlang-recv'), and 'hlang-recv' is the language the
    answerer expects to receive in the media (which in most cases is one
    of the languages in the offer's 'hlang-send').



>  Den 2017-02-26 kl. 07:46, skrev Gunnar Hellstr=F6m:
>
>>  Den 2017-02-25 kl. 20:58, skrev Randall Gellens:
>>
>>>  Hi Gunnar,
>>>
>>>  At 11:04 AM +0100 2/25/17, Gunnar Hellstr=F6m wrote:
>>>
>>>>  Fine, I find that we have only issues 5, 6 and 12 still to discuss.
>>>>
>>>>  You did not answer issue 6, use of=20
>>>> asymmetrical language rather than=20
>>>> unidirectional media. I assume you accepted=20
>>>> it.
>>>>
>>>
>>>  Yes, I thought I had indicated that, sorry if I didn't.
>>>
>>  Good.
>>
>>>
>>>>
>>>>  On 5, the request to reinsert wording about=20
>>>> seeing the speaker in video, it is still a=20
>>>> huge difference in specifying a preference=20
>>>> to see the speaker for language perception=20
>>>> reasons, versus only specifying that I want=20
>>>> a video stream for supplementary purposes.=20
>>>> With the current wording in version -07,=20
>>>> section 5.3 says that that combination is=20
>>>> undefined. Nothing in the LC discussion=20
>>>> indicated that it should be undefined. Why=20
>>>> did you suddenly want to delete it? It is=20
>>>> useful. Please reinsert with the wording=20
>>>> changes I propose.
>>>>
>>>
>>>  The email discussion led me to believe that=20
>>> the text was controversial. We need to get=20
>>> the draft finished, so it's better to delete=20
>>> controversial text than to spend months=20
>>> fighting about it.
>>>
>>  The comments were first about the uncertainty=20
>> about how the "silly states" were to be=20
>> interpreted.
>>  We described them all but decided to only keep=20
>> the view of the speaker because it is a real=20
>> and useful case.
>>  The idea to differentiate spoken and written=20
>> cases by script tags caused discussions and=20
>> was dropped. The remaining real case with the=20
>> view of the speaker was mentioned twice in the=20
>> draft, so it was recommended that one of them=20
>> should be deleted, but not both.
>>
>>>
>>>>
>>>>  On 12, the meaning of the placement of the asterisk, you ask:
>>>>  "Making the asterisk a purely-advisory hint=20
>>>> as to the least-preferred media/language=20
>>>> combination seems harmless enough, as it=20
>>>> would not be required to support it;=20
>>>> however, I'm not sure it provides any=20
>>>> benefit: if an offer contains some set of=20
>>>> media with language, and the answerer can=20
>>>> support all of them, should the answerer=20
>>>> only include in its answer those without an=20
>>>> asterisk? It seems simpler for the answerer=20
>>>> to include everything in the offer that it=20
>>>> can support."
>>>>
>>>>  The answering party should aim at answering=20
>>>> with one of the languages that is without=20
>>>> the asterisk in the offer. Only if the=20
>>>> answering party does not have capability in=20
>>>> a language without an asterisk, one with=20
>>>> asterisk should be selected. Thereby you get=20
>>>> the best opportunity to start the call in a=20
>>>> language combination that satisfies both=20
>>>> users.
>>>>
>>>>  Example: A hard-of-hearing user can just=20
>>>> barely conduct spoken calls with persons she=20
>>>> knows. From others it is much more reliable=20
>>>> to get text. She calls and declares:
>>>>
>>>>  m=3Daudio
>>>>  a=3Dhuml-send:en
>>>>  a=3Dhuml-recv:en*
>>>>  m=3Dtext
>>>>  a=3Dhuml-recv:en
>>>>
>>>>  The answering party with text capabilities=20
>>>> sees that matching text for sending is=20
>>>> higher preferred than talking, and thus=20
>>>> responds:
>>>>
>>>>  m=3Daudio
>>>>  a=3Dhuml-recv:en
>>>>  m=3Dtext
>>>>  a=3Dhuml-send:en
>>>>
>>>>  The answering party sends the initial=20
>>>> greeting in text and the call continues=20
>>>> smoothly in well managed langauage/modality=20
>>>> combinations.
>>>>
>>>>  Another called party may not have text=20
>>>> capabilities, and may therefore select the=20
>>>> less favoured alternative with using speech=20
>>>> both ways, answering:
>>>>
>>>>  m=3Daudio
>>>>  a=3Dhuml-recv:en
>>>>  a=3Dhuml-send:en
>>>>  m=3Dtext 0
>>>>
>>>>  The answering party starts taking and the=20
>>>> parties try as well as possible to manage=20
>>>> the call in this less preferred combination=20
>>>> that may be less reliable.
>>>>
>>>>  If the placement of the asterisk had no=20
>>>> special meaning as it is in version -07, it=20
>>>> is a high risk that the answering party in=20
>>>> the first example would select to answer=20
>>>> with spoken language that would be=20
>>>> unreliably received. Time and effort would=20
>>>> be spent by speech to make the answering=20
>>>> party switch to sending text instead of=20
>>>> talking in order to arrange for a more=20
>>>> reliable call situation.
>>>>
>>>>  If instead the caller only indicated the most favoured combinations,
>>>>
>>>>  m=3Daudio
>>>>  a=3Dhuml-send:en
>>>>  m=3Dtext
>>>>  a=3Dhuml-recv:en
>>>>
>>>>  Then the answering parties without text=20
>>>> capability would not dare to try to answer,=20
>>>> and a reasonably successful call would be=20
>>>> missed.
>>>>
>>>>  Many other similar realistic examples can be=20
>>>> created, where placement of the asterisk(s)=20
>>>> would be a sufficient indication of lower=20
>>>> preference for language match among=20
>>>> alternatives that would make call=20
>>>> establishment successful and smooth in many=20
>>>> more cases than without this indication=20
>>>> opportunity.
>>>>
>>>>  Do you want more examples?
>>>>
>>>>  Please accept proposal 12.
>>>>
>>>
>>>  This convinces me that we cannot accept the=20
>>> proposed text, as it would introduce=20
>>> complexity that the WG explicitly decided to=20
>>> not pursue in this draft. In the examples you=20
>>> provided, it seems better for the answerer to=20
>>> include all media and languages from the=20
>>> offer that it can support. This is much=20
>>> simpler, has only trivial drawbacks (extra=20
>>> media negotiated that might not be used), and=20
>>> is what the WG agreed to.
>>>
>>  Yes, you could let the answer SDP contain one=20
>> common language per media and direction, but=20
>> the answering human need guidance on which=20
>> language is best suited to start the=20
>> conversation. Therefore the placement of the=20
>> asterisk is used to hint the answering party=20
>> how to start the call.
>>
>>  The first example above can be modified to:
>>
>>  Example: A hard-of-hearing user can just=20
>> barely conduct spoken calls with persons she=20
>> knows. From others it is much more reliable to=20
>> get text. She calls and declares:
>>
>>  m=3Daudio
>>  a=3Dhuml-send:en
>>  a=3Dhuml-recv:en*
>>  m=3Dtext
>>  a=3Dhuml-recv:en
>>
>>  The answering party with capabilities for both=20
>> written and spoken English sees that matching=20
>> text for sending is higher preferred than=20
>> talking and sends the answer indicating the=20
>> capabilities:
>>
>>  m=3Daudio
>>  a=3Dhuml-recv:en
>>  a=3Dhuml-send:en
>>  m=3Dtext
>>  a=3Dhuml-send:en
>>
>>  The answering party makes use of the hint that=20
>> the caller prefers to receive written text and=20
>> therefore sends the initial greeting in text=20
>> and the call continues smoothly in well=20
>> managed langauage/modality combinations.
>>
>>  ----------
>>  There is no complexity left in this solution,=20
>> it helps to motivate why we have the asterisk=20
>> on media level, and it helps to successful=20
>> call initiations, so I think it should be=20
>> acceptable.
>>
>>  Gunnar
>>
>>>
>>>  --Randy
>>>
>>>>  Den 2017-02-25 kl. 01:32, skrev Randall Gellens:
>>>>
>>>>>  At 5:35 PM +0100 2/24/17, Gunnar Hellstr=F6m wrote:
>>>>>
>>>>>>  Den 2017-02-23 kl. 05:15, skrev Randall Gellens:
>>>>>>
>>>>>>>  Version -07 addresses all comments except=20
>>>>>>> for the unresolved issue of renaming the=20
>>>>>>> two attributes which is currently being=20
>>>>>>> discussed on the list, and adding a new=20
>>>>>>> attribute for bidirectionality.
>>>>>>>
>>>>>>>  Per Dale's suggestion, the draft adds=20
>>>>>>> advice that if a call is rejected due to=20
>>>>>>> no languages in common, SIP response code=20
>>>>>>> 488 (Not Acceptable Here) or 606 (Not=20
>>>>>>> Acceptable) be used, along with a Warning=20
>>>>>>> header field indicating the supported=20
>>>>>>> languages. The draft registers a new=20
>>>>>>> entry in the warn-code sub-registry of=20
>>>>>>> SIP parameters for this purpose. The=20
>>>>>>> draft also has an expanded set of=20
>>>>>>> examples.
>>>>>>>
>>>>>>  Good progress. Good to see the enriched examples chapter 5.5.
>>>>>>  I have a few comments on version -07:
>>>>>>
>>>>>>  1. Section 4. second line
>>>>>>  ------------old text----------------------
>>>>>>  but is not sufficiently sufficiently
>>>>>>  ------------new text--------------------------
>>>>>>  but is not sufficiently
>>>>>>  ----------end of change 1-----------------
>>>>>>  Motivation: New typo in version -07
>>>>>>
>>>>>
>>>>>  Thanks.
>>>>>
>>>>>>
>>>>>>  2. Section 5.2, first line
>>>>>>  ----------------old text-----------------
>>>>>>  This document defines two new media-level ..
>>>>>>  ----------------new text----------------------
>>>>>>  This document defines two media-level ...
>>>>>>  ----------------end of change 2----------------
>>>>>>  Motivation: It was commented that when the=20
>>>>>> draft is published, this is not new=20
>>>>>> anymore.
>>>>>>  There are three more occasions of "new" in=20
>>>>>> the document that may be modified as well.
>>>>>>
>>>>>
>>>>>  OK.
>>>>>
>>>>>>
>>>>>>  3. 5.2 second paragraph
>>>>>>  -------------------old text--------------------------------
>>>>>>  In an offer, the 'humintlang-send' values indicates the language(s)
>>>>>>  the offerer is willing to use when sending using the media, and the
>>>>>>  'humintlang-recv' values indicates the language(s) the offerer is
>>>>>>  willing to use when receiving using the media.
>>>>>>  -----------------new text---------------------------------
>>>>>>  In an offer, the 'humintlang-send' values indicate the language(s)
>>>>>>  the offerer is willing to select from for use when sending using the
>>>>>>  media, and the 'humintlang-recv' values indicate the language(s) the
>>>>>>  offerer is willing to receive one of in the media stream.
>>>>>>  ----------------end of change----------------------------------
>>>>>>  Motivation 1:) change from "indicates" to=20
>>>>>> "indicate" in two places to match the new=20
>>>>>> use of plural "values".
>>>>>>  Motivation 2:) Be sure to indicate that we=20
>>>>>> only intend to negotiate one language per=20
>>>>>> media and direction, so that we do not end=20
>>>>>> up as unspecified regarding number of=20
>>>>>> matches required as the sdp "lang"=20
>>>>>> attribute is.
>>>>>>
>>>>>
>>>>>  Reworded.
>>>>>
>>>>>>
>>>>>>  4. 5.2 Second paragraph
>>>>>>  -----------------old text-----------------------
>>>>>>  When a media is intended
>>>>>>  for use in one direction only
>>>>>>  ----------------new text---------------------
>>>>>>  When a media is intended
>>>>>>  for use for language communication in one direction only
>>>>>>  ----------------end of change---------------------------
>>>>>>  Motivation: Deletion of a note in this=20
>>>>>> sentence made it less obvious that we are=20
>>>>>> only talking about directions of use of=20
>>>>>> language communication, and not about=20
>>>>>> establishing asymmetric media connections.=20
>>>>>> Therefore add this clarification.
>>>>>>
>>>>>
>>>>>  Reworded.
>>>>>
>>>>>>
>>>>>>  5. 5.2 Deleted paragraph 6 before "Clients acting on behalf..."
>>>>>>  ----------reinsert modified paragraph----------------------------
>>>>>>  While signed language tags are used with a video stream to
>>>>>>  indicate sign language, a spoken language tag for a video stream
>>>>>>  indicates a request or offer to see the speaker, when that is of
>>>>>>  importance for language perception.
>>>>>>  -------------end of change------------------------------------------=
-
>>>>>>  Motivation: There was in the LC mail=20
>>>>>> exchange a discussion about sharpening up=20
>>>>>> the specification of use of "unusual=20
>>>>>> combinations".
>>>>>>  There was no agreement to delete them all.=20
>>>>>> The one described in this paragraph is the=20
>>>>>> main one that has widespread use and needs=20
>>>>>> to be clearly specified for use by a large=20
>>>>>> number of hard-of-hearing and deaf users.
>>>>>>
>>>>>
>>>>>  The text as it is now does not prohibit=20
>>>>> anything and explicitly mentions=20
>>>>> negotiating supplemental video by omitting=20
>>>>> language attributes on a video media.
>>>>>
>>>>>>
>>>>>>  6. 5.2 Sixth paragraph
>>>>>>  --------------------current text--------------------
>>>>>>  (or for unidirectional streams, one of)
>>>>>>  ------------------new text ------------------------
>>>>>>  (or for asymmetrical use of languages, one of)
>>>>>>  -----------------end of change----------------------
>>>>>>  Motivation: We are not primarily talking=20
>>>>>> about enabled transmission directions of=20
>>>>>> the streams, but about language use in the=20
>>>>>> streams. We do not want to limit the media=20
>>>>>> stream directions just because we do not=20
>>>>>> specify an initial language to use for=20
>>>>>> that direction. There are other usage of=20
>>>>>> media, and there may even be occasional=20
>>>>>> use of language in the direction, just not=20
>>>>>> worth mentioning as an initial and=20
>>>>>> preferred use. The suggested change should=20
>>>>>> make that clear.
>>>>>>
>>>>>>  7. 5.3 Next to last paragraph
>>>>>>  ------------------old text------------------------------
>>>>>>  a list of supported languages.
>>>>>>  -------------------new text-------------------------
>>>>>>  a list of supported languages, media and directions.
>>>>>>  -------------------end of change----------------
>>>>>>  Motivation: It is not sufficient to know=20
>>>>>> which languages are supported, it is also=20
>>>>>> essential to know in which media they are=20
>>>>>> supported and in which directions. (media=20
>>>>>> could be replaced with modality, but the=20
>>>>>> media can become ambigous then, so use=20
>>>>>> media here to be brief.
>>>>>>
>>>>>
>>>>>  I don't know that we can require this, but=20
>>>>> I'll add SHOULD kist supported languages=20
>>>>> and media. Demanding direction as well=20
>>>>> might be too unwieldy.
>>>>>
>>>>>>
>>>>>>  8. 5.3, last line
>>>>>>  --------------old text----------------------------------
>>>>>>  Supported languages are: es, en"
>>>>>>  --------------new text-------------------------------
>>>>>>  Supported languages are: es, en=20
>>>>>> transmission in audio; es, en reception in=20
>>>>>> audio"
>>>>>>  ----------------------------------------------------------
>>>>>>  Motivation: Same as for 7.
>>>>>>
>>>>>
>>>>>  Fixed as above.
>>>>>
>>>>>>
>>>>>>  9. 5.4 Undefined combinations
>>>>>>  ----------------------------old=20
>>>>>> text--------------------------------------
>>>>>>  The behavior when specifying a non-signed language tag for a video
>>>>>>  media stream, or a signed language tag for an audio or text media
>>>>>>  stream, is not defined.
>>>>>>  ---------------------------new=20
>>>>>> text-----------------------------------------
>>>>>>  There is no way specified for indicating=20
>>>>>> use of text based language in a video=20
>>>>>> media stream.
>>>>>>  There is no meaning assigned to=20
>>>>>> specification of sign language in an audio=20
>>>>>> or text media stream.
>>>>>>  --------------------------end of change-----------------------------=
--
>>>>>>  Motivation: Seeing the speaker in video is=20
>>>>>> an important combination reinserted above=20
>>>>>> in section 5.2.
>>>>>>  This section therefore needed rewording to not include that combinat=
ion.
>>>>>>
>>>>>
>>>>>  The draft explicitly mentions video for supplemental purposes.
>>>>>
>>>>>>
>>>>>>
>>>>>>  10. 6.2 Last sentence
>>>>>>  -----------------current text---------------------
>>>>>>  Supported languages are: [list of supported languages]."
>>>>>>  -----------------new text------------------------
>>>>>>  Supported languages and media and=20
>>>>>> transmission directions are:[list of=20
>>>>>> supported languages and media and=20
>>>>>> transmission directions.]"
>>>>>>  -----------------end of change--------------------------
>>>>>>  Motivation: Same as for 7.
>>>>>>
>>>>>
>>>>>  Fixed as above.
>>>>>
>>>>>>
>>>>>>  11. 6.1 MUX Category
>>>>>>  ----------old text in two locations-------------------
>>>>>>  MUX Category: normal
>>>>>>  ---------new text in same two locations--------------
>>>>>>  Mux Category: NORMAL
>>>>>>  ---------end of change-----------------
>>>>>>  Motivation: Follow RFC 4566bis and IANA habits regarding use of capi=
tals
>>>>>>
>>>>>
>>>>>  Fixed.
>>>>>
>>>>>>
>>>>>>  12. 5.3
>>>>>>  -------------old text-----------------
>>>>>>  5.3 No Language in Common
>>>>>>  -------------new text----------------
>>>>>>  5.3 Preference parameter
>>>>>>  ------------end of change 1 in 5.3---------------
>>>>>>
>>>>>
>>>>>  The section is more than just the asterisk,=20
>>>>> it also advises use of specific SIP=20
>>>>> response codes if the call is failed.
>>>>>
>>>>>>
>>>>>>  -------------old text-in 5.3, second=20
>>>>>> paragraph-------------------------------
>>>>>>  The mechanism for indicating this preference is that, in an offer, i=
f
>>>>>>  the last character of any of the 'humintlang-recv' or 'humintlang-
>>>>>>  send' values is an asterisk, this=20
>>>>>> indicates a request to not fail the call.
>>>>>>  --------------------------new text-------------------------------
>>>>>>  The mechanism for indicating this preference is that, in an offer, i=
f
>>>>>>  the last character of any of the 'humintlang-recv' or 'humintlang-
>>>>>>  send' values is an asterisk, this=20
>>>>>> indicates a request to not fail the call.
>>>>>>  The asterisk should be attached to attributes with languages of lowe=
r
>>>>>>  preference to be matched if such difference can be specified. Thereb=
y
>>>>>>  the location of the asterisk can be used to support the decision on
>>>>>>  which languages to use in the call.
>>>>>>  ---------------------------end of change 2=20
>>>>>> in=20
>>>>>> 5.3--------------------------------------
>>>>>>  Motivation: There has not yet been any=20
>>>>>> conclusion for my proposal no 5 in the=20
>>>>>> IETF LC comments of Feb 12.
>>>>>>  This is a dramatically reduced version=20
>>>>>> that may be easier to accept at this=20
>>>>>> stage, still covering one of the missing=20
>>>>>> functionalities in the draft.
>>>>>>  The asterisk is used as a preference=20
>>>>>> parameter in the attributes. Thereby the=20
>>>>>> proposed title change on 5.3
>>>>>>  With this additional rule about where the=20
>>>>>> asterisk(s) are placed, the answering=20
>>>>>> parties get good clues about the=20
>>>>>> preferences between alternatives presented=20
>>>>>> by the offeror. The chance to set up calls=20
>>>>>> with satisfied users increase dramatically=20
>>>>>> compared to letting the answering party=20
>>>>>> select by chance between alternatives.
>>>>>>
>>>>>
>>>>>  Making the asterisk a purely-advisory hint=20
>>>>> as to the least-preferred media/language=20
>>>>> combination seems harmless enough, as it=20
>>>>> would not be required to support it;=20
>>>>> however, I'm not sure it provides any=20
>>>>> benefit: if an offer contains some set of=20
>>>>> media with language, and the answerer can=20
>>>>> support all of them, should the answerer=20
>>>>> only include in its answer those without an=20
>>>>> asterisk? It seems simpler for the answerer=20
>>>>> to include everything in the offer that it=20
>>>>> can support.
>>>>>
>>>>
>>>>  --
>>>>  -----------------------------------------
>>>>  Gunnar Hellstr=F6m
>>>>  Omnitor
>>>>  gunnar.hellstrom@omnitor.se
>>>>  +46 708 204 288
>>>>
>>>
>>>
>>
>
>  --
>  -----------------------------------------
>  Gunnar Hellstr=F6m
>  Omnitor
>  gunnar.hellstrom@omnitor.se
>  +46 708 204 288


-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
I would suggest that there is s very significant danger that
they have listened to us!
    --Comments during a Federal Open Market Committee meeting in 2004


From nobody Mon Feb 27 00:01: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 289A8129BD9 for ; Mon, 27 Feb 2017 00:01:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, 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 QecbMZzD4jE9 for ; Mon, 27 Feb 2017 00:01:20 -0800 (PST)
Received: from bin-vsp-out-02.atm.binero.net (vsp-unauthed02.binero.net [195.74.38.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B043A126CD8 for ; Mon, 27 Feb 2017 00:01:19 -0800 (PST)
X-Halon-ID: e50e311e-fcc2-11e6-af93-005056917f90
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [77.53.231.21]) by bin-vsp-out-02.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Mon, 27 Feb 2017 09:01:07 +0100 (CET)
To: Randall Gellens , slim@ietf.org, Natasha Rooney , Bernard Aboba , "Phillips, Addison" 
References: <148782279664.31054.8793649134696520241.idtracker@ietfa.amsl.com>  <49fd730e-6e90-1a49-eae8-80f8b1285a76@omnitor.se>  <83152ba7-c3fb-25d8-f97d-59c7840cad56@omnitor.se>  <4b36f347-955e-e2b9-12f2-f426d47d3d33@omnitor.se> 
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: <7f844aaa-17ce-2ab7-0602-a999a40235de@omnitor.se>
Date: Mon, 27 Feb 2017 09:01:10 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
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] I-D Action: draft-ietf-slim-negotiating-human-language-07.txt
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Feb 2017 08:01:23 -0000

Randall,
good to see that we are converging,
Den 2017-02-27 kl. 01:55, skrev Randall Gellens:
> At 7:46 AM +0100 2/26/17, Gunnar Hellström wrote:
>
>>  Den 2017-02-25 kl. 20:58, skrev Randall Gellens:
>>>  Hi Gunnar,
>>>
>>>  At 11:04 AM +0100 2/25/17, Gunnar Hellström wrote:
>>>
>>>>   Fine, I find that we have only issues 5, 6 and 12 still to discuss.
>>>>
>>>>   You did not answer issue 6, use of asymmetrical language rather 
>>>> than unidirectional media. I assume you accepted it.
>>>
>>>  Yes, I thought I had indicated that, sorry if I didn't.
>>  Good.
>>>
>>>>
>>>>   On 5, the request to reinsert wording about seeing the speaker in 
>>>> video, it is still a huge difference in specifying a preference to 
>>>> see the speaker for language perception reasons, versus only 
>>>> specifying that I want a video stream for supplementary purposes. 
>>>> With the current wording in version -07, section 5.3 says that that 
>>>> combination is undefined. Nothing in the LC discussion indicated 
>>>> that it should be undefined. Why did you suddenly want to delete 
>>>> it? It is useful. Please reinsert with the wording changes I propose.
>>>
>>>  The email discussion led me to believe that the text was 
>>> controversial.  We need to get the draft finished, so it's better to 
>>> delete controversial text than to spend months fighting about it.
>>  The comments were first about the uncertainty about how the "silly 
>> states" were to be interpreted.
>>  We described them all but decided to only keep the view of the 
>> speaker because it is a real and useful case.
>>  The idea to differentiate spoken and written cases by script tags 
>> caused discussions and was dropped. The remaining real case with the 
>> view of the speaker was mentioned twice in the draft, so it was 
>> recommended that one of them should be deleted, but not both.
>
> OK, I'll restore the text in section 5.2:
>
>    Note that while signed language tags are used with a video stream to
>    indicate sign language, a spoken language tag for a video stream in
>    parallel with an audio stream with the same spoken language tag
>    indicates a request for a supplemental video stream to see the
>    speaker.
>
> And modify section 5.4 to exclude this case:
>
>    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.
Addison did not like the expression "spoken/written language tag" when 
we used it in the discussion about section 5.4.
We may get the same reaction here.
You would have avoided it if you took my wording proposal as it was.
>
>
>>>
>>>>
>>>>   On 12, the meaning of the placement of the asterisk, you ask:
>>>>   "Making the asterisk a purely-advisory hint as to the 
>>>> least-preferred media/language combination seems harmless enough, 
>>>> as it would not be required to support it; however, I'm not sure it 
>>>> provides any benefit: if an offer contains some set of media with 
>>>> language, and the answerer can support all of them, should the 
>>>> answerer only include in its answer those without an asterisk? It 
>>>> seems simpler for the answerer to include everything in the offer 
>>>> that it can support."
>>>>
>>>>   The answering party should aim at answering with one of the 
>>>> languages that is without the asterisk in the offer. Only if the 
>>>> answering party does not have capability in a language without an 
>>>> asterisk, one with asterisk should be selected. Thereby you get the 
>>>> best opportunity to start the call in a language combination that 
>>>> satisfies both users.
>>>>
>>>>   Example: A hard-of-hearing user can just barely conduct spoken 
>>>> calls with persons she knows. From others it is much more reliable 
>>>> to get text.  She calls and declares:
>>>>
>>>>   m=audio
>>>>   a=huml-send:en
>>>>   a=huml-recv:en*
>>>>   m=text
>>>>   a=huml-recv:en
>>>>
>>>>   The answering party with text capabilities sees that matching 
>>>> text for sending is higher preferred than talking, and thus responds:
>>>>
>>>>   m=audio
>>>>   a=huml-recv:en
>>>>   m=text
>>>>   a=huml-send:en
>>>>
>>>>   The answering party sends the initial greeting in text and the 
>>>> call continues smoothly in well managed langauage/modality 
>>>> combinations.
>>>>
>>>>   Another called party may not have text capabilities, and may 
>>>> therefore select the less favoured alternative with using speech 
>>>> both ways, answering:
>>>>
>>>>   m=audio
>>>>   a=huml-recv:en
>>>>   a=huml-send:en
>>>>   m=text 0
>>>>
>>>>   The answering party starts taking and the parties try as well as 
>>>> possible to manage the call in this less preferred combination that 
>>>> may be less reliable.
>>>>
>>>>   If the placement of the asterisk had no special meaning as it is 
>>>> in version -07, it is a high risk that the answering party in the 
>>>> first example would select to answer with spoken language that 
>>>> would be unreliably received. Time and effort would be spent by 
>>>> speech to make the answering party switch to sending text instead 
>>>> of talking in order to arrange for a more reliable call situation.
>>>>
>>>>   If instead the caller only indicated the most favoured combinations,
>>>>
>>>>   m=audio
>>>>   a=huml-send:en
>>>>   m=text
>>>>   a=huml-recv:en
>>>>
>>>>   Then the answering parties without text capability would not dare 
>>>> to try to answer, and a reasonably successful call would be missed.
>>>>
>>>>   Many other similar realistic examples can be created, where 
>>>> placement of the asterisk(s) would be a sufficient indication of 
>>>> lower preference for language match among alternatives that would 
>>>> make call establishment successful and smooth in many more cases 
>>>> than without this indication opportunity.
>>>>
>>>>   Do you want more examples?
>>>>
>>>>   Please accept proposal 12.
>>>
>>>  This convinces me that we cannot accept the proposed text, as it 
>>> would introduce complexity that the WG explicitly decided to not 
>>> pursue in this draft.  In the examples you provided, it seems better 
>>> for the answerer to include all media and languages from the offer 
>>> that it can support.  This is much simpler, has only trivial 
>>> drawbacks (extra media negotiated that might not be used), and is 
>>> what the WG agreed to.
>>  Yes, you could let the answer SDP contain one common language per 
>> media and direction, but the answering human need guidance on which 
>> language is best suited to start the conversation. Therefore the 
>> placement of the asterisk is used to hint the answering party how to 
>> start the call.
>
> I believe the WG discussed proposals to provide information to the 
> humans regarding the languages and media that were negotiated, and 
> decided it is out of scope of the draft as an implementation issue, 
> not a protocol issue.
Yes, we did, and said that the mechanism for providing the result of the 
indication and negotiation to the user is out of scope, but the 
resulting information needs to be provided to the user. It is the user 
who generates language and the user needs to know the most preferred 
common languages so that the user can start the call in an appropriate 
language.
This is valid for the language as well as the preference indication.

And we say that by the end of section 1. " Both sides should be aware of 
which language was negotiated."    No mechanism specified, but the 
result needs to be conveyed to the user.

Now, when there is no required protocol influence implied by the 
placement of the asterisk, all feared complexity is gone and only the 
huge increase in usability remains.

It is not fair that users who want to express preference between 
languages in a single modality can do it, but users who have preferences 
between languages in different modalities cannot indicate that. Let us 
cover that gap when it is so free from complexity to do it.

>
>>
>>  The first example above can be modified to:
>>
>>   Example: A hard-of-hearing user can just barely conduct spoken 
>> calls with persons she knows. From others it is much more reliable to 
>> get text.  She calls and declares:
>>
>>   m=audio
>>   a=huml-send:en
>>   a=huml-recv:en*
>>   m=text
>>   a=huml-recv:en
>>
>>   The answering party with capabilities for both written and spoken 
>> English sees that matching text for sending is higher preferred than 
>> talking and sends the answer indicating the capabilities:
>>
>>   m=audio
>>   a=huml-recv:en
>>  a=huml-send:en
>>   m=text
>>   a=huml-send:en
>>
>>   The answering party makes use of the hint that the caller prefers 
>> to receive written text and therefore sends the initial greeting in 
>> text and the call continues smoothly in well managed 
>> langauage/modality combinations.
>>
>>  ----------
>>  There is no complexity left in this solution, it helps to motivate 
>> why we have the asterisk on media level, and it helps to successful 
>> call initiations, so I think it should be acceptable.
>
> My suggestion is that you write this idea as a new draft offering 
> implementation guidance, and ask the WG to adopt it as either 
> Informational or BCP.  It doesn't affect the protocol in the current 
> draft, but provides guidance on how to use the protocol in both an 
> offer and an answer and potentially in the UI.
I suggest that the chairs and area director assign a procedure suitable 
for the current state of the draft to potentially include the meaning of 
the placement of the asterisk as proposed in my issue 12.

Thanks
Gunnar
>
>
>
>>>
>>>>   Den 2017-02-25 kl. 01:32, skrev Randall Gellens:
>>>>>   At 5:35 PM +0100 2/24/17, Gunnar Hellström wrote:
>>>>>
>>>>>>    Den 2017-02-23 kl. 05:15, skrev Randall Gellens:
>>>>>>>    Version -07 addresses all comments except for the unresolved 
>>>>>>> issue of renaming the two attributes which is currently being 
>>>>>>> discussed on the list, and adding a new attribute for 
>>>>>>> bidirectionality.
>>>>>>>
>>>>>>>    Per Dale's suggestion, the draft adds advice that if a call 
>>>>>>> is rejected due to no languages in common, SIP response code 488 
>>>>>>> (Not Acceptable Here) or 606 (Not Acceptable) be used, along 
>>>>>>> with a Warning header field indicating the supported languages.  
>>>>>>> The draft registers a new entry in the warn-code sub-registry of 
>>>>>>> SIP parameters for this purpose.  The draft also has an expanded 
>>>>>>> set of examples.
>>>>>>>
>>>>>>    Good progress. Good to see the enriched examples chapter 5.5.
>>>>>>    I have a few comments on version -07:
>>>>>>
>>>>>>    1.  Section  4. second line
>>>>>>    ------------old text----------------------
>>>>>>    but is not sufficiently sufficiently
>>>>>>    ------------new text--------------------------
>>>>>>    but is not sufficiently
>>>>>>    ----------end of change 1-----------------
>>>>>>    Motivation: New typo in version -07
>>>>>
>>>>>   Thanks.
>>>>>
>>>>>>
>>>>>>    2. Section 5.2, first line
>>>>>>    ----------------old text-----------------
>>>>>>    This document defines two new media-level ..
>>>>>>    ----------------new text----------------------
>>>>>>    This document defines two media-level ...
>>>>>>    ----------------end of change 2----------------
>>>>>>    Motivation: It was commented that when the draft is published, 
>>>>>> this is not new anymore.
>>>>>>    There are three more occasions of "new" in the document that 
>>>>>> may be modified as well.
>>>>>
>>>>>   OK.
>>>>>
>>>>>>
>>>>>>    3.  5.2 second paragraph
>>>>>>    -------------------old text--------------------------------
>>>>>>    In an offer, the 'humintlang-send' values indicates the 
>>>>>> language(s)
>>>>>>       the offerer is willing to use when sending using the media, 
>>>>>> and the
>>>>>>       'humintlang-recv' values indicates the language(s) the 
>>>>>> offerer is
>>>>>>       willing to use when receiving using the media.
>>>>>>    -----------------new text---------------------------------
>>>>>>    In an offer, the 'humintlang-send' values indicate the 
>>>>>> language(s)
>>>>>>    the offerer is willing to select from for use when sending 
>>>>>> using the
>>>>>>    media, and the 'humintlang-recv' values indicate the 
>>>>>> language(s) the
>>>>>>    offerer is willing to receive one of in the media stream.
>>>>>>    ----------------end of change----------------------------------
>>>>>>    Motivation 1:) change from "indicates" to "indicate" in two 
>>>>>> places to match the new use of plural "values".
>>>>>>    Motivation 2:) Be sure to indicate that we only intend to 
>>>>>> negotiate one language per media and direction, so that we do not 
>>>>>> end up as unspecified regarding number of matches required as the 
>>>>>> sdp "lang" attribute is.
>>>>>
>>>>>   Reworded.
>>>>>
>>>>>>
>>>>>>    4.  5.2 Second paragraph
>>>>>>    -----------------old text-----------------------
>>>>>>    When a media is intended
>>>>>>       for use in one direction only
>>>>>>    ----------------new text---------------------
>>>>>>    When a media is intended
>>>>>>       for use for language communication in one direction only
>>>>>>    ----------------end of change---------------------------
>>>>>>    Motivation: Deletion of a note in this sentence made it less 
>>>>>> obvious that we are only talking about directions of use of 
>>>>>> language communication, and not about establishing asymmetric 
>>>>>> media connections. Therefore add this clarification.
>>>>>
>>>>>   Reworded.
>>>>>
>>>>>>
>>>>>>    5.  5.2 Deleted paragraph 6 before "Clients acting on behalf..."
>>>>>>    ----------reinsert modified paragraph----------------------------
>>>>>>    While signed language tags are used with a video stream to
>>>>>>    indicate sign language, a spoken language tag for a video stream
>>>>>>    indicates a request or offer to see the speaker, when that is of
>>>>>>    importance for language perception.
>>>>>>    -------------end of 
>>>>>> change-------------------------------------------
>>>>>>    Motivation: There was in the LC mail exchange a discussion 
>>>>>> about sharpening up the specification of use of "unusual 
>>>>>> combinations".
>>>>>>    There was no agreement to delete them all. The one described 
>>>>>> in this paragraph is the main one that has widespread use and 
>>>>>> needs to be clearly specified for use by a large number of 
>>>>>> hard-of-hearing and deaf users.
>>>>>
>>>>>   The text as it is now does not prohibit anything and explicitly 
>>>>> mentions negotiating supplemental video by omitting language 
>>>>> attributes on a video media.
>>>>>
>>>>>>
>>>>>>    6.  5.2 Sixth paragraph
>>>>>>    --------------------current text--------------------
>>>>>>    (or for unidirectional streams, one of)
>>>>>>    ------------------new text ------------------------
>>>>>>    (or for asymmetrical use of languages, one of)
>>>>>>    -----------------end of change----------------------
>>>>>>    Motivation: We are not primarily talking about enabled 
>>>>>> transmission directions of the streams, but about language use in 
>>>>>> the streams. We do not want to limit the media stream directions 
>>>>>> just because we do not specify an initial language to use for 
>>>>>> that direction. There are other usage of media, and there may 
>>>>>> even be occasional use of language in the direction, just not 
>>>>>> worth mentioning as an initial and preferred use. The suggested 
>>>>>> change should make that clear.
>>>>>>
>>>>>>    7.   5.3 Next to last paragraph
>>>>>>    ------------------old text------------------------------
>>>>>>    a list of supported languages.
>>>>>>    -------------------new text-------------------------
>>>>>>    a list of supported languages, media and directions.
>>>>>>    -------------------end of change----------------
>>>>>>    Motivation: It is not sufficient to know which languages are 
>>>>>> supported, it is also essential to know in which media they are 
>>>>>> supported and in which directions. (media could be replaced with 
>>>>>> modality, but the media can become ambigous then, so use media 
>>>>>> here to be brief.
>>>>>
>>>>>   I don't know that we can require this, but I'll add SHOULD kist 
>>>>> supported languages and media. Demanding direction as well might 
>>>>> be too unwieldy.
>>>>>
>>>>>>
>>>>>>    8.      5.3, last line
>>>>>>    --------------old text----------------------------------
>>>>>>     Supported languages are: es, en"
>>>>>>    --------------new text-------------------------------
>>>>>>     Supported languages are: es, en transmission in audio; es, en 
>>>>>> reception in audio"
>>>>>> ----------------------------------------------------------
>>>>>>    Motivation: Same as for 7.
>>>>>
>>>>>   Fixed as above.
>>>>>
>>>>>>
>>>>>>    9.  5.4 Undefined combinations
>>>>>>    ----------------------------old 
>>>>>> text--------------------------------------
>>>>>>       The behavior when specifying a non-signed language tag for 
>>>>>> a video
>>>>>>       media stream, or a signed language tag for an audio or text 
>>>>>> media
>>>>>>       stream, is not defined.
>>>>>>    ---------------------------new 
>>>>>> text-----------------------------------------
>>>>>>    There is no way specified for indicating use of text based 
>>>>>> language in a video media stream.
>>>>>>    There is no meaning assigned to specification of sign language 
>>>>>> in an audio or text media stream.
>>>>>>    --------------------------end of 
>>>>>> change-------------------------------
>>>>>>    Motivation: Seeing the speaker in video is an important 
>>>>>> combination reinserted above in section 5.2.
>>>>>>    This section therefore needed rewording to not include that 
>>>>>> combination.
>>>>>
>>>>>   The draft explicitly mentions video for supplemental purposes.
>>>>>
>>>>>>
>>>>>>
>>>>>>    10.     6.2 Last sentence
>>>>>>    -----------------current text---------------------
>>>>>>    Supported languages are: [list of supported languages]."
>>>>>>    -----------------new text------------------------
>>>>>>    Supported languages and media and transmission directions 
>>>>>> are:[list of supported languages and media and transmission 
>>>>>> directions.]"
>>>>>>    -----------------end of change--------------------------
>>>>>>    Motivation: Same as for 7.
>>>>>
>>>>>   Fixed as above.
>>>>>
>>>>>>
>>>>>>    11.  6.1 MUX Category
>>>>>>    ----------old text in two locations-------------------
>>>>>>    MUX Category:  normal
>>>>>>    ---------new text in same two locations--------------
>>>>>>    Mux Category:  NORMAL
>>>>>>    ---------end of change-----------------
>>>>>>    Motivation: Follow RFC 4566bis and IANA habits regarding use 
>>>>>> of capitals
>>>>>
>>>>>   Fixed.
>>>>>
>>>>>>
>>>>>>    12.  5.3
>>>>>>    -------------old text-----------------
>>>>>>    5.3 No Language in Common
>>>>>>    -------------new text----------------
>>>>>>    5.3 Preference parameter
>>>>>>    ------------end of change 1 in 5.3---------------
>>>>>
>>>>>   The section is more than just the asterisk, it also advises use 
>>>>> of specific SIP response codes if the call is failed.
>>>>>
>>>>>>
>>>>>>    -------------old text-in 5.3, second 
>>>>>> paragraph-------------------------------
>>>>>>    The mechanism for indicating this preference is that, in an 
>>>>>> offer, if
>>>>>>    the last character of any of the 'humintlang-recv' or 
>>>>>> 'humintlang-
>>>>>>    send' values is an asterisk, this indicates a request to not 
>>>>>> fail the call.
>>>>>>    --------------------------new text-------------------------------
>>>>>>    The mechanism for indicating this preference is that, in an 
>>>>>> offer, if
>>>>>>       the last character of any of the 'humintlang-recv' or 
>>>>>> 'humintlang-
>>>>>>       send' values is an asterisk, this indicates a request to 
>>>>>> not fail the call.
>>>>>>    The asterisk should be attached to attributes with languages 
>>>>>> of lower
>>>>>>    preference to be matched if such difference can be specified. 
>>>>>> Thereby
>>>>>>    the location of the asterisk can be used to support the 
>>>>>> decision on
>>>>>>    which languages to use in the call.
>>>>>>    ---------------------------end of change 2 in 
>>>>>> 5.3--------------------------------------
>>>>>>    Motivation: There has not yet been any conclusion for my 
>>>>>> proposal no 5 in the IETF LC comments of Feb 12.
>>>>>>    This is a dramatically reduced version that may be easier to 
>>>>>> accept at this stage, still covering one of the missing 
>>>>>> functionalities in the draft.
>>>>>>    The asterisk is used as a preference parameter in the 
>>>>>> attributes. Thereby the proposed title change on 5.3
>>>>>>    With this additional rule about where the asterisk(s) are 
>>>>>> placed, the answering parties get good clues about the 
>>>>>> preferences between alternatives presented by the offeror. The 
>>>>>> chance to set up calls with satisfied users increase dramatically 
>>>>>> compared to letting the answering party select by chance between 
>>>>>> alternatives.
>>>>>
>>>>>   Making the asterisk a purely-advisory hint as to the 
>>>>> least-preferred media/language combination seems harmless enough, 
>>>>> as it would not be required to support it; however, I'm not sure 
>>>>> it provides any benefit: if an offer contains some set of media 
>>>>> with language, and the answerer can support all of them, should 
>>>>> the answerer only include in its answer those without an asterisk? 
>>>>> It seems simpler for the answerer to include everything in the 
>>>>> offer that it can support.
>>>>>
>>>>
>>>>   --
>>>>   -----------------------------------------
>>>>   Gunnar Hellström
>>>>   Omnitor
>>>>   gunnar.hellstrom@omnitor.se
>>>>   +46 708 204 288
>>>
>>>
>>
>>  --
>>  -----------------------------------------
>>  Gunnar Hellström
>>  Omnitor
>>  gunnar.hellstrom@omnitor.se
>>  +46 708 204 288
>
>

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


From nobody Mon Feb 27 05:37:54 2017
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFC45129FA6 for ; Mon, 27 Feb 2017 05:37:52 -0800 (PST)
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 rY2l5pm8_hdc for ; Mon, 27 Feb 2017 05:37:49 -0800 (PST)
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 3BB08129FA5 for ; Mon, 27 Feb 2017 05:37:49 -0800 (PST)
X-Halon-ID: ea87398b-fcf1-11e6-ad4a-005056917a89
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [77.53.231.21]) by bin-vsp-out-01.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Mon, 27 Feb 2017 14:37:43 +0100 (CET)
To: Randall Gellens , slim@ietf.org, Bernard Aboba 
References: <148782279664.31054.8793649134696520241.idtracker@ietfa.amsl.com>  <49fd730e-6e90-1a49-eae8-80f8b1285a76@omnitor.se>  <83152ba7-c3fb-25d8-f97d-59c7840cad56@omnitor.se>  <4b36f347-955e-e2b9-12f2-f426d47d3d33@omnitor.se> <59d7939c-d4c5-b74a-e960-3234f0524b39@omnitor.se> 
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: <024da389-19d4-5e1b-4956-ee359580b4e1@omnitor.se>
Date: Mon, 27 Feb 2017 14:37:40 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
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] I-D Action: draft-ietf-slim-negotiating-human-language-07.txt
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Feb 2017 13:37:53 -0000

Den 2017-02-27 kl. 02:01, skrev Randall Gellens:
> At 8:38 AM +0100 2/26/17, Gunnar Hellström wrote:
>
>>  Randall,
>>
>>  One more clarification for issue 12 - the asterisk placement as a 
>> preference hint:
>>
>>  You say:
>>
>>  " it seems better for the answerer to include all media and 
>> languages from the offer that it can support. "
>>
>>  You are right. I misread this paragraph in section 5.2:
>>  " In an answer, 'humintlang-send' is the language the answerer will
>>  send (which in most cases is one of the languages in the offer's
>>  'humintlang-recv'), and 'humintlang-recv' is the language the
>>  answerer expects to receive (which in most cases is one of the
>>  languages in the offer's 'humintlang-send')."
>>
>>  That gave me the impression that I need to answer with only one 
>> language per direction in the whole SDP.
>
> It's per media.
>
>
>>  But in the first paragraph of 5.2, it is said: "to negotiate
>>  which human language is used in each interactive media stream. "
>>
>>  So, we are allowed to include more than one language per direction 
>> in the SDP, but the users are not expected to use more than one 
>> language per direction, at least initially in the call.
>
> There's nothing in the protocol that says anything about people using 
> more than one media in each direction.
>
>
>>  (that makes the wording "will send" and "expects to receive" in the 
>> cited paragraph a bit misleading, because as you point out, some of 
>> them might never be used. "is prepared to send" and "can accept to 
>> receive" might better correspond to what it means. Ending the 
>> sentence with "per media steram" might also help to remind the reader 
>> about the semantics. I leave to you to change these if you want.)
>
> OK, I'm happy to add the additional clarification.  The paragraph now 
> reads:
>
>    In an answer, 'hlang-send' is the language the answerer will send
>    when using the media (which in most cases is one of the languages in
>    the offer's 'hlang-recv'), and 'hlang-recv' is the language the
>    answerer expects to receive in the media (which in most cases is one
>    of the languages in the offer's 'hlang-send').

Yes, that might be acceptable if "will send when using the media" can be 
read as being conditional: "will send if use of the media for language 
purposes is selected",
but not if it is read as a definite usage "will send for the periods of 
time that this media will definitively be used for language 
communication."  With the latter interpretation we have not improved our 
logic over the lang attribute that could be interpreted as it required 
use of all declared languages in the session.

I still think it is safer to say "is prepared to send" instead of "will 
send".
While for the other direction, I think the "expects to receive" is vague 
enough to mean that another media might be used.

Sorry for continuing to watch out for logic gaps here.

Gunnar
>
>
>
>>  Den 2017-02-26 kl. 07:46, skrev Gunnar Hellström:
>>
>>>  Den 2017-02-25 kl. 20:58, skrev Randall Gellens:
>>>
>>>>  Hi Gunnar,
>>>>
>>>>  At 11:04 AM +0100 2/25/17, Gunnar Hellström wrote:
>>>>
>>>>>  Fine, I find that we have only issues 5, 6 and 12 still to discuss.
>>>>>
>>>>>  You did not answer issue 6, use of asymmetrical language rather 
>>>>> than unidirectional media. I assume you accepted it.
>>>>>
>>>>
>>>>  Yes, I thought I had indicated that, sorry if I didn't.
>>>>
>>>  Good.
>>>
>>>>
>>>>>
>>>>>  On 5, the request to reinsert wording about seeing the speaker in 
>>>>> video, it is still a huge difference in specifying a preference to 
>>>>> see the speaker for language perception reasons, versus only 
>>>>> specifying that I want a video stream for supplementary purposes. 
>>>>> With the current wording in version -07, section 5.3 says that 
>>>>> that combination is undefined. Nothing in the LC discussion 
>>>>> indicated that it should be undefined. Why did you suddenly want 
>>>>> to delete it? It is useful. Please reinsert with the wording 
>>>>> changes I propose.
>>>>>
>>>>
>>>>  The email discussion led me to believe that the text was 
>>>> controversial. We need to get the draft finished, so it's better to 
>>>> delete controversial text than to spend months fighting about it.
>>>>
>>>  The comments were first about the uncertainty about how the "silly 
>>> states" were to be interpreted.
>>>  We described them all but decided to only keep the view of the 
>>> speaker because it is a real and useful case.
>>>  The idea to differentiate spoken and written cases by script tags 
>>> caused discussions and was dropped. The remaining real case with the 
>>> view of the speaker was mentioned twice in the draft, so it was 
>>> recommended that one of them should be deleted, but not both.
>>>
>>>>
>>>>>
>>>>>  On 12, the meaning of the placement of the asterisk, you ask:
>>>>>  "Making the asterisk a purely-advisory hint as to the 
>>>>> least-preferred media/language combination seems harmless enough, 
>>>>> as it would not be required to support it; however, I'm not sure 
>>>>> it provides any benefit: if an offer contains some set of media 
>>>>> with language, and the answerer can support all of them, should 
>>>>> the answerer only include in its answer those without an asterisk? 
>>>>> It seems simpler for the answerer to include everything in the 
>>>>> offer that it can support."
>>>>>
>>>>>  The answering party should aim at answering with one of the 
>>>>> languages that is without the asterisk in the offer. Only if the 
>>>>> answering party does not have capability in a language without an 
>>>>> asterisk, one with asterisk should be selected. Thereby you get 
>>>>> the best opportunity to start the call in a language combination 
>>>>> that satisfies both users.
>>>>>
>>>>>  Example: A hard-of-hearing user can just barely conduct spoken 
>>>>> calls with persons she knows. From others it is much more reliable 
>>>>> to get text. She calls and declares:
>>>>>
>>>>>  m=audio
>>>>>  a=huml-send:en
>>>>>  a=huml-recv:en*
>>>>>  m=text
>>>>>  a=huml-recv:en
>>>>>
>>>>>  The answering party with text capabilities sees that matching 
>>>>> text for sending is higher preferred than talking, and thus responds:
>>>>>
>>>>>  m=audio
>>>>>  a=huml-recv:en
>>>>>  m=text
>>>>>  a=huml-send:en
>>>>>
>>>>>  The answering party sends the initial greeting in text and the 
>>>>> call continues smoothly in well managed langauage/modality 
>>>>> combinations.
>>>>>
>>>>>  Another called party may not have text capabilities, and may 
>>>>> therefore select the less favoured alternative with using speech 
>>>>> both ways, answering:
>>>>>
>>>>>  m=audio
>>>>>  a=huml-recv:en
>>>>>  a=huml-send:en
>>>>>  m=text 0
>>>>>
>>>>>  The answering party starts taking and the parties try as well as 
>>>>> possible to manage the call in this less preferred combination 
>>>>> that may be less reliable.
>>>>>
>>>>>  If the placement of the asterisk had no special meaning as it is 
>>>>> in version -07, it is a high risk that the answering party in the 
>>>>> first example would select to answer with spoken language that 
>>>>> would be unreliably received. Time and effort would be spent by 
>>>>> speech to make the answering party switch to sending text instead 
>>>>> of talking in order to arrange for a more reliable call situation.
>>>>>
>>>>>  If instead the caller only indicated the most favoured combinations,
>>>>>
>>>>>  m=audio
>>>>>  a=huml-send:en
>>>>>  m=text
>>>>>  a=huml-recv:en
>>>>>
>>>>>  Then the answering parties without text capability would not dare 
>>>>> to try to answer, and a reasonably successful call would be missed.
>>>>>
>>>>>  Many other similar realistic examples can be created, where 
>>>>> placement of the asterisk(s) would be a sufficient indication of 
>>>>> lower preference for language match among alternatives that would 
>>>>> make call establishment successful and smooth in many more cases 
>>>>> than without this indication opportunity.
>>>>>
>>>>>  Do you want more examples?
>>>>>
>>>>>  Please accept proposal 12.
>>>>>
>>>>
>>>>  This convinces me that we cannot accept the proposed text, as it 
>>>> would introduce complexity that the WG explicitly decided to not 
>>>> pursue in this draft. In the examples you provided, it seems better 
>>>> for the answerer to include all media and languages from the offer 
>>>> that it can support. This is much simpler, has only trivial 
>>>> drawbacks (extra media negotiated that might not be used), and is 
>>>> what the WG agreed to.
>>>>
>>>  Yes, you could let the answer SDP contain one common language per 
>>> media and direction, but the answering human need guidance on which 
>>> language is best suited to start the conversation. Therefore the 
>>> placement of the asterisk is used to hint the answering party how to 
>>> start the call.
>>>
>>>  The first example above can be modified to:
>>>
>>>  Example: A hard-of-hearing user can just barely conduct spoken 
>>> calls with persons she knows. From others it is much more reliable 
>>> to get text. She calls and declares:
>>>
>>>  m=audio
>>>  a=huml-send:en
>>>  a=huml-recv:en*
>>>  m=text
>>>  a=huml-recv:en
>>>
>>>  The answering party with capabilities for both written and spoken 
>>> English sees that matching text for sending is higher preferred than 
>>> talking and sends the answer indicating the capabilities:
>>>
>>>  m=audio
>>>  a=huml-recv:en
>>>  a=huml-send:en
>>>  m=text
>>>  a=huml-send:en
>>>
>>>  The answering party makes use of the hint that the caller prefers 
>>> to receive written text and therefore sends the initial greeting in 
>>> text and the call continues smoothly in well managed 
>>> langauage/modality combinations.
>>>
>>>  ----------
>>>  There is no complexity left in this solution, it helps to motivate 
>>> why we have the asterisk on media level, and it helps to successful 
>>> call initiations, so I think it should be acceptable.
>>>
>>>  Gunnar
>>>
>>>>
>>>>  --Randy
>>>>
>>>>>  Den 2017-02-25 kl. 01:32, skrev Randall Gellens:
>>>>>
>>>>>>  At 5:35 PM +0100 2/24/17, Gunnar Hellström wrote:
>>>>>>
>>>>>>>  Den 2017-02-23 kl. 05:15, skrev Randall Gellens:
>>>>>>>
>>>>>>>>  Version -07 addresses all comments except for the unresolved 
>>>>>>>> issue of renaming the two attributes which is currently being 
>>>>>>>> discussed on the list, and adding a new attribute for 
>>>>>>>> bidirectionality.
>>>>>>>>
>>>>>>>>  Per Dale's suggestion, the draft adds advice that if a call is 
>>>>>>>> rejected due to no languages in common, SIP response code 488 
>>>>>>>> (Not Acceptable Here) or 606 (Not Acceptable) be used, along 
>>>>>>>> with a Warning header field indicating the supported languages. 
>>>>>>>> The draft registers a new entry in the warn-code sub-registry 
>>>>>>>> of SIP parameters for this purpose. The draft also has an 
>>>>>>>> expanded set of examples.
>>>>>>>>
>>>>>>>  Good progress. Good to see the enriched examples chapter 5.5.
>>>>>>>  I have a few comments on version -07:
>>>>>>>
>>>>>>>  1. Section 4. second line
>>>>>>>  ------------old text----------------------
>>>>>>>  but is not sufficiently sufficiently
>>>>>>>  ------------new text--------------------------
>>>>>>>  but is not sufficiently
>>>>>>>  ----------end of change 1-----------------
>>>>>>>  Motivation: New typo in version -07
>>>>>>>
>>>>>>
>>>>>>  Thanks.
>>>>>>
>>>>>>>
>>>>>>>  2. Section 5.2, first line
>>>>>>>  ----------------old text-----------------
>>>>>>>  This document defines two new media-level ..
>>>>>>>  ----------------new text----------------------
>>>>>>>  This document defines two media-level ...
>>>>>>>  ----------------end of change 2----------------
>>>>>>>  Motivation: It was commented that when the draft is published, 
>>>>>>> this is not new anymore.
>>>>>>>  There are three more occasions of "new" in the document that 
>>>>>>> may be modified as well.
>>>>>>>
>>>>>>
>>>>>>  OK.
>>>>>>
>>>>>>>
>>>>>>>  3. 5.2 second paragraph
>>>>>>>  -------------------old text--------------------------------
>>>>>>>  In an offer, the 'humintlang-send' values indicates the 
>>>>>>> language(s)
>>>>>>>  the offerer is willing to use when sending using the media, and 
>>>>>>> the
>>>>>>>  'humintlang-recv' values indicates the language(s) the offerer is
>>>>>>>  willing to use when receiving using the media.
>>>>>>>  -----------------new text---------------------------------
>>>>>>>  In an offer, the 'humintlang-send' values indicate the language(s)
>>>>>>>  the offerer is willing to select from for use when sending 
>>>>>>> using the
>>>>>>>  media, and the 'humintlang-recv' values indicate the 
>>>>>>> language(s) the
>>>>>>>  offerer is willing to receive one of in the media stream.
>>>>>>>  ----------------end of change----------------------------------
>>>>>>>  Motivation 1:) change from "indicates" to "indicate" in two 
>>>>>>> places to match the new use of plural "values".
>>>>>>>  Motivation 2:) Be sure to indicate that we only intend to 
>>>>>>> negotiate one language per media and direction, so that we do 
>>>>>>> not end up as unspecified regarding number of matches required 
>>>>>>> as the sdp "lang" attribute is.
>>>>>>>
>>>>>>
>>>>>>  Reworded.
>>>>>>
>>>>>>>
>>>>>>>  4. 5.2 Second paragraph
>>>>>>>  -----------------old text-----------------------
>>>>>>>  When a media is intended
>>>>>>>  for use in one direction only
>>>>>>>  ----------------new text---------------------
>>>>>>>  When a media is intended
>>>>>>>  for use for language communication in one direction only
>>>>>>>  ----------------end of change---------------------------
>>>>>>>  Motivation: Deletion of a note in this sentence made it less 
>>>>>>> obvious that we are only talking about directions of use of 
>>>>>>> language communication, and not about establishing asymmetric 
>>>>>>> media connections. Therefore add this clarification.
>>>>>>>
>>>>>>
>>>>>>  Reworded.
>>>>>>
>>>>>>>
>>>>>>>  5. 5.2 Deleted paragraph 6 before "Clients acting on behalf..."
>>>>>>>  ----------reinsert modified paragraph----------------------------
>>>>>>>  While signed language tags are used with a video stream to
>>>>>>>  indicate sign language, a spoken language tag for a video stream
>>>>>>>  indicates a request or offer to see the speaker, when that is of
>>>>>>>  importance for language perception.
>>>>>>>  -------------end of 
>>>>>>> change-------------------------------------------
>>>>>>>  Motivation: There was in the LC mail exchange a discussion 
>>>>>>> about sharpening up the specification of use of "unusual 
>>>>>>> combinations".
>>>>>>>  There was no agreement to delete them all. The one described in 
>>>>>>> this paragraph is the main one that has widespread use and needs 
>>>>>>> to be clearly specified for use by a large number of 
>>>>>>> hard-of-hearing and deaf users.
>>>>>>>
>>>>>>
>>>>>>  The text as it is now does not prohibit anything and explicitly 
>>>>>> mentions negotiating supplemental video by omitting language 
>>>>>> attributes on a video media.
>>>>>>
>>>>>>>
>>>>>>>  6. 5.2 Sixth paragraph
>>>>>>>  --------------------current text--------------------
>>>>>>>  (or for unidirectional streams, one of)
>>>>>>>  ------------------new text ------------------------
>>>>>>>  (or for asymmetrical use of languages, one of)
>>>>>>>  -----------------end of change----------------------
>>>>>>>  Motivation: We are not primarily talking about enabled 
>>>>>>> transmission directions of the streams, but about language use 
>>>>>>> in the streams. We do not want to limit the media stream 
>>>>>>> directions just because we do not specify an initial language to 
>>>>>>> use for that direction. There are other usage of media, and 
>>>>>>> there may even be occasional use of language in the direction, 
>>>>>>> just not worth mentioning as an initial and preferred use. The 
>>>>>>> suggested change should make that clear.
>>>>>>>
>>>>>>>  7. 5.3 Next to last paragraph
>>>>>>>  ------------------old text------------------------------
>>>>>>>  a list of supported languages.
>>>>>>>  -------------------new text-------------------------
>>>>>>>  a list of supported languages, media and directions.
>>>>>>>  -------------------end of change----------------
>>>>>>>  Motivation: It is not sufficient to know which languages are 
>>>>>>> supported, it is also essential to know in which media they are 
>>>>>>> supported and in which directions. (media could be replaced with 
>>>>>>> modality, but the media can become ambigous then, so use media 
>>>>>>> here to be brief.
>>>>>>>
>>>>>>
>>>>>>  I don't know that we can require this, but I'll add SHOULD kist 
>>>>>> supported languages and media. Demanding direction as well might 
>>>>>> be too unwieldy.
>>>>>>
>>>>>>>
>>>>>>>  8. 5.3, last line
>>>>>>>  --------------old text----------------------------------
>>>>>>>  Supported languages are: es, en"
>>>>>>>  --------------new text-------------------------------
>>>>>>>  Supported languages are: es, en transmission in audio; es, en 
>>>>>>> reception in audio"
>>>>>>>  ----------------------------------------------------------
>>>>>>>  Motivation: Same as for 7.
>>>>>>>
>>>>>>
>>>>>>  Fixed as above.
>>>>>>
>>>>>>>
>>>>>>>  9. 5.4 Undefined combinations
>>>>>>>  ----------------------------old 
>>>>>>> text--------------------------------------
>>>>>>>  The behavior when specifying a non-signed language tag for a video
>>>>>>>  media stream, or a signed language tag for an audio or text media
>>>>>>>  stream, is not defined.
>>>>>>>  ---------------------------new 
>>>>>>> text-----------------------------------------
>>>>>>>  There is no way specified for indicating use of text based 
>>>>>>> language in a video media stream.
>>>>>>>  There is no meaning assigned to specification of sign language 
>>>>>>> in an audio or text media stream.
>>>>>>>  --------------------------end of 
>>>>>>> change-------------------------------
>>>>>>>  Motivation: Seeing the speaker in video is an important 
>>>>>>> combination reinserted above in section 5.2.
>>>>>>>  This section therefore needed rewording to not include that 
>>>>>>> combination.
>>>>>>>
>>>>>>
>>>>>>  The draft explicitly mentions video for supplemental purposes.
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>  10. 6.2 Last sentence
>>>>>>>  -----------------current text---------------------
>>>>>>>  Supported languages are: [list of supported languages]."
>>>>>>>  -----------------new text------------------------
>>>>>>>  Supported languages and media and transmission directions 
>>>>>>> are:[list of supported languages and media and transmission 
>>>>>>> directions.]"
>>>>>>>  -----------------end of change--------------------------
>>>>>>>  Motivation: Same as for 7.
>>>>>>>
>>>>>>
>>>>>>  Fixed as above.
>>>>>>
>>>>>>>
>>>>>>>  11. 6.1 MUX Category
>>>>>>>  ----------old text in two locations-------------------
>>>>>>>  MUX Category: normal
>>>>>>>  ---------new text in same two locations--------------
>>>>>>>  Mux Category: NORMAL
>>>>>>>  ---------end of change-----------------
>>>>>>>  Motivation: Follow RFC 4566bis and IANA habits regarding use of 
>>>>>>> capitals
>>>>>>>
>>>>>>
>>>>>>  Fixed.
>>>>>>
>>>>>>>
>>>>>>>  12. 5.3
>>>>>>>  -------------old text-----------------
>>>>>>>  5.3 No Language in Common
>>>>>>>  -------------new text----------------
>>>>>>>  5.3 Preference parameter
>>>>>>>  ------------end of change 1 in 5.3---------------
>>>>>>>
>>>>>>
>>>>>>  The section is more than just the asterisk, it also advises use 
>>>>>> of specific SIP response codes if the call is failed.
>>>>>>
>>>>>>>
>>>>>>>  -------------old text-in 5.3, second 
>>>>>>> paragraph-------------------------------
>>>>>>>  The mechanism for indicating this preference is that, in an 
>>>>>>> offer, if
>>>>>>>  the last character of any of the 'humintlang-recv' or 'humintlang-
>>>>>>>  send' values is an asterisk, this indicates a request to not 
>>>>>>> fail the call.
>>>>>>>  --------------------------new text-------------------------------
>>>>>>>  The mechanism for indicating this preference is that, in an 
>>>>>>> offer, if
>>>>>>>  the last character of any of the 'humintlang-recv' or 'humintlang-
>>>>>>>  send' values is an asterisk, this indicates a request to not 
>>>>>>> fail the call.
>>>>>>>  The asterisk should be attached to attributes with languages of 
>>>>>>> lower
>>>>>>>  preference to be matched if such difference can be specified. 
>>>>>>> Thereby
>>>>>>>  the location of the asterisk can be used to support the 
>>>>>>> decision on
>>>>>>>  which languages to use in the call.
>>>>>>>  ---------------------------end of change 2 in 
>>>>>>> 5.3--------------------------------------
>>>>>>>  Motivation: There has not yet been any conclusion for my 
>>>>>>> proposal no 5 in the IETF LC comments of Feb 12.
>>>>>>>  This is a dramatically reduced version that may be easier to 
>>>>>>> accept at this stage, still covering one of the missing 
>>>>>>> functionalities in the draft.
>>>>>>>  The asterisk is used as a preference parameter in the 
>>>>>>> attributes. Thereby the proposed title change on 5.3
>>>>>>>  With this additional rule about where the asterisk(s) are 
>>>>>>> placed, the answering parties get good clues about the 
>>>>>>> preferences between alternatives presented by the offeror. The 
>>>>>>> chance to set up calls with satisfied users increase 
>>>>>>> dramatically compared to letting the answering party select by 
>>>>>>> chance between alternatives.
>>>>>>>
>>>>>>
>>>>>>  Making the asterisk a purely-advisory hint as to the 
>>>>>> least-preferred media/language combination seems harmless enough, 
>>>>>> as it would not be required to support it; however, I'm not sure 
>>>>>> it provides any benefit: if an offer contains some set of media 
>>>>>> with language, and the answerer can support all of them, should 
>>>>>> the answerer only include in its answer those without an 
>>>>>> asterisk? It seems simpler for the answerer to include everything 
>>>>>> in the offer that it can support.
>>>>>>
>>>>>
>>>>>  --
>>>>>  -----------------------------------------
>>>>>  Gunnar Hellström
>>>>>  Omnitor
>>>>>  gunnar.hellstrom@omnitor.se
>>>>>  +46 708 204 288
>>>>>
>>>>
>>>>
>>>
>>
>>  --
>>  -----------------------------------------
>>  Gunnar Hellström
>>  Omnitor
>>  gunnar.hellstrom@omnitor.se
>>  +46 708 204 288
>
>

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


From nobody Mon Feb 27 07:32:00 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 1E97712A155 for ; Mon, 27 Feb 2017 07:31:58 -0800 (PST)
X-Quarantine-ID: 
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -1.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 FT09nCK81HKm for ; Mon, 27 Feb 2017 07:31:56 -0800 (PST)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id D811512A150 for ; Mon, 27 Feb 2017 07:31:55 -0800 (PST)
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Mon, 27 Feb 2017 07:21:42 -0800
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <7f844aaa-17ce-2ab7-0602-a999a40235de@omnitor.se>
References: <148782279664.31054.8793649134696520241.idtracker@ietfa.amsl.com>  <49fd730e-6e90-1a49-eae8-80f8b1285a76@omnitor.se>  <83152ba7-c3fb-25d8-f97d-59c7840cad56@omnitor.se>  <4b36f347-955e-e2b9-12f2-f426d47d3d33@omnitor.se>  <7f844aaa-17ce-2ab7-0602-a999a40235de@omnitor.se>
X-Mailer: Eudora for Mac OS X
Date: Mon, 27 Feb 2017 07:31:52 -0800
To: Gunnar =?iso-8859-1?Q?Hellstr=F6m?=  , slim@ietf.org, Natasha Rooney , Bernard Aboba , "Phillips, Addison" 
From: Randall Gellens 
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
Archived-At: 
Subject: Re: [Slim] I-D Action: draft-ietf-slim-negotiating-human-language-07.txt
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Feb 2017 15:31:58 -0000

At 9:01 AM +0100 2/27/17, Gunnar Hellstr=F6m wrote:

>  Randall,
>  good to see that we are converging,
>  Den 2017-02-27 kl. 01:55, skrev Randall Gellens:
>>  At 7:46 AM +0100 2/26/17, Gunnar Hellstr=F6m wrote:
>>
>>>   Den 2017-02-25 kl. 20:58, skrev Randall Gellens:
>>>>   Hi Gunnar,
>>>>
>>>>   At 11:04 AM +0100 2/25/17, Gunnar Hellstr=F6m wrote:
>>>>
>>>>>    Fine, I find that we have only issues 5, 6 and 12 still to discuss.
>>>>>
>>>>>    You did not answer issue 6, use of=20
>>>>> asymmetrical language rather than=20
>>>>> unidirectional media. I assume you accepted=20
>>>>> it.
>>>>
>>>>   Yes, I thought I had indicated that, sorry if I didn't.
>>>   Good.
>>>>
>>>>>
>>>>>    On 5, the request to reinsert wording=20
>>>>> about seeing the speaker in video, it is=20
>>>>> still a huge difference in specifying a=20
>>>>> preference to see the speaker for language=20
>>>>> perception reasons, versus only specifying=20
>>>>> that I want a video stream for=20
>>>>> supplementary purposes. With the current=20
>>>>> wording in version -07, section 5.3 says=20
>>>>> that that combination is undefined. Nothing=20
>>>>> in the LC discussion indicated that it=20
>>>>> should be undefined. Why did you suddenly=20
>>>>> want to delete it? It is useful. Please=20
>>>>> reinsert with the wording changes I propose.
>>>>
>>>>   The email discussion led me to believe that=20
>>>> the text was controversial.  We need to get=20
>>>> the draft finished, so it's better to delete=20
>>>> controversial text than to spend months=20
>>>> fighting about it.
>>>   The comments were first about the=20
>>> uncertainty about how the "silly states" were=20
>>> to be interpreted.
>>>   We described them all but decided to only=20
>>> keep the view of the speaker because it is a=20
>>> real and useful case.
>>>   The idea to differentiate spoken and written=20
>>> cases by script tags caused discussions and=20
>>> was dropped. The remaining real case with the=20
>>> view of the speaker was mentioned twice in=20
>>> the draft, so it was recommended that one of=20
>>> them should be deleted, but not both.
>>
>>  OK, I'll restore the text in section 5.2:
>>
>>     Note that while signed language tags are used with a video stream to
>>     indicate sign language, a spoken language tag for a video stream in
>>     parallel with an audio stream with the same spoken language tag
>>     indicates a request for a supplemental video stream to see the
>>     speaker.
>>
>>  And modify section 5.4 to exclude this case:
>>
>>     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.
>  Addison did not like the expression=20
> "spoken/written language tag" when we used it=20
> in the discussion about section 5.4.
>  We may get the same reaction here.
>  You would have avoided it if you took my wording proposal as it was.
>>
>>
>>>>
>>>>>
>>>>>    On 12, the meaning of the placement of the asterisk, you ask:
>>>>>    "Making the asterisk a purely-advisory=20
>>>>> hint as to the least-preferred=20
>>>>> media/language combination seems harmless=20
>>>>> enough, as it would not be required to=20
>>>>> support it; however, I'm not sure it=20
>>>>> provides any benefit: if an offer contains=20
>>>>> some set of media with language, and the=20
>>>>> answerer can support all of them, should=20
>>>>> the answerer only include in its answer=20
>>>>> those without an asterisk? It seems simpler=20
>>>>> for the answerer to include everything in=20
>>>>> the offer that it can support."
>>>>>
>>>>>    The answering party should aim at=20
>>>>> answering with one of the languages that is=20
>>>>> without the asterisk in the offer. Only if=20
>>>>> the answering party does not have=20
>>>>> capability in a language without an=20
>>>>> asterisk, one with asterisk should be=20
>>>>> selected. Thereby you get the best=20
>>>>> opportunity to start the call in a language=20
>>>>> combination that satisfies both users.
>>>>>
>>>>>    Example: A hard-of-hearing user can just=20
>>>>> barely conduct spoken calls with persons=20
>>>>> she knows. From others it is much more=20
>>>>> reliable to get text.  She calls and=20
>>>>> declares:
>>>>>
>>>>>    m=3Daudio
>>>>>    a=3Dhuml-send:en
>>>>>    a=3Dhuml-recv:en*
>>>>>    m=3Dtext
>>>>>    a=3Dhuml-recv:en
>>>>>
>>>>>    The answering party with text=20
>>>>> capabilities sees that matching text for=20
>>>>> sending is higher preferred than talking,=20
>>>>> and thus responds:
>>>>>
>>>>>    m=3Daudio
>>>>>    a=3Dhuml-recv:en
>>>>>    m=3Dtext
>>>>>    a=3Dhuml-send:en
>>>>>
>>>>>    The answering party sends the initial=20
>>>>> greeting in text and the call continues=20
>>>>> smoothly in well managed langauage/modality=20
>>>>> combinations.
>>>>>
>>>>>    Another called party may not have text=20
>>>>> capabilities, and may therefore select the=20
>>>>> less favoured alternative with using speech=20
>>>>> both ways, answering:
>>>>>
>>>>>    m=3Daudio
>>>>>    a=3Dhuml-recv:en
>>>>>    a=3Dhuml-send:en
>>>>>    m=3Dtext 0
>>>>>
>>>>>    The answering party starts taking and the=20
>>>>> parties try as well as possible to manage=20
>>>>> the call in this less preferred combination=20
>>>>> that may be less reliable.
>>>>>
>>>>>    If the placement of the asterisk had no=20
>>>>> special meaning as it is in version -07, it=20
>>>>> is a high risk that the answering party in=20
>>>>> the first example would select to answer=20
>>>>> with spoken language that would be=20
>>>>> unreliably received. Time and effort would=20
>>>>> be spent by speech to make the answering=20
>>>>> party switch to sending text instead of=20
>>>>> talking in order to arrange for a more=20
>>>>> reliable call situation.
>>>>>
>>>>>    If instead the caller only indicated the most favoured combinations=
,
>>>>>
>>>>>    m=3Daudio
>>>>>    a=3Dhuml-send:en
>>>>>    m=3Dtext
>>>>>    a=3Dhuml-recv:en
>>>>>
>>>>>    Then the answering parties without text=20
>>>>> capability would not dare to try to answer,=20
>>>>> and a reasonably successful call would be=20
>>>>> missed.
>>>>>
>>>>>    Many other similar realistic examples can=20
>>>>> be created, where placement of the=20
>>>>> asterisk(s) would be a sufficient=20
>>>>> indication of lower preference for language=20
>>>>> match among alternatives that would make=20
>>>>> call establishment successful and smooth in=20
>>>>> many more cases than without this=20
>>>>> indication opportunity.
>>>>>
>>>>>    Do you want more examples?
>>>>>
>>>>>    Please accept proposal 12.
>>>>
>>>>   This convinces me that we cannot accept the=20
>>>> proposed text, as it would introduce=20
>>>> complexity that the WG explicitly decided to=20
>>>> not pursue in this draft.  In the examples=20
>>>> you provided, it seems better for the=20
>>>> answerer to include all media and languages=20
>>>> from the offer that it can support.  This is=20
>>>> much simpler, has only trivial drawbacks=20
>>>> (extra media negotiated that might not be=20
>>>> used), and is what the WG agreed to.
>>>   Yes, you could let the answer SDP contain=20
>>> one common language per media and direction,=20
>>> but the answering human need guidance on=20
>>> which language is best suited to start the=20
>>> conversation. Therefore the placement of the=20
>>> asterisk is used to hint the answering party=20
>>> how to start the call.
>>
>>  I believe the WG discussed proposals to=20
>> provide information to the humans regarding=20
>> the languages and media that were negotiated,=20
>> and decided it is out of scope of the draft as=20
>> an implementation issue, not a protocol issue.
>  Yes, we did, and said that the mechanism for=20
> providing the result of the indication and=20
> negotiation to the user is out of scope, but=20
> the resulting information needs to be provided=20
> to the user. It is the user who generates=20
> language and the user needs to know the most=20
> preferred common languages so that the user can=20
> start the call in an appropriate language.
>  This is valid for the language as well as the preference indication.
>
>  And we say that by the end of section 1. " Both=20
> sides should be aware of which language was=20
> negotiated."    No mechanism specified, but the=20
> result needs to be conveyed to the user.
>
>  Now, when there is no required protocol=20
> influence implied by the placement of the=20
> asterisk, all feared complexity is gone and=20
> only the huge increase in usability remains.
>
>  It is not fair that users who want to express=20
> preference between languages in a single=20
> modality can do it, but users who have=20
> preferences between languages in different=20
> modalities cannot indicate that. Let us cover=20
> that gap when it is so free from complexity to=20
> do it.

Conveying information to the user is UI which is out of scope of this draft.

>
>>
>>>
>>>   The first example above can be modified to:
>>>
>>>    Example: A hard-of-hearing user can just=20
>>> barely conduct spoken calls with persons she=20
>>> knows. From others it is much more reliable=20
>>> to get text.  She calls and declares:
>>>
>>>    m=3Daudio
>>>    a=3Dhuml-send:en
>>>    a=3Dhuml-recv:en*
>>>    m=3Dtext
>>>    a=3Dhuml-recv:en
>>>
>>>    The answering party with capabilities for=20
>>> both written and spoken English sees that=20
>>> matching text for sending is higher preferred=20
>>> than talking and sends the answer indicating=20
>>> the capabilities:
>>>
>>>    m=3Daudio
>>>    a=3Dhuml-recv:en
>>>   a=3Dhuml-send:en
>>>    m=3Dtext
>>>    a=3Dhuml-send:en
>>>
>>>    The answering party makes use of the hint=20
>>> that the caller prefers to receive written=20
>>> text and therefore sends the initial greeting=20
>>> in text and the call continues smoothly in=20
>>> well managed langauage/modality combinations.
>>>
>>>   ----------
>>>   There is no complexity left in this=20
>>> solution, it helps to motivate why we have=20
>>> the asterisk on media level, and it helps to=20
>>> successful call initiations, so I think it=20
>>> should be acceptable.
>>
>>  My suggestion is that you write this idea as a=20
>> new draft offering implementation guidance,=20
>> and ask the WG to adopt it as either=20
>> Informational or BCP.  It doesn't affect the=20
>> protocol in the current draft, but provides=20
>> guidance on how to use the protocol in both an=20
>> offer and an answer and potentially in the UI.
>  I suggest that the chairs and area director=20
> assign a procedure suitable for the current=20
> state of the draft to potentially include the=20
> meaning of the placement of the asterisk as=20
> proposed in my issue 12.

UI is out of scope of the draft.  If you write an=20
"advice to implementers" type document, that can=20
accomplish your goal.



>
>  Thanks
>  Gunnar
>>
>>
>>
>>>>
>>>>>    Den 2017-02-25 kl. 01:32, skrev Randall Gellens:
>>>>>>    At 5:35 PM +0100 2/24/17, Gunnar Hellstr=F6m wrote:
>>>>>>
>>>>>>>     Den 2017-02-23 kl. 05:15, skrev Randall Gellens:
>>>>>>>>     Version -07 addresses all comments=20
>>>>>>>> except for the unresolved issue of=20
>>>>>>>> renaming the two attributes which is=20
>>>>>>>> currently being discussed on the list,=20
>>>>>>>> and adding a new attribute for=20
>>>>>>>> bidirectionality.
>>>>>>>>
>>>>>>>>     Per Dale's suggestion, the draft adds=20
>>>>>>>> advice that if a call is rejected due to=20
>>>>>>>> no languages in common, SIP response=20
>>>>>>>> code 488 (Not Acceptable Here) or 606=20
>>>>>>>> (Not Acceptable) be used, along with a=20
>>>>>>>> Warning header field indicating the=20
>>>>>>>> supported languages.  The draft=20
>>>>>>>> registers a new entry in the warn-code=20
>>>>>>>> sub-registry of SIP parameters for this=20
>>>>>>>> purpose.  The draft also has an expanded=20
>>>>>>>> set of examples.
>>>>>>>>
>>>>>>>     Good progress. Good to see the enriched examples chapter 5.5.
>>>>>>>     I have a few comments on version -07:
>>>>>>>
>>>>>>>     1.  Section  4. second line
>>>>>>>     ------------old text----------------------
>>>>>>>     but is not sufficiently sufficiently
>>>>>>>     ------------new text--------------------------
>>>>>>>     but is not sufficiently
>>>>>>>     ----------end of change 1-----------------
>>>>>>>     Motivation: New typo in version -07
>>>>>>
>>>>>>    Thanks.
>>>>>>
>>>>>>>
>>>>>>>     2. Section 5.2, first line
>>>>>>>     ----------------old text-----------------
>>>>>>>     This document defines two new media-level ..
>>>>>>>     ----------------new text----------------------
>>>>>>>     This document defines two media-level ...
>>>>>>>     ----------------end of change 2----------------
>>>>>>>     Motivation: It was commented that when=20
>>>>>>> the draft is published, this is not new=20
>>>>>>> anymore.
>>>>>>>     There are three more occasions of=20
>>>>>>> "new" in the document that may be=20
>>>>>>> modified as well.
>>>>>>
>>>>>>    OK.
>>>>>>
>>>>>>>
>>>>>>>     3.  5.2 second paragraph
>>>>>>>     -------------------old text--------------------------------
>>>>>>>     In an offer, the 'humintlang-send' values indicates the language=
(s)
>>>>>>>        the offerer is willing to use when=20
>>>>>>> sending using the media, and the
>>>>>>>        'humintlang-recv' values indicates the language(s) the=
 offerer is
>>>>>>>        willing to use when receiving using the media.
>>>>>>>     -----------------new text---------------------------------
>>>>>>>     In an offer, the 'humintlang-send' values indicate the language(=
s)
>>>>>>>     the offerer is willing to select from for use when sending using=
 the
>>>>>>>     media, and the 'humintlang-recv' values indicate the language(s)=
 the
>>>>>>>     offerer is willing to receive one of in the media stream.
>>>>>>>     ----------------end of change----------------------------------
>>>>>>>     Motivation 1:) change from "indicates"=20
>>>>>>> to "indicate" in two places to match the=20
>>>>>>> new use of plural "values".
>>>>>>>     Motivation 2:) Be sure to indicate=20
>>>>>>> that we only intend to negotiate one=20
>>>>>>> language per media and direction, so that=20
>>>>>>> we do not end up as unspecified regarding=20
>>>>>>> number of matches required as the sdp=20
>>>>>>> "lang" attribute is.
>>>>>>
>>>>>>    Reworded.
>>>>>>
>>>>>>>
>>>>>>>     4.  5.2 Second paragraph
>>>>>>>     -----------------old text-----------------------
>>>>>>>     When a media is intended
>>>>>>>        for use in one direction only
>>>>>>>     ----------------new text---------------------
>>>>>>>     When a media is intended
>>>>>>>        for use for language communication in one direction only
>>>>>>>     ----------------end of change---------------------------
>>>>>>>     Motivation: Deletion of a note in this=20
>>>>>>> sentence made it less obvious that we are=20
>>>>>>> only talking about directions of use of=20
>>>>>>> language communication, and not about=20
>>>>>>> establishing asymmetric media=20
>>>>>>> connections. Therefore add this=20
>>>>>>> clarification.
>>>>>>
>>>>>>    Reworded.
>>>>>>
>>>>>>>
>>>>>>>     5.  5.2 Deleted paragraph 6 before "Clients acting on behalf..."
>>>>>>>     ----------reinsert modified paragraph---------------------------=
-
>>>>>>>     While signed language tags are used with a video stream to
>>>>>>>     indicate sign language, a spoken language tag for a video stream
>>>>>>>     indicates a request or offer to see the speaker, when that is of
>>>>>>>     importance for language perception.
>>>>>>>     -------------end of=20
>>>>>>> change-------------------------------------------
>>>>>>>     Motivation: There was in the LC mail=20
>>>>>>> exchange a discussion about sharpening up=20
>>>>>>> the specification of use of "unusual=20
>>>>>>> combinations".
>>>>>>>     There was no agreement to delete them=20
>>>>>>> all. The one described in this paragraph=20
>>>>>>> is the main one that has widespread use=20
>>>>>>> and needs to be clearly specified for use=20
>>>>>>> by a large number of hard-of-hearing and=20
>>>>>>> deaf users.
>>>>>>
>>>>>>    The text as it is now does not prohibit=20
>>>>>> anything and explicitly mentions=20
>>>>>> negotiating supplemental video by omitting=20
>>>>>> language attributes on a video media.
>>>>>>
>>>>>>>
>>>>>>>     6.  5.2 Sixth paragraph
>>>>>>>     --------------------current text--------------------
>>>>>>>     (or for unidirectional streams, one of)
>>>>>>>     ------------------new text ------------------------
>>>>>>>     (or for asymmetrical use of languages, one of)
>>>>>>>     -----------------end of change----------------------
>>>>>>>     Motivation: We are not primarily=20
>>>>>>> talking about enabled transmission=20
>>>>>>> directions of the streams, but about=20
>>>>>>> language use in the streams. We do not=20
>>>>>>> want to limit the media stream directions=20
>>>>>>> just because we do not specify an initial=20
>>>>>>> language to use for that direction. There=20
>>>>>>> are other usage of media, and there may=20
>>>>>>> even be occasional use of language in the=20
>>>>>>> direction, just not worth mentioning as=20
>>>>>>> an initial and preferred use. The=20
>>>>>>> suggested change should make that clear.
>>>>>>>
>>>>>>>     7.   5.3 Next to last paragraph
>>>>>>>     ------------------old text------------------------------
>>>>>>>     a list of supported languages.
>>>>>>>     -------------------new text-------------------------
>>>>>>>     a list of supported languages, media and directions.
>>>>>>>     -------------------end of change----------------
>>>>>>>     Motivation: It is not sufficient to=20
>>>>>>> know which languages are supported, it is=20
>>>>>>> also essential to know in which media=20
>>>>>>> they are supported and in which=20
>>>>>>> directions. (media could be replaced with=20
>>>>>>> modality, but the media can become=20
>>>>>>> ambigous then, so use media here to be=20
>>>>>>> brief.
>>>>>>
>>>>>>    I don't know that we can require this,=20
>>>>>> but I'll add SHOULD kist supported=20
>>>>>> languages and media. Demanding direction=20
>>>>>> as well might be too unwieldy.
>>>>>>
>>>>>>>
>>>>>>>     8.      5.3, last line
>>>>>>>     --------------old text----------------------------------
>>>>>>>      Supported languages are: es, en"
>>>>>>>     --------------new text-------------------------------
>>>>>>>      Supported languages are: es, en=20
>>>>>>> transmission in audio; es, en reception=20
>>>>>>> in audio"
>>>>>>>  ----------------------------------------------------------
>>>>>>>     Motivation: Same as for 7.
>>>>>>
>>>>>>    Fixed as above.
>>>>>>
>>>>>>>
>>>>>>>     9.  5.4 Undefined combinations
>>>>>>>     ----------------------------old=20
>>>>>>> text--------------------------------------
>>>>>>>        The behavior when specifying a=20
>>>>>>> non-signed language tag for a video
>>>>>>>        media stream, or a signed language tag for an audio or text m=
edia
>>>>>>>        stream, is not defined.
>>>>>>>     ---------------------------new=20
>>>>>>> text-----------------------------------------
>>>>>>>     There is no way specified for=20
>>>>>>> indicating use of text based language in=20
>>>>>>> a video media stream.
>>>>>>>     There is no meaning assigned to=20
>>>>>>> specification of sign language in an=20
>>>>>>> audio or text media stream.
>>>>>>>     --------------------------end of=20
>>>>>>> change-------------------------------
>>>>>>>     Motivation: Seeing the speaker in=20
>>>>>>> video is an important combination=20
>>>>>>> reinserted above in section 5.2.
>>>>>>>     This section therefore needed=20
>>>>>>> rewording to not include that combination.
>>>>>>
>>>>>>    The draft explicitly mentions video for supplemental purposes.
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>     10.     6.2 Last sentence
>>>>>>>     -----------------current text---------------------
>>>>>>>     Supported languages are: [list of supported languages]."
>>>>>>>     -----------------new text------------------------
>>>>>>>     Supported languages and media and=20
>>>>>>> transmission directions are:[list of=20
>>>>>>> supported languages and media and=20
>>>>>>> transmission directions.]"
>>>>>>>     -----------------end of change--------------------------
>>>>>>>     Motivation: Same as for 7.
>>>>>>
>>>>>>    Fixed as above.
>>>>>>
>>>>>>>
>>>>>>>     11.  6.1 MUX Category
>>>>>>>     ----------old text in two locations-------------------
>>>>>>>     MUX Category:  normal
>>>>>>>     ---------new text in same two locations--------------
>>>>>>>     Mux Category:  NORMAL
>>>>>>>     ---------end of change-----------------
>>>>>>>     Motivation: Follow RFC 4566bis and=20
>>>>>>> IANA habits regarding use of capitals
>>>>>>
>>>>>>    Fixed.
>>>>>>
>>>>>>>
>>>>>>>     12.  5.3
>>>>>>>     -------------old text-----------------
>>>>>>>     5.3 No Language in Common
>>>>>>>     -------------new text----------------
>>>>>>>     5.3 Preference parameter
>>>>>>>     ------------end of change 1 in 5.3---------------
>>>>>>
>>>>>>    The section is more than just the=20
>>>>>> asterisk, it also advises use of specific=20
>>>>>> SIP response codes if the call is failed.
>>>>>>
>>>>>>>
>>>>>>>     -------------old text-in 5.3, second=20
>>>>>>> paragraph-------------------------------
>>>>>>>     The mechanism for indicating this=20
>>>>>>> preference is that, in an offer, if
>>>>>>>     the last character of any of the 'humintlang-recv' or 'humintlan=
g-
>>>>>>>     send' values is an asterisk, this=20
>>>>>>> indicates a request to not fail the call.
>>>>>>>     --------------------------new text------------------------------=
-
>>>>>>>     The mechanism for indicating this=20
>>>>>>> preference is that, in an offer, if
>>>>>>>        the last character of any of the=20
>>>>>>> 'humintlang-recv' or 'humintlang-
>>>>>>>        send' values is an asterisk, this=20
>>>>>>> indicates a request to not fail the call.
>>>>>>>     The asterisk should be attached to=20
>>>>>>> attributes with languages of lower
>>>>>>>     preference to be matched if such=20
>>>>>>> difference can be specified. Thereby
>>>>>>>     the location of the asterisk can be used to support the decision=
 on
>>>>>>>     which languages to use in the call.
>>>>>>>     ---------------------------end of=20
>>>>>>> change 2 in=20
>>>>>>> 5.3--------------------------------------
>>>>>>>     Motivation: There has not yet been any=20
>>>>>>> conclusion for my proposal no 5 in the=20
>>>>>>> IETF LC comments of Feb 12.
>>>>>>>     This is a dramatically reduced version=20
>>>>>>> that may be easier to accept at this=20
>>>>>>> stage, still covering one of the missing=20
>>>>>>> functionalities in the draft.
>>>>>>>     The asterisk is used as a preference=20
>>>>>>> parameter in the attributes. Thereby the=20
>>>>>>> proposed title change on 5.3
>>>>>>>     With this additional rule about where=20
>>>>>>> the asterisk(s) are placed, the answering=20
>>>>>>> parties get good clues about the=20
>>>>>>> preferences between alternatives=20
>>>>>>> presented by the offeror. The chance to=20
>>>>>>> set up calls with satisfied users=20
>>>>>>> increase dramatically compared to letting=20
>>>>>>> the answering party select by chance=20
>>>>>>> between alternatives.
>>>>>>
>>>>>>    Making the asterisk a purely-advisory=20
>>>>>> hint as to the least-preferred=20
>>>>>> media/language combination seems harmless=20
>>>>>> enough, as it would not be required to=20
>>>>>> support it; however, I'm not sure it=20
>>>>>> provides any benefit: if an offer contains=20
>>>>>> some set of media with language, and the=20
>>>>>> answerer can support all of them, should=20
>>>>>> the answerer only include in its answer=20
>>>>>> those without an asterisk? It seems=20
>>>>>> simpler for the answerer to include=20
>>>>>> everything in the offer that it can=20
>>>>>> support.
>>>>>>
>>>>>
>>>>>    --
>>>>>    -----------------------------------------
>>>>>    Gunnar Hellstr=F6m
>>>>>    Omnitor
>>>>>    gunnar.hellstrom@omnitor.se
>>>>>    +46 708 204 288
>>>>
>>>>
>>>
>>>   --
>>>   -----------------------------------------
>>>   Gunnar Hellstr=F6m
>>>   Omnitor
>>>   gunnar.hellstrom@omnitor.se
>>>   +46 708 204 288
>>
>>
>
>  --
>  -----------------------------------------
>  Gunnar Hellstr=F6m
>  Omnitor
>  gunnar.hellstrom@omnitor.se
>  +46 708 204 288


-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Some days you feel like Schrodinger's cat.   --M. S. Hutchenreuther


From nobody Mon Feb 27 07:34: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 D83D212A150 for ; Mon, 27 Feb 2017 07:34:11 -0800 (PST)
X-Quarantine-ID: 
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -1.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 MO0b9ZcCV4JC for ; Mon, 27 Feb 2017 07:34:09 -0800 (PST)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 4BEFF12A137 for ; Mon, 27 Feb 2017 07:34:09 -0800 (PST)
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Mon, 27 Feb 2017 07:23:56 -0800
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <024da389-19d4-5e1b-4956-ee359580b4e1@omnitor.se>
References: <148782279664.31054.8793649134696520241.idtracker@ietfa.amsl.com>  <49fd730e-6e90-1a49-eae8-80f8b1285a76@omnitor.se>  <83152ba7-c3fb-25d8-f97d-59c7840cad56@omnitor.se>  <4b36f347-955e-e2b9-12f2-f426d47d3d33@omnitor.se> <59d7939c-d4c5-b74a-e960-3234f0524b39@omnitor.se>  <024da389-19d4-5e1b-4956-ee359580b4e1@omnitor.se>
X-Mailer: Eudora for Mac OS X
Date: Mon, 27 Feb 2017 07:34:03 -0800
To: Gunnar =?iso-8859-1?Q?Hellstr=F6m?=  , slim@ietf.org, Bernard Aboba 
From: Randall Gellens 
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
Archived-At: 
Subject: Re: [Slim] I-D Action: draft-ietf-slim-negotiating-human-language-07.txt
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Feb 2017 15:34:12 -0000

At 2:37 PM +0100 2/27/17, Gunnar Hellstr=F6m wrote:

>  Den 2017-02-27 kl. 02:01, skrev Randall Gellens:
>>  At 8:38 AM +0100 2/26/17, Gunnar Hellstr=F6m wrote:
>>
>>>   Randall,
>>>
>>>   One more clarification for issue 12 - the=20
>>> asterisk placement as a preference hint:
>>>
>>>   You say:
>>>
>>>   " it seems better for the answerer to=20
>>> include all media and languages from the=20
>>> offer that it can support. "
>>>
>>>   You are right. I misread this paragraph in section 5.2:
>>>   " In an answer, 'humintlang-send' is the language the answerer will
>>>   send (which in most cases is one of the languages in the offer's
>>>   'humintlang-recv'), and 'humintlang-recv' is the language the
>>>   answerer expects to receive (which in most cases is one of the
>>>   languages in the offer's 'humintlang-send')."
>>>
>>>   That gave me the impression that I need to=20
>>> answer with only one language per direction=20
>>> in the whole SDP.
>>
>>  It's per media.
>>
>>>   But in the first paragraph of 5.2, it is said: "to negotiate
>>>   which human language is used in each interactive media stream. "
>>>
>>>   So, we are allowed to include more than one=20
>>> language per direction in the SDP, but the=20
>>> users are not expected to use more than one=20
>>> language per direction, at least initially in=20
>>> the call.
>>
>>  There's nothing in the protocol that says=20
>> anything about people using more than one=20
>> media in each direction.
>>
>>>   (that makes the wording "will send" and=20
>>> "expects to receive" in the cited paragraph a=20
>>> bit misleading, because as you point out,=20
>>> some of them might never be used. "is=20
>>> prepared to send" and "can accept to receive"=20
>>> might better correspond to what it means.=20
>>> Ending the sentence with "per media steram"=20
>>> might also help to remind the reader about=20
>>> the semantics. I leave to you to change these=20
>>> if you want.)
>>
>>  OK, I'm happy to add the additional clarification.  The paragraph now re=
ads:
>>
>>     In an answer, 'hlang-send' is the language the answerer will send
>>     when using the media (which in most cases is one of the languages in
>>     the offer's 'hlang-recv'), and 'hlang-recv' is the language the
>>     answerer expects to receive in the media (which in most cases is one
>>     of the languages in the offer's 'hlang-send').
>
>  Yes, that might be acceptable if "will send=20
> when using the media" can be read as being=20
> conditional: "will send if use of the media for=20
> language purposes is selected",
>  but not if it is read as a definite usage "will=20
> send for the periods of time that this media=20
> will definitively be used for language=20
> communication."  With the latter interpretation=20
> we have not improved our logic over the lang=20
> attribute that could be interpreted as it=20
> required use of all declared languages in the=20
> session.

I think "when using the media" is clear.

>
>  I still think it is safer to say "is prepared=20
> to send" instead of "will send".
>  While for the other direction, I think the=20
> "expects to receive" is vague enough to mean=20
> that another media might be used.
>
>  Sorry for continuing to watch out for logic gaps here.
>
>  Gunnar
>>
>>
>>
>>>   Den 2017-02-26 kl. 07:46, skrev Gunnar Hellstr=F6m:
>>>
>>>>   Den 2017-02-25 kl. 20:58, skrev Randall Gellens:
>>>>
>>>>>   Hi Gunnar,
>>>>>
>>>>>   At 11:04 AM +0100 2/25/17, Gunnar Hellstr=F6m wrote:
>>>>>
>>>>>>   Fine, I find that we have only issues 5, 6 and 12 still to discuss.
>>>>>>
>>>>>>   You did not answer issue 6, use of=20
>>>>>> asymmetrical language rather than=20
>>>>>> unidirectional media. I assume you=20
>>>>>> accepted it.
>>>>>>
>>>>>
>>>>>   Yes, I thought I had indicated that, sorry if I didn't.
>>>>>
>>>>   Good.
>>>>
>>>>>
>>>>>>
>>>>>>   On 5, the request to reinsert wording=20
>>>>>> about seeing the speaker in video, it is=20
>>>>>> still a huge difference in specifying a=20
>>>>>> preference to see the speaker for language=20
>>>>>> perception reasons, versus only specifying=20
>>>>>> that I want a video stream for=20
>>>>>> supplementary purposes. With the current=20
>>>>>> wording in version -07, section 5.3 says=20
>>>>>> that that combination is undefined.=20
>>>>>> Nothing in the LC discussion indicated=20
>>>>>> that it should be undefined. Why did you=20
>>>>>> suddenly want to delete it? It is useful.=20
>>>>>> Please reinsert with the wording changes I=20
>>>>>> propose.
>>>>>>
>>>>>
>>>>>   The email discussion led me to believe=20
>>>>> that the text was controversial. We need to=20
>>>>> get the draft finished, so it's better to=20
>>>>> delete controversial text than to spend=20
>>>>> months fighting about it.
>>>>>
>>>>   The comments were first about the=20
>>>> uncertainty about how the "silly states"=20
>>>> were to be interpreted.
>>>>   We described them all but decided to only=20
>>>> keep the view of the speaker because it is a=20
>>>> real and useful case.
>>>>   The idea to differentiate spoken and=20
>>>> written cases by script tags caused=20
>>>> discussions and was dropped. The remaining=20
>>>> real case with the view of the speaker was=20
>>>> mentioned twice in the draft, so it was=20
>>>> recommended that one of them should be=20
>>>> deleted, but not both.
>>>>
>>>>>
>>>>>>
>>>>>>   On 12, the meaning of the placement of the asterisk, you ask:
>>>>>>   "Making the asterisk a purely-advisory=20
>>>>>> hint as to the least-preferred=20
>>>>>> media/language combination seems harmless=20
>>>>>> enough, as it would not be required to=20
>>>>>> support it; however, I'm not sure it=20
>>>>>> provides any benefit: if an offer contains=20
>>>>>> some set of media with language, and the=20
>>>>>> answerer can support all of them, should=20
>>>>>> the answerer only include in its answer=20
>>>>>> those without an asterisk? It seems=20
>>>>>> simpler for the answerer to include=20
>>>>>> everything in the offer that it can=20
>>>>>> support."
>>>>>>
>>>>>>   The answering party should aim at=20
>>>>>> answering with one of the languages that=20
>>>>>> is without the asterisk in the offer. Only=20
>>>>>> if the answering party does not have=20
>>>>>> capability in a language without an=20
>>>>>> asterisk, one with asterisk should be=20
>>>>>> selected. Thereby you get the best=20
>>>>>> opportunity to start the call in a=20
>>>>>> language combination that satisfies both=20
>>>>>> users.
>>>>>>
>>>>>>   Example: A hard-of-hearing user can just=20
>>>>>> barely conduct spoken calls with persons=20
>>>>>> she knows. From others it is much more=20
>>>>>> reliable to get text. She calls and=20
>>>>>> declares:
>>>>>>
>>>>>>   m=3Daudio
>>>>>>   a=3Dhuml-send:en
>>>>>>   a=3Dhuml-recv:en*
>>>>>>   m=3Dtext
>>>>>>   a=3Dhuml-recv:en
>>>>>>
>>>>>>   The answering party with text=20
>>>>>> capabilities sees that matching text for=20
>>>>>> sending is higher preferred than talking,=20
>>>>>> and thus responds:
>>>>>>
>>>>>>   m=3Daudio
>>>>>>   a=3Dhuml-recv:en
>>>>>>   m=3Dtext
>>>>>>   a=3Dhuml-send:en
>>>>>>
>>>>>>   The answering party sends the initial=20
>>>>>> greeting in text and the call continues=20
>>>>>> smoothly in well managed=20
>>>>>> langauage/modality combinations.
>>>>>>
>>>>>>   Another called party may not have text=20
>>>>>> capabilities, and may therefore select the=20
>>>>>> less favoured alternative with using=20
>>>>>> speech both ways, answering:
>>>>>>
>>>>>>   m=3Daudio
>>>>>>   a=3Dhuml-recv:en
>>>>>>   a=3Dhuml-send:en
>>>>>>   m=3Dtext 0
>>>>>>
>>>>>>   The answering party starts taking and the=20
>>>>>> parties try as well as possible to manage=20
>>>>>> the call in this less preferred=20
>>>>>> combination that may be less reliable.
>>>>>>
>>>>>>   If the placement of the asterisk had no=20
>>>>>> special meaning as it is in version -07,=20
>>>>>> it is a high risk that the answering party=20
>>>>>> in the first example would select to=20
>>>>>> answer with spoken language that would be=20
>>>>>> unreliably received. Time and effort would=20
>>>>>> be spent by speech to make the answering=20
>>>>>> party switch to sending text instead of=20
>>>>>> talking in order to arrange for a more=20
>>>>>> reliable call situation.
>>>>>>
>>>>>>   If instead the caller only indicated the most favoured combinations=
,
>>>>>>
>>>>>>   m=3Daudio
>>>>>>   a=3Dhuml-send:en
>>>>>>   m=3Dtext
>>>>>>   a=3Dhuml-recv:en
>>>>>>
>>>>>>   Then the answering parties without text=20
>>>>>> capability would not dare to try to=20
>>>>>> answer, and a reasonably successful call=20
>>>>>> would be missed.
>>>>>>
>>>>>>   Many other similar realistic examples can=20
>>>>>> be created, where placement of the=20
>>>>>> asterisk(s) would be a sufficient=20
>>>>>> indication of lower preference for=20
>>>>>> language match among alternatives that=20
>>>>>> would make call establishment successful=20
>>>>>> and smooth in many more cases than without=20
>>>>>> this indication opportunity.
>>>>>>
>>>>>>   Do you want more examples?
>>>>>>
>>>>>>   Please accept proposal 12.
>>>>>>
>>>>>
>>>>>   This convinces me that we cannot accept=20
>>>>> the proposed text, as it would introduce=20
>>>>> complexity that the WG explicitly decided=20
>>>>> to not pursue in this draft. In the=20
>>>>> examples you provided, it seems better for=20
>>>>> the answerer to include all media and=20
>>>>> languages from the offer that it can=20
>>>>> support. This is much simpler, has only=20
>>>>> trivial drawbacks (extra media negotiated=20
>>>>> that might not be used), and is what the WG=20
>>>>> agreed to.
>>>>>
>>>>   Yes, you could let the answer SDP contain=20
>>>> one common language per media and direction,=20
>>>> but the answering human need guidance on=20
>>>> which language is best suited to start the=20
>>>> conversation. Therefore the placement of the=20
>>>> asterisk is used to hint the answering party=20
>>>> how to start the call.
>>>>
>>>>   The first example above can be modified to:
>>>>
>>>>   Example: A hard-of-hearing user can just=20
>>>> barely conduct spoken calls with persons she=20
>>>> knows. From others it is much more reliable=20
>>>> to get text. She calls and declares:
>>>>
>>>>   m=3Daudio
>>>>   a=3Dhuml-send:en
>>>>   a=3Dhuml-recv:en*
>>>>   m=3Dtext
>>>>   a=3Dhuml-recv:en
>>>>
>>>>   The answering party with capabilities for=20
>>>> both written and spoken English sees that=20
>>>> matching text for sending is higher=20
>>>> preferred than talking and sends the answer=20
>>>> indicating the capabilities:
>>>>
>>>>   m=3Daudio
>>>>   a=3Dhuml-recv:en
>>>>   a=3Dhuml-send:en
>>>>   m=3Dtext
>>>>   a=3Dhuml-send:en
>>>>
>>>>   The answering party makes use of the hint=20
>>>> that the caller prefers to receive written=20
>>>> text and therefore sends the initial=20
>>>> greeting in text and the call continues=20
>>>> smoothly in well managed langauage/modality=20
>>>> combinations.
>>>>
>>>>   ----------
>>>>   There is no complexity left in this=20
>>>> solution, it helps to motivate why we have=20
>>>> the asterisk on media level, and it helps to=20
>>>> successful call initiations, so I think it=20
>>>> should be acceptable.
>>>>
>>>>   Gunnar
>>>>
>>>>>
>>>>>   --Randy
>>>>>
>>>>>>   Den 2017-02-25 kl. 01:32, skrev Randall Gellens:
>>>>>>
>>>>>>>   At 5:35 PM +0100 2/24/17, Gunnar Hellstr=F6m wrote:
>>>>>>>
>>>>>>>>   Den 2017-02-23 kl. 05:15, skrev Randall Gellens:
>>>>>>>>
>>>>>>>>>   Version -07 addresses all comments=20
>>>>>>>>> except for the unresolved issue of=20
>>>>>>>>> renaming the two attributes which is=20
>>>>>>>>> currently being discussed on the list,=20
>>>>>>>>> and adding a new attribute for=20
>>>>>>>>> bidirectionality.
>>>>>>>>>
>>>>>>>>>   Per Dale's suggestion, the draft adds=20
>>>>>>>>> advice that if a call is rejected due=20
>>>>>>>>> to no languages in common, SIP response=20
>>>>>>>>> code 488 (Not Acceptable Here) or 606=20
>>>>>>>>> (Not Acceptable) be used, along with a=20
>>>>>>>>> Warning header field indicating the=20
>>>>>>>>> supported languages. The draft=20
>>>>>>>>> registers a new entry in the warn-code=20
>>>>>>>>> sub-registry of SIP parameters for this=20
>>>>>>>>> purpose. The draft also has an expanded=20
>>>>>>>>> set of examples.
>>>>>>>>>
>>>>>>>>   Good progress. Good to see the enriched examples chapter 5.5.
>>>>>>>>   I have a few comments on version -07:
>>>>>>>>
>>>>>>>>   1. Section 4. second line
>>>>>>>>   ------------old text----------------------
>>>>>>>>   but is not sufficiently sufficiently
>>>>>>>>   ------------new text--------------------------
>>>>>>>>   but is not sufficiently
>>>>>>>>   ----------end of change 1-----------------
>>>>>>>>   Motivation: New typo in version -07
>>>>>>>>
>>>>>>>
>>>>>>>   Thanks.
>>>>>>>
>>>>>>>>
>>>>>>>>   2. Section 5.2, first line
>>>>>>>>   ----------------old text-----------------
>>>>>>>>   This document defines two new media-level ..
>>>>>>>>   ----------------new text----------------------
>>>>>>>>   This document defines two media-level ...
>>>>>>>>   ----------------end of change 2----------------
>>>>>>>>   Motivation: It was commented that when=20
>>>>>>>> the draft is published, this is not new=20
>>>>>>>> anymore.
>>>>>>>>   There are three more occasions of "new"=20
>>>>>>>> in the document that may be modified as=20
>>>>>>>> well.
>>>>>>>>
>>>>>>>
>>>>>>>   OK.
>>>>>>>
>>>>>>>>
>>>>>>>>   3. 5.2 second paragraph
>>>>>>>>   -------------------old text--------------------------------
>>>>>>>>   In an offer, the 'humintlang-send' values indicates the language(=
s)
>>>>>>>>   the offerer is willing to use when sending using the media, and t=
he
>>>>>>>>   'humintlang-recv' values indicates the language(s) the offerer is
>>>>>>>>   willing to use when receiving using the media.
>>>>>>>>   -----------------new text---------------------------------
>>>>>>>>   In an offer, the 'humintlang-send' values indicate the language(s=
)
>>>>>>>>   the offerer is willing to select from for use when sending using =
the
>>>>>>>>   media, and the 'humintlang-recv' values indicate the language(s) =
the
>>>>>>>>   offerer is willing to receive one of in the media stream.
>>>>>>>>   ----------------end of change----------------------------------
>>>>>>>>   Motivation 1:) change from "indicates"=20
>>>>>>>> to "indicate" in two places to match the=20
>>>>>>>> new use of plural "values".
>>>>>>>>   Motivation 2:) Be sure to indicate that=20
>>>>>>>> we only intend to negotiate one language=20
>>>>>>>> per media and direction, so that we do=20
>>>>>>>> not end up as unspecified regarding=20
>>>>>>>> number of matches required as the sdp=20
>>>>>>>> "lang" attribute is.
>>>>>>>>
>>>>>>>
>>>>>>>   Reworded.
>>>>>>>
>>>>>>>>
>>>>>>>>   4. 5.2 Second paragraph
>>>>>>>>   -----------------old text-----------------------
>>>>>>>>   When a media is intended
>>>>>>>>   for use in one direction only
>>>>>>>>   ----------------new text---------------------
>>>>>>>>   When a media is intended
>>>>>>>>   for use for language communication in one direction only
>>>>>>>>   ----------------end of change---------------------------
>>>>>>>>   Motivation: Deletion of a note in this=20
>>>>>>>> sentence made it less obvious that we=20
>>>>>>>> are only talking about directions of use=20
>>>>>>>> of language communication, and not about=20
>>>>>>>> establishing asymmetric media=20
>>>>>>>> connections. Therefore add this=20
>>>>>>>> clarification.
>>>>>>>>
>>>>>>>
>>>>>>>   Reworded.
>>>>>>>
>>>>>>>>
>>>>>>>>   5. 5.2 Deleted paragraph 6 before "Clients acting on behalf..."
>>>>>>>>   ----------reinsert modified paragraph----------------------------
>>>>>>>>   While signed language tags are used with a video stream to
>>>>>>>>   indicate sign language, a spoken language tag for a video stream
>>>>>>>>   indicates a request or offer to see the speaker, when that is of
>>>>>>>>   importance for language perception.
>>>>>>>>   -------------end of change---------------------------------------=
----
>>>>>>>>   Motivation: There was in the LC mail=20
>>>>>>>> exchange a discussion about sharpening=20
>>>>>>>> up the specification of use of "unusual=20
>>>>>>>> combinations".
>>>>>>>>   There was no agreement to delete them=20
>>>>>>>> all. The one described in this paragraph=20
>>>>>>>> is the main one that has widespread use=20
>>>>>>>> and needs to be clearly specified for=20
>>>>>>>> use by a large number of hard-of-hearing=20
>>>>>>>> and deaf users.
>>>>>>>>
>>>>>>>
>>>>>>>   The text as it is now does not prohibit=20
>>>>>>> anything and explicitly mentions=20
>>>>>>> negotiating supplemental video by=20
>>>>>>> omitting language attributes on a video=20
>>>>>>> media.
>>>>>>>
>>>>>>>>
>>>>>>>>   6. 5.2 Sixth paragraph
>>>>>>>>   --------------------current text--------------------
>>>>>>>>   (or for unidirectional streams, one of)
>>>>>>>>   ------------------new text ------------------------
>>>>>>>>   (or for asymmetrical use of languages, one of)
>>>>>>>>   -----------------end of change----------------------
>>>>>>>>   Motivation: We are not primarily=20
>>>>>>>> talking about enabled transmission=20
>>>>>>>> directions of the streams, but about=20
>>>>>>>> language use in the streams. We do not=20
>>>>>>>> want to limit the media stream=20
>>>>>>>> directions just because we do not=20
>>>>>>>> specify an initial language to use for=20
>>>>>>>> that direction. There are other usage of=20
>>>>>>>> media, and there may even be occasional=20
>>>>>>>> use of language in the direction, just=20
>>>>>>>> not worth mentioning as an initial and=20
>>>>>>>> preferred use. The suggested change=20
>>>>>>>> should make that clear.
>>>>>>>>
>>>>>>>>   7. 5.3 Next to last paragraph
>>>>>>>>   ------------------old text------------------------------
>>>>>>>>   a list of supported languages.
>>>>>>>>   -------------------new text-------------------------
>>>>>>>>   a list of supported languages, media and directions.
>>>>>>>>   -------------------end of change----------------
>>>>>>>>   Motivation: It is not sufficient to=20
>>>>>>>> know which languages are supported, it=20
>>>>>>>> is also essential to know in which media=20
>>>>>>>> they are supported and in which=20
>>>>>>>> directions. (media could be replaced=20
>>>>>>>> with modality, but the media can become=20
>>>>>>>> ambigous then, so use media here to be=20
>>>>>>>> brief.
>>>>>>>>
>>>>>>>
>>>>>>>   I don't know that we can require this,=20
>>>>>>> but I'll add SHOULD kist supported=20
>>>>>>> languages and media. Demanding direction=20
>>>>>>> as well might be too unwieldy.
>>>>>>>
>>>>>>>>
>>>>>>>>   8. 5.3, last line
>>>>>>>>   --------------old text----------------------------------
>>>>>>>>   Supported languages are: es, en"
>>>>>>>>   --------------new text-------------------------------
>>>>>>>>   Supported languages are: es, en=20
>>>>>>>> transmission in audio; es, en reception=20
>>>>>>>> in audio"
>>>>>>>>   ----------------------------------------------------------
>>>>>>>>   Motivation: Same as for 7.
>>>>>>>>
>>>>>>>
>>>>>>>   Fixed as above.
>>>>>>>
>>>>>>>>
>>>>>>>>   9. 5.4 Undefined combinations
>>>>>>>>   ----------------------------old=20
>>>>>>>> text--------------------------------------
>>>>>>>>   The behavior when specifying a non-signed language tag for a vide=
o
>>>>>>>>   media stream, or a signed language tag for an audio or text media
>>>>>>>>   stream, is not defined.
>>>>>>>>   ---------------------------new=20
>>>>>>>> text-----------------------------------------
>>>>>>>>   There is no way specified for=20
>>>>>>>> indicating use of text based language in=20
>>>>>>>> a video media stream.
>>>>>>>>   There is no meaning assigned to=20
>>>>>>>> specification of sign language in an=20
>>>>>>>> audio or text media stream.
>>>>>>>>   --------------------------end of=20
>>>>>>>> change-------------------------------
>>>>>>>>   Motivation: Seeing the speaker in video=20
>>>>>>>> is an important combination reinserted=20
>>>>>>>> above in section 5.2.
>>>>>>>>   This section therefore needed rewording=20
>>>>>>>> to not include that combination.
>>>>>>>>
>>>>>>>
>>>>>>>   The draft explicitly mentions video for supplemental purposes.
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>   10. 6.2 Last sentence
>>>>>>>>   -----------------current text---------------------
>>>>>>>>   Supported languages are: [list of supported languages]."
>>>>>>>>   -----------------new text------------------------
>>>>>>>>   Supported languages and media and=20
>>>>>>>> transmission directions are:[list of=20
>>>>>>>> supported languages and media and=20
>>>>>>>> transmission directions.]"
>>>>>>>>   -----------------end of change--------------------------
>>>>>>>>   Motivation: Same as for 7.
>>>>>>>>
>>>>>>>
>>>>>>>   Fixed as above.
>>>>>>>
>>>>>>>>
>>>>>>>>   11. 6.1 MUX Category
>>>>>>>>   ----------old text in two locations-------------------
>>>>>>>>   MUX Category: normal
>>>>>>>>   ---------new text in same two locations--------------
>>>>>>>>   Mux Category: NORMAL
>>>>>>>>   ---------end of change-----------------
>>>>>>>>   Motivation: Follow RFC 4566bis and IANA=20
>>>>>>>> habits regarding use of capitals
>>>>>>>>
>>>>>>>
>>>>>>>   Fixed.
>>>>>>>
>>>>>>>>
>>>>>>>>   12. 5.3
>>>>>>>>   -------------old text-----------------
>>>>>>>>   5.3 No Language in Common
>>>>>>>>   -------------new text----------------
>>>>>>>>   5.3 Preference parameter
>>>>>>>>   ------------end of change 1 in 5.3---------------
>>>>>>>>
>>>>>>>
>>>>>>>   The section is more than just the=20
>>>>>>> asterisk, it also advises use of specific=20
>>>>>>> SIP response codes if the call is failed.
>>>>>>>
>>>>>>>>
>>>>>>>>   -------------old text-in 5.3, second=20
>>>>>>>> paragraph-------------------------------
>>>>>>>>   The mechanism for indicating this preference is that, in an=
 offer, if
>>>>>>>>   the last character of any of the 'humintlang-recv' or 'humintlang=
-
>>>>>>>>   send' values is an asterisk, this=20
>>>>>>>> indicates a request to not fail the call.
>>>>>>>>   --------------------------new text-------------------------------
>>>>>>>>   The mechanism for indicating this preference is that, in an=
 offer, if
>>>>>>>>   the last character of any of the 'humintlang-recv' or 'humintlang=
-
>>>>>>>>   send' values is an asterisk, this=20
>>>>>>>> indicates a request to not fail the call.
>>>>>>>>   The asterisk should be attached to attributes with languages of l=
ower
>>>>>>>>   preference to be matched if such difference can be specified. The=
reby
>>>>>>>>   the location of the asterisk can be used to support the decision =
on
>>>>>>>>   which languages to use in the call.
>>>>>>>>   ---------------------------end of=20
>>>>>>>> change 2 in=20
>>>>>>>> 5.3--------------------------------------
>>>>>>>>   Motivation: There has not yet been any=20
>>>>>>>> conclusion for my proposal no 5 in the=20
>>>>>>>> IETF LC comments of Feb 12.
>>>>>>>>   This is a dramatically reduced version=20
>>>>>>>> that may be easier to accept at this=20
>>>>>>>> stage, still covering one of the missing=20
>>>>>>>> functionalities in the draft.
>>>>>>>>   The asterisk is used as a preference=20
>>>>>>>> parameter in the attributes. Thereby the=20
>>>>>>>> proposed title change on 5.3
>>>>>>>>   With this additional rule about where=20
>>>>>>>> the asterisk(s) are placed, the=20
>>>>>>>> answering parties get good clues about=20
>>>>>>>> the preferences between alternatives=20
>>>>>>>> presented by the offeror. The chance to=20
>>>>>>>> set up calls with satisfied users=20
>>>>>>>> increase dramatically compared to=20
>>>>>>>> letting the answering party select by=20
>>>>>>>> chance between alternatives.
>>>>>>>>
>>>>>>>
>>>>>>>   Making the asterisk a purely-advisory=20
>>>>>>> hint as to the least-preferred=20
>>>>>>> media/language combination seems harmless=20
>>>>>>> enough, as it would not be required to=20
>>>>>>> support it; however, I'm not sure it=20
>>>>>>> provides any benefit: if an offer=20
>>>>>>> contains some set of media with language,=20
>>>>>>> and the answerer can support all of them,=20
>>>>>>> should the answerer only include in its=20
>>>>>>> answer those without an asterisk? It=20
>>>>>>> seems simpler for the answerer to include=20
>>>>>>> everything in the offer that it can=20
>>>>>>> support.
>>>>>>>
>>>>>>
>>>>>>   --
>>>>>>   -----------------------------------------
>>>>>>   Gunnar Hellstr=F6m
>>>>>>   Omnitor
>>>>>>   gunnar.hellstrom@omnitor.se
>>>>>>   +46 708 204 288
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>   --
>>>   -----------------------------------------
>>>   Gunnar Hellstr=F6m
>>>   Omnitor
>>>   gunnar.hellstrom@omnitor.se
>>>   +46 708 204 288
>>
>>
>
>  --
>  -----------------------------------------
>  Gunnar Hellstr=F6m
>  Omnitor
>  gunnar.hellstrom@omnitor.se
>  +46 708 204 288


-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
This is a nasty, rotten business.
    --Robert L. Crandall, CEO & President of American Airlines


From nobody Mon Feb 27 14:54:14 2017
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21683129458 for ; Mon, 27 Feb 2017 14:54:12 -0800 (PST)
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 sC3QYfaIAnae for ; Mon, 27 Feb 2017 14:53:56 -0800 (PST)
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 9400712944F for ; Mon, 27 Feb 2017 14:53:47 -0800 (PST)
X-Halon-ID: 92121b10-fd3f-11e6-af93-005056917f90
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [77.53.231.21]) by bin-vsp-out-02.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Mon, 27 Feb 2017 23:53:32 +0100 (CET)
To: Randall Gellens , slim@ietf.org, Natasha Rooney , Bernard Aboba , "Phillips, Addison" 
References: <148782279664.31054.8793649134696520241.idtracker@ietfa.amsl.com>  <49fd730e-6e90-1a49-eae8-80f8b1285a76@omnitor.se>  <83152ba7-c3fb-25d8-f97d-59c7840cad56@omnitor.se>  <4b36f347-955e-e2b9-12f2-f426d47d3d33@omnitor.se>  <7f844aaa-17ce-2ab7-0602-a999a40235de@omnitor.se> 
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: <825fa638-b223-d716-6a3c-238903a37b92@omnitor.se>
Date: Mon, 27 Feb 2017 23:53:35 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
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] I-D Action: draft-ietf-slim-negotiating-human-language-07.txt
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Feb 2017 22:54:12 -0000

Den 2017-02-27 kl. 16:31, skrev Randall Gellens:
> At 9:01 AM +0100 2/27/17, Gunnar Hellström wrote:
>
>>  Randall,
>>  good to see that we are converging,
>>  Den 2017-02-27 kl. 01:55, skrev Randall Gellens:
>>>  At 7:46 AM +0100 2/26/17, Gunnar Hellström wrote:
>>>
>>>>   Den 2017-02-25 kl. 20:58, skrev Randall Gellens:
>>>>>   Hi Gunnar,
>>>>>
>>>>>   At 11:04 AM +0100 2/25/17, Gunnar Hellström wrote:
>>>>>
>>>>>>    Fine, I find that we have only issues 5, 6 and 12 still to 
>>>>>> discuss.
>>>>>>
>>>>>>    You did not answer issue 6, use of asymmetrical language 
>>>>>> rather than unidirectional media. I assume you accepted it.
>>>>>
>>>>>   Yes, I thought I had indicated that, sorry if I didn't.
>>>>   Good.
>>>>>
>>>>>>
>>>>>>    On 5, the request to reinsert wording about seeing the speaker 
>>>>>> in video, it is still a huge difference in specifying a 
>>>>>> preference to see the speaker for language perception reasons, 
>>>>>> versus only specifying that I want a video stream for 
>>>>>> supplementary purposes. With the current wording in version -07, 
>>>>>> section 5.3 says that that combination is undefined. Nothing in 
>>>>>> the LC discussion indicated that it should be undefined. Why did 
>>>>>> you suddenly want to delete it? It is useful. Please reinsert 
>>>>>> with the wording changes I propose.
>>>>>
>>>>>   The email discussion led me to believe that the text was 
>>>>> controversial.  We need to get the draft finished, so it's better 
>>>>> to delete controversial text than to spend months fighting about it.
>>>>   The comments were first about the uncertainty about how the 
>>>> "silly states" were to be interpreted.
>>>>   We described them all but decided to only keep the view of the 
>>>> speaker because it is a real and useful case.
>>>>   The idea to differentiate spoken and written cases by script tags 
>>>> caused discussions and was dropped. The remaining real case with 
>>>> the view of the speaker was mentioned twice in the draft, so it was 
>>>> recommended that one of them should be deleted, but not both.
>>>
>>>  OK, I'll restore the text in section 5.2:
>>>
>>>     Note that while signed language tags are used with a video 
>>> stream to
>>>     indicate sign language, a spoken language tag for a video stream in
>>>     parallel with an audio stream with the same spoken language tag
>>>     indicates a request for a supplemental video stream to see the
>>>     speaker.
>>>
>>>  And modify section 5.4 to exclude this case:
>>>
>>>     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.
>>  Addison did not like the expression "spoken/written language tag" 
>> when we used it in the discussion about section 5.4.
>>  We may get the same reaction here.
>>  You would have avoided it if you took my wording proposal as it was.
>>>
>>>
>>>>>
>>>>>>
>>>>>>    On 12, the meaning of the placement of the asterisk, you ask:
>>>>>>    "Making the asterisk a purely-advisory hint as to the 
>>>>>> least-preferred media/language combination seems harmless enough, 
>>>>>> as it would not be required to support it; however, I'm not sure 
>>>>>> it provides any benefit: if an offer contains some set of media 
>>>>>> with language, and the answerer can support all of them, should 
>>>>>> the answerer only include in its answer those without an 
>>>>>> asterisk? It seems simpler for the answerer to include everything 
>>>>>> in the offer that it can support."
>>>>>>
>>>>>>    The answering party should aim at answering with one of the 
>>>>>> languages that is without the asterisk in the offer. Only if the 
>>>>>> answering party does not have capability in a language without an 
>>>>>> asterisk, one with asterisk should be selected. Thereby you get 
>>>>>> the best opportunity to start the call in a language combination 
>>>>>> that satisfies both users.
>>>>>>
>>>>>>    Example: A hard-of-hearing user can just barely conduct spoken 
>>>>>> calls with persons she knows. From others it is much more 
>>>>>> reliable to get text.  She calls and declares:
>>>>>>
>>>>>>    m=audio
>>>>>>    a=huml-send:en
>>>>>>    a=huml-recv:en*
>>>>>>    m=text
>>>>>>    a=huml-recv:en
>>>>>>
>>>>>>    The answering party with text capabilities sees that matching 
>>>>>> text for sending is higher preferred than talking, and thus 
>>>>>> responds:
>>>>>>
>>>>>>    m=audio
>>>>>>    a=huml-recv:en
>>>>>>    m=text
>>>>>>    a=huml-send:en
>>>>>>
>>>>>>    The answering party sends the initial greeting in text and the 
>>>>>> call continues smoothly in well managed langauage/modality 
>>>>>> combinations.
>>>>>>
>>>>>>    Another called party may not have text capabilities, and may 
>>>>>> therefore select the less favoured alternative with using speech 
>>>>>> both ways, answering:
>>>>>>
>>>>>>    m=audio
>>>>>>    a=huml-recv:en
>>>>>>    a=huml-send:en
>>>>>>    m=text 0
>>>>>>
>>>>>>    The answering party starts taking and the parties try as well 
>>>>>> as possible to manage the call in this less preferred combination 
>>>>>> that may be less reliable.
>>>>>>
>>>>>>    If the placement of the asterisk had no special meaning as it 
>>>>>> is in version -07, it is a high risk that the answering party in 
>>>>>> the first example would select to answer with spoken language 
>>>>>> that would be unreliably received. Time and effort would be spent 
>>>>>> by speech to make the answering party switch to sending text 
>>>>>> instead of talking in order to arrange for a more reliable call 
>>>>>> situation.
>>>>>>
>>>>>>    If instead the caller only indicated the most favoured 
>>>>>> combinations,
>>>>>>
>>>>>>    m=audio
>>>>>>    a=huml-send:en
>>>>>>    m=text
>>>>>>    a=huml-recv:en
>>>>>>
>>>>>>    Then the answering parties without text capability would not 
>>>>>> dare to try to answer, and a reasonably successful call would be 
>>>>>> missed.
>>>>>>
>>>>>>    Many other similar realistic examples can be created, where 
>>>>>> placement of the asterisk(s) would be a sufficient indication of 
>>>>>> lower preference for language match among alternatives that would 
>>>>>> make call establishment successful and smooth in many more cases 
>>>>>> than without this indication opportunity.
>>>>>>
>>>>>>    Do you want more examples?
>>>>>>
>>>>>>    Please accept proposal 12.
>>>>>
>>>>>   This convinces me that we cannot accept the proposed text, as it 
>>>>> would introduce complexity that the WG explicitly decided to not 
>>>>> pursue in this draft.  In the examples you provided, it seems 
>>>>> better for the answerer to include all media and languages from 
>>>>> the offer that it can support.  This is much simpler, has only 
>>>>> trivial drawbacks (extra media negotiated that might not be used), 
>>>>> and is what the WG agreed to.
>>>>   Yes, you could let the answer SDP contain one common language per 
>>>> media and direction, but the answering human need guidance on which 
>>>> language is best suited to start the conversation. Therefore the 
>>>> placement of the asterisk is used to hint the answering party how 
>>>> to start the call.
>>>
>>>  I believe the WG discussed proposals to provide information to the 
>>> humans regarding the languages and media that were negotiated, and 
>>> decided it is out of scope of the draft as an implementation issue, 
>>> not a protocol issue.
>>  Yes, we did, and said that the mechanism for providing the result of 
>> the indication and negotiation to the user is out of scope, but the 
>> resulting information needs to be provided to the user. It is the 
>> user who generates language and the user needs to know the most 
>> preferred common languages so that the user can start the call in an 
>> appropriate language.
>>  This is valid for the language as well as the preference indication.
>>
>>  And we say that by the end of section 1. " Both sides should be 
>> aware of which language was negotiated."    No mechanism specified, 
>> but the result needs to be conveyed to the user.
>>
>>  Now, when there is no required protocol influence implied by the 
>> placement of the asterisk, all feared complexity is gone and only the 
>> huge increase in usability remains.
>>
>>  It is not fair that users who want to express preference between 
>> languages in a single modality can do it, but users who have 
>> preferences between languages in different modalities cannot indicate 
>> that. Let us cover that gap when it is so free from complexity to do it.
>
> Conveying information to the user is UI which is out of scope of this 
> draft.
We are talking about protocol just as much as for specifying the 
languages. We are not saying how the result of language negotiation is 
provided to the user, because the procedure is out of scope. But we say 
that the user must be made aware of the result of the indication and 
negotiation. Otherwise they will not be able to start the call in the 
preferred language. Both languages and preferences need to be indicated 
to the users.
All resulting information need to be conveyed to the user and we do not 
say how for any of the items, we just say that that is the intention of 
sending all these indications.

Please be positive to the minimal proposal we are down to now, adding a 
sentence and changing the title of section 5.3, and let us ask our 
chairs for the correct procedure to include it.

/Gunnar


>
>>
>>>
>>>>
>>>>   The first example above can be modified to:
>>>>
>>>>    Example: A hard-of-hearing user can just barely conduct spoken 
>>>> calls with persons she knows. From others it is much more reliable 
>>>> to get text.  She calls and declares:
>>>>
>>>>    m=audio
>>>>    a=huml-send:en
>>>>    a=huml-recv:en*
>>>>    m=text
>>>>    a=huml-recv:en
>>>>
>>>>    The answering party with capabilities for both written and 
>>>> spoken English sees that matching text for sending is higher 
>>>> preferred than talking and sends the answer indicating the 
>>>> capabilities:
>>>>
>>>>    m=audio
>>>>    a=huml-recv:en
>>>>   a=huml-send:en
>>>>    m=text
>>>>    a=huml-send:en
>>>>
>>>>    The answering party makes use of the hint that the caller 
>>>> prefers to receive written text and therefore sends the initial 
>>>> greeting in text and the call continues smoothly in well managed 
>>>> langauage/modality combinations.
>>>>
>>>>   ----------
>>>>   There is no complexity left in this solution, it helps to 
>>>> motivate why we have the asterisk on media level, and it helps to 
>>>> successful call initiations, so I think it should be acceptable.
>>>
>>>  My suggestion is that you write this idea as a new draft offering 
>>> implementation guidance, and ask the WG to adopt it as either 
>>> Informational or BCP.  It doesn't affect the protocol in the current 
>>> draft, but provides guidance on how to use the protocol in both an 
>>> offer and an answer and potentially in the UI.
>>  I suggest that the chairs and area director assign a procedure 
>> suitable for the current state of the draft to potentially include 
>> the meaning of the placement of the asterisk as proposed in my issue 12.
>
> UI is out of scope of the draft.  If you write an "advice to 
> implementers" type document, that can accomplish your goal.
>
>
>
>>
>>  Thanks
>>  Gunnar
>>>
>>>
>>>
>>>>>
>>>>>>    Den 2017-02-25 kl. 01:32, skrev Randall Gellens:
>>>>>>>    At 5:35 PM +0100 2/24/17, Gunnar Hellström wrote:
>>>>>>>
>>>>>>>>     Den 2017-02-23 kl. 05:15, skrev Randall Gellens:
>>>>>>>>>     Version -07 addresses all comments except for the 
>>>>>>>>> unresolved issue of renaming the two attributes which is 
>>>>>>>>> currently being discussed on the list, and adding a new 
>>>>>>>>> attribute for bidirectionality.
>>>>>>>>>
>>>>>>>>>     Per Dale's suggestion, the draft adds advice that if a 
>>>>>>>>> call is rejected due to no languages in common, SIP response 
>>>>>>>>> code 488 (Not Acceptable Here) or 606 (Not Acceptable) be 
>>>>>>>>> used, along with a Warning header field indicating the 
>>>>>>>>> supported languages.  The draft registers a new entry in the 
>>>>>>>>> warn-code sub-registry of SIP parameters for this purpose.  
>>>>>>>>> The draft also has an expanded set of examples.
>>>>>>>>>
>>>>>>>>     Good progress. Good to see the enriched examples chapter 5.5.
>>>>>>>>     I have a few comments on version -07:
>>>>>>>>
>>>>>>>>     1.  Section  4. second line
>>>>>>>>     ------------old text----------------------
>>>>>>>>     but is not sufficiently sufficiently
>>>>>>>>     ------------new text--------------------------
>>>>>>>>     but is not sufficiently
>>>>>>>>     ----------end of change 1-----------------
>>>>>>>>     Motivation: New typo in version -07
>>>>>>>
>>>>>>>    Thanks.
>>>>>>>
>>>>>>>>
>>>>>>>>     2. Section 5.2, first line
>>>>>>>>     ----------------old text-----------------
>>>>>>>>     This document defines two new media-level ..
>>>>>>>>     ----------------new text----------------------
>>>>>>>>     This document defines two media-level ...
>>>>>>>>     ----------------end of change 2----------------
>>>>>>>>     Motivation: It was commented that when the draft is 
>>>>>>>> published, this is not new anymore.
>>>>>>>>     There are three more occasions of "new" in the document 
>>>>>>>> that may be modified as well.
>>>>>>>
>>>>>>>    OK.
>>>>>>>
>>>>>>>>
>>>>>>>>     3.  5.2 second paragraph
>>>>>>>>     -------------------old text--------------------------------
>>>>>>>>     In an offer, the 'humintlang-send' values indicates the 
>>>>>>>> language(s)
>>>>>>>>        the offerer is willing to use when sending using the 
>>>>>>>> media, and the
>>>>>>>>        'humintlang-recv' values indicates the language(s) the 
>>>>>>>> offerer is
>>>>>>>>        willing to use when receiving using the media.
>>>>>>>>     -----------------new text---------------------------------
>>>>>>>>     In an offer, the 'humintlang-send' values indicate the 
>>>>>>>> language(s)
>>>>>>>>     the offerer is willing to select from for use when sending 
>>>>>>>> using the
>>>>>>>>     media, and the 'humintlang-recv' values indicate the 
>>>>>>>> language(s) the
>>>>>>>>     offerer is willing to receive one of in the media stream.
>>>>>>>>     ----------------end of 
>>>>>>>> change----------------------------------
>>>>>>>>     Motivation 1:) change from "indicates" to "indicate" in two 
>>>>>>>> places to match the new use of plural "values".
>>>>>>>>     Motivation 2:) Be sure to indicate that we only intend to 
>>>>>>>> negotiate one language per media and direction, so that we do 
>>>>>>>> not end up as unspecified regarding number of matches required 
>>>>>>>> as the sdp "lang" attribute is.
>>>>>>>
>>>>>>>    Reworded.
>>>>>>>
>>>>>>>>
>>>>>>>>     4.  5.2 Second paragraph
>>>>>>>>     -----------------old text-----------------------
>>>>>>>>     When a media is intended
>>>>>>>>        for use in one direction only
>>>>>>>>     ----------------new text---------------------
>>>>>>>>     When a media is intended
>>>>>>>>        for use for language communication in one direction only
>>>>>>>>     ----------------end of change---------------------------
>>>>>>>>     Motivation: Deletion of a note in this sentence made it 
>>>>>>>> less obvious that we are only talking about directions of use 
>>>>>>>> of language communication, and not about establishing 
>>>>>>>> asymmetric media connections. Therefore add this clarification.
>>>>>>>
>>>>>>>    Reworded.
>>>>>>>
>>>>>>>>
>>>>>>>>     5.  5.2 Deleted paragraph 6 before "Clients acting on 
>>>>>>>> behalf..."
>>>>>>>>     ----------reinsert modified 
>>>>>>>> paragraph----------------------------
>>>>>>>>     While signed language tags are used with a video stream to
>>>>>>>>     indicate sign language, a spoken language tag for a video 
>>>>>>>> stream
>>>>>>>>     indicates a request or offer to see the speaker, when that 
>>>>>>>> is of
>>>>>>>>     importance for language perception.
>>>>>>>>     -------------end of 
>>>>>>>> change-------------------------------------------
>>>>>>>>     Motivation: There was in the LC mail exchange a discussion 
>>>>>>>> about sharpening up the specification of use of "unusual 
>>>>>>>> combinations".
>>>>>>>>     There was no agreement to delete them all. The one 
>>>>>>>> described in this paragraph is the main one that has widespread 
>>>>>>>> use and needs to be clearly specified for use by a large number 
>>>>>>>> of hard-of-hearing and deaf users.
>>>>>>>
>>>>>>>    The text as it is now does not prohibit anything and 
>>>>>>> explicitly mentions negotiating supplemental video by omitting 
>>>>>>> language attributes on a video media.
>>>>>>>
>>>>>>>>
>>>>>>>>     6.  5.2 Sixth paragraph
>>>>>>>>     --------------------current text--------------------
>>>>>>>>     (or for unidirectional streams, one of)
>>>>>>>>     ------------------new text ------------------------
>>>>>>>>     (or for asymmetrical use of languages, one of)
>>>>>>>>     -----------------end of change----------------------
>>>>>>>>     Motivation: We are not primarily talking about enabled 
>>>>>>>> transmission directions of the streams, but about language use 
>>>>>>>> in the streams. We do not want to limit the media stream 
>>>>>>>> directions just because we do not specify an initial language 
>>>>>>>> to use for that direction. There are other usage of media, and 
>>>>>>>> there may even be occasional use of language in the direction, 
>>>>>>>> just not worth mentioning as an initial and preferred use. The 
>>>>>>>> suggested change should make that clear.
>>>>>>>>
>>>>>>>>     7.   5.3 Next to last paragraph
>>>>>>>>     ------------------old text------------------------------
>>>>>>>>     a list of supported languages.
>>>>>>>>     -------------------new text-------------------------
>>>>>>>>     a list of supported languages, media and directions.
>>>>>>>>     -------------------end of change----------------
>>>>>>>>     Motivation: It is not sufficient to know which languages 
>>>>>>>> are supported, it is also essential to know in which media they 
>>>>>>>> are supported and in which directions. (media could be replaced 
>>>>>>>> with modality, but the media can become ambigous then, so use 
>>>>>>>> media here to be brief.
>>>>>>>
>>>>>>>    I don't know that we can require this, but I'll add SHOULD 
>>>>>>> kist supported languages and media. Demanding direction as well 
>>>>>>> might be too unwieldy.
>>>>>>>
>>>>>>>>
>>>>>>>>     8.      5.3, last line
>>>>>>>>     --------------old text----------------------------------
>>>>>>>>      Supported languages are: es, en"
>>>>>>>>     --------------new text-------------------------------
>>>>>>>>      Supported languages are: es, en transmission in audio; es, 
>>>>>>>> en reception in audio"
>>>>>>>>  ----------------------------------------------------------
>>>>>>>>     Motivation: Same as for 7.
>>>>>>>
>>>>>>>    Fixed as above.
>>>>>>>
>>>>>>>>
>>>>>>>>     9.  5.4 Undefined combinations
>>>>>>>>     ----------------------------old 
>>>>>>>> text--------------------------------------
>>>>>>>>        The behavior when specifying a non-signed language tag 
>>>>>>>> for a video
>>>>>>>>        media stream, or a signed language tag for an audio or 
>>>>>>>> text media
>>>>>>>>        stream, is not defined.
>>>>>>>>     ---------------------------new 
>>>>>>>> text-----------------------------------------
>>>>>>>>     There is no way specified for indicating use of text based 
>>>>>>>> language in a video media stream.
>>>>>>>>     There is no meaning assigned to specification of sign 
>>>>>>>> language in an audio or text media stream.
>>>>>>>>     --------------------------end of 
>>>>>>>> change-------------------------------
>>>>>>>>     Motivation: Seeing the speaker in video is an important 
>>>>>>>> combination reinserted above in section 5.2.
>>>>>>>>     This section therefore needed rewording to not include that 
>>>>>>>> combination.
>>>>>>>
>>>>>>>    The draft explicitly mentions video for supplemental purposes.
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>     10.     6.2 Last sentence
>>>>>>>>     -----------------current text---------------------
>>>>>>>>     Supported languages are: [list of supported languages]."
>>>>>>>>     -----------------new text------------------------
>>>>>>>>     Supported languages and media and transmission directions 
>>>>>>>> are:[list of supported languages and media and transmission 
>>>>>>>> directions.]"
>>>>>>>>     -----------------end of change--------------------------
>>>>>>>>     Motivation: Same as for 7.
>>>>>>>
>>>>>>>    Fixed as above.
>>>>>>>
>>>>>>>>
>>>>>>>>     11.  6.1 MUX Category
>>>>>>>>     ----------old text in two locations-------------------
>>>>>>>>     MUX Category:  normal
>>>>>>>>     ---------new text in same two locations--------------
>>>>>>>>     Mux Category:  NORMAL
>>>>>>>>     ---------end of change-----------------
>>>>>>>>     Motivation: Follow RFC 4566bis and IANA habits regarding 
>>>>>>>> use of capitals
>>>>>>>
>>>>>>>    Fixed.
>>>>>>>
>>>>>>>>
>>>>>>>>     12.  5.3
>>>>>>>>     -------------old text-----------------
>>>>>>>>     5.3 No Language in Common
>>>>>>>>     -------------new text----------------
>>>>>>>>     5.3 Preference parameter
>>>>>>>>     ------------end of change 1 in 5.3---------------
>>>>>>>
>>>>>>>    The section is more than just the asterisk, it also advises 
>>>>>>> use of specific SIP response codes if the call is failed.
>>>>>>>
>>>>>>>>
>>>>>>>>     -------------old text-in 5.3, second 
>>>>>>>> paragraph-------------------------------
>>>>>>>>     The mechanism for indicating this preference is that, in an 
>>>>>>>> offer, if
>>>>>>>>     the last character of any of the 'humintlang-recv' or 
>>>>>>>> 'humintlang-
>>>>>>>>     send' values is an asterisk, this indicates a request to 
>>>>>>>> not fail the call.
>>>>>>>>     --------------------------new 
>>>>>>>> text-------------------------------
>>>>>>>>     The mechanism for indicating this preference is that, in an 
>>>>>>>> offer, if
>>>>>>>>        the last character of any of the 'humintlang-recv' or 
>>>>>>>> 'humintlang-
>>>>>>>>        send' values is an asterisk, this indicates a request to 
>>>>>>>> not fail the call.
>>>>>>>>     The asterisk should be attached to attributes with 
>>>>>>>> languages of lower
>>>>>>>>     preference to be matched if such difference can be 
>>>>>>>> specified. Thereby
>>>>>>>>     the location of the asterisk can be used to support the 
>>>>>>>> decision on
>>>>>>>>     which languages to use in the call.
>>>>>>>>     ---------------------------end of change 2 in 
>>>>>>>> 5.3--------------------------------------
>>>>>>>>     Motivation: There has not yet been any conclusion for my 
>>>>>>>> proposal no 5 in the IETF LC comments of Feb 12.
>>>>>>>>     This is a dramatically reduced version that may be easier 
>>>>>>>> to accept at this stage, still covering one of the missing 
>>>>>>>> functionalities in the draft.
>>>>>>>>     The asterisk is used as a preference parameter in the 
>>>>>>>> attributes. Thereby the proposed title change on 5.3
>>>>>>>>     With this additional rule about where the asterisk(s) are 
>>>>>>>> placed, the answering parties get good clues about the 
>>>>>>>> preferences between alternatives presented by the offeror. The 
>>>>>>>> chance to set up calls with satisfied users increase 
>>>>>>>> dramatically compared to letting the answering party select by 
>>>>>>>> chance between alternatives.
>>>>>>>
>>>>>>>    Making the asterisk a purely-advisory hint as to the 
>>>>>>> least-preferred media/language combination seems harmless 
>>>>>>> enough, as it would not be required to support it; however, I'm 
>>>>>>> not sure it provides any benefit: if an offer contains some set 
>>>>>>> of media with language, and the answerer can support all of 
>>>>>>> them, should the answerer only include in its answer those 
>>>>>>> without an asterisk? It seems simpler for the answerer to 
>>>>>>> include everything in the offer that it can support.
>>>>>>>
>>>>>>
>>>>>>    --
>>>>>>    -----------------------------------------
>>>>>>    Gunnar Hellström
>>>>>>    Omnitor
>>>>>>    gunnar.hellstrom@omnitor.se
>>>>>>    +46 708 204 288
>>>>>
>>>>>
>>>>
>>>>   --
>>>>   -----------------------------------------
>>>>   Gunnar Hellström
>>>>   Omnitor
>>>>   gunnar.hellstrom@omnitor.se
>>>>   +46 708 204 288
>>>
>>>
>>
>>  --
>>  -----------------------------------------
>>  Gunnar Hellström
>>  Omnitor
>>  gunnar.hellstrom@omnitor.se
>>  +46 708 204 288
>
>

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


From nobody Mon Feb 27 14:58: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 BDA1412944E for ; Mon, 27 Feb 2017 14:58:50 -0800 (PST)
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 VY7MDx8B71Vs for ; Mon, 27 Feb 2017 14:58:47 -0800 (PST)
Received: from bin-vsp-out-03.atm.binero.net (bin-mail-out-06.binero.net [195.74.38.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33C0512944D for ; Mon, 27 Feb 2017 14:58:47 -0800 (PST)
X-Halon-ID: 499251db-fd40-11e6-9c99-0050569116f7
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [77.53.231.21]) by bin-vsp-out-03.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Mon, 27 Feb 2017 23:58:41 +0100 (CET)
To: Randall Gellens , slim@ietf.org, Bernard Aboba 
References: <148782279664.31054.8793649134696520241.idtracker@ietfa.amsl.com>  <49fd730e-6e90-1a49-eae8-80f8b1285a76@omnitor.se>  <83152ba7-c3fb-25d8-f97d-59c7840cad56@omnitor.se>  <4b36f347-955e-e2b9-12f2-f426d47d3d33@omnitor.se> <59d7939c-d4c5-b74a-e960-3234f0524b39@omnitor.se>  <024da389-19d4-5e1b-4956-ee359580b4e1@omnitor.se> 
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: <05babdd5-99d3-0f1e-c03f-a1a664622715@omnitor.se>
Date: Mon, 27 Feb 2017 23:58:38 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
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] I-D Action: draft-ietf-slim-negotiating-human-language-07.txt
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Feb 2017 22:58:51 -0000

Den 2017-02-27 kl. 16:34, skrev Randall Gellens:
> At 2:37 PM +0100 2/27/17, Gunnar Hellström wrote:
>
>>  Den 2017-02-27 kl. 02:01, skrev Randall Gellens:
>>>  At 8:38 AM +0100 2/26/17, Gunnar Hellström wrote:
>>>
>>>>   Randall,
>>>>
>>>>   One more clarification for issue 12 - the asterisk placement as a 
>>>> preference hint:
>>>>
>>>>   You say:
>>>>
>>>>   " it seems better for the answerer to include all media and 
>>>> languages from the offer that it can support. "
>>>>
>>>>   You are right. I misread this paragraph in section 5.2:
>>>>   " In an answer, 'humintlang-send' is the language the answerer will
>>>>   send (which in most cases is one of the languages in the offer's
>>>>   'humintlang-recv'), and 'humintlang-recv' is the language the
>>>>   answerer expects to receive (which in most cases is one of the
>>>>   languages in the offer's 'humintlang-send')."
>>>>
>>>>   That gave me the impression that I need to answer with only one 
>>>> language per direction in the whole SDP.
>>>
>>>  It's per media.
>>>
>>>>   But in the first paragraph of 5.2, it is said: "to negotiate
>>>>   which human language is used in each interactive media stream. "
>>>>
>>>>   So, we are allowed to include more than one language per 
>>>> direction in the SDP, but the users are not expected to use more 
>>>> than one language per direction, at least initially in the call.
>>>
>>>  There's nothing in the protocol that says anything about people 
>>> using more than one media in each direction.
>>>
>>>>   (that makes the wording "will send" and "expects to receive" in 
>>>> the cited paragraph a bit misleading, because as you point out, 
>>>> some of them might never be used. "is prepared to send" and "can 
>>>> accept to receive" might better correspond to what it means. Ending 
>>>> the sentence with "per media steram" might also help to remind the 
>>>> reader about the semantics. I leave to you to change these if you 
>>>> want.)
>>>
>>>  OK, I'm happy to add the additional clarification.  The paragraph 
>>> now reads:
>>>
>>>     In an answer, 'hlang-send' is the language the answerer will send
>>>     when using the media (which in most cases is one of the 
>>> languages in
>>>     the offer's 'hlang-recv'), and 'hlang-recv' is the language the
>>>     answerer expects to receive in the media (which in most cases is 
>>> one
>>>     of the languages in the offer's 'hlang-send').
>>
>>  Yes, that might be acceptable if "will send when using the media" 
>> can be read as being conditional: "will send if use of the media for 
>> language purposes is selected",
>>  but not if it is read as a definite usage "will send for the periods 
>> of time that this media will definitively be used for language 
>> communication."  With the latter interpretation we have not improved 
>> our logic over the lang attribute that could be interpreted as it 
>> required use of all declared languages in the session.
>
> I think "when using the media" is clear.
I hope you are right. I stop arguing about this one.
Thanks
Gunnar
>
>>
>>  I still think it is safer to say "is prepared to send" instead of 
>> "will send".
>>  While for the other direction, I think the "expects to receive" is 
>> vague enough to mean that another media might be used.
>>
>>  Sorry for continuing to watch out for logic gaps here.
>>
>>  Gunnar
>>>
>>>
>>>
>>>>   Den 2017-02-26 kl. 07:46, skrev Gunnar Hellström:
>>>>
>>>>>   Den 2017-02-25 kl. 20:58, skrev Randall Gellens:
>>>>>
>>>>>>   Hi Gunnar,
>>>>>>
>>>>>>   At 11:04 AM +0100 2/25/17, Gunnar Hellström wrote:
>>>>>>
>>>>>>>   Fine, I find that we have only issues 5, 6 and 12 still to 
>>>>>>> discuss.
>>>>>>>
>>>>>>>   You did not answer issue 6, use of asymmetrical language 
>>>>>>> rather than unidirectional media. I assume you accepted it.
>>>>>>>
>>>>>>
>>>>>>   Yes, I thought I had indicated that, sorry if I didn't.
>>>>>>
>>>>>   Good.
>>>>>
>>>>>>
>>>>>>>
>>>>>>>   On 5, the request to reinsert wording about seeing the speaker 
>>>>>>> in video, it is still a huge difference in specifying a 
>>>>>>> preference to see the speaker for language perception reasons, 
>>>>>>> versus only specifying that I want a video stream for 
>>>>>>> supplementary purposes. With the current wording in version -07, 
>>>>>>> section 5.3 says that that combination is undefined. Nothing in 
>>>>>>> the LC discussion indicated that it should be undefined. Why did 
>>>>>>> you suddenly want to delete it? It is useful. Please reinsert 
>>>>>>> with the wording changes I propose.
>>>>>>>
>>>>>>
>>>>>>   The email discussion led me to believe that the text was 
>>>>>> controversial. We need to get the draft finished, so it's better 
>>>>>> to delete controversial text than to spend months fighting about it.
>>>>>>
>>>>>   The comments were first about the uncertainty about how the 
>>>>> "silly states" were to be interpreted.
>>>>>   We described them all but decided to only keep the view of the 
>>>>> speaker because it is a real and useful case.
>>>>>   The idea to differentiate spoken and written cases by script 
>>>>> tags caused discussions and was dropped. The remaining real case 
>>>>> with the view of the speaker was mentioned twice in the draft, so 
>>>>> it was recommended that one of them should be deleted, but not both.
>>>>>
>>>>>>
>>>>>>>
>>>>>>>   On 12, the meaning of the placement of the asterisk, you ask:
>>>>>>>   "Making the asterisk a purely-advisory hint as to the 
>>>>>>> least-preferred media/language combination seems harmless 
>>>>>>> enough, as it would not be required to support it; however, I'm 
>>>>>>> not sure it provides any benefit: if an offer contains some set 
>>>>>>> of media with language, and the answerer can support all of 
>>>>>>> them, should the answerer only include in its answer those 
>>>>>>> without an asterisk? It seems simpler for the answerer to 
>>>>>>> include everything in the offer that it can support."
>>>>>>>
>>>>>>>   The answering party should aim at answering with one of the 
>>>>>>> languages that is without the asterisk in the offer. Only if the 
>>>>>>> answering party does not have capability in a language without 
>>>>>>> an asterisk, one with asterisk should be selected. Thereby you 
>>>>>>> get the best opportunity to start the call in a language 
>>>>>>> combination that satisfies both users.
>>>>>>>
>>>>>>>   Example: A hard-of-hearing user can just barely conduct spoken 
>>>>>>> calls with persons she knows. From others it is much more 
>>>>>>> reliable to get text. She calls and declares:
>>>>>>>
>>>>>>>   m=audio
>>>>>>>   a=huml-send:en
>>>>>>>   a=huml-recv:en*
>>>>>>>   m=text
>>>>>>>   a=huml-recv:en
>>>>>>>
>>>>>>>   The answering party with text capabilities sees that matching 
>>>>>>> text for sending is higher preferred than talking, and thus 
>>>>>>> responds:
>>>>>>>
>>>>>>>   m=audio
>>>>>>>   a=huml-recv:en
>>>>>>>   m=text
>>>>>>>   a=huml-send:en
>>>>>>>
>>>>>>>   The answering party sends the initial greeting in text and the 
>>>>>>> call continues smoothly in well managed langauage/modality 
>>>>>>> combinations.
>>>>>>>
>>>>>>>   Another called party may not have text capabilities, and may 
>>>>>>> therefore select the less favoured alternative with using speech 
>>>>>>> both ways, answering:
>>>>>>>
>>>>>>>   m=audio
>>>>>>>   a=huml-recv:en
>>>>>>>   a=huml-send:en
>>>>>>>   m=text 0
>>>>>>>
>>>>>>>   The answering party starts taking and the parties try as well 
>>>>>>> as possible to manage the call in this less preferred 
>>>>>>> combination that may be less reliable.
>>>>>>>
>>>>>>>   If the placement of the asterisk had no special meaning as it 
>>>>>>> is in version -07, it is a high risk that the answering party in 
>>>>>>> the first example would select to answer with spoken language 
>>>>>>> that would be unreliably received. Time and effort would be 
>>>>>>> spent by speech to make the answering party switch to sending 
>>>>>>> text instead of talking in order to arrange for a more reliable 
>>>>>>> call situation.
>>>>>>>
>>>>>>>   If instead the caller only indicated the most favoured 
>>>>>>> combinations,
>>>>>>>
>>>>>>>   m=audio
>>>>>>>   a=huml-send:en
>>>>>>>   m=text
>>>>>>>   a=huml-recv:en
>>>>>>>
>>>>>>>   Then the answering parties without text capability would not 
>>>>>>> dare to try to answer, and a reasonably successful call would be 
>>>>>>> missed.
>>>>>>>
>>>>>>>   Many other similar realistic examples can be created, where 
>>>>>>> placement of the asterisk(s) would be a sufficient indication of 
>>>>>>> lower preference for language match among alternatives that 
>>>>>>> would make call establishment successful and smooth in many more 
>>>>>>> cases than without this indication opportunity.
>>>>>>>
>>>>>>>   Do you want more examples?
>>>>>>>
>>>>>>>   Please accept proposal 12.
>>>>>>>
>>>>>>
>>>>>>   This convinces me that we cannot accept the proposed text, as 
>>>>>> it would introduce complexity that the WG explicitly decided to 
>>>>>> not pursue in this draft. In the examples you provided, it seems 
>>>>>> better for the answerer to include all media and languages from 
>>>>>> the offer that it can support. This is much simpler, has only 
>>>>>> trivial drawbacks (extra media negotiated that might not be 
>>>>>> used), and is what the WG agreed to.
>>>>>>
>>>>>   Yes, you could let the answer SDP contain one common language 
>>>>> per media and direction, but the answering human need guidance on 
>>>>> which language is best suited to start the conversation. Therefore 
>>>>> the placement of the asterisk is used to hint the answering party 
>>>>> how to start the call.
>>>>>
>>>>>   The first example above can be modified to:
>>>>>
>>>>>   Example: A hard-of-hearing user can just barely conduct spoken 
>>>>> calls with persons she knows. From others it is much more reliable 
>>>>> to get text. She calls and declares:
>>>>>
>>>>>   m=audio
>>>>>   a=huml-send:en
>>>>>   a=huml-recv:en*
>>>>>   m=text
>>>>>   a=huml-recv:en
>>>>>
>>>>>   The answering party with capabilities for both written and 
>>>>> spoken English sees that matching text for sending is higher 
>>>>> preferred than talking and sends the answer indicating the 
>>>>> capabilities:
>>>>>
>>>>>   m=audio
>>>>>   a=huml-recv:en
>>>>>   a=huml-send:en
>>>>>   m=text
>>>>>   a=huml-send:en
>>>>>
>>>>>   The answering party makes use of the hint that the caller 
>>>>> prefers to receive written text and therefore sends the initial 
>>>>> greeting in text and the call continues smoothly in well managed 
>>>>> langauage/modality combinations.
>>>>>
>>>>>   ----------
>>>>>   There is no complexity left in this solution, it helps to 
>>>>> motivate why we have the asterisk on media level, and it helps to 
>>>>> successful call initiations, so I think it should be acceptable.
>>>>>
>>>>>   Gunnar
>>>>>
>>>>>>
>>>>>>   --Randy
>>>>>>
>>>>>>>   Den 2017-02-25 kl. 01:32, skrev Randall Gellens:
>>>>>>>
>>>>>>>>   At 5:35 PM +0100 2/24/17, Gunnar Hellström wrote:
>>>>>>>>
>>>>>>>>>   Den 2017-02-23 kl. 05:15, skrev Randall Gellens:
>>>>>>>>>
>>>>>>>>>>   Version -07 addresses all comments except for the 
>>>>>>>>>> unresolved issue of renaming the two attributes which is 
>>>>>>>>>> currently being discussed on the list, and adding a new 
>>>>>>>>>> attribute for bidirectionality.
>>>>>>>>>>
>>>>>>>>>>   Per Dale's suggestion, the draft adds advice that if a call 
>>>>>>>>>> is rejected due to no languages in common, SIP response code 
>>>>>>>>>> 488 (Not Acceptable Here) or 606 (Not Acceptable) be used, 
>>>>>>>>>> along with a Warning header field indicating the supported 
>>>>>>>>>> languages. The draft registers a new entry in the warn-code 
>>>>>>>>>> sub-registry of SIP parameters for this purpose. The draft 
>>>>>>>>>> also has an expanded set of examples.
>>>>>>>>>>
>>>>>>>>>   Good progress. Good to see the enriched examples chapter 5.5.
>>>>>>>>>   I have a few comments on version -07:
>>>>>>>>>
>>>>>>>>>   1. Section 4. second line
>>>>>>>>>   ------------old text----------------------
>>>>>>>>>   but is not sufficiently sufficiently
>>>>>>>>>   ------------new text--------------------------
>>>>>>>>>   but is not sufficiently
>>>>>>>>>   ----------end of change 1-----------------
>>>>>>>>>   Motivation: New typo in version -07
>>>>>>>>>
>>>>>>>>
>>>>>>>>   Thanks.
>>>>>>>>
>>>>>>>>>
>>>>>>>>>   2. Section 5.2, first line
>>>>>>>>>   ----------------old text-----------------
>>>>>>>>>   This document defines two new media-level ..
>>>>>>>>>   ----------------new text----------------------
>>>>>>>>>   This document defines two media-level ...
>>>>>>>>>   ----------------end of change 2----------------
>>>>>>>>>   Motivation: It was commented that when the draft is 
>>>>>>>>> published, this is not new anymore.
>>>>>>>>>   There are three more occasions of "new" in the document that 
>>>>>>>>> may be modified as well.
>>>>>>>>>
>>>>>>>>
>>>>>>>>   OK.
>>>>>>>>
>>>>>>>>>
>>>>>>>>>   3. 5.2 second paragraph
>>>>>>>>>   -------------------old text--------------------------------
>>>>>>>>>   In an offer, the 'humintlang-send' values indicates the 
>>>>>>>>> language(s)
>>>>>>>>>   the offerer is willing to use when sending using the media, 
>>>>>>>>> and the
>>>>>>>>>   'humintlang-recv' values indicates the language(s) the 
>>>>>>>>> offerer is
>>>>>>>>>   willing to use when receiving using the media.
>>>>>>>>>   -----------------new text---------------------------------
>>>>>>>>>   In an offer, the 'humintlang-send' values indicate the 
>>>>>>>>> language(s)
>>>>>>>>>   the offerer is willing to select from for use when sending 
>>>>>>>>> using the
>>>>>>>>>   media, and the 'humintlang-recv' values indicate the 
>>>>>>>>> language(s) the
>>>>>>>>>   offerer is willing to receive one of in the media stream.
>>>>>>>>>   ----------------end of change----------------------------------
>>>>>>>>>   Motivation 1:) change from "indicates" to "indicate" in two 
>>>>>>>>> places to match the new use of plural "values".
>>>>>>>>>   Motivation 2:) Be sure to indicate that we only intend to 
>>>>>>>>> negotiate one language per media and direction, so that we do 
>>>>>>>>> not end up as unspecified regarding number of matches required 
>>>>>>>>> as the sdp "lang" attribute is.
>>>>>>>>>
>>>>>>>>
>>>>>>>>   Reworded.
>>>>>>>>
>>>>>>>>>
>>>>>>>>>   4. 5.2 Second paragraph
>>>>>>>>>   -----------------old text-----------------------
>>>>>>>>>   When a media is intended
>>>>>>>>>   for use in one direction only
>>>>>>>>>   ----------------new text---------------------
>>>>>>>>>   When a media is intended
>>>>>>>>>   for use for language communication in one direction only
>>>>>>>>>   ----------------end of change---------------------------
>>>>>>>>>   Motivation: Deletion of a note in this sentence made it less 
>>>>>>>>> obvious that we are only talking about directions of use of 
>>>>>>>>> language communication, and not about establishing asymmetric 
>>>>>>>>> media connections. Therefore add this clarification.
>>>>>>>>>
>>>>>>>>
>>>>>>>>   Reworded.
>>>>>>>>
>>>>>>>>>
>>>>>>>>>   5. 5.2 Deleted paragraph 6 before "Clients acting on behalf..."
>>>>>>>>>   ----------reinsert modified 
>>>>>>>>> paragraph----------------------------
>>>>>>>>>   While signed language tags are used with a video stream to
>>>>>>>>>   indicate sign language, a spoken language tag for a video 
>>>>>>>>> stream
>>>>>>>>>   indicates a request or offer to see the speaker, when that 
>>>>>>>>> is of
>>>>>>>>>   importance for language perception.
>>>>>>>>>   -------------end of 
>>>>>>>>> change-------------------------------------------
>>>>>>>>>   Motivation: There was in the LC mail exchange a discussion 
>>>>>>>>> about sharpening up the specification of use of "unusual 
>>>>>>>>> combinations".
>>>>>>>>>   There was no agreement to delete them all. The one described 
>>>>>>>>> in this paragraph is the main one that has widespread use and 
>>>>>>>>> needs to be clearly specified for use by a large number of 
>>>>>>>>> hard-of-hearing and deaf users.
>>>>>>>>>
>>>>>>>>
>>>>>>>>   The text as it is now does not prohibit anything and 
>>>>>>>> explicitly mentions negotiating supplemental video by omitting 
>>>>>>>> language attributes on a video media.
>>>>>>>>
>>>>>>>>>
>>>>>>>>>   6. 5.2 Sixth paragraph
>>>>>>>>>   --------------------current text--------------------
>>>>>>>>>   (or for unidirectional streams, one of)
>>>>>>>>>   ------------------new text ------------------------
>>>>>>>>>   (or for asymmetrical use of languages, one of)
>>>>>>>>>   -----------------end of change----------------------
>>>>>>>>>   Motivation: We are not primarily talking about enabled 
>>>>>>>>> transmission directions of the streams, but about language use 
>>>>>>>>> in the streams. We do not want to limit the media stream 
>>>>>>>>> directions just because we do not specify an initial language 
>>>>>>>>> to use for that direction. There are other usage of media, and 
>>>>>>>>> there may even be occasional use of language in the direction, 
>>>>>>>>> just not worth mentioning as an initial and preferred use. The 
>>>>>>>>> suggested change should make that clear.
>>>>>>>>>
>>>>>>>>>   7. 5.3 Next to last paragraph
>>>>>>>>>   ------------------old text------------------------------
>>>>>>>>>   a list of supported languages.
>>>>>>>>>   -------------------new text-------------------------
>>>>>>>>>   a list of supported languages, media and directions.
>>>>>>>>>   -------------------end of change----------------
>>>>>>>>>   Motivation: It is not sufficient to know which languages are 
>>>>>>>>> supported, it is also essential to know in which media they 
>>>>>>>>> are supported and in which directions. (media could be 
>>>>>>>>> replaced with modality, but the media can become ambigous 
>>>>>>>>> then, so use media here to be brief.
>>>>>>>>>
>>>>>>>>
>>>>>>>>   I don't know that we can require this, but I'll add SHOULD 
>>>>>>>> kist supported languages and media. Demanding direction as well 
>>>>>>>> might be too unwieldy.
>>>>>>>>
>>>>>>>>>
>>>>>>>>>   8. 5.3, last line
>>>>>>>>>   --------------old text----------------------------------
>>>>>>>>>   Supported languages are: es, en"
>>>>>>>>>   --------------new text-------------------------------
>>>>>>>>>   Supported languages are: es, en transmission in audio; es, 
>>>>>>>>> en reception in audio"
>>>>>>>>> ----------------------------------------------------------
>>>>>>>>>   Motivation: Same as for 7.
>>>>>>>>>
>>>>>>>>
>>>>>>>>   Fixed as above.
>>>>>>>>
>>>>>>>>>
>>>>>>>>>   9. 5.4 Undefined combinations
>>>>>>>>>   ----------------------------old 
>>>>>>>>> text--------------------------------------
>>>>>>>>>   The behavior when specifying a non-signed language tag for a 
>>>>>>>>> video
>>>>>>>>>   media stream, or a signed language tag for an audio or text 
>>>>>>>>> media
>>>>>>>>>   stream, is not defined.
>>>>>>>>>   ---------------------------new 
>>>>>>>>> text-----------------------------------------
>>>>>>>>>   There is no way specified for indicating use of text based 
>>>>>>>>> language in a video media stream.
>>>>>>>>>   There is no meaning assigned to specification of sign 
>>>>>>>>> language in an audio or text media stream.
>>>>>>>>>   --------------------------end of 
>>>>>>>>> change-------------------------------
>>>>>>>>>   Motivation: Seeing the speaker in video is an important 
>>>>>>>>> combination reinserted above in section 5.2.
>>>>>>>>>   This section therefore needed rewording to not include that 
>>>>>>>>> combination.
>>>>>>>>>
>>>>>>>>
>>>>>>>>   The draft explicitly mentions video for supplemental purposes.
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>   10. 6.2 Last sentence
>>>>>>>>>   -----------------current text---------------------
>>>>>>>>>   Supported languages are: [list of supported languages]."
>>>>>>>>>   -----------------new text------------------------
>>>>>>>>>   Supported languages and media and transmission directions 
>>>>>>>>> are:[list of supported languages and media and transmission 
>>>>>>>>> directions.]"
>>>>>>>>>   -----------------end of change--------------------------
>>>>>>>>>   Motivation: Same as for 7.
>>>>>>>>>
>>>>>>>>
>>>>>>>>   Fixed as above.
>>>>>>>>
>>>>>>>>>
>>>>>>>>>   11. 6.1 MUX Category
>>>>>>>>>   ----------old text in two locations-------------------
>>>>>>>>>   MUX Category: normal
>>>>>>>>>   ---------new text in same two locations--------------
>>>>>>>>>   Mux Category: NORMAL
>>>>>>>>>   ---------end of change-----------------
>>>>>>>>>   Motivation: Follow RFC 4566bis and IANA habits regarding use 
>>>>>>>>> of capitals
>>>>>>>>>
>>>>>>>>
>>>>>>>>   Fixed.
>>>>>>>>
>>>>>>>>>
>>>>>>>>>   12. 5.3
>>>>>>>>>   -------------old text-----------------
>>>>>>>>>   5.3 No Language in Common
>>>>>>>>>   -------------new text----------------
>>>>>>>>>   5.3 Preference parameter
>>>>>>>>>   ------------end of change 1 in 5.3---------------
>>>>>>>>>
>>>>>>>>
>>>>>>>>   The section is more than just the asterisk, it also advises 
>>>>>>>> use of specific SIP response codes if the call is failed.
>>>>>>>>
>>>>>>>>>
>>>>>>>>>   -------------old text-in 5.3, second 
>>>>>>>>> paragraph-------------------------------
>>>>>>>>>   The mechanism for indicating this preference is that, in an 
>>>>>>>>> offer, if
>>>>>>>>>   the last character of any of the 'humintlang-recv' or 
>>>>>>>>> 'humintlang-
>>>>>>>>>   send' values is an asterisk, this indicates a request to not 
>>>>>>>>> fail the call.
>>>>>>>>>   --------------------------new 
>>>>>>>>> text-------------------------------
>>>>>>>>>   The mechanism for indicating this preference is that, in an 
>>>>>>>>> offer, if
>>>>>>>>>   the last character of any of the 'humintlang-recv' or 
>>>>>>>>> 'humintlang-
>>>>>>>>>   send' values is an asterisk, this indicates a request to not 
>>>>>>>>> fail the call.
>>>>>>>>>   The asterisk should be attached to attributes with languages 
>>>>>>>>> of lower
>>>>>>>>>   preference to be matched if such difference can be 
>>>>>>>>> specified. Thereby
>>>>>>>>>   the location of the asterisk can be used to support the 
>>>>>>>>> decision on
>>>>>>>>>   which languages to use in the call.
>>>>>>>>>   ---------------------------end of change 2 in 
>>>>>>>>> 5.3--------------------------------------
>>>>>>>>>   Motivation: There has not yet been any conclusion for my 
>>>>>>>>> proposal no 5 in the IETF LC comments of Feb 12.
>>>>>>>>>   This is a dramatically reduced version that may be easier to 
>>>>>>>>> accept at this stage, still covering one of the missing 
>>>>>>>>> functionalities in the draft.
>>>>>>>>>   The asterisk is used as a preference parameter in the 
>>>>>>>>> attributes. Thereby the proposed title change on 5.3
>>>>>>>>>   With this additional rule about where the asterisk(s) are 
>>>>>>>>> placed, the answering parties get good clues about the 
>>>>>>>>> preferences between alternatives presented by the offeror. The 
>>>>>>>>> chance to set up calls with satisfied users increase 
>>>>>>>>> dramatically compared to letting the answering party select by 
>>>>>>>>> chance between alternatives.
>>>>>>>>>
>>>>>>>>
>>>>>>>>   Making the asterisk a purely-advisory hint as to the 
>>>>>>>> least-preferred media/language combination seems harmless 
>>>>>>>> enough, as it would not be required to support it; however, I'm 
>>>>>>>> not sure it provides any benefit: if an offer contains some set 
>>>>>>>> of media with language, and the answerer can support all of 
>>>>>>>> them, should the answerer only include in its answer those 
>>>>>>>> without an asterisk? It seems simpler for the answerer to 
>>>>>>>> include everything in the offer that it can support.
>>>>>>>>
>>>>>>>
>>>>>>>   --
>>>>>>>   -----------------------------------------
>>>>>>>   Gunnar Hellström
>>>>>>>   Omnitor
>>>>>>> gunnar.hellstrom@omnitor.se
>>>>>>>   +46 708 204 288
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>   --
>>>>   -----------------------------------------
>>>>   Gunnar Hellström
>>>>   Omnitor
>>>> gunnar.hellstrom@omnitor.se
>>>>   +46 708 204 288
>>>
>>>
>>
>>  --
>>  -----------------------------------------
>>  Gunnar Hellström
>>  Omnitor
>>  gunnar.hellstrom@omnitor.se
>>  +46 708 204 288
>
>

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


From nobody Tue Feb 28 17:08:46 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 DEE061289C4 for ; Tue, 28 Feb 2017 17:08:44 -0800 (PST)
X-Quarantine-ID: 
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fgDN9xnpXPt2 for ; Tue, 28 Feb 2017 17:08:43 -0800 (PST)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id D99A1126DFB for ; Tue, 28 Feb 2017 17:08:43 -0800 (PST)
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Tue, 28 Feb 2017 16:58:15 -0800
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <825fa638-b223-d716-6a3c-238903a37b92@omnitor.se>
References: <148782279664.31054.8793649134696520241.idtracker@ietfa.amsl.com>  <49fd730e-6e90-1a49-eae8-80f8b1285a76@omnitor.se>  <83152ba7-c3fb-25d8-f97d-59c7840cad56@omnitor.se>  <4b36f347-955e-e2b9-12f2-f426d47d3d33@omnitor.se>  <7f844aaa-17ce-2ab7-0602-a999a40235de@omnitor.se>  <825fa638-b223-d716-6a3c-238903a37b92@omnitor.se>
X-Mailer: Eudora for Mac OS X
Date: Tue, 28 Feb 2017 17:08:50 -0800
To: Gunnar =?iso-8859-1?Q?Hellstr=F6m?=  , slim@ietf.org, Natasha Rooney , Bernard Aboba , "Phillips, Addison" 
From: Randall Gellens 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
Archived-At: 
Subject: Re: [Slim] I-D Action: draft-ietf-slim-negotiating-human-language-07.txt
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 01 Mar 2017 01:08:45 -0000

Hi Gunnar,

I'm starting a new message to cut out the huge amount of quoting.

Your proposal is that text be added that advises the calling client 
to place an asterisk on the least-preferred language/media, and 
advises the answering client to indicate to the answering human which 
language/media is not the least preferred (did not have an asterisk 
in the offer), is that accurate?

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
If you would look up bad labor relations in the dictionary, you
would have an American Airlines logo beside it.
    --U.S. District Judge Joe Kendall, issuing a restraining order
against an American Airlines APA pilot union sick out, 10 Feb 1999.


From nobody Tue Feb 28 23:27:06 2017
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA90D1294BC for ; Tue, 28 Feb 2017 23:27:04 -0800 (PST)
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 ceykPomReuJU for ; Tue, 28 Feb 2017 23:27:03 -0800 (PST)
Received: from bin-vsp-out-03.atm.binero.net (vsp-unauthed02.binero.net [195.74.38.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7A541294A7 for ; Tue, 28 Feb 2017 23:27:02 -0800 (PST)
X-Halon-ID: 7541a8fb-fe50-11e6-9c99-0050569116f7
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [77.53.231.21]) by bin-vsp-out-03.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Wed,  1 Mar 2017 08:26:59 +0100 (CET)
To: Randall Gellens , slim@ietf.org, Natasha Rooney , Bernard Aboba , "Phillips, Addison" 
References: <148782279664.31054.8793649134696520241.idtracker@ietfa.amsl.com>  <49fd730e-6e90-1a49-eae8-80f8b1285a76@omnitor.se>  <83152ba7-c3fb-25d8-f97d-59c7840cad56@omnitor.se>  <4b36f347-955e-e2b9-12f2-f426d47d3d33@omnitor.se>  <7f844aaa-17ce-2ab7-0602-a999a40235de@omnitor.se>  <825fa638-b223-d716-6a3c-238903a37b92@omnitor.se> 
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: 
Date: Wed, 1 Mar 2017 08:26:56 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------736A66D225C35BE19A77D2B6"
Archived-At: 
Subject: Re: [Slim] I-D Action: draft-ietf-slim-negotiating-human-language-07.txt
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 01 Mar 2017 07:27:05 -0000

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

Hi Randall,
Den 2017-03-01 kl. 02:08, skrev Randall Gellens:
> Hi Gunnar,
>
> I'm starting a new message to cut out the huge amount of quoting.
>
> Your proposal is that text be added that advises the calling client to 
> place an asterisk on the least-preferred language/media, and advises 
> the answering client to indicate to the answering human which 
> language/media is not the least preferred (did not have an asterisk in 
> the offer), is that accurate?
Yes, with slight rewording to:
"text that advises the *offering* client to place an asterisk on the 
least-preferred language/media *indications*, and advises the answering 
client to indicate to the answering human which language/media are not 
the least preferred (did not have an asterisk in the offer)"

The inclusion of the "indications" is just to assure that it is clear 
that it does not need to be just one indication that gets the asterisk .
The last part sounds awkward, but matches technically what the lack of 
an asterisk means. I inherited the inverted logic for the asterisk from 
its already defined non-denial meaning.
If you are considering wording for the draft, I suggest that you 
straighten the logic to say "*which language/media are most preferred 
(did not have an asterisk in the offer)*"

It does also not need to be an "answering human" that gets this 
indication and makes use of it for guidance on how to answer the call. 
It can just as well be e.g. a multi-modal answering machine or some 
other application interacting with human language. I am not sure if 
"*answering party*" is more appropriate and can be considered including 
such automata.

Thanks,
Gunnar



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


  
    
  
  
    Hi Randall, 

    
Den 2017-03-01 kl. 02:08, skrev Randall
      Gellens:

    

    
Hi Gunnar,
      

      

      I'm starting a new message to cut out the huge amount of quoting.
      

      

      Your proposal is that text be added that advises the calling
      client to place an asterisk on the least-preferred language/media,
      and advises the answering client to indicate to the answering
      human which language/media is not the least preferred (did not
      have an asterisk in the offer), is that accurate?
      

    

    Yes, with slight rewording to:

    "text that advises the offering client to place an asterisk
    on the least-preferred language/media indications, and
    advises the answering client to indicate to the answering human
    which language/media are not the least preferred (did not have an
    asterisk in the offer)"

    

    The inclusion of the "indications" is just to assure that it is
    clear that it does not need to be just one indication that gets the
    asterisk .

    The last part sounds awkward, but matches technically what the lack
    of an asterisk means. I inherited the inverted logic for the
    asterisk from its already defined non-denial meaning. 

    If you are considering wording for the draft, I suggest that you
    straighten the logic to say "which language/media are most
      preferred (did not have an asterisk in the offer)"

    

    It does also not need to be an "answering human" that gets this
    indication and makes use of it for guidance on how to answer the
    call. It can just as well be e.g. a multi-modal answering machine or
    some other application interacting with human language. I am not
    sure if "answering party" is more appropriate and can be
    considered including such automata.  

    

    Thanks,

    Gunnar

    

    

  


--------------736A66D225C35BE19A77D2B6--