From nobody Tue Mar 3 15:33:46 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65A5A1A1BCC for ; Tue, 3 Mar 2015 15:33: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: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hqvA7ZqxLsPS for ; Tue, 3 Mar 2015 15:33:42 -0800 (PST) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D42221A0277 for ; Tue, 3 Mar 2015 15:33:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1425425623; x=1456961623; h=message-id:date:to:from:subject; bh=gN2SuLF5ZZMWD6easVRFw6WOiyL75E4xkEKG0EteStY=; b=gnVnNi450fNbQtnLtxEQL+LvwIJaOmPjcETE4hjZVTnlY5dfu+HRXbdG v7/vpAvUMtSX6Su75ivTJlVSSt90vXZe0L5TAt0qlCtIFaCGlNaS0/o8D E0YH31+/RmAG1V69LSlWnNSg7dY8mxxxEh9wDvnE0x/pUAVspUn5ohRWR k=; X-IronPort-AV: E=McAfee;i="5600,1067,7729"; a="85020606" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by sabertooth02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Mar 2015 15:33:35 -0800 X-IronPort-AV: E=Sophos;i="5.09,684,1418112000"; d="scan'208";a="862828903" Received: from plus.qualcomm.com ([10.52.255.8]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Mar 2015 15:33:34 -0800 Received: from Ironmsg04-R.qualcomm.com (ironmsg04-R.qualcomm.com [172.30.46.18]) by plus.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id t23NXY1a030049; Tue, 3 Mar 2015 15:33:34 -0800 X-IronPort-AV: E=Sophos;i="5.09,684,1418112000"; d="scan'208";a="916634842" X-ojodefuego: yes Received: from unknown (HELO [99.111.97.136]) ([10.64.167.27]) by Ironmsg04-R.qualcomm.com with ESMTP; 03 Mar 2015 15:33:32 -0800 Mime-Version: 1.0 Message-Id: X-Mailer: Eudora for Mac OS X Date: Tue, 3 Mar 2015 15:33:31 -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 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 Archived-At: Subject: [Slim] Proposed SLIM charter X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2015 23:33:44 -0000 Hi SLIM people, Here is a revised proposed charter. The intent is to focus on the two current drafts and get those completed. ---------- SLIM: Selection of Language for Internet Media Description of Working Group: A mutually comprehensible language is helpful for human communication. This is true across a range of circumstances and environments. In general, the problem is most acute in situations where there is not a clear choice for a single language, such as environments lacking contextual or out-of-band information regarding the identity of the parties and the language to be used. The group will address two specific cases that most urgently need a technical solution: One problem space is non-real-time communication, specifically email for one-to-many or where the set of recipients is dynamic or different recipients require different languages; the other is real-time communication, specifically emergency calling, preferably also useful for other cases where the parties may not know each other personally or where one party wishes to accommodate people with varying language and media needs. In the real-time communication case, language and media are intrinsically linked, for example, signed languages require a video media. While the two use cases are in different contexts (real time and non-real-time), the fundamental goal is the same: to enable selection of the best-fit language(s) for a specific situation. Some of the details will also be in common across the cases. Having a single WG address both cases makes it clear that these are two aspects of the same basic problem. A single WG also makes it easier to maximize similarities and avoid unnecessary fragmentation of the solutions. The group will produce two documents, one for email, and one for real-time communications. In the email case, the group will produce a MIME content type specification that enables a single email message to contain multiple language versions of the content, with provisions to help clients select a best fit version. In the real-time communication case, the group will produce a specification enabling negotiation of a human language per media stream. The specification must be suitable for use in emergency communications as specified in RFC 6443 and RFC 6881; it is desirable to also be suitable for use in non-emergency real-time communications that share the same call set-up and media negotiation protocols. The mechanism will permit the caller's media and language needs and preferences to be matched against what the called party is able to provide. The mechanism will permit resources (e.g., translation, relay, media) to be allocated or engaged as early as possible in the call set-up or for the call to be routed or handled specially (e.g., routed to a resource able to provide a needed language and/or media). Goals and Milestones: June 2015 -- Submit "Multiple Language Content Type" to the IESG for consideration as a Standards Track RFC June 2015 -- Submit "Negotiating Human Language in Real-Time Communications" to the IESG for consideration as a Standards Track RFC ---------- -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Wealth is not only money. Wealth can be happiness in your sweetheart or your honey. --(Fortune cookie) From nobody Wed Mar 4 11:09:33 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24CE51ACE2C for ; Wed, 4 Mar 2015 11:09:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7-CQ7zsw9dow for ; Wed, 4 Mar 2015 11:09:31 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF3501ACE2E for ; Wed, 4 Mar 2015 11:09:30 -0800 (PST) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t24J9Uj4006173 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 4 Mar 2015 19:09:30 GMT Received: from hermes-fe-1.easd.brm.oracle.com (hermes-fe-1.easd.brm.oracle.com [10.79.248.10]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t24J9TYM017210 for ; Wed, 4 Mar 2015 19:09:30 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII Received: from [10.145.183.59] (dhcp-arcadia01-4fl-east-10-145-183-59.usdhcp.oraclecorp.com [10.145.183.59]) by hermes-fe-1.easd.brm.oracle.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTPSA id <0NKP00L5RBVR3M00@hermes-fe-1.easd.brm.oracle.com> for slim@ietf.org; Wed, 04 Mar 2015 11:09:29 -0800 (PST) Date: Wed, 04 Mar 2015 11:09:27 -0800 From: Chris Newman To: slim@ietf.org Message-id: <69D3652906B11DC7284386C9@dhcp-arcadia01-4fl-east-10-145-183-59.usdhcp.oraclecorp.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Subject: Re: [Slim] Proposed SLIM charter X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 19:09:32 -0000 I support the creation of this WG. The charter text is fine. - Chris From nobody Wed Mar 4 13:57:42 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBF101A8980 for ; Wed, 4 Mar 2015 13:57:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 i4E8JUIUTUDl for ; Wed, 4 Mar 2015 13:57:40 -0800 (PST) Received: from resqmta-po-08v.sys.comcast.net (resqmta-po-08v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:167]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37C0E1A8978 for ; Wed, 4 Mar 2015 13:57:40 -0800 (PST) Received: from resomta-po-11v.sys.comcast.net ([96.114.154.235]) by resqmta-po-08v.sys.comcast.net with comcast id zZxb1p00954zqzk01ZxfE0; Wed, 04 Mar 2015 21:57:39 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-11v.sys.comcast.net with comcast id zZxe1p00W3Ge9ey01ZxfMa; Wed, 04 Mar 2015 21:57:39 +0000 Message-ID: <54F78072.5060206@alum.mit.edu> Date: Wed, 04 Mar 2015 17:00:18 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: slim@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1425506259; bh=iJl4tEOA9UUxXJ3qFHkR11S00W+TG5HImXQWTemPysI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=wtYuRf4jpB1O2JqlsYZDsXn4Czb3C6qstcW1p/n21oMYHer/b9bTm1zmtFT6Sg1DN 758fqm+xlsZSnEhqcJHAYeKOnnz4vPBSUD3zwK+uLEyA/9fW8pKhEyBaFIludF0okP wimKFbxXSJVWWejv3Mmi+gPFy58gZclAGfW/7+aEKdiTtIiBWlepp8nzf2iip5c/Ao mpaPK/GzzfhTejEux/Z5GsbdKausOGk1jE2bll/jQHFKPgIwC3NDE37CGyTxwohrfC 8PDfnLzzl2MG1PnSP0IADlhqcz7Qhuzwvp3dqTJ53eNIiljOTyOhXOGcy7DWOK0DfV ajoBDY7XQ+YOA== Archived-At: Subject: Re: [Slim] Proposed SLIM charter X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 21:57:41 -0000 I support this. But I find the schedule vastly overoptimistic, especially for real-time. Add a year or two. Thanks, Paul On 3/3/15 6:33 PM, Randall Gellens wrote: > Hi SLIM people, > > Here is a revised proposed charter. The intent is to focus on the two > current drafts and get those completed. > > ---------- > > SLIM: Selection of Language for Internet Media > > Description of Working Group: > > A mutually comprehensible language is helpful for human communication. > This is true across a range of circumstances and environments. In > general, the problem is most acute in situations where there is not a > clear choice for a single language, such as environments lacking > contextual or out-of-band information regarding the identity of the > parties and the language to be used. > > The group will address two specific cases that most urgently need a > technical solution: One problem space is non-real-time communication, > specifically email for one-to-many or where the set of recipients is > dynamic or different recipients require different languages; the other > is real-time communication, specifically emergency calling, preferably > also useful for other cases where the parties may not know each other > personally or where one party wishes to accommodate people with varying > language and media needs. > > In the real-time communication case, language and media are > intrinsically linked, for example, signed languages require a video media. > > While the two use cases are in different contexts (real time and > non-real-time), the fundamental goal is the same: to enable selection of > the best-fit language(s) for a specific situation. Some of the details > will also be in common across the cases. Having a single WG address > both cases makes it clear that these are two aspects of the same basic > problem. A single WG also makes it easier to maximize similarities and > avoid unnecessary fragmentation of the solutions. > > The group will produce two documents, one for email, and one for > real-time communications. > > In the email case, the group will produce a MIME content type > specification that enables a single email message to contain multiple > language versions of the content, with provisions to help clients select > a best fit version. > > In the real-time communication case, the group will produce a > specification enabling negotiation of a human language per media > stream. The specification must be suitable for use in emergency > communications as specified in RFC 6443 and RFC 6881; it is desirable to > also be suitable for use in non-emergency real-time communications that > share the same call set-up and media negotiation protocols. The > mechanism will permit the caller's media and language needs and > preferences to be matched against what the called party is able to > provide. The mechanism will permit resources (e.g., translation, relay, > media) to be allocated or engaged as early as possible in the call > set-up or for the call to be routed or handled specially (e.g., routed > to a resource able to provide a needed language and/or media). > > Goals and Milestones: > > June 2015 -- Submit "Multiple Language Content Type" to the IESG for > consideration as a Standards Track RFC > June 2015 -- Submit "Negotiating Human Language in Real-Time > Communications" to the IESG for consideration as a Standards Track RFC > > ---------- > From nobody Wed Mar 4 16:50:10 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA7951A700A for ; Wed, 4 Mar 2015 16:50:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AIUEKs95ga2Q for ; Wed, 4 Mar 2015 16:50:07 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE3591A017E for ; Wed, 4 Mar 2015 16:50:06 -0800 (PST) Received: from ppp118-209-123-122.lns20.mel4.internode.on.net ([118.209.123.122]:49687 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1YTJyA-0000I2-Lv for slim@ietf.org; Thu, 05 Mar 2015 11:48:54 +1100 Message-ID: <54F7A836.6000307@nteczone.com> Date: Thu, 05 Mar 2015 11:49:58 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: slim@ietf.org References: <54F78072.5060206@alum.mit.edu> In-Reply-To: <54F78072.5060206@alum.mit.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [Slim] Proposed SLIM charter X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 00:50:08 -0000 Hello Randall, I agree with Paul that it does seem optimistic. In the question text its mentions the caller's "media needs". I'm pretty sure I under the scope of "language needs" but "media needs" could be a little open ended. What sort of enhancements do you see to the existing negotiation methods? Regards, Christian On 5/03/2015 9:00 AM, Paul Kyzivat wrote: > I support this. > > But I find the schedule vastly overoptimistic, especially for > real-time. Add a year or two. > > Thanks, > Paul > > On 3/3/15 6:33 PM, Randall Gellens wrote: >> Hi SLIM people, >> >> Here is a revised proposed charter. The intent is to focus on the two >> current drafts and get those completed. >> >> ---------- >> >> SLIM: Selection of Language for Internet Media >> >> Description of Working Group: >> >> A mutually comprehensible language is helpful for human communication. >> This is true across a range of circumstances and environments. In >> general, the problem is most acute in situations where there is not a >> clear choice for a single language, such as environments lacking >> contextual or out-of-band information regarding the identity of the >> parties and the language to be used. >> >> The group will address two specific cases that most urgently need a >> technical solution: One problem space is non-real-time communication, >> specifically email for one-to-many or where the set of recipients is >> dynamic or different recipients require different languages; the other >> is real-time communication, specifically emergency calling, preferably >> also useful for other cases where the parties may not know each other >> personally or where one party wishes to accommodate people with varying >> language and media needs. >> >> In the real-time communication case, language and media are >> intrinsically linked, for example, signed languages require a video >> media. >> >> While the two use cases are in different contexts (real time and >> non-real-time), the fundamental goal is the same: to enable selection of >> the best-fit language(s) for a specific situation. Some of the details >> will also be in common across the cases. Having a single WG address >> both cases makes it clear that these are two aspects of the same basic >> problem. A single WG also makes it easier to maximize similarities and >> avoid unnecessary fragmentation of the solutions. >> >> The group will produce two documents, one for email, and one for >> real-time communications. >> >> In the email case, the group will produce a MIME content type >> specification that enables a single email message to contain multiple >> language versions of the content, with provisions to help clients select >> a best fit version. >> >> In the real-time communication case, the group will produce a >> specification enabling negotiation of a human language per media >> stream. The specification must be suitable for use in emergency >> communications as specified in RFC 6443 and RFC 6881; it is desirable to >> also be suitable for use in non-emergency real-time communications that >> share the same call set-up and media negotiation protocols. The >> mechanism will permit the caller's media and language needs and >> preferences to be matched against what the called party is able to >> provide. The mechanism will permit resources (e.g., translation, relay, >> media) to be allocated or engaged as early as possible in the call >> set-up or for the call to be routed or handled specially (e.g., routed >> to a resource able to provide a needed language and/or media). >> >> Goals and Milestones: >> >> June 2015 -- Submit "Multiple Language Content Type" to the IESG for >> consideration as a Standards Track RFC >> June 2015 -- Submit "Negotiating Human Language in Real-Time >> Communications" to the IESG for consideration as a Standards Track RFC >> >> ---------- >> > > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim > From nobody Wed Mar 4 22:36:13 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D60111B29E0 for ; Wed, 4 Mar 2015 22:36:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.898 X-Spam-Level: X-Spam-Status: No, score=0.898 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, J_CHICKENPOX_31=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 0v6U826q2DAm for ; Wed, 4 Mar 2015 22:36:09 -0800 (PST) Received: from bin-vsp-out-05.atm.binero.net (vsp-unauthed01.binero.net [195.74.38.225]) (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 21C781B29DF for ; Wed, 4 Mar 2015 22:36:08 -0800 (PST) X-Halon-ID: e70a8d64-c301-11e4-a4af-005056916f53 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.42] (unknown [77.53.231.174]) by bin-vsp-out-05.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Thu, 5 Mar 2015 07:36:06 +0100 (CET) Message-ID: <54F7F951.5020109@omnitor.se> Date: Thu, 05 Mar 2015 07:36:01 +0100 From: =?windows-1252?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: slim@ietf.org References: <54F78072.5060206@alum.mit.edu> <54F7A836.6000307@nteczone.com> In-Reply-To: <54F7A836.6000307@nteczone.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Slim] Proposed SLIM charter X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 06:36:12 -0000 I also view the charter to be good and want to see the work started. There are drafts to start with: https://tools.ietf.org/html/draft-gellens-slim-negotiating-human-language-00 https://tools.ietf.org/html/draft-tomkinson-slim-multilangcontent-00 Answering Christians question about what extensions might be needed, I want to answer relative towhat is in the realtime draft now. I see some topics that may need discussion: 1. Coding of unspecified language but specific mode. I expect that in many cases it is merely the modality that is of interest to negotiate, rather than the exact language. There is often a default language in a specific area, and as long as you use that, you will feel that it is a burden to specify that exactly, but rather indicate in what medium you want the language exchange. You may want to use text for language exchange and audio to convey the sound from a location. So, you would like to specify your preference for spoken, listened, written, read, visualized and seen. And for signed and perceiving sign languages. Regardless of exact language. So, some codes to use in place of specific languages for these kinds of general modalities could be needed. 2. Relative preference between media. I think it can be important to have a coding for preference between media, to express for example if I prefer to speak but can accept to type. We have an order of preference indication between languages in the same medium in the draft, but not between media. 3. Absolute versus relative preference between languages. We have a relative order of preference indication between languages in the same medium in the draft. I can see cases when it is instead an absolute preference that would be of importance. E.g. I am equally happy to get spoken German or spoken French in this call, but may as the last resort do with spoken English. Or, same thing between media: One case can be: I strongly prefer to use spoken French, but can as the last resort accept to use written French. Another can be: I must receive both spoken French and French text. 4. Same media conveyed under different media types The current draft specifies SDP as the base for the language declarations. How do we resolve the cases when the same language modality can be conveyed under different media types? Text is conveyed in real time under the media type text. But it is possible to have some near real-time exchange of text under media type message (MSRP). How do we express that these might be alternatives for carrying the same written language? That question also surfaces the problem that in the language register there are no good way to express if it is a spoken use of the language or a written use of the language we want to specify. There are separate language tags for sign languages but not for spoken varsus written. (there are some sub-tags for scripts, but they should only be used when it is important to select between script variants )(There is even an SDP-less way to carry text, in the SIP MESSAGE method. There will be no way to express that as an alternative way to convey language when we base the method on SDP.) 3. Slow start of SIP. We can in SIP have INVITE without SDP offer, and let the responding party send the offer with SDP. With the negotiation mechanism based on SDP, does this slow start cause any restrictions for us regarding the possiblilities to express and negotiate language? I do not want to cause eternal discussions about border cases, and I do not want to extend the method into unmanageable complexity. I just want us to take good decisions on the mechanism so that it covers the cases we want it to cover with a method that is not too complex. Christian, maybe in your question was also how the intended work differs from language negotiation methods already available in RFC:s? The current draft, section 6 has a discussion about that. One difference is that there is today no way to indicate order of preference between languages. Another is the one I described above; the Language tag as such does not indicate the difference between spoken and written. /Gunnar Christian Groves skrev den 2015-03-05 01:49: > Hello Randall, > > I agree with Paul that it does seem optimistic. > > In the question text its mentions the caller's "media needs". I'm > pretty sure I under the scope of "language needs" but "media needs" > could be a little open ended. What sort of enhancements do you see to > the existing negotiation methods? > > Regards, Christian > > On 5/03/2015 9:00 AM, Paul Kyzivat wrote: >> I support this. >> >> But I find the schedule vastly overoptimistic, especially for >> real-time. Add a year or two. >> >> Thanks, >> Paul >> >> On 3/3/15 6:33 PM, Randall Gellens wrote: >>> Hi SLIM people, >>> >>> Here is a revised proposed charter. The intent is to focus on the two >>> current drafts and get those completed. >>> >>> ---------- >>> >>> SLIM: Selection of Language for Internet Media >>> >>> Description of Working Group: >>> >>> A mutually comprehensible language is helpful for human communication. >>> This is true across a range of circumstances and environments. In >>> general, the problem is most acute in situations where there is not a >>> clear choice for a single language, such as environments lacking >>> contextual or out-of-band information regarding the identity of the >>> parties and the language to be used. >>> >>> The group will address two specific cases that most urgently need a >>> technical solution: One problem space is non-real-time communication, >>> specifically email for one-to-many or where the set of recipients is >>> dynamic or different recipients require different languages; the other >>> is real-time communication, specifically emergency calling, preferably >>> also useful for other cases where the parties may not know each other >>> personally or where one party wishes to accommodate people with varying >>> language and media needs. >>> >>> In the real-time communication case, language and media are >>> intrinsically linked, for example, signed languages require a video >>> media. >>> >>> While the two use cases are in different contexts (real time and >>> non-real-time), the fundamental goal is the same: to enable >>> selection of >>> the best-fit language(s) for a specific situation. Some of the details >>> will also be in common across the cases. Having a single WG address >>> both cases makes it clear that these are two aspects of the same basic >>> problem. A single WG also makes it easier to maximize similarities and >>> avoid unnecessary fragmentation of the solutions. >>> >>> The group will produce two documents, one for email, and one for >>> real-time communications. >>> >>> In the email case, the group will produce a MIME content type >>> specification that enables a single email message to contain multiple >>> language versions of the content, with provisions to help clients >>> select >>> a best fit version. >>> >>> In the real-time communication case, the group will produce a >>> specification enabling negotiation of a human language per media >>> stream. The specification must be suitable for use in emergency >>> communications as specified in RFC 6443 and RFC 6881; it is >>> desirable to >>> also be suitable for use in non-emergency real-time communications that >>> share the same call set-up and media negotiation protocols. The >>> mechanism will permit the caller's media and language needs and >>> preferences to be matched against what the called party is able to >>> provide. The mechanism will permit resources (e.g., translation, >>> relay, >>> media) to be allocated or engaged as early as possible in the call >>> set-up or for the call to be routed or handled specially (e.g., routed >>> to a resource able to provide a needed language and/or media). >>> >>> Goals and Milestones: >>> >>> June 2015 -- Submit "Multiple Language Content Type" to the IESG for >>> consideration as a Standards Track RFC >>> June 2015 -- Submit "Negotiating Human Language in Real-Time >>> Communications" to the IESG for consideration as a Standards Track RFC >>> >>> ---------- >>> >> >> _______________________________________________ >> SLIM mailing list >> SLIM@ietf.org >> https://www.ietf.org/mailman/listinfo/slim >> > > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 From nobody Thu Mar 5 09:25:34 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC4141A1B45 for ; Thu, 5 Mar 2015 09:25:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IrF5DEKs8xp3 for ; Thu, 5 Mar 2015 09:25:23 -0800 (PST) Received: from p3plwbeout03-06.prod.phx3.secureserver.net (p3plsmtp03-06-2.prod.phx3.secureserver.net [72.167.218.218]) by ietfa.amsl.com (Postfix) with ESMTP id 849781A1BB4 for ; Thu, 5 Mar 2015 09:24:23 -0800 (PST) Received: from localhost ([72.167.218.245]) by p3plwbeout03-06.prod.phx3.secureserver.net with bizsmtp id ztQP1p0015JG3DC01tQPRz; Thu, 05 Mar 2015 10:24:23 -0700 X-SID: ztQP1p0015JG3DC01 Received: (qmail 14376 invoked by uid 99); 5 Mar 2015 17:24:23 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 208.51.143.189 User-Agent: Workspace Webmail 5.10.1 Message-Id: <20150305102421.665a7a7059d7ee80bb4d670165c8327d.696b57de0a.wbe@email03.secureserver.net> From: "Doug Ewell" To: slim@ietf.org Date: Thu, 05 Mar 2015 10:24:21 -0700 Mime-Version: 1.0 Archived-At: Cc: gunnar.hellstrom@omnitor.se Subject: Re: [Slim] Proposed SLIM charter X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 17:25:29 -0000 Gunnar Hellstr=C3=B6m wrote:=0A=0A= > I expect that in many cases it is merely the modality that is of=0A> inte= rest to negotiate, rather than the exact language. There is often=0A> a def= ault language in a specific area, and as long as you use that,=0A> you will= feel that it is a burden to specify that exactly, but rather=0A> indicate = in what medium you want the language exchange. You may want=0A> to use text= for language exchange and audio to convey the sound from a=0A> location.= =0A> So, you would like to specify your preference for spoken, listened,=0A= > written, read, visualized and seen. And for signed and perceiving=0A> si= gn languages. Regardless of exact language.=0A> So, some codes to use in pl= ace of specific languages for these kinds=0A> of general modalities could b= e needed.=0A>=0A> [...]=0A>=0A> How do we express that these might be alter= natives for=0A> carrying the same written language?=0A> That question also = surfaces the problem that in the language register=0A> there are no good wa= y to express if it is a spoken use of the language=0A> or a written use of = the language we want to specify. There are=0A> separate language tags for s= ign languages but not for spoken varsus=0A> written.=0A=0AOne of the goals = I hope to accomplish in this project is to encourage=0Aproper use of BCP 47= (RFC 5646), and dispel some myths about what=0Aproblems BCP 47 is and is n= ot able to handle.=0A=0AThere are a few ways this project could represent s= poken vs. written=0Alanguage. One is to use private-use subtags: "de-x-spok= en" and=0A"de-x-written" should be clear enough to everyone. When the actua= l=0Alanguage is unspecified, but the mode is important, "und-x-spoken" and= =0A"und-x-written" could be used.=0A=0AAnother approach would involve scrip= t subtags: "de-Latn" for written=0AGerman and "de-Zxxx" for spoken German, = when (and only when) this=0Adistinction is considered important. The draft = would need to be clear=0Athat this use of otherwise-redundant script subtag= s is meant to convey=0Aspoken vs. written. Not everyone agrees that this is= a good use of=0Ascript subtags, so more discussion is needed.=0A=0AAlterna= tively, and perhaps more in keeping with Section 5 of the draft,=0Aseparate= SLIM-specific fields such as Content-Mode could be invented.=0A=0AI just w= ant to stay away from the trap of intentionally restricting the=0Ause of BC= P 47, as Section 5 does by recommending only a primary language=0Asubtag, a= nd then asserting that BCP 47 is not expressive enough, and=0Aadditional me= chanisms need to be introduced.=0A=0A--=0ADoug Ewell | http://ewellic.org |= Thornton, CO =F0=9F=87=BA=F0=9F=87=B8 =F0=9F=95=99 From nobody Thu Mar 5 11:57:15 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4C521A88F2 for ; Thu, 5 Mar 2015 11:57:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oh7XKgpVJVfj for ; Thu, 5 Mar 2015 11:57:10 -0800 (PST) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D89C1A88E3 for ; Thu, 5 Mar 2015 11:57:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1425585430; x=1457121430; h=message-id:in-reply-to:references:date:to:from:subject: mime-version; bh=3dnnz3Ni/FgKsj2AT5/igrB2MpevHLcrXYQa5EJPDpY=; b=x3wb8Td/rExCu/edmG14JX+36aCKLvEoY9SOfhXDqMtFl+rFbPIkFTkE lFTZxP8BdEMIfG6r5CquGueyhuLrVxRTnhndZ5iHQk7xQTxEnmyPUE2lV GgBkXU3fsnfMyxfdtbh7i0yRsRrAc2JxnhckQqqQvyLrmMC9v7g/IRuDB k=; X-IronPort-AV: E=McAfee;i="5600,1067,7731"; a="85140560" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by sabertooth02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Mar 2015 11:57:09 -0800 X-IronPort-AV: E=Sophos;i="5.11,348,1422950400"; d="scan'208";a="829174165" Received: from nasanexm02f.na.qualcomm.com ([10.85.0.87]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 05 Mar 2015 11:57:09 -0800 Received: from [99.111.97.136] (10.80.80.8) by nasanexm02f.na.qualcomm.com (10.85.0.87) with Microsoft SMTP Server (TLS) id 15.0.995.29; Thu, 5 Mar 2015 11:57:08 -0800 Message-ID: In-Reply-To: <54F7A836.6000307@nteczone.com> References: <54F78072.5060206@alum.mit.edu> <54F7A836.6000307@nteczone.com> X-Mailer: Eudora for Mac OS X Date: Thu, 5 Mar 2015 11:57:06 -0800 To: Christian Groves , 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-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01E.na.qualcomm.com (10.85.0.31) To nasanexm02f.na.qualcomm.com (10.85.0.87) Archived-At: Subject: Re: [Slim] Proposed SLIM charter X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 19:57:14 -0000 Hi Christian, To answer your question, by "media needs" I meant audio, text, or video media for interactive communications, which is already negotiated using SDP in SIP. I believe that by adding language to the existing media negotiation we can meet the basic use cases and be able to enhance later as needed. At 11:49 AM +1100 3/5/15, Christian Groves wrote: > Hello Randall, > > I agree with Paul that it does seem optimistic. > > In the question text its mentions the caller's "media needs". I'm > pretty sure I under the scope of "language needs" but "media needs" > could be a little open ended. What sort of enhancements do you see > to the existing negotiation methods? > > Regards, Christian > > On 5/03/2015 9:00 AM, Paul Kyzivat wrote: >> I support this. >> >> But I find the schedule vastly overoptimistic, especially for >> real-time. Add a year or two. >> >> Thanks, >> Paul >> >> On 3/3/15 6:33 PM, Randall Gellens wrote: >>> Hi SLIM people, >>> >>> Here is a revised proposed charter. The intent is to focus on the two >>> current drafts and get those completed. >>> >>> ---------- >>> >>> SLIM: Selection of Language for Internet Media >>> >>> Description of Working Group: >>> >>> A mutually comprehensible language is helpful for human communication. >>> This is true across a range of circumstances and environments. In >>> general, the problem is most acute in situations where there is not a >>> clear choice for a single language, such as environments lacking >>> contextual or out-of-band information regarding the identity of the >>> parties and the language to be used. >>> >>> The group will address two specific cases that most urgently need a >>> technical solution: One problem space is non-real-time communication, >>> specifically email for one-to-many or where the set of recipients is >>> dynamic or different recipients require different languages; the other >>> is real-time communication, specifically emergency calling, preferably >>> also useful for other cases where the parties may not know each other >>> personally or where one party wishes to accommodate people with varying >>> language and media needs. >>> >>> In the real-time communication case, language and media are >>> intrinsically linked, for example, signed languages require a video media. >>> >>> While the two use cases are in different contexts (real time and >>> non-real-time), the fundamental goal is the same: to enable selection of >>> the best-fit language(s) for a specific situation. Some of the details >>> will also be in common across the cases. Having a single WG address >>> both cases makes it clear that these are two aspects of the same basic >>> problem. A single WG also makes it easier to maximize similarities and >>> avoid unnecessary fragmentation of the solutions. >>> >>> The group will produce two documents, one for email, and one for >>> real-time communications. >>> >>> In the email case, the group will produce a MIME content type >>> specification that enables a single email message to contain multiple >>> language versions of the content, with provisions to help clients select >>> a best fit version. >>> >>> In the real-time communication case, the group will produce a >>> specification enabling negotiation of a human language per media >>> stream. The specification must be suitable for use in emergency >>> communications as specified in RFC 6443 and RFC 6881; it is desirable to >>> also be suitable for use in non-emergency real-time communications that >>> share the same call set-up and media negotiation protocols. The >>> mechanism will permit the caller's media and language needs and >>> preferences to be matched against what the called party is able to >>> provide. The mechanism will permit resources (e.g., translation, relay, >>> media) to be allocated or engaged as early as possible in the call >>> set-up or for the call to be routed or handled specially (e.g., routed >>> to a resource able to provide a needed language and/or media). >>> >>> Goals and Milestones: >>> >>> June 2015 -- Submit "Multiple Language Content Type" to the IESG for >>> consideration as a Standards Track RFC >>> June 2015 -- Submit "Negotiating Human Language in Real-Time >>> Communications" to the IESG for consideration as a Standards Track RFC >>> >>> ---------- >>> >> >> _______________________________________________ >> 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: --------------- Hofstadter's Law: It always takes longer than you expect, even when you take Hofstadter's Law into account. From nobody Thu Mar 5 12:07:02 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49D4B1A89A6 for ; Thu, 5 Mar 2015 12:07:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rq6JgI6cbq9J for ; Thu, 5 Mar 2015 12:06:58 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B9DA1A89B4 for ; Thu, 5 Mar 2015 12:06:53 -0800 (PST) Received: from [192.168.131.142] ([80.92.121.102]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MMkDH-1YOvCu2Uyl-008ZaU for ; Thu, 05 Mar 2015 21:06:51 +0100 Message-ID: <54F8B75A.2040300@gmx.net> Date: Thu, 05 Mar 2015 21:06:50 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: slim@ietf.org OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="KEL8tIIwwBHD7aKSA96mlBd2kXi1KSN0h" X-Provags-ID: V03:K0:xFt8N55e8X/vpqHXiHrDS+BzQKsGheOsrJIkTpvllm7HIrtiwUY UrekVHJRbjOFcOTRuo6UBu/NEyIUy2yPO+zhj7VzS2EzcxmWV3erAmvjOCQ0Ckr+XTQMCER RWRLT/8+1fNMa0jpLKJdAdZAp2ZVDRJXhAeBy3nmuLkn8MdFMGa6aco56LpRKbmx+nq5sTV K2gl40ZNfYRBXF7zL3kzg== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: [Slim] SLIM Charter X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 20:07:00 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --KEL8tIIwwBHD7aKSA96mlBd2kXi1KSN0h Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Randy, Hi all, I read through the charter text at http://www.ietf.org/mail-archive/web/slim/current/msg00004.html and I am happy with it. I would like to see a solution for the emergency services use case since this has been talked about for a long time already. I care less about the email case but it is fine to cover both in that group. The milestones are ambitious but given that there are documents available that are in good shape (at least the emergency services doc) I am positive that this can be accomplished. Thank you Randy for moving this topic forward! Ciao Hannes --KEL8tIIwwBHD7aKSA96mlBd2kXi1KSN0h Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJU+LdaAAoJEGhJURNOOiAtCaAH/Ran/6JgmsbKSz45oqnl+FqX n0L+lnpjeiaBY9opa1n1ljpa20dzd5ykfoKc1QVzY748nSsn9KCTtC7Z4jFt2WZl alyw9W+6MzQoKTZUkxKjNdJbL0leN4rfitPUWkjRZE/SCEaD2ADp2HpyVjVBoc26 aliPGFSNzaEP8nnTBJ4o+ku7IFIm/XXQzmGR+thCJqlwoI2vMZ7im0eNubxnvZcp MCIFtbNvx6dYllIFbnuqIE1AigDtl0OM2hkmjelWdxpFDYtwiA8tja/sBtN5bmD7 e1nENaK4RvSqWlvw86LNZeBDYUiCa555Wq+swSqpXHFLbT/4SyAfcY6JWwbsLxM= =LJnw -----END PGP SIGNATURE----- --KEL8tIIwwBHD7aKSA96mlBd2kXi1KSN0h-- From nobody Thu Mar 5 12:10:54 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95F8E1A893A for ; Thu, 5 Mar 2015 12:10:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.111 X-Spam-Level: X-Spam-Status: No, score=-6.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_31=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kMgznjbI_r2E for ; Thu, 5 Mar 2015 12:10:50 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76AA61A8932 for ; Thu, 5 Mar 2015 12:10:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1425586250; x=1457122250; h=message-id:in-reply-to:references:date:to:from:subject: mime-version:content-transfer-encoding; bh=zpY/eRm2yEJpTPXo4o1vTuSFuS78yN/FaSicYiu1Rd4=; b=E/YQPoWvdHnsZzdczp80gF3KyTtyfE2ZxthjqjBnI6pOVW+UY2cY82gq m4cpR8aNHzQhFrjRBbJfBRrH4JU4tfGX0S97XRrLgs8jpVczIhVSAgGtK DUk8vImk9SG+Jmw9zyXHGAoXD46BY5sObCi8ItH+7QOMd59TS0lbemrCR A=; X-IronPort-AV: E=McAfee;i="5600,1067,7731"; a="106480194" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Mar 2015 12:10:49 -0800 X-IronPort-AV: E=Sophos;i="5.11,348,1422950400"; d="scan'208";a="918189852" Received: from nasanexm02f.na.qualcomm.com ([10.85.0.87]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 05 Mar 2015 12:10:49 -0800 Received: from [99.111.97.136] (10.80.80.8) by nasanexm02f.na.qualcomm.com (10.85.0.87) with Microsoft SMTP Server (TLS) id 15.0.995.29; Thu, 5 Mar 2015 12:10:48 -0800 Message-ID: In-Reply-To: <54F7F951.5020109@omnitor.se> References: <54F78072.5060206@alum.mit.edu> <54F7A836.6000307@nteczone.com> <54F7F951.5020109@omnitor.se> X-Mailer: Eudora for Mac OS X Date: Thu, 5 Mar 2015 12:10:46 -0800 To: 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-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01F.na.qualcomm.com (10.85.0.32) To nasanexm02f.na.qualcomm.com (10.85.0.87) Archived-At: Subject: Re: [Slim] Proposed SLIM charter X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 20:10:53 -0000 Hi Gunnar, At 7:36 AM +0100 3/5/15, Gunnar Hellstr=F6m wrote: > I also view the charter to be good and want to see the work started. Thank you. > > There are drafts to start with: > https://tools.ietf.org/html/draft-gellens-slim-negotiating-human-language= -00 > https://tools.ietf.org/html/draft-tomkinson-slim-multilangcontent-00 > > Answering Christians question about what=20 > extensions might be needed, I want to answer=20 > relative towhat is in the realtime draft now. > > I see some topics that may need discussion: The point of the group is to have discussion on=20 what we need. One thing that has been beaten=20 into me by painful experience over many years is=20 that it's best to start with the simplest=20 possible solution that meets enough of the use=20 cases to be useful, and build on that after=20 gaining experience. I've seen this approach=20 work, whereas creating a more complex solution=20 that tries to meet all or most anticipated use=20 cases often fails due to being too difficult to=20 implement. > > 1. Coding of unspecified language but specific mode. > I expect that in many cases it is merely the=20 > modality that is of interest to negotiate,=20 > rather than the exact language. There is often=20 > a default language in a specific area, and as=20 > long as you use that, you will feel that it is=20 > a burden to specify that exactly, but rather=20 > indicate in what medium you want the language=20 > exchange. You may want to use text for language=20 > exchange and audio to convey the sound from a=20 > location. > So, you would like to specify your preference=20 > for spoken, listened, written, read, visualized=20 > and seen. And for signed and perceiving sign=20 > languages. Regardless of exact language. > So, some codes to use in place of specific=20 > languages for these kinds of general modalities=20 > could be needed. We can discuss this in the group. We already=20 have the ability to negotiate media with no=20 language expression, which might be sufficient=20 for the basic use cases. Adding a new tag for=20 the default language wouldn't be a huge burden,=20 but I'd like to see discussion on why it's needed=20 before proceeding. > > 2. Relative preference between media. > I think it can be important to have a coding=20 > for preference between media, to express for=20 > example if I prefer to speak but can accept to=20 > type. > We have an order of preference indication=20 > between languages in the same medium in the=20 > draft, but not between media. This would be worth discussing in the group as=20 well. My question would be if the incremental=20 value of being able to specify this would result=20 in any real-world benefit, that is, would it=20 change the result of the negotiation over what we=20 have now? > > 3. Absolute versus relative preference between languages. > We have a relative order of preference=20 > indication between languages in the same medium=20 > in the draft. > I can see cases when it is instead an absolute=20 > preference that would be of importance. > E.g. I am equally happy to get spoken German or=20 > spoken French in this call, but may as the last=20 > resort do with spoken English. > Or, same thing between media: > One case can be: I strongly prefer to use=20 > spoken French, but can as the last resort=20 > accept to use written French. > Another can be: I must receive both spoken French and French text. I would expect that the called party would have a=20 set of language and media capabilities (either=20 in-house or by bridging in translation, relay, or=20 interpreter services) and would want to support=20 the caller's needs. I doubt that getting fancy=20 with preferences would change the result very=20 much. > > 4. Same media conveyed under different media types > The current draft specifies SDP as the base for=20 > the language declarations. How do we resolve=20 > the cases when the same language modality can=20 > be conveyed under different media types? > Text is conveyed in real time under the media=20 > type text. But it is possible to have some near=20 > real-time exchange of text under media type=20 > message (MSRP). How do we express that these=20 > might be alternatives for carrying the same=20 > written language? > That question also surfaces the problem that in=20 > the language register there are no good way to=20 > express if it is a spoken use of the language=20 > or a written use of the language we want to=20 > specify. There are separate language tags for=20 > sign languages but not for spoken varsus=20 > written. (there are some sub-tags for scripts,=20 > but they should only be used when it is=20 > important to select between script variants=20 > )(There is even an SDP-less way to carry text,=20 > in the SIP MESSAGE method. There will be no way=20 > to express that as an alternative way to convey=20 > language when we base the method on SDP.) I'm happy to look at non-SDP and/or non-SIP=20 mechanisms once we have the SDP-and-SIP one done.=20 Since emergency calling is based on SDP and SIP,=20 I think we need to start there. > > 3. Slow start of SIP. > We can in SIP have INVITE without SDP offer,=20 > and let the responding party send the offer=20 > with SDP. > With the negotiation mechanism based on SDP,=20 > does this slow start cause any restrictions for=20 > us regarding the possiblilities to express and=20 > negotiate language? I think we need to focus initially on what's=20 needed for emergency calling and similar use=20 cases. We can expand after we get something done. > > I do not want to cause eternal discussions=20 > about border cases, and I do not want to extend=20 > the method into unmanageable complexity. I just=20 > want us to take good decisions on the mechanism=20 > so that it covers the cases we want it to cover=20 > with a method that is not too complex. Thank you, that's good to hear. > > Christian, maybe in your question was also how=20 > the intended work differs from language=20 > negotiation methods already available in RFC:s? > The current draft, section 6 has a discussion=20 > about that. One difference is that there is=20 > today no way to indicate order of preference=20 > between languages. Another is the one I=20 > described above; the Language tag as such does=20 > not indicate the difference between spoken and=20 > written. > > /Gunnar > > > Christian Groves skrev den 2015-03-05 01:49: >> Hello Randall, >> >> I agree with Paul that it does seem optimistic. >> >> In the question text its mentions the caller's=20 >> "media needs". I'm pretty sure I under the=20 >> scope of "language needs" but "media needs"=20 >> could be a little open ended. What sort of=20 >> enhancements do you see to the existing=20 >> negotiation methods? >> >> Regards, Christian >> >> On 5/03/2015 9:00 AM, Paul Kyzivat wrote: >>> I support this. >>> >>> But I find the schedule vastly=20 >>> overoptimistic, especially for real-time. Add=20 >>> a year or two. >>> >>> Thanks, >>> Paul >>> >>> On 3/3/15 6:33 PM, Randall Gellens wrote: >>>> Hi SLIM people, >>>> >>>> Here is a revised proposed charter. The intent is to focus on the two >>>> current drafts and get those completed. >>>> >>>> ---------- >>>> >>>> SLIM: Selection of Language for Internet Media >>>> >>>> Description of Working Group: >>>> >>>> A mutually comprehensible language is helpful for human communication. >>>> This is true across a range of circumstances and environments. In >>>> general, the problem is most acute in situations where there is not a >>>> clear choice for a single language, such as environments lacking >>>> contextual or out-of-band information regarding the identity of the >>>> parties and the language to be used. >>>> >>>> The group will address two specific cases that most urgently need a >>>> technical solution: One problem space is non-real-time communication, >>>> specifically email for one-to-many or where the set of recipients is >>>> dynamic or different recipients require different languages; the other >>>> is real-time communication, specifically emergency calling, preferably >>>> also useful for other cases where the parties may not know each other >>>> personally or where one party wishes to accommodate people with varyin= g >>>> language and media needs. >>>> >>>> In the real-time communication case, language and media are >>>> intrinsically linked, for example, signed languages require a video me= dia. >>>> >>>> While the two use cases are in different contexts (real time and >>>> non-real-time), the fundamental goal is the same: to enable selection = of >>>> the best-fit language(s) for a specific situation. Some of the detail= s >>>> will also be in common across the cases. Having a single WG address >>>> both cases makes it clear that these are two aspects of the same basic >>>> problem. A single WG also makes it easier to maximize similarities an= d >>>> avoid unnecessary fragmentation of the solutions. >>>> >>>> The group will produce two documents, one for email, and one for >>>> real-time communications. >>>> >>>> In the email case, the group will produce a MIME content type >>>> specification that enables a single email message to contain multiple >>>> language versions of the content, with provisions to help clients sele= ct >>>> a best fit version. >>>> >>>> In the real-time communication case, the group will produce a >>>> specification enabling negotiation of a human language per media >>>> stream. The specification must be suitable for use in emergency >>>> communications as specified in RFC 6443 and RFC 6881; it is desirable = to >>>> also be suitable for use in non-emergency real-time communications tha= t >>>> share the same call set-up and media negotiation protocols. The >>>> mechanism will permit the caller's media and language needs and >>>> preferences to be matched against what the called party is able to >>>> provide. The mechanism will permit resources (e.g., translation, rela= y, >>>> media) to be allocated or engaged as early as possible in the call >>>> set-up or for the call to be routed or handled specially (e.g., routed >>>> to a resource able to provide a needed language and/or media). >>>> >>>> Goals and Milestones: >>>> >>>> June 2015 -- Submit "Multiple Language Content Type" to the IESG for >>>> consideration as a Standards Track RFC >>>> June 2015 -- Submit "Negotiating Human Language in Real-Time >>>> Communications" to the IESG for consideration as a Standards Track RFC >>>> >>>> ---------- >>>> >>> >>> _______________________________________________ >>> 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=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: --------------- Fashion is a form of ugliness so intolerable that we have to alter it every six months. --Oscar Wilde From nobody Thu Mar 5 12:13:33 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46F671A893E for ; Thu, 5 Mar 2015 12:13:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tpJUvwlGEd2I for ; Thu, 5 Mar 2015 12:13:29 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82F2B1A893A for ; Thu, 5 Mar 2015 12:13:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1425586409; x=1457122409; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version:content-transfer-encoding; bh=rtmeCO7w/XrE2BEbpMQAqZozkq4gWf3S6JNGuiLcgDw=; b=utKB7mwaR3cu4EDVGd8d3SJfLuegWNFXF1Onu045hui35Kqwi8QPDSR0 DJb1riWW27cbFjXsHAEDaDILi3quaf3BIBYigB7xI8LKbbYVC9wAA5LAK MPjScNBPifuJR8InIlhucpUReg5Whtp3Z/Ctq8RgtEamSzUyzDFakL7gx Y=; X-IronPort-AV: E=McAfee;i="5600,1067,7731"; a="198556412" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Mar 2015 12:13:29 -0800 X-IronPort-AV: E=Sophos;i="5.11,348,1422950400"; d="scan'208";a="864376823" Received: from nasanexm02f.na.qualcomm.com ([10.85.0.87]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 05 Mar 2015 12:13:29 -0800 Received: from [99.111.97.136] (10.80.80.8) by nasanexm02f.na.qualcomm.com (10.85.0.87) with Microsoft SMTP Server (TLS) id 15.0.995.29; Thu, 5 Mar 2015 12:13:28 -0800 Message-ID: In-Reply-To: <20150305102421.665a7a7059d7ee80bb4d670165c8327d.696b57de0a.wbe@email0 3.secureserver.net> References: <20150305102421.665a7a7059d7ee80bb4d670165c8327d.696b57de0a.wbe@email0 3.secureserver.net> X-Mailer: Eudora for Mac OS X Date: Thu, 5 Mar 2015 12:13:26 -0800 To: Doug Ewell , 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-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01C.na.qualcomm.com (10.85.0.83) To nasanexm02f.na.qualcomm.com (10.85.0.87) Archived-At: Cc: gunnar.hellstrom@omnitor.se Subject: Re: [Slim] Proposed SLIM charter X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 20:13:31 -0000 Hi Doug, At 10:24 AM -0700 3/5/15, Doug Ewell wrote: > Gunnar Hellstr=F6m wrote: > >> I expect that in many cases it is merely the modality that is of >> interest to negotiate, rather than the exact language. There is often >> a default language in a specific area, and as long as you use that, >> you will feel that it is a burden to specify that exactly, but rather >> indicate in what medium you want the language exchange. You may want >> to use text for language exchange and audio to convey the sound from a >> location. >> So, you would like to specify your preference for spoken, listened, >> written, read, visualized and seen. And for signed and perceiving >> sign languages. Regardless of exact language. >> So, some codes to use in place of specific languages for these kinds >> of general modalities could be needed. >> >> [...] >> >> How do we express that these might be alternatives for >> carrying the same written language? >> That question also surfaces the problem that in the language register >> there are no good way to express if it is a spoken use of the language >> or a written use of the language we want to specify. There are >> separate language tags for sign languages but not for spoken varsus >> written. > > One of the goals I hope to accomplish in this project is to encourage > proper use of BCP 47 (RFC 5646), and dispel some myths about what > problems BCP 47 is and is not able to handle. > > There are a few ways this project could represent spoken vs. written > language. One is to use private-use subtags: "de-x-spoken" and > "de-x-written" should be clear enough to everyone. When the actual > language is unspecified, but the mode is important, "und-x-spoken" and > "und-x-written" could be used. > > Another approach would involve script subtags: "de-Latn" for written > German and "de-Zxxx" for spoken German, when (and only when) this > distinction is considered important. The draft would need to be clear > that this use of otherwise-redundant script subtags is meant to convey > spoken vs. written. Not everyone agrees that this is a good use of > script subtags, so more discussion is needed. Note that the media itself indicates the form: an=20 audio media is used for spoken languages, text=20 for written, and video for signed (which also=20 have their own language tags). > > Alternatively, and perhaps more in keeping with Section 5 of the draft, > separate SLIM-specific fields such as Content-Mode could be invented. > > I just want to stay away from the trap of intentionally restricting the > use of BCP 47, as Section 5 does by recommending only a primary language > subtag, and then asserting that BCP 47 is not expressive enough, and > additional mechanisms need to be introduced. I agree. It would be silly to restrict use of=20 language tags and then complain that they are too=20 restrictive. The goal is to enable mutually=20 comprehensible language, especially for emergency=20 calls. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Those were my children being slaughtered. --Donald Burr, on the death of People Express. From nobody Thu Mar 5 13:49:47 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B786B1A907F for ; Thu, 5 Mar 2015 13:49:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.001 X-Spam-Level: X-Spam-Status: No, score=-1.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_31=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 cGwSKSBtirTF for ; Thu, 5 Mar 2015 13:49:42 -0800 (PST) Received: from bin-vsp-out-05.atm.binero.net (vsp-authed01.binero.net [195.74.38.224]) (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 B32981A907B for ; Thu, 5 Mar 2015 13:49:41 -0800 (PST) X-Halon-ID: 85bfa103-c381-11e4-a4af-005056916f53 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.42] (unknown [77.53.231.174]) by bin-vsp-out-05.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Thu, 5 Mar 2015 22:49:38 +0100 (CET) Message-ID: <54F8CF6D.3010107@omnitor.se> Date: Thu, 05 Mar 2015 22:49:33 +0100 From: =?windows-1252?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: slim@ietf.org References: <54F78072.5060206@alum.mit.edu> <54F7A836.6000307@nteczone.com> <54F7F951.5020109@omnitor.se> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [Slim] Use cases X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 21:49:45 -0000 In order to decide on what to support, I think we should now collect a long list of use cases and then decide which ones to support and which ones to not support. I can imagine two kinds of use cases: 1. architectural cases outlining callers, callees and call distribution and routing functions and additional services. 2. call cases: callers with language and media preferences called parties with media and language capabilities and additional services with language capabilities. So, here is a use case: Emergency call from an Australian Sign language user A deaf person in Australia has prepared her phone with the following preferences: Prefer to use Australian Sign Language for both signing and perceiving sign in video. Can with less but fair preference do International Sign in both directions in video. Can but do not prefer to use real-time text in English in the text channel. Has a terminal with audio function both ways but has no interest to use that for language communication. She has an emergency in Australia and calls the Australian emergency number. The emergency service has no own sign language capability, but has a few terminals and operators who handle video, audio and real-time text (total conversation). They have an agreement to call for interpretation between Australian Sign Laguage and Spoken English, but that service is allowed to have up to two minutes answering time. The call is analyzed for language and media contents and the ACD offers it to the group of operators with total conversation terminals with an indication that the two sign languages are preferred but that English text is possible. The analysis also causes an outgoing call in all media to the sign language interpreting service because no operator in the emergency service know sign language. The emergency operator takes the call and establish all media, and see from the declaration that it is possible to start asking about the emergency by text. The deaf caller see all media being established but also see that at the moment the only common language is typed English. A minute later the sign laguage interpreter answers. The call is modified to a three-party call, the capability indication changes so that it is evident to the caller that Australian sign language can be used now. The call can continue in convenient sign with the calling user and speech between the interpreter and the emergency operator. If anything needs exact spelling or remembered, then the text channel is still there for occasional use. Gunnar Randall Gellens skrev den 2015-03-05 21:10: > Hi Gunnar, > > At 7:36 AM +0100 3/5/15, Gunnar Hellström wrote: > >> I also view the charter to be good and want to see the work started. > > Thank you. > >> >> There are drafts to start with: >> https://tools.ietf.org/html/draft-gellens-slim-negotiating-human-language-00 >> >> https://tools.ietf.org/html/draft-tomkinson-slim-multilangcontent-00 >> >> Answering Christians question about what extensions might be needed, >> I want to answer relative towhat is in the realtime draft now. >> >> I see some topics that may need discussion: > > The point of the group is to have discussion on what we need. One > thing that has been beaten into me by painful experience over many > years is that it's best to start with the simplest possible solution > that meets enough of the use cases to be useful, and build on that > after gaining experience. I've seen this approach work, whereas > creating a more complex solution that tries to meet all or most > anticipated use cases often fails due to being too difficult to > implement. > >> >> 1. Coding of unspecified language but specific mode. >> I expect that in many cases it is merely the modality that is of >> interest to negotiate, rather than the exact language. There is often >> a default language in a specific area, and as long as you use that, >> you will feel that it is a burden to specify that exactly, but rather >> indicate in what medium you want the language exchange. You may want >> to use text for language exchange and audio to convey the sound from >> a location. >> So, you would like to specify your preference for spoken, listened, >> written, read, visualized and seen. And for signed and perceiving >> sign languages. Regardless of exact language. >> So, some codes to use in place of specific languages for these kinds >> of general modalities could be needed. > > We can discuss this in the group. We already have the ability to > negotiate media with no language expression, which might be sufficient > for the basic use cases. Adding a new tag for the default language > wouldn't be a huge burden, but I'd like to see discussion on why it's > needed before proceeding. > >> >> 2. Relative preference between media. >> I think it can be important to have a coding for preference between >> media, to express for example if I prefer to speak but can accept to >> type. >> We have an order of preference indication between languages in the >> same medium in the draft, but not between media. > > This would be worth discussing in the group as well. My question > would be if the incremental value of being able to specify this would > result in any real-world benefit, that is, would it change the result > of the negotiation over what we have now? > >> >> 3. Absolute versus relative preference between languages. >> We have a relative order of preference indication between languages >> in the same medium in the draft. >> I can see cases when it is instead an absolute preference that would >> be of importance. >> E.g. I am equally happy to get spoken German or spoken French in >> this call, but may as the last resort do with spoken English. >> Or, same thing between media: >> One case can be: I strongly prefer to use spoken French, but can as >> the last resort accept to use written French. >> Another can be: I must receive both spoken French and French text. > > I would expect that the called party would have a set of language and > media capabilities (either in-house or by bridging in translation, > relay, or interpreter services) and would want to support the caller's > needs. I doubt that getting fancy with preferences would change the > result very much. > >> >> 4. Same media conveyed under different media types >> The current draft specifies SDP as the base for the language >> declarations. How do we resolve the cases when the same language >> modality can be conveyed under different media types? >> Text is conveyed in real time under the media type text. But it is >> possible to have some near real-time exchange of text under media >> type message (MSRP). How do we express that these might be >> alternatives for carrying the same written language? >> That question also surfaces the problem that in the language >> register there are no good way to express if it is a spoken use of >> the language or a written use of the language we want to specify. >> There are separate language tags for sign languages but not for >> spoken varsus written. (there are some sub-tags for scripts, but they >> should only be used when it is important to select between script >> variants )(There is even an SDP-less way to carry text, in the SIP >> MESSAGE method. There will be no way to express that as an >> alternative way to convey language when we base the method on SDP.) > > I'm happy to look at non-SDP and/or non-SIP mechanisms once we have > the SDP-and-SIP one done. Since emergency calling is based on SDP and > SIP, I think we need to start there. > >> >> 3. Slow start of SIP. >> We can in SIP have INVITE without SDP offer, and let the responding >> party send the offer with SDP. >> With the negotiation mechanism based on SDP, does this slow start >> cause any restrictions for us regarding the possiblilities to express >> and negotiate language? > > I think we need to focus initially on what's needed for emergency > calling and similar use cases. We can expand after we get something > done. > >> >> I do not want to cause eternal discussions about border cases, and I >> do not want to extend the method into unmanageable complexity. I just >> want us to take good decisions on the mechanism so that it covers the >> cases we want it to cover with a method that is not too complex. > > Thank you, that's good to hear. > >> >> Christian, maybe in your question was also how the intended work >> differs from language negotiation methods already available in RFC:s? >> The current draft, section 6 has a discussion about that. One >> difference is that there is today no way to indicate order of >> preference between languages. Another is the one I described above; >> the Language tag as such does not indicate the difference between >> spoken and written. >> >> /Gunnar >> >> >> Christian Groves skrev den 2015-03-05 01:49: >>> Hello Randall, >>> >>> I agree with Paul that it does seem optimistic. >>> >>> In the question text its mentions the caller's "media needs". I'm >>> pretty sure I under the scope of "language needs" but "media needs" >>> could be a little open ended. What sort of enhancements do you see >>> to the existing negotiation methods? >>> >>> Regards, Christian >>> >>> On 5/03/2015 9:00 AM, Paul Kyzivat wrote: >>>> I support this. >>>> >>>> But I find the schedule vastly overoptimistic, especially for >>>> real-time. Add a year or two. >>>> >>>> Thanks, >>>> Paul >>>> >>>> On 3/3/15 6:33 PM, Randall Gellens wrote: >>>>> Hi SLIM people, >>>>> >>>>> Here is a revised proposed charter. The intent is to focus on >>>>> the two >>>>> current drafts and get those completed. >>>>> >>>>> ---------- >>>>> >>>>> SLIM: Selection of Language for Internet Media >>>>> >>>>> Description of Working Group: >>>>> >>>>> A mutually comprehensible language is helpful for human >>>>> communication. >>>>> This is true across a range of circumstances and environments. In >>>>> general, the problem is most acute in situations where there is >>>>> not a >>>>> clear choice for a single language, such as environments lacking >>>>> contextual or out-of-band information regarding the identity of the >>>>> parties and the language to be used. >>>>> >>>>> The group will address two specific cases that most urgently need a >>>>> technical solution: One problem space is non-real-time >>>>> communication, >>>>> specifically email for one-to-many or where the set of recipients is >>>>> dynamic or different recipients require different languages; the >>>>> other >>>>> is real-time communication, specifically emergency calling, >>>>> preferably >>>>> also useful for other cases where the parties may not know each >>>>> other >>>>> personally or where one party wishes to accommodate people with >>>>> varying >>>>> language and media needs. >>>>> >>>>> In the real-time communication case, language and media are >>>>> intrinsically linked, for example, signed languages require a >>>>> video media. >>>>> >>>>> While the two use cases are in different contexts (real time and >>>>> non-real-time), the fundamental goal is the same: to enable >>>>> selection of >>>>> the best-fit language(s) for a specific situation. Some of the >>>>> details >>>>> will also be in common across the cases. Having a single WG address >>>>> both cases makes it clear that these are two aspects of the same >>>>> basic >>>>> problem. A single WG also makes it easier to maximize >>>>> similarities and >>>>> avoid unnecessary fragmentation of the solutions. >>>>> >>>>> The group will produce two documents, one for email, and one for >>>>> real-time communications. >>>>> >>>>> In the email case, the group will produce a MIME content type >>>>> specification that enables a single email message to contain >>>>> multiple >>>>> language versions of the content, with provisions to help clients >>>>> select >>>>> a best fit version. >>>>> >>>>> In the real-time communication case, the group will produce a >>>>> specification enabling negotiation of a human language per media >>>>> stream. The specification must be suitable for use in emergency >>>>> communications as specified in RFC 6443 and RFC 6881; it is >>>>> desirable to >>>>> also be suitable for use in non-emergency real-time >>>>> communications that >>>>> share the same call set-up and media negotiation protocols. The >>>>> mechanism will permit the caller's media and language needs and >>>>> preferences to be matched against what the called party is able to >>>>> provide. The mechanism will permit resources (e.g., translation, >>>>> relay, >>>>> media) to be allocated or engaged as early as possible in the call >>>>> set-up or for the call to be routed or handled specially (e.g., >>>>> routed >>>>> to a resource able to provide a needed language and/or media). >>>>> >>>>> Goals and Milestones: >>>>> >>>>> June 2015 -- Submit "Multiple Language Content Type" to the IESG for >>>>> consideration as a Standards Track RFC >>>>> June 2015 -- Submit "Negotiating Human Language in Real-Time >>>>> Communications" to the IESG for consideration as a Standards >>>>> Track RFC >>>>> >>>>> ---------- >>>>> >>>> >>>> _______________________________________________ >>>> 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 Thu Mar 5 14:16:33 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1CAD1A894F for ; Thu, 5 Mar 2015 14:16:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.635 X-Spam-Level: X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_31=0.6, SPF_SOFTFAIL=0.665] autolearn=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 Mim871TU6GOV for ; Thu, 5 Mar 2015 14:16:28 -0800 (PST) Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:37]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 852E81A8939 for ; Thu, 5 Mar 2015 14:16:28 -0800 (PST) Received: from resomta-ch2-15v.sys.comcast.net ([69.252.207.111]) by resqmta-ch2-05v.sys.comcast.net with comcast id zyG11p0052Qkjl901yGT2C; Thu, 05 Mar 2015 22:16:27 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-15v.sys.comcast.net with comcast id zyGT1p0023Ge9ey01yGTv9; Thu, 05 Mar 2015 22:16:27 +0000 Message-ID: <54F8D5BA.2050305@alum.mit.edu> Date: Thu, 05 Mar 2015 17:16:26 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: slim@ietf.org References: <54F78072.5060206@alum.mit.edu> <54F7A836.6000307@nteczone.com> <54F7F951.5020109@omnitor.se> <54F8CF6D.3010107@omnitor.se> In-Reply-To: <54F8CF6D.3010107@omnitor.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1425593787; bh=VRx0e2Bcfa7mY4p1VE365bvL8+zO3gCSQn9Ag2pH22Q=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=e5Z3a797FnlsZ1E2w2oe442wAHjtyjAuJuEEP6O6vv/Rq+Fe7PYw0arbQ43g0tTiR CJQyqiAOlP3Yul4hz5d9ZfA9wtWXetNX73ndPGM77sDEcUDaWk8Qk0lSGvKOIhdOKa +NAjz17YTZ6/sTJjo7DrtrQ0LPfs2Kuv8bDmXaHQ7iER6kp7xGxlyLxVPwWuR0FNAs bf1mUxp4A4LTI/JD79BEK9mAkw94KT/VgGW2lF5/O53n4ZdOgzukkiIKkpSSRRKV6w clS7dxELc3Z/n3UkdbrpoJEDf3HHIElR1j7ywRk7rwOqeBlmFiHkiGgl+PylWWPzyj AeJV9xfO7OodQ== Archived-At: Subject: Re: [Slim] Use cases X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 22:16:31 -0000 The use case below is a good start. Are use cases for non-emergency real time communications also in scope? I'll also observe that there is major interaction between the way the language and media preferences are signaled and the architecture of the systems that ensure there is a match of capabilities. Some of today's relay services depend on being able to know the preferences of the callee before communications are established to the callee. They do this in order to queue the call until relay services are available before contacting the callee. That is in conflict to allowing the called device to signal its preferences without pre-arrangement. In the use case below, the emergency operator takes the call before the relay is included. This works out because there is *some* medium in common that can be used before relaying comes online. There would be a problem if the emergency operator only supported audio - the call would be established but there would initially be no useful media. That would be distressing for the caller. In emergency cases it is plausible to expect the emergency operators to have extra technology to help with these cases. But in non-emergency cases that isn't necessarily true. My point is simply that the architecture(s) required to support these features should be considered as part of the work. (This may not lead to any normative requirements. It might only be examples or use cases.) Thanks, Paul On 3/5/15 4:49 PM, Gunnar Hellström wrote: > In order to decide on what to support, I think we should now collect a > long list of use cases and then decide which ones to support and which > ones to not support. > > I can imagine two kinds of use cases: > 1. architectural cases outlining callers, callees and call distribution > and routing functions and additional services. > 2. call cases: callers with language and media preferences called > parties with media and language capabilities and additional services > with language capabilities. > > So, here is a use case: > > Emergency call from an Australian Sign language user > > A deaf person in Australia has prepared her phone with the following > preferences: > Prefer to use Australian Sign Language for both signing and perceiving > sign in video. > Can with less but fair preference do International Sign in both > directions in video. > Can but do not prefer to use real-time text in English in the text channel. > Has a terminal with audio function both ways but has no interest to use > that for language communication. > She has an emergency in Australia and calls the Australian emergency > number. > The emergency service has no own sign language capability, but has a few > terminals and operators who handle video, audio and real-time text > (total conversation). They have an agreement to call for interpretation > between Australian Sign Laguage and Spoken English, but that service is > allowed to have up to two minutes answering time. > The call is analyzed for language and media contents and the ACD offers > it to the group of operators with total conversation terminals with an > indication that the two sign languages are preferred but that English > text is possible. > The analysis also causes an outgoing call in all media to the sign > language interpreting service because no operator in the emergency > service know sign language. > The emergency operator takes the call and establish all media, and see > from the declaration that it is possible to start asking about the > emergency by text. The deaf caller see all media being established but > also see that at the moment the only common language is typed English. > A minute later the sign laguage interpreter answers. The call is > modified to a three-party call, the capability indication changes so > that it is evident to the caller that Australian sign language can be > used now. > The call can continue in convenient sign with the calling user and > speech between the interpreter and the emergency operator. If anything > needs exact spelling or remembered, then the text channel is still there > for occasional use. > > > Gunnar > > > > Randall Gellens skrev den 2015-03-05 21:10: >> Hi Gunnar, >> >> At 7:36 AM +0100 3/5/15, Gunnar Hellström wrote: >> >>> I also view the charter to be good and want to see the work started. >> >> Thank you. >> >>> >>> There are drafts to start with: >>> https://tools.ietf.org/html/draft-gellens-slim-negotiating-human-language-00 >>> >>> https://tools.ietf.org/html/draft-tomkinson-slim-multilangcontent-00 >>> >>> Answering Christians question about what extensions might be needed, >>> I want to answer relative towhat is in the realtime draft now. >>> >>> I see some topics that may need discussion: >> >> The point of the group is to have discussion on what we need. One >> thing that has been beaten into me by painful experience over many >> years is that it's best to start with the simplest possible solution >> that meets enough of the use cases to be useful, and build on that >> after gaining experience. I've seen this approach work, whereas >> creating a more complex solution that tries to meet all or most >> anticipated use cases often fails due to being too difficult to >> implement. >> >>> >>> 1. Coding of unspecified language but specific mode. >>> I expect that in many cases it is merely the modality that is of >>> interest to negotiate, rather than the exact language. There is often >>> a default language in a specific area, and as long as you use that, >>> you will feel that it is a burden to specify that exactly, but rather >>> indicate in what medium you want the language exchange. You may want >>> to use text for language exchange and audio to convey the sound from >>> a location. >>> So, you would like to specify your preference for spoken, listened, >>> written, read, visualized and seen. And for signed and perceiving >>> sign languages. Regardless of exact language. >>> So, some codes to use in place of specific languages for these kinds >>> of general modalities could be needed. >> >> We can discuss this in the group. We already have the ability to >> negotiate media with no language expression, which might be sufficient >> for the basic use cases. Adding a new tag for the default language >> wouldn't be a huge burden, but I'd like to see discussion on why it's >> needed before proceeding. >> >>> >>> 2. Relative preference between media. >>> I think it can be important to have a coding for preference between >>> media, to express for example if I prefer to speak but can accept to >>> type. >>> We have an order of preference indication between languages in the >>> same medium in the draft, but not between media. >> >> This would be worth discussing in the group as well. My question >> would be if the incremental value of being able to specify this would >> result in any real-world benefit, that is, would it change the result >> of the negotiation over what we have now? >> >>> >>> 3. Absolute versus relative preference between languages. >>> We have a relative order of preference indication between languages >>> in the same medium in the draft. >>> I can see cases when it is instead an absolute preference that would >>> be of importance. >>> E.g. I am equally happy to get spoken German or spoken French in >>> this call, but may as the last resort do with spoken English. >>> Or, same thing between media: >>> One case can be: I strongly prefer to use spoken French, but can as >>> the last resort accept to use written French. >>> Another can be: I must receive both spoken French and French text. >> >> I would expect that the called party would have a set of language and >> media capabilities (either in-house or by bridging in translation, >> relay, or interpreter services) and would want to support the caller's >> needs. I doubt that getting fancy with preferences would change the >> result very much. >> >>> >>> 4. Same media conveyed under different media types >>> The current draft specifies SDP as the base for the language >>> declarations. How do we resolve the cases when the same language >>> modality can be conveyed under different media types? >>> Text is conveyed in real time under the media type text. But it is >>> possible to have some near real-time exchange of text under media >>> type message (MSRP). How do we express that these might be >>> alternatives for carrying the same written language? >>> That question also surfaces the problem that in the language >>> register there are no good way to express if it is a spoken use of >>> the language or a written use of the language we want to specify. >>> There are separate language tags for sign languages but not for >>> spoken varsus written. (there are some sub-tags for scripts, but they >>> should only be used when it is important to select between script >>> variants )(There is even an SDP-less way to carry text, in the SIP >>> MESSAGE method. There will be no way to express that as an >>> alternative way to convey language when we base the method on SDP.) >> >> I'm happy to look at non-SDP and/or non-SIP mechanisms once we have >> the SDP-and-SIP one done. Since emergency calling is based on SDP and >> SIP, I think we need to start there. >> >>> >>> 3. Slow start of SIP. >>> We can in SIP have INVITE without SDP offer, and let the responding >>> party send the offer with SDP. >>> With the negotiation mechanism based on SDP, does this slow start >>> cause any restrictions for us regarding the possiblilities to express >>> and negotiate language? >> >> I think we need to focus initially on what's needed for emergency >> calling and similar use cases. We can expand after we get something >> done. >> >>> >>> I do not want to cause eternal discussions about border cases, and I >>> do not want to extend the method into unmanageable complexity. I just >>> want us to take good decisions on the mechanism so that it covers the >>> cases we want it to cover with a method that is not too complex. >> >> Thank you, that's good to hear. >> >>> >>> Christian, maybe in your question was also how the intended work >>> differs from language negotiation methods already available in RFC:s? >>> The current draft, section 6 has a discussion about that. One >>> difference is that there is today no way to indicate order of >>> preference between languages. Another is the one I described above; >>> the Language tag as such does not indicate the difference between >>> spoken and written. >>> >>> /Gunnar >>> >>> >>> Christian Groves skrev den 2015-03-05 01:49: >>>> Hello Randall, >>>> >>>> I agree with Paul that it does seem optimistic. >>>> >>>> In the question text its mentions the caller's "media needs". I'm >>>> pretty sure I under the scope of "language needs" but "media needs" >>>> could be a little open ended. What sort of enhancements do you see >>>> to the existing negotiation methods? >>>> >>>> Regards, Christian >>>> >>>> On 5/03/2015 9:00 AM, Paul Kyzivat wrote: >>>>> I support this. >>>>> >>>>> But I find the schedule vastly overoptimistic, especially for >>>>> real-time. Add a year or two. >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>> On 3/3/15 6:33 PM, Randall Gellens wrote: >>>>>> Hi SLIM people, >>>>>> >>>>>> Here is a revised proposed charter. The intent is to focus on >>>>>> the two >>>>>> current drafts and get those completed. >>>>>> >>>>>> ---------- >>>>>> >>>>>> SLIM: Selection of Language for Internet Media >>>>>> >>>>>> Description of Working Group: >>>>>> >>>>>> A mutually comprehensible language is helpful for human >>>>>> communication. >>>>>> This is true across a range of circumstances and environments. In >>>>>> general, the problem is most acute in situations where there is >>>>>> not a >>>>>> clear choice for a single language, such as environments lacking >>>>>> contextual or out-of-band information regarding the identity of the >>>>>> parties and the language to be used. >>>>>> >>>>>> The group will address two specific cases that most urgently need a >>>>>> technical solution: One problem space is non-real-time >>>>>> communication, >>>>>> specifically email for one-to-many or where the set of recipients is >>>>>> dynamic or different recipients require different languages; the >>>>>> other >>>>>> is real-time communication, specifically emergency calling, >>>>>> preferably >>>>>> also useful for other cases where the parties may not know each >>>>>> other >>>>>> personally or where one party wishes to accommodate people with >>>>>> varying >>>>>> language and media needs. >>>>>> >>>>>> In the real-time communication case, language and media are >>>>>> intrinsically linked, for example, signed languages require a >>>>>> video media. >>>>>> >>>>>> While the two use cases are in different contexts (real time and >>>>>> non-real-time), the fundamental goal is the same: to enable >>>>>> selection of >>>>>> the best-fit language(s) for a specific situation. Some of the >>>>>> details >>>>>> will also be in common across the cases. Having a single WG address >>>>>> both cases makes it clear that these are two aspects of the same >>>>>> basic >>>>>> problem. A single WG also makes it easier to maximize >>>>>> similarities and >>>>>> avoid unnecessary fragmentation of the solutions. >>>>>> >>>>>> The group will produce two documents, one for email, and one for >>>>>> real-time communications. >>>>>> >>>>>> In the email case, the group will produce a MIME content type >>>>>> specification that enables a single email message to contain >>>>>> multiple >>>>>> language versions of the content, with provisions to help clients >>>>>> select >>>>>> a best fit version. >>>>>> >>>>>> In the real-time communication case, the group will produce a >>>>>> specification enabling negotiation of a human language per media >>>>>> stream. The specification must be suitable for use in emergency >>>>>> communications as specified in RFC 6443 and RFC 6881; it is >>>>>> desirable to >>>>>> also be suitable for use in non-emergency real-time >>>>>> communications that >>>>>> share the same call set-up and media negotiation protocols. The >>>>>> mechanism will permit the caller's media and language needs and >>>>>> preferences to be matched against what the called party is able to >>>>>> provide. The mechanism will permit resources (e.g., translation, >>>>>> relay, >>>>>> media) to be allocated or engaged as early as possible in the call >>>>>> set-up or for the call to be routed or handled specially (e.g., >>>>>> routed >>>>>> to a resource able to provide a needed language and/or media). >>>>>> >>>>>> Goals and Milestones: >>>>>> >>>>>> June 2015 -- Submit "Multiple Language Content Type" to the IESG for >>>>>> consideration as a Standards Track RFC >>>>>> June 2015 -- Submit "Negotiating Human Language in Real-Time >>>>>> Communications" to the IESG for consideration as a Standards >>>>>> Track RFC >>>>>> >>>>>> ---------- >>>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >> >> >> > From nobody Thu Mar 5 14:39:23 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84FE31A907F for ; Thu, 5 Mar 2015 14:39:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.001 X-Spam-Level: X-Spam-Status: No, score=-1.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_31=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 n1Yy7kuLmPCE for ; Thu, 5 Mar 2015 14:39:11 -0800 (PST) Received: from bin-vsp-out-05.atm.binero.net (vsp-authed01.binero.net [195.74.38.224]) (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 BAF721A894F for ; Thu, 5 Mar 2015 14:39:10 -0800 (PST) X-Halon-ID: 6fd04e8f-c388-11e4-a4af-005056916f53 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.42] (unknown [77.53.231.174]) by bin-vsp-out-05.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Thu, 5 Mar 2015 23:39:08 +0100 (CET) Message-ID: <54F8DB06.5060905@omnitor.se> Date: Thu, 05 Mar 2015 23:39:02 +0100 From: =?windows-1252?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: slim@ietf.org References: <54F78072.5060206@alum.mit.edu> <54F7A836.6000307@nteczone.com> <54F7F951.5020109@omnitor.se> <54F8CF6D.3010107@omnitor.se> <54F8D5BA.2050305@alum.mit.edu> In-Reply-To: <54F8D5BA.2050305@alum.mit.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Slim] Use cases X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 22:39:16 -0000 Paul, Paul Kyzivat skrev den 2015-03-05 23:16: > The use case below is a good start. > > Are use cases for non-emergency real time communications also in scope? Yes. > > I'll also observe that there is major interaction between the way the > language and media preferences are signaled and the architecture of > the systems that ensure there is a match of capabilities. Some of > today's relay services depend on being able to know the preferences of > the callee before communications are established to the callee. They > do this in order to queue the call until relay services are available > before contacting the callee. That is in conflict to allowing the > called device to signal its preferences without pre-arrangement. Right. This is a problem with SDP-based preferences. We have discussed SIP Media tag based preferences. They can be conveyed at Register time and stored in SIP servers, and then compared for routing decisions with what the caller has. That approach is described in the draft Appendix A. I think the main problem with that approach was what we thought was a lack of way to describe spoken versus written language ( that we have learned a way around today ), and that the already specified ways for decision maing with RFC 3840 - 3841 did not seem to fit totally. A way in a closed environment would be to require support for OPTIONS, to get a preview of the SDP. And in this case you might be able to require OPTIONS support if you want to have your calls properly routed, and an assumption that if there is no resonse on OPTIONS, then that user is supposed to be a speech user with the default language of the area. > > In the use case below, the emergency operator takes the call before > the relay is included. This works out because there is *some* medium > in common that can be used before relaying comes online. There would > be a problem if the emergency operator only supported audio - the call > would be established but there would initially be no useful media. > That would be distressing for the caller. In emergency cases it is > plausible to expect the emergency operators to have extra technology > to help with these cases. But in non-emergency cases that isn't > necessarily true. Yes, I agree completely that answering a call and finding that you have no common language is distressing. The 2 minute wait for interpreter should of course also be avoided. But exsists in reality. > > My point is simply that the architecture(s) required to support these > features should be considered as part of the work. (This may not lead > to any normative requirements. It might only be examples or use cases.) Yes. > > Thanks, > Paul > > On 3/5/15 4:49 PM, Gunnar Hellström wrote: >> In order to decide on what to support, I think we should now collect a >> long list of use cases and then decide which ones to support and which >> ones to not support. >> >> I can imagine two kinds of use cases: >> 1. architectural cases outlining callers, callees and call distribution >> and routing functions and additional services. >> 2. call cases: callers with language and media preferences called >> parties with media and language capabilities and additional services >> with language capabilities. >> >> So, here is a use case: >> >> Emergency call from an Australian Sign language user >> >> A deaf person in Australia has prepared her phone with the following >> preferences: >> Prefer to use Australian Sign Language for both signing and perceiving >> sign in video. >> Can with less but fair preference do International Sign in both >> directions in video. >> Can but do not prefer to use real-time text in English in the text >> channel. >> Has a terminal with audio function both ways but has no interest to use >> that for language communication. >> She has an emergency in Australia and calls the Australian emergency >> number. >> The emergency service has no own sign language capability, but has a few >> terminals and operators who handle video, audio and real-time text >> (total conversation). They have an agreement to call for interpretation >> between Australian Sign Laguage and Spoken English, but that service is >> allowed to have up to two minutes answering time. >> The call is analyzed for language and media contents and the ACD offers >> it to the group of operators with total conversation terminals with an >> indication that the two sign languages are preferred but that English >> text is possible. >> The analysis also causes an outgoing call in all media to the sign >> language interpreting service because no operator in the emergency >> service know sign language. >> The emergency operator takes the call and establish all media, and see >> from the declaration that it is possible to start asking about the >> emergency by text. The deaf caller see all media being established but >> also see that at the moment the only common language is typed English. >> A minute later the sign laguage interpreter answers. The call is >> modified to a three-party call, the capability indication changes so >> that it is evident to the caller that Australian sign language can be >> used now. >> The call can continue in convenient sign with the calling user and >> speech between the interpreter and the emergency operator. If anything >> needs exact spelling or remembered, then the text channel is still there >> for occasional use. >> >> >> Gunnar >> >> >> >> Randall Gellens skrev den 2015-03-05 21:10: >>> Hi Gunnar, >>> >>> At 7:36 AM +0100 3/5/15, Gunnar Hellström wrote: >>> >>>> I also view the charter to be good and want to see the work started. >>> >>> Thank you. >>> >>>> >>>> There are drafts to start with: >>>> https://tools.ietf.org/html/draft-gellens-slim-negotiating-human-language-00 >>>> >>>> >>>> https://tools.ietf.org/html/draft-tomkinson-slim-multilangcontent-00 >>>> >>>> Answering Christians question about what extensions might be needed, >>>> I want to answer relative towhat is in the realtime draft now. >>>> >>>> I see some topics that may need discussion: >>> >>> The point of the group is to have discussion on what we need. One >>> thing that has been beaten into me by painful experience over many >>> years is that it's best to start with the simplest possible solution >>> that meets enough of the use cases to be useful, and build on that >>> after gaining experience. I've seen this approach work, whereas >>> creating a more complex solution that tries to meet all or most >>> anticipated use cases often fails due to being too difficult to >>> implement. >>> >>>> >>>> 1. Coding of unspecified language but specific mode. >>>> I expect that in many cases it is merely the modality that is of >>>> interest to negotiate, rather than the exact language. There is often >>>> a default language in a specific area, and as long as you use that, >>>> you will feel that it is a burden to specify that exactly, but rather >>>> indicate in what medium you want the language exchange. You may want >>>> to use text for language exchange and audio to convey the sound from >>>> a location. >>>> So, you would like to specify your preference for spoken, listened, >>>> written, read, visualized and seen. And for signed and perceiving >>>> sign languages. Regardless of exact language. >>>> So, some codes to use in place of specific languages for these kinds >>>> of general modalities could be needed. >>> >>> We can discuss this in the group. We already have the ability to >>> negotiate media with no language expression, which might be sufficient >>> for the basic use cases. Adding a new tag for the default language >>> wouldn't be a huge burden, but I'd like to see discussion on why it's >>> needed before proceeding. >>> >>>> >>>> 2. Relative preference between media. >>>> I think it can be important to have a coding for preference between >>>> media, to express for example if I prefer to speak but can accept to >>>> type. >>>> We have an order of preference indication between languages in the >>>> same medium in the draft, but not between media. >>> >>> This would be worth discussing in the group as well. My question >>> would be if the incremental value of being able to specify this would >>> result in any real-world benefit, that is, would it change the result >>> of the negotiation over what we have now? >>> >>>> >>>> 3. Absolute versus relative preference between languages. >>>> We have a relative order of preference indication between languages >>>> in the same medium in the draft. >>>> I can see cases when it is instead an absolute preference that would >>>> be of importance. >>>> E.g. I am equally happy to get spoken German or spoken French in >>>> this call, but may as the last resort do with spoken English. >>>> Or, same thing between media: >>>> One case can be: I strongly prefer to use spoken French, but can as >>>> the last resort accept to use written French. >>>> Another can be: I must receive both spoken French and French text. >>> >>> I would expect that the called party would have a set of language and >>> media capabilities (either in-house or by bridging in translation, >>> relay, or interpreter services) and would want to support the caller's >>> needs. I doubt that getting fancy with preferences would change the >>> result very much. >>> >>>> >>>> 4. Same media conveyed under different media types >>>> The current draft specifies SDP as the base for the language >>>> declarations. How do we resolve the cases when the same language >>>> modality can be conveyed under different media types? >>>> Text is conveyed in real time under the media type text. But it is >>>> possible to have some near real-time exchange of text under media >>>> type message (MSRP). How do we express that these might be >>>> alternatives for carrying the same written language? >>>> That question also surfaces the problem that in the language >>>> register there are no good way to express if it is a spoken use of >>>> the language or a written use of the language we want to specify. >>>> There are separate language tags for sign languages but not for >>>> spoken varsus written. (there are some sub-tags for scripts, but they >>>> should only be used when it is important to select between script >>>> variants )(There is even an SDP-less way to carry text, in the SIP >>>> MESSAGE method. There will be no way to express that as an >>>> alternative way to convey language when we base the method on SDP.) >>> >>> I'm happy to look at non-SDP and/or non-SIP mechanisms once we have >>> the SDP-and-SIP one done. Since emergency calling is based on SDP and >>> SIP, I think we need to start there. >>> >>>> >>>> 3. Slow start of SIP. >>>> We can in SIP have INVITE without SDP offer, and let the responding >>>> party send the offer with SDP. >>>> With the negotiation mechanism based on SDP, does this slow start >>>> cause any restrictions for us regarding the possiblilities to express >>>> and negotiate language? >>> >>> I think we need to focus initially on what's needed for emergency >>> calling and similar use cases. We can expand after we get something >>> done. >>> >>>> >>>> I do not want to cause eternal discussions about border cases, and I >>>> do not want to extend the method into unmanageable complexity. I just >>>> want us to take good decisions on the mechanism so that it covers the >>>> cases we want it to cover with a method that is not too complex. >>> >>> Thank you, that's good to hear. >>> >>>> >>>> Christian, maybe in your question was also how the intended work >>>> differs from language negotiation methods already available in RFC:s? >>>> The current draft, section 6 has a discussion about that. One >>>> difference is that there is today no way to indicate order of >>>> preference between languages. Another is the one I described above; >>>> the Language tag as such does not indicate the difference between >>>> spoken and written. >>>> >>>> /Gunnar >>>> >>>> >>>> Christian Groves skrev den 2015-03-05 01:49: >>>>> Hello Randall, >>>>> >>>>> I agree with Paul that it does seem optimistic. >>>>> >>>>> In the question text its mentions the caller's "media needs". I'm >>>>> pretty sure I under the scope of "language needs" but "media needs" >>>>> could be a little open ended. What sort of enhancements do you see >>>>> to the existing negotiation methods? >>>>> >>>>> Regards, Christian >>>>> >>>>> On 5/03/2015 9:00 AM, Paul Kyzivat wrote: >>>>>> I support this. >>>>>> >>>>>> But I find the schedule vastly overoptimistic, especially for >>>>>> real-time. Add a year or two. >>>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> >>>>>> On 3/3/15 6:33 PM, Randall Gellens wrote: >>>>>>> Hi SLIM people, >>>>>>> >>>>>>> Here is a revised proposed charter. The intent is to focus on >>>>>>> the two >>>>>>> current drafts and get those completed. >>>>>>> >>>>>>> ---------- >>>>>>> >>>>>>> SLIM: Selection of Language for Internet Media >>>>>>> >>>>>>> Description of Working Group: >>>>>>> >>>>>>> A mutually comprehensible language is helpful for human >>>>>>> communication. >>>>>>> This is true across a range of circumstances and environments. In >>>>>>> general, the problem is most acute in situations where there is >>>>>>> not a >>>>>>> clear choice for a single language, such as environments lacking >>>>>>> contextual or out-of-band information regarding the identity of >>>>>>> the >>>>>>> parties and the language to be used. >>>>>>> >>>>>>> The group will address two specific cases that most urgently >>>>>>> need a >>>>>>> technical solution: One problem space is non-real-time >>>>>>> communication, >>>>>>> specifically email for one-to-many or where the set of >>>>>>> recipients is >>>>>>> dynamic or different recipients require different languages; the >>>>>>> other >>>>>>> is real-time communication, specifically emergency calling, >>>>>>> preferably >>>>>>> also useful for other cases where the parties may not know each >>>>>>> other >>>>>>> personally or where one party wishes to accommodate people with >>>>>>> varying >>>>>>> language and media needs. >>>>>>> >>>>>>> In the real-time communication case, language and media are >>>>>>> intrinsically linked, for example, signed languages require a >>>>>>> video media. >>>>>>> >>>>>>> While the two use cases are in different contexts (real time and >>>>>>> non-real-time), the fundamental goal is the same: to enable >>>>>>> selection of >>>>>>> the best-fit language(s) for a specific situation. Some of the >>>>>>> details >>>>>>> will also be in common across the cases. Having a single WG >>>>>>> address >>>>>>> both cases makes it clear that these are two aspects of the same >>>>>>> basic >>>>>>> problem. A single WG also makes it easier to maximize >>>>>>> similarities and >>>>>>> avoid unnecessary fragmentation of the solutions. >>>>>>> >>>>>>> The group will produce two documents, one for email, and one for >>>>>>> real-time communications. >>>>>>> >>>>>>> In the email case, the group will produce a MIME content type >>>>>>> specification that enables a single email message to contain >>>>>>> multiple >>>>>>> language versions of the content, with provisions to help clients >>>>>>> select >>>>>>> a best fit version. >>>>>>> >>>>>>> In the real-time communication case, the group will produce a >>>>>>> specification enabling negotiation of a human language per media >>>>>>> stream. The specification must be suitable for use in emergency >>>>>>> communications as specified in RFC 6443 and RFC 6881; it is >>>>>>> desirable to >>>>>>> also be suitable for use in non-emergency real-time >>>>>>> communications that >>>>>>> share the same call set-up and media negotiation protocols. The >>>>>>> mechanism will permit the caller's media and language needs and >>>>>>> preferences to be matched against what the called party is able to >>>>>>> provide. The mechanism will permit resources (e.g., translation, >>>>>>> relay, >>>>>>> media) to be allocated or engaged as early as possible in the call >>>>>>> set-up or for the call to be routed or handled specially (e.g., >>>>>>> routed >>>>>>> to a resource able to provide a needed language and/or media). >>>>>>> >>>>>>> Goals and Milestones: >>>>>>> >>>>>>> June 2015 -- Submit "Multiple Language Content Type" to the >>>>>>> IESG for >>>>>>> consideration as a Standards Track RFC >>>>>>> June 2015 -- Submit "Negotiating Human Language in Real-Time >>>>>>> Communications" to the IESG for consideration as a Standards >>>>>>> Track RFC >>>>>>> >>>>>>> ---------- >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>> >>> >>> >> > > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 From nobody Thu Mar 5 15:34:37 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 938B21A907E for ; Thu, 5 Mar 2015 15:34:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_31=0.6] autolearn=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 sqhv8gO52xZr for ; Thu, 5 Mar 2015 15:34:34 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9537C1A9073 for ; Thu, 5 Mar 2015 15:34:33 -0800 (PST) Received: from ppp118-209-141-233.lns20.mel8.internode.on.net ([118.209.141.233]:54766 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1YTfGO-00088j-Ch for slim@ietf.org; Fri, 06 Mar 2015 10:33:08 +1100 Message-ID: <54F8E7E2.3090703@nteczone.com> Date: Fri, 06 Mar 2015 10:33:54 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: slim@ietf.org References: <54F78072.5060206@alum.mit.edu> <54F7A836.6000307@nteczone.com> <54F7F951.5020109@omnitor.se> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [Slim] Proposed SLIM charter X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 23:34:36 -0000 Hello Gunnar and Randall, I agree with your comments regarding a targeted solution. My question was really to see the scope of changes people were thinking about around media negotiation. E.g. whether specific language related additions are needed or more of a general solution for media preferences. I think Randall's it would be worth adding some text to the charter would be a reminder to avoid scope creep. Something similar to Randall's clarification that: "media needs means audio, text, or video media for interactive communications, which is already negotiated using SDP in SIP. I believe that by adding language to the existing media negotiation we can meet the basic use cases and be able to enhance later as needed." A separate question: does the group expect to discuss the use of CLUE? When multiple streams are used it does have the ability to indicate language, priority and other metadata that could be helpful to the selection of language/media. Regards, Christian On 6/03/2015 7:10 AM, Randall Gellens wrote: > Hi Gunnar, > > At 7:36 AM +0100 3/5/15, Gunnar Hellström wrote: > >> I also view the charter to be good and want to see the work started. > > Thank you. > >> >> There are drafts to start with: >> https://tools.ietf.org/html/draft-gellens-slim-negotiating-human-language-00 >> >> https://tools.ietf.org/html/draft-tomkinson-slim-multilangcontent-00 >> >> Answering Christians question about what extensions might be needed, >> I want to answer relative towhat is in the realtime draft now. >> >> I see some topics that may need discussion: > > The point of the group is to have discussion on what we need. One > thing that has been beaten into me by painful experience over many > years is that it's best to start with the simplest possible solution > that meets enough of the use cases to be useful, and build on that > after gaining experience. I've seen this approach work, whereas > creating a more complex solution that tries to meet all or most > anticipated use cases often fails due to being too difficult to > implement. >> >> 1. Coding of unspecified language but specific mode. >> I expect that in many cases it is merely the modality that is of >> interest to negotiate, rather than the exact language. There is often >> a default language in a specific area, and as long as you use that, >> you will feel that it is a burden to specify that exactly, but rather >> indicate in what medium you want the language exchange. You may want >> to use text for language exchange and audio to convey the sound from >> a location. >> So, you would like to specify your preference for spoken, listened, >> written, read, visualized and seen. And for signed and perceiving >> sign languages. Regardless of exact language. >> So, some codes to use in place of specific languages for these kinds >> of general modalities could be needed. > > We can discuss this in the group. We already have the ability to > negotiate media with no language expression, which might be sufficient > for the basic use cases. Adding a new tag for the default language > wouldn't be a huge burden, but I'd like to see discussion on why it's > needed before proceeding. > >> >> 2. Relative preference between media. >> I think it can be important to have a coding for preference between >> media, to express for example if I prefer to speak but can accept to >> type. >> We have an order of preference indication between languages in the >> same medium in the draft, but not between media. > > This would be worth discussing in the group as well. My question > would be if the incremental value of being able to specify this would > result in any real-world benefit, that is, would it change the result > of the negotiation over what we have now? > >> >> 3. Absolute versus relative preference between languages. >> We have a relative order of preference indication between languages >> in the same medium in the draft. >> I can see cases when it is instead an absolute preference that would >> be of importance. >> E.g. I am equally happy to get spoken German or spoken French in >> this call, but may as the last resort do with spoken English. >> Or, same thing between media: >> One case can be: I strongly prefer to use spoken French, but can as >> the last resort accept to use written French. >> Another can be: I must receive both spoken French and French text. > > I would expect that the called party would have a set of language and > media capabilities (either in-house or by bridging in translation, > relay, or interpreter services) and would want to support the caller's > needs. I doubt that getting fancy with preferences would change the > result very much. > >> >> 4. Same media conveyed under different media types >> The current draft specifies SDP as the base for the language >> declarations. How do we resolve the cases when the same language >> modality can be conveyed under different media types? >> Text is conveyed in real time under the media type text. But it is >> possible to have some near real-time exchange of text under media >> type message (MSRP). How do we express that these might be >> alternatives for carrying the same written language? >> That question also surfaces the problem that in the language >> register there are no good way to express if it is a spoken use of >> the language or a written use of the language we want to specify. >> There are separate language tags for sign languages but not for >> spoken varsus written. (there are some sub-tags for scripts, but they >> should only be used when it is important to select between script >> variants )(There is even an SDP-less way to carry text, in the SIP >> MESSAGE method. There will be no way to express that as an >> alternative way to convey language when we base the method on SDP.) > > I'm happy to look at non-SDP and/or non-SIP mechanisms once we have > the SDP-and-SIP one done. Since emergency calling is based on SDP and > SIP, I think we need to start there. > >> >> 3. Slow start of SIP. >> We can in SIP have INVITE without SDP offer, and let the responding >> party send the offer with SDP. >> With the negotiation mechanism based on SDP, does this slow start >> cause any restrictions for us regarding the possiblilities to express >> and negotiate language? > > I think we need to focus initially on what's needed for emergency > calling and similar use cases. We can expand after we get something > done. > >> >> I do not want to cause eternal discussions about border cases, and I >> do not want to extend the method into unmanageable complexity. I just >> want us to take good decisions on the mechanism so that it covers the >> cases we want it to cover with a method that is not too complex. > > Thank you, that's good to hear. > >> >> Christian, maybe in your question was also how the intended work >> differs from language negotiation methods already available in RFC:s? >> The current draft, section 6 has a discussion about that. One >> difference is that there is today no way to indicate order of >> preference between languages. Another is the one I described above; >> the Language tag as such does not indicate the difference between >> spoken and written. >> >> /Gunnar >> >> >> Christian Groves skrev den 2015-03-05 01:49: >>> Hello Randall, >>> >>> I agree with Paul that it does seem optimistic. >>> >>> In the question text its mentions the caller's "media needs". I'm >>> pretty sure I under the scope of "language needs" but "media needs" >>> could be a little open ended. What sort of enhancements do you see >>> to the existing negotiation methods? >>> >>> Regards, Christian >>> >>> On 5/03/2015 9:00 AM, Paul Kyzivat wrote: >>>> I support this. >>>> >>>> But I find the schedule vastly overoptimistic, especially for >>>> real-time. Add a year or two. >>>> >>>> Thanks, >>>> Paul >>>> >>>> On 3/3/15 6:33 PM, Randall Gellens wrote: >>>>> Hi SLIM people, >>>>> >>>>> Here is a revised proposed charter. The intent is to focus on >>>>> the two >>>>> current drafts and get those completed. >>>>> >>>>> ---------- >>>>> >>>>> SLIM: Selection of Language for Internet Media >>>>> >>>>> Description of Working Group: >>>>> >>>>> A mutually comprehensible language is helpful for human >>>>> communication. >>>>> This is true across a range of circumstances and environments. In >>>>> general, the problem is most acute in situations where there is >>>>> not a >>>>> clear choice for a single language, such as environments lacking >>>>> contextual or out-of-band information regarding the identity of the >>>>> parties and the language to be used. >>>>> >>>>> The group will address two specific cases that most urgently need a >>>>> technical solution: One problem space is non-real-time >>>>> communication, >>>>> specifically email for one-to-many or where the set of recipients is >>>>> dynamic or different recipients require different languages; the >>>>> other >>>>> is real-time communication, specifically emergency calling, >>>>> preferably >>>>> also useful for other cases where the parties may not know each >>>>> other >>>>> personally or where one party wishes to accommodate people with >>>>> varying >>>>> language and media needs. >>>>> >>>>> In the real-time communication case, language and media are >>>>> intrinsically linked, for example, signed languages require a >>>>> video media. >>>>> >>>>> While the two use cases are in different contexts (real time and >>>>> non-real-time), the fundamental goal is the same: to enable >>>>> selection of >>>>> the best-fit language(s) for a specific situation. Some of the >>>>> details >>>>> will also be in common across the cases. Having a single WG address >>>>> both cases makes it clear that these are two aspects of the same >>>>> basic >>>>> problem. A single WG also makes it easier to maximize >>>>> similarities and >>>>> avoid unnecessary fragmentation of the solutions. >>>>> >>>>> The group will produce two documents, one for email, and one for >>>>> real-time communications. >>>>> >>>>> In the email case, the group will produce a MIME content type >>>>> specification that enables a single email message to contain >>>>> multiple >>>>> language versions of the content, with provisions to help clients >>>>> select >>>>> a best fit version. >>>>> >>>>> In the real-time communication case, the group will produce a >>>>> specification enabling negotiation of a human language per media >>>>> stream. The specification must be suitable for use in emergency >>>>> communications as specified in RFC 6443 and RFC 6881; it is >>>>> desirable to >>>>> also be suitable for use in non-emergency real-time >>>>> communications that >>>>> share the same call set-up and media negotiation protocols. The >>>>> mechanism will permit the caller's media and language needs and >>>>> preferences to be matched against what the called party is able to >>>>> provide. The mechanism will permit resources (e.g., translation, >>>>> relay, >>>>> media) to be allocated or engaged as early as possible in the call >>>>> set-up or for the call to be routed or handled specially (e.g., >>>>> routed >>>>> to a resource able to provide a needed language and/or media). >>>>> >>>>> Goals and Milestones: >>>>> >>>>> June 2015 -- Submit "Multiple Language Content Type" to the IESG for >>>>> consideration as a Standards Track RFC >>>>> June 2015 -- Submit "Negotiating Human Language in Real-Time >>>>> Communications" to the IESG for consideration as a Standards >>>>> Track RFC >>>>> >>>>> ---------- >>>>> >>>> >>>> _______________________________________________ >>>> 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 > > > From nobody Thu Mar 5 19:16:59 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F8611AC410 for ; Thu, 5 Mar 2015 19:16:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 OPiGoqw69vF2 for ; Thu, 5 Mar 2015 19:16:56 -0800 (PST) Received: from resqmta-ch2-03v.sys.comcast.net (resqmta-ch2-03v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:35]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7607D1AC402 for ; Thu, 5 Mar 2015 19:16:56 -0800 (PST) Received: from resomta-ch2-11v.sys.comcast.net ([69.252.207.107]) by resqmta-ch2-03v.sys.comcast.net with comcast id 03GX1q0032Ka2Q5013Gv4o; Fri, 06 Mar 2015 03:16:55 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-11v.sys.comcast.net with comcast id 03Gv1q0023Ge9ey013Gve7; Fri, 06 Mar 2015 03:16:55 +0000 Message-ID: <54F91C26.4080600@alum.mit.edu> Date: Thu, 05 Mar 2015 22:16:54 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: slim@ietf.org References: <54F78072.5060206@alum.mit.edu> <54F7A836.6000307@nteczone.com> <54F7F951.5020109@omnitor.se> <54F8E7E2.3090703@nteczone.com> In-Reply-To: <54F8E7E2.3090703@nteczone.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1425611815; bh=xjVyCsBFhV+nwXfuo0sGgoSADdHkR35yrTcp4pIJ1p0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=rfRVgzYYwTL/EBITwrLiXGhJUP+3Y2N1X1Ud4YIjL3X9vO9XN5zTEUB0WeRU/RVuz 4nErtCL9GbC7D+4tAftkqUm3WhDkF4Lu4lPTOFbeX7bl4rBlZJ0Vxg0aosmc4euWP+ 2q12YBmmvURoKafnzlJv8kpL5HmcTOmiJaU1M4JvycI5w60QsvLkhrqatMWh11jPZS Rnj9O3SluAZg4pQpTv/udy9IVtzjQXHcwP5FwMBlhygZ88bUinsECIWar3fRWrebva rMhxGORz0nfP2Llnf/T/6Mrr6GJxKfjAOmFb+47TCSQzumiiZ7KIxgimnL/HH20jcL SX3aTV+i/hB1Q== Archived-At: Subject: Re: [Slim] Proposed SLIM charter X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 03:16:57 -0000 On 3/5/15 6:33 PM, Christian Groves wrote: > A separate question: does the group expect to discuss the use of CLUE? > When multiple streams are used it does have the ability to indicate > language, priority and other metadata that could be helpful to the > selection of language/media. I was going to bring this up, but you beat me to it. :-( CLUE certainly offers a basis for a solution to this sort of problem. But it is a bit heavyweight. My thought is that the SLIM mechanism would eventually be something that would *eventually* be used in most session establishments, with most degenerating to a simple media call without need for any relaying/conversions. At the same time it would gracefully hook to the more complex scenarios when needed. You wouldn't want to set up a CLUE session for every call just to find out if you need some media/language conversions. But maybe it would be helpful in the more complex cases. In any case, I think this is a mechanism discussion, not a charter discussion. Thanks, Paul From nobody Fri Mar 6 11:34:03 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8A711A6F2F for ; Fri, 6 Mar 2015 11:34:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.512 X-Spam-Level: X-Spam-Status: No, score=-4.512 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3UB0G-XCq40X for ; Fri, 6 Mar 2015 11:33:54 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24C891A6F2B for ; Fri, 6 Mar 2015 11:33:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1425670434; x=1457206434; h=message-id:in-reply-to:references:date:to:from:subject: mime-version:content-transfer-encoding; bh=QApnwtNP2hlRGQrDpS7ZL+mtYXlWhQoeerZpmHmwqyw=; b=m4QToRVGdXi99Zbk2XOKrhvOiLwpdLEiJ4qCF3UbLEgnOtSsC/Bj7gqp +qzR21tP8BzCN4+P/C62kni34NhQdUzMtu6ZFJH416jxIX3ebgxbhUMaj RZ0/bbZ730vBl4G8jQU11jR6T0Lhduo9TVDKpVqBtpQeCWnC4vGKBF/GJ k=; X-IronPort-AV: E=McAfee;i="5600,1067,7732"; a="198772259" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Mar 2015 11:33:53 -0800 X-IronPort-AV: E=Sophos;i="5.11,354,1422950400"; d="scan'208";a="855526358" Received: from nasanexm02f.na.qualcomm.com ([10.85.0.87]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 06 Mar 2015 11:33:53 -0800 Received: from [99.111.97.136] (10.80.80.8) by nasanexm02f.na.qualcomm.com (10.85.0.87) with Microsoft SMTP Server (TLS) id 15.0.995.29; Fri, 6 Mar 2015 11:33:52 -0800 Message-ID: In-Reply-To: <54F8E7E2.3090703@nteczone.com> References: <54F78072.5060206@alum.mit.edu> <54F7A836.6000307@nteczone.com> <54F7F951.5020109@omnitor.se> <54F8E7E2.3090703@nteczone.com> X-Mailer: Eudora for Mac OS X Date: Fri, 6 Mar 2015 11:33:50 -0800 To: Christian Groves , 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-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01C.na.qualcomm.com (10.85.0.83) To nasanexm02f.na.qualcomm.com (10.85.0.87) Archived-At: Subject: Re: [Slim] Proposed SLIM charter X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 19:34:01 -0000 Hi Christian, I'm happy with your suggestion to add clarifying=20 text to the proposed charter as an additional=20 guard against scope creep. How about this: Change the sentence: The specification must be suitable for use in emergency communications as specified in RFC 6443 and RFC 6881; it is desirable to also be suitable for use in non-emergency real-time communications that share the same call set-up and media negotiation protocols. to: The specification must be suitable for use in emergency communications as specified in RFC 6443 and RFC 6881 (which use SIP and SDP to negotiate media); it is desirable to also be suitable for use in non-emergency real-time communications that share the same call set-up and media negotiation protocols. The difference is the parenthetical aside. Also, we can add a new paragraph based on Christian's suggestion: By adding language to the existing media negotiation mechanism, the group can meet the basic use cases with minimal added complexity and be able to enhance later for additional use cases as needed. If people are happy with this, I will add it to the proposed charter. At 10:33 AM +1100 3/6/15, Christian Groves wrote: > Hello Gunnar and Randall, > > I agree with your comments regarding a targeted=20 > solution. My question was really to see the=20 > scope of changes people were thinking about=20 > around media negotiation. E.g. whether specific=20 > language related additions are needed or more=20 > of a general solution for media preferences. > > I think Randall's it would be worth adding some=20 > text to the charter would be a reminder to=20 > avoid scope creep. Something similar to=20 > Randall's clarification that: "media needs=20 > means audio, text, or video media for=20 > interactive communications, which is already=20 > negotiated using SDP in SIP. I believe that by=20 > adding language to the existing media=20 > negotiation we can meet the basic use cases and=20 > be able to enhance later as needed." > > A separate question: does the group expect to=20 > discuss the use of CLUE? When multiple streams=20 > are used it does have the ability to indicate=20 > language, priority and other metadata that=20 > could be helpful to the selection of=20 > language/media. > > Regards, Christian > > On 6/03/2015 7:10 AM, Randall Gellens wrote: >> Hi Gunnar, >> >> At 7:36 AM +0100 3/5/15, Gunnar Hellstr=F6m wrote: >> >>> I also view the charter to be good and want to see the work started. >> >> Thank you. >> >>> >>> There are drafts to start with: >>>=20 >>> https://tools.ietf.org/html/draft-gellens-slim-negotiating-human-languag= e-00 >>> https://tools.ietf.org/html/draft-tomkinson-slim-multilangcontent-00 >>> >>> Answering Christians question about what=20 >>> extensions might be needed, I want to answer=20 >>> relative towhat is in the realtime draft now. >>> >>> I see some topics that may need discussion: >> >> The point of the group is to have discussion=20 >> on what we need. One thing that has been=20 >> beaten into me by painful experience over many=20 >> years is that it's best to start with the=20 >> simplest possible solution that meets enough=20 >> of the use cases to be useful, and build on=20 >> that after gaining experience. I've seen this=20 >> approach work, whereas creating a more complex=20 >> solution that tries to meet all or most=20 >> anticipated use cases often fails due to being=20 >> too difficult to implement. > >>> >>> 1. Coding of unspecified language but specific mode. >>> I expect that in many cases it is merely the=20 >>> modality that is of interest to negotiate,=20 >>> rather than the exact language. There is=20 >>> often a default language in a specific area,=20 >>> and as long as you use that, you will feel=20 >>> that it is a burden to specify that exactly,=20 >>> but rather indicate in what medium you want=20 >>> the language exchange. You may want to use=20 >>> text for language exchange and audio to=20 >>> convey the sound from a location. >>> So, you would like to specify your=20 >>> preference for spoken, listened, written,=20 >>> read, visualized and seen. And for signed=20 >>> and perceiving sign languages. Regardless of=20 >>> exact language. >>> So, some codes to use in place of specific=20 >>> languages for these kinds of general=20 >>> modalities could be needed. >> >> We can discuss this in the group. We already=20 >> have the ability to negotiate media with no=20 >> language expression, which might be sufficient=20 >> for the basic use cases. Adding a new tag for=20 >> the default language wouldn't be a huge=20 >> burden, but I'd like to see discussion on why=20 >> it's needed before proceeding. >> >>> >>> 2. Relative preference between media. >>> I think it can be important to have a coding=20 >>> for preference between media, to express for=20 >>> example if I prefer to speak but can accept=20 >>> to type. >>> We have an order of preference indication=20 >>> between languages in the same medium in the=20 >>> draft, but not between media. >> >> This would be worth discussing in the group as=20 >> well. My question would be if the incremental=20 >> value of being able to specify this would=20 >> result in any real-world benefit, that is,=20 >> would it change the result of the negotiation=20 >> over what we have now? >> >>> >>> 3. Absolute versus relative preference between languages. >>> We have a relative order of preference=20 >>> indication between languages in the same=20 >>> medium in the draft. >>> I can see cases when it is instead an=20 >>> absolute preference that would be of=20 >>> importance. >>> E.g. I am equally happy to get spoken German=20 >>> or spoken French in this call, but may as the=20 >>> last resort do with spoken English. >>> Or, same thing between media: >>> One case can be: I strongly prefer to use=20 >>> spoken French, but can as the last resort=20 >>> accept to use written French. >>> Another can be: I must receive both spoken French and French text. >> >> I would expect that the called party would=20 >> have a set of language and media capabilities=20 >> (either in-house or by bridging in=20 >> translation, relay, or interpreter services)=20 >> and would want to support the caller's needs.=20 >> I doubt that getting fancy with preferences=20 >> would change the result very much. >> >>> >>> 4. Same media conveyed under different media types >>> The current draft specifies SDP as the base=20 >>> for the language declarations. How do we=20 >>> resolve the cases when the same language=20 >>> modality can be conveyed under different=20 >>> media types? >>> Text is conveyed in real time under the=20 >>> media type text. But it is possible to have=20 >>> some near real-time exchange of text under=20 >>> media type message (MSRP). How do we express=20 >>> that these might be alternatives for carrying=20 >>> the same written language? >>> That question also surfaces the problem that=20 >>> in the language register there are no good=20 >>> way to express if it is a spoken use of the=20 >>> language or a written use of the language we=20 >>> want to specify. There are separate language=20 >>> tags for sign languages but not for spoken=20 >>> varsus written. (there are some sub-tags for=20 >>> scripts, but they should only be used when it=20 >>> is important to select between script=20 >>> variants )(There is even an SDP-less way to=20 >>> carry text, in the SIP MESSAGE method. There=20 >>> will be no way to express that as an=20 >>> alternative way to convey language when we=20 >>> base the method on SDP.) >> >> I'm happy to look at non-SDP and/or non-SIP=20 >> mechanisms once we have the SDP-and-SIP one=20 >> done. Since emergency calling is based on SDP=20 >> and SIP, I think we need to start there. >> >>> >>> 3. Slow start of SIP. >>> We can in SIP have INVITE without SDP offer,=20 >>> and let the responding party send the offer=20 >>> with SDP. >>> With the negotiation mechanism based on SDP,=20 >>> does this slow start cause any restrictions=20 >>> for us regarding the possiblilities to=20 >>> express and negotiate language? >> >> I think we need to focus initially on what's=20 >> needed for emergency calling and similar use=20 >> cases. We can expand after we get something=20 >> done. >> >>> >>> I do not want to cause eternal discussions=20 >>> about border cases, and I do not want to=20 >>> extend the method into unmanageable=20 >>> complexity. I just want us to take good=20 >>> decisions on the mechanism so that it covers=20 >>> the cases we want it to cover with a method=20 >>> that is not too complex. >> >> Thank you, that's good to hear. >> >>> >>> Christian, maybe in your question was also=20 >>> how the intended work differs from language=20 >>> negotiation methods already available in=20 >>> RFC:s? >>> The current draft, section 6 has a=20 >>> discussion about that. One difference is that=20 >>> there is today no way to indicate order of=20 >>> preference between languages. Another is the=20 >>> one I described above; the Language tag as=20 >>> such does not indicate the difference between=20 >>> spoken and written. >>> >>> /Gunnar >>> >>> >>> Christian Groves skrev den 2015-03-05 01:49: >>>> Hello Randall, >>>> >>>> I agree with Paul that it does seem optimistic. >>>> >>>> In the question text its mentions the=20 >>>> caller's "media needs". I'm pretty sure I=20 >>>> under the scope of "language needs" but=20 >>>> "media needs" could be a little open ended.=20 >>>> What sort of enhancements do you see to the=20 >>>> existing negotiation methods? >>>> >>>> Regards, Christian >>>> >>>> On 5/03/2015 9:00 AM, Paul Kyzivat wrote: >>>>> I support this. >>>>> >>>>> But I find the schedule vastly=20 >>>>> overoptimistic, especially for real-time.=20 >>>>> Add a year or two. >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>> On 3/3/15 6:33 PM, Randall Gellens wrote: >>>>>> Hi SLIM people, >>>>>> >>>>>> Here is a revised proposed charter. The intent is to focus on the = two >>>>>> current drafts and get those completed. >>>>>> >>>>>> ---------- >>>>>> >>>>>> SLIM: Selection of Language for Internet Media >>>>>> >>>>>> Description of Working Group: >>>>>> >>>>>> A mutually comprehensible language is helpful for human communicati= on. >>>>>> This is true across a range of circumstances and environments. In >>>>>> general, the problem is most acute in situations where there is not= a >>>>>> clear choice for a single language, such as environments lacking >>>>>> contextual or out-of-band information regarding the identity of the >>>>>> parties and the language to be used. >>>>>> >>>>>> The group will address two specific cases that most urgently need a >>>>>> technical solution: One problem space is non-real-time communicatio= n, >>>>>> specifically email for one-to-many or where the set of recipients i= s >>>>>> dynamic or different recipients require different languages; the ot= her >>>>>> is real-time communication, specifically emergency calling, prefera= bly >>>>>> also useful for other cases where the parties may not know each oth= er >>>>>> personally or where one party wishes to accommodate people with var= ying >>>>>> language and media needs. >>>>>> >>>>>> In the real-time communication case, language and media are >>>>>> intrinsically linked, for example, signed=20 >>>>>> languages require a video media. >>>>>> >>>>>> While the two use cases are in different contexts (real time and >>>>>> non-real-time), the fundamental goal is=20 >>>>>> the same: to enable selection of >>>>>> the best-fit language(s) for a specific situation. Some of the det= ails >>>>>> will also be in common across the cases. Having a single WG addres= s >>>>>> both cases makes it clear that these are two aspects of the same ba= sic >>>>>> problem. A single WG also makes it easier to maximize similarities= and >>>>>> avoid unnecessary fragmentation of the solutions. >>>>>> >>>>>> The group will produce two documents, one for email, and one for >>>>>> real-time communications. >>>>>> >>>>>> In the email case, the group will produce a MIME content type >>>>>> specification that enables a single email message to contain multip= le >>>>>> language versions of the content, with=20 >>>>>> provisions to help clients select >>>>>> a best fit version. >>>>>> >>>>>> In the real-time communication case, the group will produce a >>>>>> specification enabling negotiation of a human language per media >>>>>> stream. The specification must be suitable for use in emergency >>>>>> communications as specified in RFC 6443=20 >>>>>> and RFC 6881; it is desirable to >>>>>> also be suitable for use in non-emergency real-time communications = that >>>>>> share the same call set-up and media negotiation protocols. The >>>>>> mechanism will permit the caller's media and language needs and >>>>>> preferences to be matched against what the called party is able to >>>>>> provide. The mechanism will permit=20 >>>>>> resources (e.g., translation, relay, >>>>>> media) to be allocated or engaged as early as possible in the call >>>>>> set-up or for the call to be routed or handled specially (e.g., rou= ted >>>>>> to a resource able to provide a needed language and/or media). >>>>>> >>>>>> Goals and Milestones: >>>>>> >>>>>> June 2015 -- Submit "Multiple Language Content Type" to the IESG fo= r >>>>>> consideration as a Standards Track RFC >>>>>> June 2015 -- Submit "Negotiating Human Language in Real-Time >>>>>> Communications" to the IESG for consideration as a Standards Track = RFC >>>>>> >>>>>> ---------- >>>>>> >>>>> >>>>> _______________________________________________ >>>>> 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=F6m >>> Omnitor >>> gunnar.hellstrom@omnitor.se >>> +46 708 204 288 >>> >>> _______________________________________________ >>> SLIM mailing list >>> SLIM@ietf.org >>> https://www.ietf.org/mailman/listinfo/slim >> >> >> > > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Being president is like running a cemetery: You've got a lot of people under you and nobody's listening. --William Jefferson Clinton From nobody Sat Mar 7 11:33:59 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ECA61A0277 for ; Sat, 7 Mar 2015 11:33:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.112 X-Spam-Level: X-Spam-Status: No, score=-5.112 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TInYgs5ZtObT for ; Sat, 7 Mar 2015 11:33:54 -0800 (PST) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A23DC1A01FA for ; Sat, 7 Mar 2015 11:33:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1425756834; x=1457292834; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version; bh=wooHNcVMPsiJDpUijyd6a8SN5okpSB3PfI1DPIFMgSo=; b=NHbsMa0NVvrOTrA9f1KIXqFC2K7THbGozWNeepnSPuzd/FGt6jAWw3CZ a4tuKwSXGQrKo37rb9yZoEQNFdPoV30Qc+hiIsc/kSp0bWvcYcq6LaiTv AdYd03K1k2SUZYPl3dimDOkUObKGMz8OB5a5NQw0UOWAD0wyDcb78Vner o=; X-IronPort-AV: E=McAfee;i="5600,1067,7733"; a="85293815" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by sabertooth02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Mar 2015 11:33:53 -0800 X-IronPort-AV: E=Sophos;i="5.11,359,1422950400"; d="scan'208";a="856185449" Received: from nasanexm02f.na.qualcomm.com ([10.85.0.87]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 07 Mar 2015 11:33:53 -0800 Received: from [99.111.97.136] (10.80.80.8) by nasanexm02f.na.qualcomm.com (10.85.0.87) with Microsoft SMTP Server (TLS) id 15.0.995.29; Sat, 7 Mar 2015 11:33:52 -0800 Message-ID: In-Reply-To: References: <54F78072.5060206@alum.mit.edu> <54F7A836.6000307@nteczone.com> <54F7F951.5020109@omnitor.se> <54F8E7E2.3090703@nteczone.com> X-Mailer: Eudora for Mac OS X Date: Sat, 7 Mar 2015 11:33:51 -0800 To: 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-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01F.na.qualcomm.com (10.85.0.32) To nasanexm02f.na.qualcomm.com (10.85.0.87) Archived-At: Cc: Christian Groves Subject: [Slim] Revised proposed SLIM charter X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2015 19:33:57 -0000 Hi SLIM people, Following Christian's suggestions and my reply, here is a revised proposed charter that adds the two fairly minor tweaks to strengthen the defense against scope creep. I also pushed out the deadline for the real-time draft by a few months. -------------------------- SLIM: Selection of Language for Internet Media Description of Working Group: A mutually comprehensible language is helpful for human communication. This is true across a range of circumstances and environments. In general, the problem is most acute in situations where there is not a clear choice for a single language, such as environments lacking contextual or out-of-band information regarding the identity of the parties and the language to be used. The group will address two specific cases that most urgently need a technical solution: One problem space is non-real-time communication, specifically email for one-to-many or where the set of recipients is dynamic or different recipients require different languages; the other is real-time communication, specifically emergency calling, preferably also useful for other cases where the parties may not know each other personally or where one party wishes to accommodate people with varying language and media needs. In the real-time communication case, language and media are intrinsically linked, for example, signed languages require a video media. While the two use cases are in different contexts (real time and non-real-time), the fundamental goal is the same: to enable selection of the best-fit language(s) for a specific situation. Some of the details will also be in common across the cases. Having a single WG address both cases makes it clear that these are two aspects of the same basic problem. A single WG also makes it easier to maximize similarities and avoid unnecessary fragmentation of the solutions. The group will produce two documents, one for email, and one for real-time communications. In the email case, the group will produce a MIME content type specification that enables a single email message to contain multiple language versions of the content, with provisions to help clients select a best fit version. In the real-time communication case, the group will produce a specification enabling negotiation of a human language per media stream. The specification must be suitable for use in emergency communications as specified in RFC 6443 and RFC 6881 (which use SIP and SDP to negotiate media); it is desirable to also be suitable for use in non-emergency real-time communications that share the same call set-up and media negotiation protocols. The mechanism will permit the caller's media and language needs and preferences to be matched against what the called party is able to provide. The mechanism will permit resources (e.g., translation, relay, media) to be allocated or engaged as early as possible in the call set-up or for the call to be routed or handled specially (e.g., routed to a resource able to provide a needed language and/or media). By adding language to the existing media negotiation mechanism as used in RFC 6443 and RFC 6881, the group can meet the basic use cases with minimal added complexity and be able to enhance later for additional use cases as needed. Goals and Milestones: July 2015 -- Submit "Multiple Language Content Type" to the IESG for consideration as a Standards Track RFC November 2015 -- Submit "Negotiating Human Language in Real-Time Communications" to the IESG for consideration as a Standards Track RFC -------------------------- -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- The only normal people are the ones you don't know very well. --Joe Ancis From nobody Sat Mar 7 13:25:27 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C5281A0430 for ; Sat, 7 Mar 2015 13:25:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.201 X-Spam-Level: X-Spam-Status: No, score=-0.201 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 9UasspMknBce for ; Sat, 7 Mar 2015 13:25:24 -0800 (PST) Received: from bin-vsp-out-04.atm.binero.net (vsp-unauthed01.binero.net [195.74.38.225]) (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 6AEE41A03A9 for ; Sat, 7 Mar 2015 13:25:23 -0800 (PST) X-Halon-ID: 744f4d76-c510-11e4-ace6-005056917c0c Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.42] (unknown [77.53.231.174]) by bin-vsp-out-04.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Sat, 7 Mar 2015 22:25:18 +0100 (CET) Message-ID: <54FB6CBD.3040704@omnitor.se> Date: Sat, 07 Mar 2015 22:25:17 +0100 From: =?windows-1252?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: slim@ietf.org References: <54F78072.5060206@alum.mit.edu> <54F7A836.6000307@nteczone.com> <54F7F951.5020109@omnitor.se> <54F8E7E2.3090703@nteczone.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Slim] Revised proposed SLIM charter X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2015 21:25:25 -0000 I think it is time to settle this charter and move on with the work. I am a bit nervous about the weakening words "it is desirable to also be suitable for use in non-emergency ..." but I have agreed to them. It is very risky if we end up in specifications of features that are only used in emergency calls, especially when the users are supposed to enter some data to prepare for the emergency case to work properly. There is an apparent risk that no or outdated settings will be there the day they need to be right, and that the user terminal does not perform as expected in the negotiation because it is never tested. It is urgent that the mechanism is used and of value in everyday calling, so that it is well tested the day it is used for an emergency. That is possible but not guaranteed with the current writing of the charter. I hope we do not end up in argumentation about border cases. I do not want to prolong the procedure of settling the charter by more tweakening. /Gunnar Randall Gellens skrev den 2015-03-07 20:33: > Hi SLIM people, > > Following Christian's suggestions and my reply, here is a revised > proposed charter that adds the two fairly minor tweaks to strengthen > the defense against scope creep. I also pushed out the deadline for > the real-time draft by a few months. > > -------------------------- > SLIM: Selection of Language for Internet Media > > Description of Working Group: > > A mutually comprehensible language is helpful for human > communication. This is true across a range of circumstances and > environments. In general, the problem is most acute in situations > where there is not a clear choice for a single language, such as > environments lacking contextual or out-of-band information regarding > the identity of the parties and the language to be used. > > The group will address two specific cases that most urgently need a > technical solution: One problem space is non-real-time communication, > specifically email for one-to-many or where the set of recipients is > dynamic or different recipients require different languages; the other > is real-time communication, specifically emergency calling, preferably > also useful for other cases where the parties may not know each other > personally or where one party wishes to accommodate people with > varying language and media needs. > > In the real-time communication case, language and media are > intrinsically linked, for example, signed languages require a video > media. > > While the two use cases are in different contexts (real time and > non-real-time), the fundamental goal is the same: to enable selection > of the best-fit language(s) for a specific situation. Some of the > details will also be in common across the cases. Having a single WG > address both cases makes it clear that these are two aspects of the > same basic problem. A single WG also makes it easier to maximize > similarities and avoid unnecessary fragmentation of the solutions. > > The group will produce two documents, one for email, and one for > real-time communications. > > In the email case, the group will produce a MIME content type > specification that enables a single email message to contain multiple > language versions of the content, with provisions to help clients > select a best fit version. > > In the real-time communication case, the group will produce a > specification enabling negotiation of a human language per media > stream. The specification must be suitable for use in emergency > communications as specified in RFC 6443 and RFC 6881 (which use SIP > and SDP to negotiate media); it is desirable to also be suitable for > use in non-emergency real-time communications that share the same call > set-up and media negotiation protocols. The mechanism will permit the > caller's media and language needs and preferences to be matched > against what the called party is able to provide. The mechanism will > permit resources (e.g., translation, relay, media) to be allocated or > engaged as early as possible in the call set-up or for the call to be > routed or handled specially (e.g., routed to a resource able to > provide a needed language and/or media). > > By adding language to the existing media negotiation mechanism as used > in RFC 6443 and RFC 6881, the group can meet the basic use cases with > minimal added complexity and be able to enhance later for additional > use cases as needed. > > Goals and Milestones: > > July 2015 -- Submit "Multiple Language Content Type" to the IESG for > consideration as a Standards Track RFC > November 2015 -- Submit "Negotiating Human Language in Real-Time > Communications" to the IESG for consideration as a Standards Track RFC > > -------------------------- > -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 From nobody Sat Mar 7 14:49:33 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01FAD1A1A07 for ; Sat, 7 Mar 2015 14:49:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.711 X-Spam-Level: X-Spam-Status: No, score=-6.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u6ckbdZ1-dQt for ; Sat, 7 Mar 2015 14:49:30 -0800 (PST) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C3C51A1A02 for ; Sat, 7 Mar 2015 14:49:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1425768570; x=1457304570; h=message-id:in-reply-to:references:date:to:from:subject: mime-version:content-transfer-encoding; bh=K4VlWwbsA0XoEU5HVABFQTu70yiJHHaBWv1axLTeO0E=; b=tBC0wr+K2xmtomvfHvUOE6Dwy6XUTLva+haR4i2COwS9LQlflF3E2BkF Eqwwq2Wm83L3y45SGbYJT2Td0yGU4kwUWttxAvgPjoyavOvTQMFmyOVUQ S44m5M85ilVffwBO3CRH03MwfWkurlDf/RMnjyL2KqFgWiCm0MLoIua+0 E=; X-IronPort-AV: E=McAfee;i="5600,1067,7733"; a="84449395" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by sabertooth01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Mar 2015 14:49:29 -0800 X-IronPort-AV: E=Sophos;i="5.11,359,1422950400"; d="scan'208";a="830814317" Received: from nasanexm02f.na.qualcomm.com ([10.85.0.87]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 07 Mar 2015 14:49:29 -0800 Received: from [99.111.97.136] (10.80.80.8) by nasanexm02f.na.qualcomm.com (10.85.0.87) with Microsoft SMTP Server (TLS) id 15.0.995.29; Sat, 7 Mar 2015 14:49:28 -0800 Message-ID: In-Reply-To: <54FB6CBD.3040704@omnitor.se> References: <54F78072.5060206@alum.mit.edu> <54F7A836.6000307@nteczone.com> <54F7F951.5020109@omnitor.se> <54F8E7E2.3090703@nteczone.com> <54FB6CBD.3040704@omnitor.se> X-Mailer: Eudora for Mac OS X Date: Sat, 7 Mar 2015 14:49:27 -0800 To: 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-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01E.na.qualcomm.com (10.85.0.31) To nasanexm02f.na.qualcomm.com (10.85.0.87) Archived-At: Subject: Re: [Slim] Revised proposed SLIM charter X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2015 22:49:33 -0000 Hi Gunnar, I agree that something only usable in emergency=20 calls is of little use because it won't be widely=20 implemented nor tested. No one has proposed such=20 a mechanism. I believe we should progress the=20 current draft, which I believe is simple enough=20 to be useful and useful enough to be used as a=20 matter of course. The charter wording is=20 intended to limit the initial work so that we=20 don't get too fancy and try to solve everything=20 at once. At 10:25 PM +0100 3/7/15, Gunnar Hellstr=F6m wrote: > I think it is time to settle this charter and=20 > move on with the work. I am a bit nervous about=20 > the weakening words "it is desirable to also be=20 > suitable for use in non-emergency ..." but I=20 > have agreed to them. > It is very risky if we end up in specifications=20 > of features that are only used in emergency=20 > calls, especially when the users are supposed=20 > to enter some data to prepare for the emergency=20 > case to work properly. There is an apparent=20 > risk that no or outdated settings will be there=20 > the day they need to be right, and that the=20 > user terminal does not perform as expected in=20 > the negotiation because it is never tested. > > It is urgent that the mechanism is used and of=20 > value in everyday calling, so that it is well=20 > tested the day it is used for an emergency. > > That is possible but not guaranteed with the=20 > current writing of the charter. I hope we do=20 > not end up in argumentation about border cases.=20 > I do not want to prolong the procedure of=20 > settling the charter by more tweakening. > > /Gunnar > > > > > > > Randall Gellens skrev den 2015-03-07 20:33: >> Hi SLIM people, >> >> Following Christian's suggestions and my=20 >> reply, here is a revised proposed charter that=20 >> adds the two fairly minor tweaks to strengthen=20 >> the defense against scope creep. I also=20 >> pushed out the deadline for the real-time=20 >> draft by a few months. >> >> -------------------------- >> SLIM: Selection of Language for Internet Media >> >> Description of Working Group: >> >> A mutually comprehensible language is helpful=20 >> for human communication. This is true across=20 >> a range of circumstances and environments. In=20 >> general, the problem is most acute in=20 >> situations where there is not a clear choice=20 >> for a single language, such as environments=20 >> lacking contextual or out-of-band information=20 >> regarding the identity of the parties and the=20 >> language to be used. >> >> The group will address two specific cases that=20 >> most urgently need a technical solution: One=20 >> problem space is non-real-time communication,=20 >> specifically email for one-to-many or where=20 >> the set of recipients is dynamic or different=20 >> recipients require different languages; the=20 >> other is real-time communication, specifically=20 >> emergency calling, preferably also useful for=20 >> other cases where the parties may not know=20 >> each other personally or where one party=20 >> wishes to accommodate people with varying=20 >> language and media needs. >> >> In the real-time communication case, language=20 >> and media are intrinsically linked, for=20 >> example, signed languages require a video=20 >> media. >> >> While the two use cases are in different=20 >> contexts (real time and non-real-time), the=20 >> fundamental goal is the same: to enable=20 >> selection of the best-fit language(s) for a=20 >> specific situation. Some of the details will=20 >> also be in common across the cases. Having a=20 >> single WG address both cases makes it clear=20 >> that these are two aspects of the same basic=20 >> problem. A single WG also makes it easier to=20 >> maximize similarities and avoid unnecessary=20 >> fragmentation of the solutions. >> >> The group will produce two documents, one for=20 >> email, and one for real-time communications. >> >> In the email case, the group will produce a=20 >> MIME content type specification that enables a=20 >> single email message to contain multiple=20 >> language versions of the content, with=20 >> provisions to help clients select a best fit=20 >> version. >> >> In the real-time communication case, the group=20 >> will produce a specification enabling=20 >> negotiation of a human language per media=20 >> stream. The specification must be suitable=20 >> for use in emergency communications as=20 >> specified in RFC 6443 and RFC 6881 (which use=20 >> SIP and SDP to negotiate media); it is=20 >> desirable to also be suitable for use in=20 >> non-emergency real-time communications that=20 >> share the same call set-up and media=20 >> negotiation protocols. The mechanism will=20 >> permit the caller's media and language needs=20 >> and preferences to be matched against what the=20 >> called party is able to provide. The=20 >> mechanism will permit resources (e.g.,=20 >> translation, relay, media) to be allocated or=20 >> engaged as early as possible in the call=20 >> set-up or for the call to be routed or handled=20 >> specially (e.g., routed to a resource able to=20 >> provide a needed language and/or media). >> >> By adding language to the existing media=20 >> negotiation mechanism as used in RFC 6443 and=20 >> RFC 6881, the group can meet the basic use=20 >> cases with minimal added complexity and be=20 >> able to enhance later for additional use cases=20 >> as needed. >> >> Goals and Milestones: >> >> July 2015 -- Submit "Multiple Language Content=20 >> Type" to the IESG for consideration as a=20 >> Standards Track RFC >> November 2015 -- Submit "Negotiating Human=20 >> Language in Real-Time Communications" to the=20 >> IESG for consideration as a Standards Track RFC >> >> -------------------------- >> > > -- > ----------------------------------------- > 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: --------------- Man is least himself when he talks in his own person. Give him a mask, and he will tell you the truth. --Oscar Wilde From nobody Sat Mar 7 14:51:07 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0941C1A1A0C for ; Sat, 7 Mar 2015 14:51:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.001 X-Spam-Level: X-Spam-Status: No, score=-1.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_31=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 n7SS4c6CZwtA for ; Sat, 7 Mar 2015 14:51:02 -0800 (PST) Received: from bin-vsp-out-01.atm.binero.net (vsp-unauthed01.binero.net [195.74.38.225]) (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 B805B1A1A04 for ; Sat, 7 Mar 2015 14:51:01 -0800 (PST) X-Halon-ID: 6b4fb4be-c51c-11e4-8273-005056917a89 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.42] (unknown [77.53.231.174]) by bin-vsp-out-01.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Sat, 7 Mar 2015 23:50:57 +0100 (CET) Message-ID: <54FB80CD.1010105@omnitor.se> Date: Sat, 07 Mar 2015 23:50:53 +0100 From: =?windows-1252?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: slim@ietf.org References: <54F78072.5060206@alum.mit.edu> <54F7A836.6000307@nteczone.com> <54F7F951.5020109@omnitor.se> <54F8CF6D.3010107@omnitor.se> <54F8D5BA.2050305@alum.mit.edu> <54F8DB06.5060905@omnitor.se> In-Reply-To: <54F8DB06.5060905@omnitor.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Slim] Use cases - Captioned telephony service need X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2015 22:51:06 -0000 Let us continue to add to the use cases: A person in Spain with hearing loss who prefers to get both rapid text and speech in the calls to combine to best perception declares strong preference for speaking Spanish, and strong preference for hearing Spanish and strong preference for reading Spanish text. She is calling another person in Spain with hearing loss and the same declaration of preferences: strong preference for speaking Spanish, and strong preference for hearing Spanish and strong preference for reading Spanish text. They have not indicated any capability for typing Spanish text. The evaluation needs to have the capabilities of both parties available for assessment. The result will be that the calling party gets a Captioned telephony service included in the call, that answers with adding the written Spanish text capability towards the caller, and let the called party's spoken Spanish capability indication pass on to the caller. On the route towards the called party, there is also a need to add rapid typed Spanish text, so another captioned telephony service is added to the call, adding Spanish Typed text capability to the indications, together with the spoken Spanish indication from the caller, so that the callee can be assured to be served well in the call. A problem for this case is how to indicate that both rapid typed Spanish text is needed and also spoken Spanish, so they are not alternatives. Another problem is what Paul brought up: The need to evaluate the combination of preferences from the caller and callee, before the callee is called. Gunnar Gunnar Hellström skrev den 2015-03-05 23:39: > Paul, > > Paul Kyzivat skrev den 2015-03-05 23:16: >> The use case below is a good start. >> >> Are use cases for non-emergency real time communications also in scope? > Yes. >> >> I'll also observe that there is major interaction between the way the >> language and media preferences are signaled and the architecture of >> the systems that ensure there is a match of capabilities. Some of >> today's relay services depend on being able to know the preferences >> of the callee before communications are established to the callee. >> They do this in order to queue the call until relay services are >> available before contacting the callee. That is in conflict to >> allowing the called device to signal its preferences without >> pre-arrangement. > Right. > This is a problem with SDP-based preferences. > We have discussed SIP Media tag based preferences. They can be > conveyed at Register time and stored in SIP servers, and then compared > for routing decisions with what the caller has. > That approach is described in the draft Appendix A. > I think the main problem with that approach was what we thought was a > lack of way to describe spoken versus written language ( that we have > learned a way around today ), and that the already specified ways for > decision maing with RFC 3840 - 3841 did not seem to fit totally. > > A way in a closed environment would be to require support for OPTIONS, > to get a preview of the SDP. And in this case you might be able to > require OPTIONS support if you want to have your calls properly > routed, and an assumption that if there is no resonse on OPTIONS, > then that user is supposed to be a speech user with the default > language of the area. > > > >> >> In the use case below, the emergency operator takes the call before >> the relay is included. This works out because there is *some* medium >> in common that can be used before relaying comes online. There would >> be a problem if the emergency operator only supported audio - the >> call would be established but there would initially be no useful >> media. That would be distressing for the caller. In emergency cases >> it is plausible to expect the emergency operators to have extra >> technology to help with these cases. But in non-emergency cases that >> isn't necessarily true. > Yes, I agree completely that answering a call and finding that you > have no common language is distressing. The 2 minute wait for > interpreter should of course also be avoided. But exsists in reality. >> >> My point is simply that the architecture(s) required to support these >> features should be considered as part of the work. (This may not lead >> to any normative requirements. It might only be examples or use cases.) > Yes. >> >> Thanks, >> Paul >> >> On 3/5/15 4:49 PM, Gunnar Hellström wrote: >>> In order to decide on what to support, I think we should now collect a >>> long list of use cases and then decide which ones to support and which >>> ones to not support. >>> >>> I can imagine two kinds of use cases: >>> 1. architectural cases outlining callers, callees and call >>> distribution >>> and routing functions and additional services. >>> 2. call cases: callers with language and media preferences called >>> parties with media and language capabilities and additional services >>> with language capabilities. >>> >>> So, here is a use case: >>> >>> Emergency call from an Australian Sign language user >>> >>> A deaf person in Australia has prepared her phone with the following >>> preferences: >>> Prefer to use Australian Sign Language for both signing and perceiving >>> sign in video. >>> Can with less but fair preference do International Sign in both >>> directions in video. >>> Can but do not prefer to use real-time text in English in the text >>> channel. >>> Has a terminal with audio function both ways but has no interest to use >>> that for language communication. >>> She has an emergency in Australia and calls the Australian emergency >>> number. >>> The emergency service has no own sign language capability, but has a >>> few >>> terminals and operators who handle video, audio and real-time text >>> (total conversation). They have an agreement to call for interpretation >>> between Australian Sign Laguage and Spoken English, but that service is >>> allowed to have up to two minutes answering time. >>> The call is analyzed for language and media contents and the ACD offers >>> it to the group of operators with total conversation terminals with an >>> indication that the two sign languages are preferred but that English >>> text is possible. >>> The analysis also causes an outgoing call in all media to the sign >>> language interpreting service because no operator in the emergency >>> service know sign language. >>> The emergency operator takes the call and establish all media, and see >>> from the declaration that it is possible to start asking about the >>> emergency by text. The deaf caller see all media being established but >>> also see that at the moment the only common language is typed English. >>> A minute later the sign laguage interpreter answers. The call is >>> modified to a three-party call, the capability indication changes so >>> that it is evident to the caller that Australian sign language can be >>> used now. >>> The call can continue in convenient sign with the calling user and >>> speech between the interpreter and the emergency operator. If anything >>> needs exact spelling or remembered, then the text channel is still >>> there >>> for occasional use. >>> >>> >>> Gunnar >>> >>> >>> >>> Randall Gellens skrev den 2015-03-05 21:10: >>>> Hi Gunnar, >>>> >>>> At 7:36 AM +0100 3/5/15, Gunnar Hellström wrote: >>>> >>>>> I also view the charter to be good and want to see the work started. >>>> >>>> Thank you. >>>> >>>>> >>>>> There are drafts to start with: >>>>> https://tools.ietf.org/html/draft-gellens-slim-negotiating-human-language-00 >>>>> >>>>> >>>>> https://tools.ietf.org/html/draft-tomkinson-slim-multilangcontent-00 >>>>> >>>>> Answering Christians question about what extensions might be needed, >>>>> I want to answer relative towhat is in the realtime draft now. >>>>> >>>>> I see some topics that may need discussion: >>>> >>>> The point of the group is to have discussion on what we need. One >>>> thing that has been beaten into me by painful experience over many >>>> years is that it's best to start with the simplest possible solution >>>> that meets enough of the use cases to be useful, and build on that >>>> after gaining experience. I've seen this approach work, whereas >>>> creating a more complex solution that tries to meet all or most >>>> anticipated use cases often fails due to being too difficult to >>>> implement. >>>> >>>>> >>>>> 1. Coding of unspecified language but specific mode. >>>>> I expect that in many cases it is merely the modality that is of >>>>> interest to negotiate, rather than the exact language. There is often >>>>> a default language in a specific area, and as long as you use that, >>>>> you will feel that it is a burden to specify that exactly, but rather >>>>> indicate in what medium you want the language exchange. You may want >>>>> to use text for language exchange and audio to convey the sound from >>>>> a location. >>>>> So, you would like to specify your preference for spoken, listened, >>>>> written, read, visualized and seen. And for signed and perceiving >>>>> sign languages. Regardless of exact language. >>>>> So, some codes to use in place of specific languages for these kinds >>>>> of general modalities could be needed. >>>> >>>> We can discuss this in the group. We already have the ability to >>>> negotiate media with no language expression, which might be sufficient >>>> for the basic use cases. Adding a new tag for the default language >>>> wouldn't be a huge burden, but I'd like to see discussion on why it's >>>> needed before proceeding. >>>> >>>>> >>>>> 2. Relative preference between media. >>>>> I think it can be important to have a coding for preference between >>>>> media, to express for example if I prefer to speak but can accept to >>>>> type. >>>>> We have an order of preference indication between languages in the >>>>> same medium in the draft, but not between media. >>>> >>>> This would be worth discussing in the group as well. My question >>>> would be if the incremental value of being able to specify this would >>>> result in any real-world benefit, that is, would it change the result >>>> of the negotiation over what we have now? >>>> >>>>> >>>>> 3. Absolute versus relative preference between languages. >>>>> We have a relative order of preference indication between languages >>>>> in the same medium in the draft. >>>>> I can see cases when it is instead an absolute preference that would >>>>> be of importance. >>>>> E.g. I am equally happy to get spoken German or spoken French in >>>>> this call, but may as the last resort do with spoken English. >>>>> Or, same thing between media: >>>>> One case can be: I strongly prefer to use spoken French, but can as >>>>> the last resort accept to use written French. >>>>> Another can be: I must receive both spoken French and French text. >>>> >>>> I would expect that the called party would have a set of language and >>>> media capabilities (either in-house or by bridging in translation, >>>> relay, or interpreter services) and would want to support the caller's >>>> needs. I doubt that getting fancy with preferences would change the >>>> result very much. >>>> >>>>> >>>>> 4. Same media conveyed under different media types >>>>> The current draft specifies SDP as the base for the language >>>>> declarations. How do we resolve the cases when the same language >>>>> modality can be conveyed under different media types? >>>>> Text is conveyed in real time under the media type text. But it is >>>>> possible to have some near real-time exchange of text under media >>>>> type message (MSRP). How do we express that these might be >>>>> alternatives for carrying the same written language? >>>>> That question also surfaces the problem that in the language >>>>> register there are no good way to express if it is a spoken use of >>>>> the language or a written use of the language we want to specify. >>>>> There are separate language tags for sign languages but not for >>>>> spoken varsus written. (there are some sub-tags for scripts, but they >>>>> should only be used when it is important to select between script >>>>> variants )(There is even an SDP-less way to carry text, in the SIP >>>>> MESSAGE method. There will be no way to express that as an >>>>> alternative way to convey language when we base the method on SDP.) >>>> >>>> I'm happy to look at non-SDP and/or non-SIP mechanisms once we have >>>> the SDP-and-SIP one done. Since emergency calling is based on SDP and >>>> SIP, I think we need to start there. >>>> >>>>> >>>>> 3. Slow start of SIP. >>>>> We can in SIP have INVITE without SDP offer, and let the responding >>>>> party send the offer with SDP. >>>>> With the negotiation mechanism based on SDP, does this slow start >>>>> cause any restrictions for us regarding the possiblilities to express >>>>> and negotiate language? >>>> >>>> I think we need to focus initially on what's needed for emergency >>>> calling and similar use cases. We can expand after we get something >>>> done. >>>> >>>>> >>>>> I do not want to cause eternal discussions about border cases, and I >>>>> do not want to extend the method into unmanageable complexity. I just >>>>> want us to take good decisions on the mechanism so that it covers the >>>>> cases we want it to cover with a method that is not too complex. >>>> >>>> Thank you, that's good to hear. >>>> >>>>> >>>>> Christian, maybe in your question was also how the intended work >>>>> differs from language negotiation methods already available in RFC:s? >>>>> The current draft, section 6 has a discussion about that. One >>>>> difference is that there is today no way to indicate order of >>>>> preference between languages. Another is the one I described above; >>>>> the Language tag as such does not indicate the difference between >>>>> spoken and written. >>>>> >>>>> /Gunnar >>>>> >>>>> >>>>> Christian Groves skrev den 2015-03-05 01:49: >>>>>> Hello Randall, >>>>>> >>>>>> I agree with Paul that it does seem optimistic. >>>>>> >>>>>> In the question text its mentions the caller's "media needs". I'm >>>>>> pretty sure I under the scope of "language needs" but "media needs" >>>>>> could be a little open ended. What sort of enhancements do you see >>>>>> to the existing negotiation methods? >>>>>> >>>>>> Regards, Christian >>>>>> >>>>>> On 5/03/2015 9:00 AM, Paul Kyzivat wrote: >>>>>>> I support this. >>>>>>> >>>>>>> But I find the schedule vastly overoptimistic, especially for >>>>>>> real-time. Add a year or two. >>>>>>> >>>>>>> Thanks, >>>>>>> Paul >>>>>>> >>>>>>> On 3/3/15 6:33 PM, Randall Gellens wrote: >>>>>>>> Hi SLIM people, >>>>>>>> >>>>>>>> Here is a revised proposed charter. The intent is to focus on >>>>>>>> the two >>>>>>>> current drafts and get those completed. >>>>>>>> >>>>>>>> ---------- >>>>>>>> >>>>>>>> SLIM: Selection of Language for Internet Media >>>>>>>> >>>>>>>> Description of Working Group: >>>>>>>> >>>>>>>> A mutually comprehensible language is helpful for human >>>>>>>> communication. >>>>>>>> This is true across a range of circumstances and environments. In >>>>>>>> general, the problem is most acute in situations where there is >>>>>>>> not a >>>>>>>> clear choice for a single language, such as environments lacking >>>>>>>> contextual or out-of-band information regarding the identity >>>>>>>> of the >>>>>>>> parties and the language to be used. >>>>>>>> >>>>>>>> The group will address two specific cases that most urgently >>>>>>>> need a >>>>>>>> technical solution: One problem space is non-real-time >>>>>>>> communication, >>>>>>>> specifically email for one-to-many or where the set of >>>>>>>> recipients is >>>>>>>> dynamic or different recipients require different languages; the >>>>>>>> other >>>>>>>> is real-time communication, specifically emergency calling, >>>>>>>> preferably >>>>>>>> also useful for other cases where the parties may not know each >>>>>>>> other >>>>>>>> personally or where one party wishes to accommodate people with >>>>>>>> varying >>>>>>>> language and media needs. >>>>>>>> >>>>>>>> In the real-time communication case, language and media are >>>>>>>> intrinsically linked, for example, signed languages require a >>>>>>>> video media. >>>>>>>> >>>>>>>> While the two use cases are in different contexts (real time and >>>>>>>> non-real-time), the fundamental goal is the same: to enable >>>>>>>> selection of >>>>>>>> the best-fit language(s) for a specific situation. Some of the >>>>>>>> details >>>>>>>> will also be in common across the cases. Having a single WG >>>>>>>> address >>>>>>>> both cases makes it clear that these are two aspects of the same >>>>>>>> basic >>>>>>>> problem. A single WG also makes it easier to maximize >>>>>>>> similarities and >>>>>>>> avoid unnecessary fragmentation of the solutions. >>>>>>>> >>>>>>>> The group will produce two documents, one for email, and one for >>>>>>>> real-time communications. >>>>>>>> >>>>>>>> In the email case, the group will produce a MIME content type >>>>>>>> specification that enables a single email message to contain >>>>>>>> multiple >>>>>>>> language versions of the content, with provisions to help clients >>>>>>>> select >>>>>>>> a best fit version. >>>>>>>> >>>>>>>> In the real-time communication case, the group will produce a >>>>>>>> specification enabling negotiation of a human language per media >>>>>>>> stream. The specification must be suitable for use in emergency >>>>>>>> communications as specified in RFC 6443 and RFC 6881; it is >>>>>>>> desirable to >>>>>>>> also be suitable for use in non-emergency real-time >>>>>>>> communications that >>>>>>>> share the same call set-up and media negotiation protocols. The >>>>>>>> mechanism will permit the caller's media and language needs and >>>>>>>> preferences to be matched against what the called party is >>>>>>>> able to >>>>>>>> provide. The mechanism will permit resources (e.g., translation, >>>>>>>> relay, >>>>>>>> media) to be allocated or engaged as early as possible in the >>>>>>>> call >>>>>>>> set-up or for the call to be routed or handled specially (e.g., >>>>>>>> routed >>>>>>>> to a resource able to provide a needed language and/or media). >>>>>>>> >>>>>>>> Goals and Milestones: >>>>>>>> >>>>>>>> June 2015 -- Submit "Multiple Language Content Type" to the >>>>>>>> IESG for >>>>>>>> consideration as a Standards Track RFC >>>>>>>> June 2015 -- Submit "Negotiating Human Language in Real-Time >>>>>>>> Communications" to the IESG for consideration as a Standards >>>>>>>> Track RFC >>>>>>>> >>>>>>>> ---------- >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>> >>>> >>>> >>> >> >> _______________________________________________ >> 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 Sat Mar 7 16:31:34 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D907A1A1A2C for ; Sat, 7 Mar 2015 16:31:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.635 X-Spam-Level: X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_31=0.6, SPF_SOFTFAIL=0.665] autolearn=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 OpQgbL9DRvmo for ; Sat, 7 Mar 2015 16:31:29 -0800 (PST) Received: from resqmta-po-07v.sys.comcast.net (resqmta-po-07v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:166]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D2851A0395 for ; Sat, 7 Mar 2015 16:31:29 -0800 (PST) Received: from resomta-po-02v.sys.comcast.net ([96.114.154.226]) by resqmta-po-07v.sys.comcast.net with comcast id 0oWf1q0014tLnxL01oXUTk; Sun, 08 Mar 2015 00:31:28 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-02v.sys.comcast.net with comcast id 0oXT1q00G3Ge9ey01oXUlx; Sun, 08 Mar 2015 00:31:28 +0000 Message-ID: <54FB985F.5040708@alum.mit.edu> Date: Sat, 07 Mar 2015 19:31:27 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: slim@ietf.org References: <54F78072.5060206@alum.mit.edu> <54F7A836.6000307@nteczone.com> <54F7F951.5020109@omnitor.se> <54F8CF6D.3010107@omnitor.se> <54F8D5BA.2050305@alum.mit.edu> <54F8DB06.5060905@omnitor.se> <54FB80CD.1010105@omnitor.se> In-Reply-To: <54FB80CD.1010105@omnitor.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1425774688; bh=Mkte2xL8lKY11opaug5m6CjPgkvLdXdiYpuvdA0RSos=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=VhV5kM0Pn20S+4iY4RXNIO8w+fBmUqW4LSjqsmuFAXQ6RaHLx3rWkLZKsdtXkPxB9 vg2NEnlCSLG8fWCh7GsMtLXmclfmDorGLVBQTIWCcD6BZ32HoSBIv87Mz/mi08lSVA Yg+CjwgRsUKlBP2OBqjj7Xb6Wkn8mHDuLW4fy4Dres2Z3WIf/m7MZH6+6cU6cPTBOB ctCZQ8J5tXEQ/D+kVNTgFDk5JR8Nn7TiOkNaJfmLMis7m5TjQd1ssRBQUUOqSmt7sF eTJVus8BuLLl+Xe6AXkiBgtoQMap7MHNIcIn5OtZ0y9NtmUDtzglNqfvSOyFwe0Q6A pbxlrFSp+n06A== Archived-At: Subject: Re: [Slim] Use cases - Captioned telephony service need X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2015 00:31:33 -0000 So far all the use cases mentioned have to do with people having hearing loss. While those are fine cases, they don't have to be the only cases. ISTM that this mechanism ought to be useful for simple natural language cases - e.g. where the caller speaks only Spanish or Vietnamese. This would be very valuable for emergency calls, but would also be useful for more everyday case - for calls to call centers that currently start with "press 1 for Spanish", etc. Thanks, Paul On 3/7/15 5:50 PM, Gunnar Hellström wrote: > Let us continue to add to the use cases: > > A person in Spain with hearing loss who prefers to get both rapid text > and speech in the calls to combine to best perception declares strong > preference for speaking Spanish, and strong preference for hearing > Spanish and strong preference for reading Spanish text. > She is calling another person in Spain with hearing loss and the same > declaration of preferences: strong preference for speaking Spanish, and > strong preference for hearing Spanish and strong preference for reading > Spanish text. > They have not indicated any capability for typing Spanish text. > > The evaluation needs to have the capabilities of both parties available > for assessment. The result will be that the calling party gets a > Captioned telephony service included in the call, that answers with > adding the written Spanish text capability towards the caller, and let > the called party's spoken Spanish capability indication pass on to the > caller. > On the route towards the called party, there is also a need to add rapid > typed Spanish text, so another captioned telephony service is added to > the call, adding Spanish Typed text capability to the indications, > together with the spoken Spanish indication from the caller, so that the > callee can be assured to be served well in the call. > > A problem for this case is how to indicate that both rapid typed Spanish > text is needed and also spoken Spanish, so they are not alternatives. > Another problem is what Paul brought up: The need to evaluate the > combination of preferences from the caller and callee, before the callee > is called. > > > Gunnar > > Gunnar Hellström skrev den 2015-03-05 23:39: >> Paul, >> >> Paul Kyzivat skrev den 2015-03-05 23:16: >>> The use case below is a good start. >>> >>> Are use cases for non-emergency real time communications also in scope? >> Yes. >>> >>> I'll also observe that there is major interaction between the way the >>> language and media preferences are signaled and the architecture of >>> the systems that ensure there is a match of capabilities. Some of >>> today's relay services depend on being able to know the preferences >>> of the callee before communications are established to the callee. >>> They do this in order to queue the call until relay services are >>> available before contacting the callee. That is in conflict to >>> allowing the called device to signal its preferences without >>> pre-arrangement. >> Right. >> This is a problem with SDP-based preferences. >> We have discussed SIP Media tag based preferences. They can be >> conveyed at Register time and stored in SIP servers, and then compared >> for routing decisions with what the caller has. >> That approach is described in the draft Appendix A. >> I think the main problem with that approach was what we thought was a >> lack of way to describe spoken versus written language ( that we have >> learned a way around today ), and that the already specified ways for >> decision maing with RFC 3840 - 3841 did not seem to fit totally. >> >> A way in a closed environment would be to require support for OPTIONS, >> to get a preview of the SDP. And in this case you might be able to >> require OPTIONS support if you want to have your calls properly >> routed, and an assumption that if there is no resonse on OPTIONS, >> then that user is supposed to be a speech user with the default >> language of the area. >> >> >> >>> >>> In the use case below, the emergency operator takes the call before >>> the relay is included. This works out because there is *some* medium >>> in common that can be used before relaying comes online. There would >>> be a problem if the emergency operator only supported audio - the >>> call would be established but there would initially be no useful >>> media. That would be distressing for the caller. In emergency cases >>> it is plausible to expect the emergency operators to have extra >>> technology to help with these cases. But in non-emergency cases that >>> isn't necessarily true. >> Yes, I agree completely that answering a call and finding that you >> have no common language is distressing. The 2 minute wait for >> interpreter should of course also be avoided. But exsists in reality. >>> >>> My point is simply that the architecture(s) required to support these >>> features should be considered as part of the work. (This may not lead >>> to any normative requirements. It might only be examples or use cases.) >> Yes. >>> >>> Thanks, >>> Paul >>> >>> On 3/5/15 4:49 PM, Gunnar Hellström wrote: >>>> In order to decide on what to support, I think we should now collect a >>>> long list of use cases and then decide which ones to support and which >>>> ones to not support. >>>> >>>> I can imagine two kinds of use cases: >>>> 1. architectural cases outlining callers, callees and call >>>> distribution >>>> and routing functions and additional services. >>>> 2. call cases: callers with language and media preferences called >>>> parties with media and language capabilities and additional services >>>> with language capabilities. >>>> >>>> So, here is a use case: >>>> >>>> Emergency call from an Australian Sign language user >>>> >>>> A deaf person in Australia has prepared her phone with the following >>>> preferences: >>>> Prefer to use Australian Sign Language for both signing and perceiving >>>> sign in video. >>>> Can with less but fair preference do International Sign in both >>>> directions in video. >>>> Can but do not prefer to use real-time text in English in the text >>>> channel. >>>> Has a terminal with audio function both ways but has no interest to use >>>> that for language communication. >>>> She has an emergency in Australia and calls the Australian emergency >>>> number. >>>> The emergency service has no own sign language capability, but has a >>>> few >>>> terminals and operators who handle video, audio and real-time text >>>> (total conversation). They have an agreement to call for interpretation >>>> between Australian Sign Laguage and Spoken English, but that service is >>>> allowed to have up to two minutes answering time. >>>> The call is analyzed for language and media contents and the ACD offers >>>> it to the group of operators with total conversation terminals with an >>>> indication that the two sign languages are preferred but that English >>>> text is possible. >>>> The analysis also causes an outgoing call in all media to the sign >>>> language interpreting service because no operator in the emergency >>>> service know sign language. >>>> The emergency operator takes the call and establish all media, and see >>>> from the declaration that it is possible to start asking about the >>>> emergency by text. The deaf caller see all media being established but >>>> also see that at the moment the only common language is typed English. >>>> A minute later the sign laguage interpreter answers. The call is >>>> modified to a three-party call, the capability indication changes so >>>> that it is evident to the caller that Australian sign language can be >>>> used now. >>>> The call can continue in convenient sign with the calling user and >>>> speech between the interpreter and the emergency operator. If anything >>>> needs exact spelling or remembered, then the text channel is still >>>> there >>>> for occasional use. >>>> >>>> >>>> Gunnar >>>> >>>> >>>> >>>> Randall Gellens skrev den 2015-03-05 21:10: >>>>> Hi Gunnar, >>>>> >>>>> At 7:36 AM +0100 3/5/15, Gunnar Hellström wrote: >>>>> >>>>>> I also view the charter to be good and want to see the work started. >>>>> >>>>> Thank you. >>>>> >>>>>> >>>>>> There are drafts to start with: >>>>>> https://tools.ietf.org/html/draft-gellens-slim-negotiating-human-language-00 >>>>>> >>>>>> >>>>>> https://tools.ietf.org/html/draft-tomkinson-slim-multilangcontent-00 >>>>>> >>>>>> Answering Christians question about what extensions might be needed, >>>>>> I want to answer relative towhat is in the realtime draft now. >>>>>> >>>>>> I see some topics that may need discussion: >>>>> >>>>> The point of the group is to have discussion on what we need. One >>>>> thing that has been beaten into me by painful experience over many >>>>> years is that it's best to start with the simplest possible solution >>>>> that meets enough of the use cases to be useful, and build on that >>>>> after gaining experience. I've seen this approach work, whereas >>>>> creating a more complex solution that tries to meet all or most >>>>> anticipated use cases often fails due to being too difficult to >>>>> implement. >>>>> >>>>>> >>>>>> 1. Coding of unspecified language but specific mode. >>>>>> I expect that in many cases it is merely the modality that is of >>>>>> interest to negotiate, rather than the exact language. There is often >>>>>> a default language in a specific area, and as long as you use that, >>>>>> you will feel that it is a burden to specify that exactly, but rather >>>>>> indicate in what medium you want the language exchange. You may want >>>>>> to use text for language exchange and audio to convey the sound from >>>>>> a location. >>>>>> So, you would like to specify your preference for spoken, listened, >>>>>> written, read, visualized and seen. And for signed and perceiving >>>>>> sign languages. Regardless of exact language. >>>>>> So, some codes to use in place of specific languages for these kinds >>>>>> of general modalities could be needed. >>>>> >>>>> We can discuss this in the group. We already have the ability to >>>>> negotiate media with no language expression, which might be sufficient >>>>> for the basic use cases. Adding a new tag for the default language >>>>> wouldn't be a huge burden, but I'd like to see discussion on why it's >>>>> needed before proceeding. >>>>> >>>>>> >>>>>> 2. Relative preference between media. >>>>>> I think it can be important to have a coding for preference between >>>>>> media, to express for example if I prefer to speak but can accept to >>>>>> type. >>>>>> We have an order of preference indication between languages in the >>>>>> same medium in the draft, but not between media. >>>>> >>>>> This would be worth discussing in the group as well. My question >>>>> would be if the incremental value of being able to specify this would >>>>> result in any real-world benefit, that is, would it change the result >>>>> of the negotiation over what we have now? >>>>> >>>>>> >>>>>> 3. Absolute versus relative preference between languages. >>>>>> We have a relative order of preference indication between languages >>>>>> in the same medium in the draft. >>>>>> I can see cases when it is instead an absolute preference that would >>>>>> be of importance. >>>>>> E.g. I am equally happy to get spoken German or spoken French in >>>>>> this call, but may as the last resort do with spoken English. >>>>>> Or, same thing between media: >>>>>> One case can be: I strongly prefer to use spoken French, but can as >>>>>> the last resort accept to use written French. >>>>>> Another can be: I must receive both spoken French and French text. >>>>> >>>>> I would expect that the called party would have a set of language and >>>>> media capabilities (either in-house or by bridging in translation, >>>>> relay, or interpreter services) and would want to support the caller's >>>>> needs. I doubt that getting fancy with preferences would change the >>>>> result very much. >>>>> >>>>>> >>>>>> 4. Same media conveyed under different media types >>>>>> The current draft specifies SDP as the base for the language >>>>>> declarations. How do we resolve the cases when the same language >>>>>> modality can be conveyed under different media types? >>>>>> Text is conveyed in real time under the media type text. But it is >>>>>> possible to have some near real-time exchange of text under media >>>>>> type message (MSRP). How do we express that these might be >>>>>> alternatives for carrying the same written language? >>>>>> That question also surfaces the problem that in the language >>>>>> register there are no good way to express if it is a spoken use of >>>>>> the language or a written use of the language we want to specify. >>>>>> There are separate language tags for sign languages but not for >>>>>> spoken varsus written. (there are some sub-tags for scripts, but they >>>>>> should only be used when it is important to select between script >>>>>> variants )(There is even an SDP-less way to carry text, in the SIP >>>>>> MESSAGE method. There will be no way to express that as an >>>>>> alternative way to convey language when we base the method on SDP.) >>>>> >>>>> I'm happy to look at non-SDP and/or non-SIP mechanisms once we have >>>>> the SDP-and-SIP one done. Since emergency calling is based on SDP and >>>>> SIP, I think we need to start there. >>>>> >>>>>> >>>>>> 3. Slow start of SIP. >>>>>> We can in SIP have INVITE without SDP offer, and let the responding >>>>>> party send the offer with SDP. >>>>>> With the negotiation mechanism based on SDP, does this slow start >>>>>> cause any restrictions for us regarding the possiblilities to express >>>>>> and negotiate language? >>>>> >>>>> I think we need to focus initially on what's needed for emergency >>>>> calling and similar use cases. We can expand after we get something >>>>> done. >>>>> >>>>>> >>>>>> I do not want to cause eternal discussions about border cases, and I >>>>>> do not want to extend the method into unmanageable complexity. I just >>>>>> want us to take good decisions on the mechanism so that it covers the >>>>>> cases we want it to cover with a method that is not too complex. >>>>> >>>>> Thank you, that's good to hear. >>>>> >>>>>> >>>>>> Christian, maybe in your question was also how the intended work >>>>>> differs from language negotiation methods already available in RFC:s? >>>>>> The current draft, section 6 has a discussion about that. One >>>>>> difference is that there is today no way to indicate order of >>>>>> preference between languages. Another is the one I described above; >>>>>> the Language tag as such does not indicate the difference between >>>>>> spoken and written. >>>>>> >>>>>> /Gunnar >>>>>> >>>>>> >>>>>> Christian Groves skrev den 2015-03-05 01:49: >>>>>>> Hello Randall, >>>>>>> >>>>>>> I agree with Paul that it does seem optimistic. >>>>>>> >>>>>>> In the question text its mentions the caller's "media needs". I'm >>>>>>> pretty sure I under the scope of "language needs" but "media needs" >>>>>>> could be a little open ended. What sort of enhancements do you see >>>>>>> to the existing negotiation methods? >>>>>>> >>>>>>> Regards, Christian >>>>>>> >>>>>>> On 5/03/2015 9:00 AM, Paul Kyzivat wrote: >>>>>>>> I support this. >>>>>>>> >>>>>>>> But I find the schedule vastly overoptimistic, especially for >>>>>>>> real-time. Add a year or two. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Paul >>>>>>>> >>>>>>>> On 3/3/15 6:33 PM, Randall Gellens wrote: >>>>>>>>> Hi SLIM people, >>>>>>>>> >>>>>>>>> Here is a revised proposed charter. The intent is to focus on >>>>>>>>> the two >>>>>>>>> current drafts and get those completed. >>>>>>>>> >>>>>>>>> ---------- >>>>>>>>> >>>>>>>>> SLIM: Selection of Language for Internet Media >>>>>>>>> >>>>>>>>> Description of Working Group: >>>>>>>>> >>>>>>>>> A mutually comprehensible language is helpful for human >>>>>>>>> communication. >>>>>>>>> This is true across a range of circumstances and environments. In >>>>>>>>> general, the problem is most acute in situations where there is >>>>>>>>> not a >>>>>>>>> clear choice for a single language, such as environments lacking >>>>>>>>> contextual or out-of-band information regarding the identity >>>>>>>>> of the >>>>>>>>> parties and the language to be used. >>>>>>>>> >>>>>>>>> The group will address two specific cases that most urgently >>>>>>>>> need a >>>>>>>>> technical solution: One problem space is non-real-time >>>>>>>>> communication, >>>>>>>>> specifically email for one-to-many or where the set of >>>>>>>>> recipients is >>>>>>>>> dynamic or different recipients require different languages; the >>>>>>>>> other >>>>>>>>> is real-time communication, specifically emergency calling, >>>>>>>>> preferably >>>>>>>>> also useful for other cases where the parties may not know each >>>>>>>>> other >>>>>>>>> personally or where one party wishes to accommodate people with >>>>>>>>> varying >>>>>>>>> language and media needs. >>>>>>>>> >>>>>>>>> In the real-time communication case, language and media are >>>>>>>>> intrinsically linked, for example, signed languages require a >>>>>>>>> video media. >>>>>>>>> >>>>>>>>> While the two use cases are in different contexts (real time and >>>>>>>>> non-real-time), the fundamental goal is the same: to enable >>>>>>>>> selection of >>>>>>>>> the best-fit language(s) for a specific situation. Some of the >>>>>>>>> details >>>>>>>>> will also be in common across the cases. Having a single WG >>>>>>>>> address >>>>>>>>> both cases makes it clear that these are two aspects of the same >>>>>>>>> basic >>>>>>>>> problem. A single WG also makes it easier to maximize >>>>>>>>> similarities and >>>>>>>>> avoid unnecessary fragmentation of the solutions. >>>>>>>>> >>>>>>>>> The group will produce two documents, one for email, and one for >>>>>>>>> real-time communications. >>>>>>>>> >>>>>>>>> In the email case, the group will produce a MIME content type >>>>>>>>> specification that enables a single email message to contain >>>>>>>>> multiple >>>>>>>>> language versions of the content, with provisions to help clients >>>>>>>>> select >>>>>>>>> a best fit version. >>>>>>>>> >>>>>>>>> In the real-time communication case, the group will produce a >>>>>>>>> specification enabling negotiation of a human language per media >>>>>>>>> stream. The specification must be suitable for use in emergency >>>>>>>>> communications as specified in RFC 6443 and RFC 6881; it is >>>>>>>>> desirable to >>>>>>>>> also be suitable for use in non-emergency real-time >>>>>>>>> communications that >>>>>>>>> share the same call set-up and media negotiation protocols. The >>>>>>>>> mechanism will permit the caller's media and language needs and >>>>>>>>> preferences to be matched against what the called party is >>>>>>>>> able to >>>>>>>>> provide. The mechanism will permit resources (e.g., translation, >>>>>>>>> relay, >>>>>>>>> media) to be allocated or engaged as early as possible in the >>>>>>>>> call >>>>>>>>> set-up or for the call to be routed or handled specially (e.g., >>>>>>>>> routed >>>>>>>>> to a resource able to provide a needed language and/or media). >>>>>>>>> >>>>>>>>> Goals and Milestones: >>>>>>>>> >>>>>>>>> June 2015 -- Submit "Multiple Language Content Type" to the >>>>>>>>> IESG for >>>>>>>>> consideration as a Standards Track RFC >>>>>>>>> June 2015 -- Submit "Negotiating Human Language in Real-Time >>>>>>>>> Communications" to the IESG for consideration as a Standards >>>>>>>>> Track RFC >>>>>>>>> >>>>>>>>> ---------- >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>> >>>>> >>>>> >>>> >>> >>> _______________________________________________ >>> SLIM mailing list >>> SLIM@ietf.org >>> https://www.ietf.org/mailman/listinfo/slim >> > From nobody Sat Mar 7 23:07:59 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 096021A1BC2 for ; Sat, 7 Mar 2015 23:07:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.898 X-Spam-Level: X-Spam-Status: No, score=0.898 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, J_CHICKENPOX_31=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 GBVInN8CPBv8 for ; Sat, 7 Mar 2015 23:07:54 -0800 (PST) Received: from bin-vsp-out-03.atm.binero.net (vsp-unauthed01.binero.net [195.74.38.225]) (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 5B45C1A1BBE for ; Sat, 7 Mar 2015 23:07:53 -0800 (PST) X-Halon-ID: d205786a-c561-11e4-9957-0050569116f7 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.42] (unknown [77.53.231.174]) by bin-vsp-out-03.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Sun, 8 Mar 2015 08:07:45 +0100 (CET) Message-ID: <54FBF53F.8070902@omnitor.se> Date: Sun, 08 Mar 2015 08:07:43 +0100 From: =?windows-1252?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: slim@ietf.org References: <54F78072.5060206@alum.mit.edu> <54F7A836.6000307@nteczone.com> <54F7F951.5020109@omnitor.se> <54F8CF6D.3010107@omnitor.se> <54F8D5BA.2050305@alum.mit.edu> <54F8DB06.5060905@omnitor.se> <54FB80CD.1010105@omnitor.se> <54FB985F.5040708@alum.mit.edu> In-Reply-To: <54FB985F.5040708@alum.mit.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Slim] Use cases - Captioned telephony service need X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2015 07:07:58 -0000 Paul Kyzivat skrev den 2015-03-08 01:31: > So far all the use cases mentioned have to do with people having > hearing loss. While those are fine cases, they don't have to be the > only cases. > > ISTM that this mechanism ought to be useful for simple natural > language cases - e.g. where the caller speaks only Spanish or > Vietnamese. This would be very valuable for emergency calls, but would > also be useful for more everyday case - for calls to call centers that > currently start with "press 1 for Spanish", etc. > Right, we need realistic such cases also. One call center case is already included in the draft, in section 4.3 of https://tools.ietf.org/html/draft-gellens-slim-negotiating-human-language-00 A person in an international company, has set the phone for indicating only spoken Spanish in the audio path and is calling a colleague who only talks Vietnamese, having the phone set to only spoken Vietnamese in the audio path. The company has an interpreting service, but does not want that service to be engaged in waiting for calls that are not answered. Therefore the phones are set to compare the languages of incoming calls with its own language settings. In this case, the answering phone detects the discrepancy, and calls the interpreting service for a third leg with both spoken Spanish and spoken Vietnamese on high priority. The call center ACD looks at the language combination and finds the best match among the profiles of the logged in interpreters. The selected interpreter also gets the language combination displayed on the phone. The interpreter is connected and can start the interpretation in the expected languages. Before that moment, the Spanish caller has got a spoken message in the call, telling that the interpreting service is on its way to enter the call. Note that in this example, the answering phone makes the decision on languages, so that the mechanism shall be possible to implement without collection of user profiles. Another way to do this, would be to let the call be answered by the phone with the Vietnamese indication, and the SIP server connecting the call has extra functionality for detection of language mismatch in the established call, and doing the rearrangement of the established call into a three-party call with the interpreter service on the third leg. /Gunnar > Thanks, > Paul > > On 3/7/15 5:50 PM, Gunnar Hellström wrote: >> Let us continue to add to the use cases: >> >> A person in Spain with hearing loss who prefers to get both rapid text >> and speech in the calls to combine to best perception declares strong >> preference for speaking Spanish, and strong preference for hearing >> Spanish and strong preference for reading Spanish text. >> She is calling another person in Spain with hearing loss and the same >> declaration of preferences: strong preference for speaking Spanish, and >> strong preference for hearing Spanish and strong preference for reading >> Spanish text. >> They have not indicated any capability for typing Spanish text. >> >> The evaluation needs to have the capabilities of both parties available >> for assessment. The result will be that the calling party gets a >> Captioned telephony service included in the call, that answers with >> adding the written Spanish text capability towards the caller, and let >> the called party's spoken Spanish capability indication pass on to the >> caller. >> On the route towards the called party, there is also a need to add rapid >> typed Spanish text, so another captioned telephony service is added to >> the call, adding Spanish Typed text capability to the indications, >> together with the spoken Spanish indication from the caller, so that the >> callee can be assured to be served well in the call. >> >> A problem for this case is how to indicate that both rapid typed Spanish >> text is needed and also spoken Spanish, so they are not alternatives. >> Another problem is what Paul brought up: The need to evaluate the >> combination of preferences from the caller and callee, before the callee >> is called. >> >> >> Gunnar >> >> Gunnar Hellström skrev den 2015-03-05 23:39: >>> Paul, >>> >>> Paul Kyzivat skrev den 2015-03-05 23:16: >>>> The use case below is a good start. >>>> >>>> Are use cases for non-emergency real time communications also in >>>> scope? >>> Yes. >>>> >>>> I'll also observe that there is major interaction between the way the >>>> language and media preferences are signaled and the architecture of >>>> the systems that ensure there is a match of capabilities. Some of >>>> today's relay services depend on being able to know the preferences >>>> of the callee before communications are established to the callee. >>>> They do this in order to queue the call until relay services are >>>> available before contacting the callee. That is in conflict to >>>> allowing the called device to signal its preferences without >>>> pre-arrangement. >>> Right. >>> This is a problem with SDP-based preferences. >>> We have discussed SIP Media tag based preferences. They can be >>> conveyed at Register time and stored in SIP servers, and then compared >>> for routing decisions with what the caller has. >>> That approach is described in the draft Appendix A. >>> I think the main problem with that approach was what we thought was a >>> lack of way to describe spoken versus written language ( that we have >>> learned a way around today ), and that the already specified ways for >>> decision maing with RFC 3840 - 3841 did not seem to fit totally. >>> >>> A way in a closed environment would be to require support for OPTIONS, >>> to get a preview of the SDP. And in this case you might be able to >>> require OPTIONS support if you want to have your calls properly >>> routed, and an assumption that if there is no resonse on OPTIONS, >>> then that user is supposed to be a speech user with the default >>> language of the area. >>> >>> >>> >>>> >>>> In the use case below, the emergency operator takes the call before >>>> the relay is included. This works out because there is *some* medium >>>> in common that can be used before relaying comes online. There would >>>> be a problem if the emergency operator only supported audio - the >>>> call would be established but there would initially be no useful >>>> media. That would be distressing for the caller. In emergency cases >>>> it is plausible to expect the emergency operators to have extra >>>> technology to help with these cases. But in non-emergency cases that >>>> isn't necessarily true. >>> Yes, I agree completely that answering a call and finding that you >>> have no common language is distressing. The 2 minute wait for >>> interpreter should of course also be avoided. But exsists in reality. >>>> >>>> My point is simply that the architecture(s) required to support these >>>> features should be considered as part of the work. (This may not lead >>>> to any normative requirements. It might only be examples or use >>>> cases.) >>> Yes. >>>> >>>> Thanks, >>>> Paul >>>> >>>> On 3/5/15 4:49 PM, Gunnar Hellström wrote: >>>>> In order to decide on what to support, I think we should now >>>>> collect a >>>>> long list of use cases and then decide which ones to support and >>>>> which >>>>> ones to not support. >>>>> >>>>> I can imagine two kinds of use cases: >>>>> 1. architectural cases outlining callers, callees and call >>>>> distribution >>>>> and routing functions and additional services. >>>>> 2. call cases: callers with language and media preferences called >>>>> parties with media and language capabilities and additional services >>>>> with language capabilities. >>>>> >>>>> So, here is a use case: >>>>> >>>>> Emergency call from an Australian Sign language user >>>>> >>>>> A deaf person in Australia has prepared her phone with the following >>>>> preferences: >>>>> Prefer to use Australian Sign Language for both signing and >>>>> perceiving >>>>> sign in video. >>>>> Can with less but fair preference do International Sign in both >>>>> directions in video. >>>>> Can but do not prefer to use real-time text in English in the text >>>>> channel. >>>>> Has a terminal with audio function both ways but has no interest >>>>> to use >>>>> that for language communication. >>>>> She has an emergency in Australia and calls the Australian emergency >>>>> number. >>>>> The emergency service has no own sign language capability, but has a >>>>> few >>>>> terminals and operators who handle video, audio and real-time text >>>>> (total conversation). They have an agreement to call for >>>>> interpretation >>>>> between Australian Sign Laguage and Spoken English, but that >>>>> service is >>>>> allowed to have up to two minutes answering time. >>>>> The call is analyzed for language and media contents and the ACD >>>>> offers >>>>> it to the group of operators with total conversation terminals >>>>> with an >>>>> indication that the two sign languages are preferred but that English >>>>> text is possible. >>>>> The analysis also causes an outgoing call in all media to the sign >>>>> language interpreting service because no operator in the emergency >>>>> service know sign language. >>>>> The emergency operator takes the call and establish all media, and >>>>> see >>>>> from the declaration that it is possible to start asking about the >>>>> emergency by text. The deaf caller see all media being established >>>>> but >>>>> also see that at the moment the only common language is typed >>>>> English. >>>>> A minute later the sign laguage interpreter answers. The call is >>>>> modified to a three-party call, the capability indication changes so >>>>> that it is evident to the caller that Australian sign language can be >>>>> used now. >>>>> The call can continue in convenient sign with the calling user and >>>>> speech between the interpreter and the emergency operator. If >>>>> anything >>>>> needs exact spelling or remembered, then the text channel is still >>>>> there >>>>> for occasional use. >>>>> >>>>> >>>>> Gunnar >>>>> >>>>> >>>>> >>>>> Randall Gellens skrev den 2015-03-05 21:10: >>>>>> Hi Gunnar, >>>>>> >>>>>> At 7:36 AM +0100 3/5/15, Gunnar Hellström wrote: >>>>>> >>>>>>> I also view the charter to be good and want to see the work >>>>>>> started. >>>>>> >>>>>> Thank you. >>>>>> >>>>>>> >>>>>>> There are drafts to start with: >>>>>>> https://tools.ietf.org/html/draft-gellens-slim-negotiating-human-language-00 >>>>>>> >>>>>>> >>>>>>> >>>>>>> https://tools.ietf.org/html/draft-tomkinson-slim-multilangcontent-00 >>>>>>> >>>>>>> >>>>>>> Answering Christians question about what extensions might be >>>>>>> needed, >>>>>>> I want to answer relative towhat is in the realtime draft now. >>>>>>> >>>>>>> I see some topics that may need discussion: >>>>>> >>>>>> The point of the group is to have discussion on what we need. One >>>>>> thing that has been beaten into me by painful experience over many >>>>>> years is that it's best to start with the simplest possible solution >>>>>> that meets enough of the use cases to be useful, and build on that >>>>>> after gaining experience. I've seen this approach work, whereas >>>>>> creating a more complex solution that tries to meet all or most >>>>>> anticipated use cases often fails due to being too difficult to >>>>>> implement. >>>>>> >>>>>>> >>>>>>> 1. Coding of unspecified language but specific mode. >>>>>>> I expect that in many cases it is merely the modality that is of >>>>>>> interest to negotiate, rather than the exact language. There is >>>>>>> often >>>>>>> a default language in a specific area, and as long as you use that, >>>>>>> you will feel that it is a burden to specify that exactly, but >>>>>>> rather >>>>>>> indicate in what medium you want the language exchange. You may >>>>>>> want >>>>>>> to use text for language exchange and audio to convey the sound >>>>>>> from >>>>>>> a location. >>>>>>> So, you would like to specify your preference for spoken, >>>>>>> listened, >>>>>>> written, read, visualized and seen. And for signed and perceiving >>>>>>> sign languages. Regardless of exact language. >>>>>>> So, some codes to use in place of specific languages for these >>>>>>> kinds >>>>>>> of general modalities could be needed. >>>>>> >>>>>> We can discuss this in the group. We already have the ability to >>>>>> negotiate media with no language expression, which might be >>>>>> sufficient >>>>>> for the basic use cases. Adding a new tag for the default language >>>>>> wouldn't be a huge burden, but I'd like to see discussion on why >>>>>> it's >>>>>> needed before proceeding. >>>>>> >>>>>>> >>>>>>> 2. Relative preference between media. >>>>>>> I think it can be important to have a coding for preference >>>>>>> between >>>>>>> media, to express for example if I prefer to speak but can >>>>>>> accept to >>>>>>> type. >>>>>>> We have an order of preference indication between languages in the >>>>>>> same medium in the draft, but not between media. >>>>>> >>>>>> This would be worth discussing in the group as well. My question >>>>>> would be if the incremental value of being able to specify this >>>>>> would >>>>>> result in any real-world benefit, that is, would it change the >>>>>> result >>>>>> of the negotiation over what we have now? >>>>>> >>>>>>> >>>>>>> 3. Absolute versus relative preference between languages. >>>>>>> We have a relative order of preference indication between >>>>>>> languages >>>>>>> in the same medium in the draft. >>>>>>> I can see cases when it is instead an absolute preference that >>>>>>> would >>>>>>> be of importance. >>>>>>> E.g. I am equally happy to get spoken German or spoken French in >>>>>>> this call, but may as the last resort do with spoken English. >>>>>>> Or, same thing between media: >>>>>>> One case can be: I strongly prefer to use spoken French, but >>>>>>> can as >>>>>>> the last resort accept to use written French. >>>>>>> Another can be: I must receive both spoken French and French text. >>>>>> >>>>>> I would expect that the called party would have a set of language >>>>>> and >>>>>> media capabilities (either in-house or by bridging in translation, >>>>>> relay, or interpreter services) and would want to support the >>>>>> caller's >>>>>> needs. I doubt that getting fancy with preferences would change the >>>>>> result very much. >>>>>> >>>>>>> >>>>>>> 4. Same media conveyed under different media types >>>>>>> The current draft specifies SDP as the base for the language >>>>>>> declarations. How do we resolve the cases when the same language >>>>>>> modality can be conveyed under different media types? >>>>>>> Text is conveyed in real time under the media type text. But it is >>>>>>> possible to have some near real-time exchange of text under media >>>>>>> type message (MSRP). How do we express that these might be >>>>>>> alternatives for carrying the same written language? >>>>>>> That question also surfaces the problem that in the language >>>>>>> register there are no good way to express if it is a spoken use of >>>>>>> the language or a written use of the language we want to specify. >>>>>>> There are separate language tags for sign languages but not for >>>>>>> spoken varsus written. (there are some sub-tags for scripts, but >>>>>>> they >>>>>>> should only be used when it is important to select between script >>>>>>> variants )(There is even an SDP-less way to carry text, in the SIP >>>>>>> MESSAGE method. There will be no way to express that as an >>>>>>> alternative way to convey language when we base the method on SDP.) >>>>>> >>>>>> I'm happy to look at non-SDP and/or non-SIP mechanisms once we have >>>>>> the SDP-and-SIP one done. Since emergency calling is based on SDP >>>>>> and >>>>>> SIP, I think we need to start there. >>>>>> >>>>>>> >>>>>>> 3. Slow start of SIP. >>>>>>> We can in SIP have INVITE without SDP offer, and let the >>>>>>> responding >>>>>>> party send the offer with SDP. >>>>>>> With the negotiation mechanism based on SDP, does this slow start >>>>>>> cause any restrictions for us regarding the possiblilities to >>>>>>> express >>>>>>> and negotiate language? >>>>>> >>>>>> I think we need to focus initially on what's needed for emergency >>>>>> calling and similar use cases. We can expand after we get something >>>>>> done. >>>>>> >>>>>>> >>>>>>> I do not want to cause eternal discussions about border cases, >>>>>>> and I >>>>>>> do not want to extend the method into unmanageable complexity. I >>>>>>> just >>>>>>> want us to take good decisions on the mechanism so that it >>>>>>> covers the >>>>>>> cases we want it to cover with a method that is not too complex. >>>>>> >>>>>> Thank you, that's good to hear. >>>>>> >>>>>>> >>>>>>> Christian, maybe in your question was also how the intended work >>>>>>> differs from language negotiation methods already available in >>>>>>> RFC:s? >>>>>>> The current draft, section 6 has a discussion about that. One >>>>>>> difference is that there is today no way to indicate order of >>>>>>> preference between languages. Another is the one I described >>>>>>> above; >>>>>>> the Language tag as such does not indicate the difference between >>>>>>> spoken and written. >>>>>>> >>>>>>> /Gunnar >>>>>>> >>>>>>> >>>>>>> Christian Groves skrev den 2015-03-05 01:49: >>>>>>>> Hello Randall, >>>>>>>> >>>>>>>> I agree with Paul that it does seem optimistic. >>>>>>>> >>>>>>>> In the question text its mentions the caller's "media needs". I'm >>>>>>>> pretty sure I under the scope of "language needs" but "media >>>>>>>> needs" >>>>>>>> could be a little open ended. What sort of enhancements do you see >>>>>>>> to the existing negotiation methods? >>>>>>>> >>>>>>>> Regards, Christian >>>>>>>> >>>>>>>> On 5/03/2015 9:00 AM, Paul Kyzivat wrote: >>>>>>>>> I support this. >>>>>>>>> >>>>>>>>> But I find the schedule vastly overoptimistic, especially for >>>>>>>>> real-time. Add a year or two. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Paul >>>>>>>>> >>>>>>>>> On 3/3/15 6:33 PM, Randall Gellens wrote: >>>>>>>>>> Hi SLIM people, >>>>>>>>>> >>>>>>>>>> Here is a revised proposed charter. The intent is to focus on >>>>>>>>>> the two >>>>>>>>>> current drafts and get those completed. >>>>>>>>>> >>>>>>>>>> ---------- >>>>>>>>>> >>>>>>>>>> SLIM: Selection of Language for Internet Media >>>>>>>>>> >>>>>>>>>> Description of Working Group: >>>>>>>>>> >>>>>>>>>> A mutually comprehensible language is helpful for human >>>>>>>>>> communication. >>>>>>>>>> This is true across a range of circumstances and >>>>>>>>>> environments. In >>>>>>>>>> general, the problem is most acute in situations where there is >>>>>>>>>> not a >>>>>>>>>> clear choice for a single language, such as environments >>>>>>>>>> lacking >>>>>>>>>> contextual or out-of-band information regarding the identity >>>>>>>>>> of the >>>>>>>>>> parties and the language to be used. >>>>>>>>>> >>>>>>>>>> The group will address two specific cases that most urgently >>>>>>>>>> need a >>>>>>>>>> technical solution: One problem space is non-real-time >>>>>>>>>> communication, >>>>>>>>>> specifically email for one-to-many or where the set of >>>>>>>>>> recipients is >>>>>>>>>> dynamic or different recipients require different languages; >>>>>>>>>> the >>>>>>>>>> other >>>>>>>>>> is real-time communication, specifically emergency calling, >>>>>>>>>> preferably >>>>>>>>>> also useful for other cases where the parties may not know each >>>>>>>>>> other >>>>>>>>>> personally or where one party wishes to accommodate people with >>>>>>>>>> varying >>>>>>>>>> language and media needs. >>>>>>>>>> >>>>>>>>>> In the real-time communication case, language and media are >>>>>>>>>> intrinsically linked, for example, signed languages require a >>>>>>>>>> video media. >>>>>>>>>> >>>>>>>>>> While the two use cases are in different contexts (real time >>>>>>>>>> and >>>>>>>>>> non-real-time), the fundamental goal is the same: to enable >>>>>>>>>> selection of >>>>>>>>>> the best-fit language(s) for a specific situation. Some of the >>>>>>>>>> details >>>>>>>>>> will also be in common across the cases. Having a single WG >>>>>>>>>> address >>>>>>>>>> both cases makes it clear that these are two aspects of the >>>>>>>>>> same >>>>>>>>>> basic >>>>>>>>>> problem. A single WG also makes it easier to maximize >>>>>>>>>> similarities and >>>>>>>>>> avoid unnecessary fragmentation of the solutions. >>>>>>>>>> >>>>>>>>>> The group will produce two documents, one for email, and one >>>>>>>>>> for >>>>>>>>>> real-time communications. >>>>>>>>>> >>>>>>>>>> In the email case, the group will produce a MIME content type >>>>>>>>>> specification that enables a single email message to contain >>>>>>>>>> multiple >>>>>>>>>> language versions of the content, with provisions to help >>>>>>>>>> clients >>>>>>>>>> select >>>>>>>>>> a best fit version. >>>>>>>>>> >>>>>>>>>> In the real-time communication case, the group will produce a >>>>>>>>>> specification enabling negotiation of a human language per >>>>>>>>>> media >>>>>>>>>> stream. The specification must be suitable for use in >>>>>>>>>> emergency >>>>>>>>>> communications as specified in RFC 6443 and RFC 6881; it is >>>>>>>>>> desirable to >>>>>>>>>> also be suitable for use in non-emergency real-time >>>>>>>>>> communications that >>>>>>>>>> share the same call set-up and media negotiation protocols. The >>>>>>>>>> mechanism will permit the caller's media and language needs and >>>>>>>>>> preferences to be matched against what the called party is >>>>>>>>>> able to >>>>>>>>>> provide. The mechanism will permit resources (e.g., >>>>>>>>>> translation, >>>>>>>>>> relay, >>>>>>>>>> media) to be allocated or engaged as early as possible in the >>>>>>>>>> call >>>>>>>>>> set-up or for the call to be routed or handled specially (e.g., >>>>>>>>>> routed >>>>>>>>>> to a resource able to provide a needed language and/or media). >>>>>>>>>> >>>>>>>>>> Goals and Milestones: >>>>>>>>>> >>>>>>>>>> June 2015 -- Submit "Multiple Language Content Type" to the >>>>>>>>>> IESG for >>>>>>>>>> consideration as a Standards Track RFC >>>>>>>>>> June 2015 -- Submit "Negotiating Human Language in Real-Time >>>>>>>>>> Communications" to the IESG for consideration as a Standards >>>>>>>>>> Track RFC >>>>>>>>>> >>>>>>>>>> ---------- >>>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 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 >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> _______________________________________________ >>>> SLIM mailing list >>>> SLIM@ietf.org >>>> https://www.ietf.org/mailman/listinfo/slim >>> >> > > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 From nobody Mon Mar 9 17:37:32 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54CB51ACE87 for ; Mon, 9 Mar 2015 17:37:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.599 X-Spam-Level: X-Spam-Status: No, score=0.599 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, J_CHICKENPOX_31=0.6] autolearn=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 zg8TZ9bhEZQg for ; Mon, 9 Mar 2015 17:37:23 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E6421ACE6C for ; Mon, 9 Mar 2015 17:37:19 -0700 (PDT) Received: from ppp118-209-228-24.lns20.mel8.internode.on.net ([118.209.228.24]:55328 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1YV88S-0003vi-Kc; Tue, 10 Mar 2015 11:35:00 +1100 Message-ID: <54FE3CBB.4080907@nteczone.com> Date: Tue, 10 Mar 2015 11:37:15 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Randall Gellens , slim@ietf.org References: <54F78072.5060206@alum.mit.edu> <54F7A836.6000307@nteczone.com> <54F7F951.5020109@omnitor.se> <54F8E7E2.3090703@nteczone.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [Slim] Proposed SLIM charter X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 00:37:26 -0000 Hello Randall, The suggested changes are OK for me. Regards, Christian On 7/03/2015 6:33 AM, Randall Gellens wrote: > Hi Christian, > > I'm happy with your suggestion to add clarifying text to the proposed > charter as an additional guard against scope creep. How about this: > > Change the sentence: > > The specification must be suitable for use in emergency > communications as specified in RFC 6443 and RFC 6881; it is > desirable to also be suitable for use in non-emergency real-time > communications that share the same call set-up and media > negotiation protocols. > > to: > > The specification must be suitable for use in emergency > communications as specified in RFC 6443 and RFC 6881 (which use > SIP and SDP to negotiate media); it is desirable to also be > suitable for use in non-emergency real-time communications that > share the same call set-up and media negotiation protocols. > > The difference is the parenthetical aside. > > Also, we can add a new paragraph based on Christian's suggestion: > > By adding language to the existing media negotiation mechanism, > the group can meet the basic use cases with minimal added > complexity and be able to enhance later for additional use cases > as needed. > > If people are happy with this, I will add it to the proposed charter. > > > > At 10:33 AM +1100 3/6/15, Christian Groves wrote: > >> Hello Gunnar and Randall, >> >> I agree with your comments regarding a targeted solution. My >> question was really to see the scope of changes people were thinking >> about around media negotiation. E.g. whether specific language >> related additions are needed or more of a general solution for media >> preferences. >> >> I think Randall's it would be worth adding some text to the charter >> would be a reminder to avoid scope creep. Something similar to >> Randall's clarification that: "media needs means audio, text, or >> video media for interactive communications, which is already >> negotiated using SDP in SIP. I believe that by adding language to >> the existing media negotiation we can meet the basic use cases and be >> able to enhance later as needed." >> >> A separate question: does the group expect to discuss the use of >> CLUE? When multiple streams are used it does have the ability to >> indicate language, priority and other metadata that could be helpful >> to the selection of language/media. >> >> Regards, Christian >> >> On 6/03/2015 7:10 AM, Randall Gellens wrote: >>> Hi Gunnar, >>> >>> At 7:36 AM +0100 3/5/15, Gunnar Hellström wrote: >>> >>>> I also view the charter to be good and want to see the work started. >>> >>> Thank you. >>> >>>> >>>> There are drafts to start with: >>>> >>>> https://tools.ietf.org/html/draft-gellens-slim-negotiating-human-language-00 >>>> >>>> https://tools.ietf.org/html/draft-tomkinson-slim-multilangcontent-00 >>>> >>>> Answering Christians question about what extensions might be >>>> needed, I want to answer relative towhat is in the realtime draft now. >>>> >>>> I see some topics that may need discussion: >>> >>> The point of the group is to have discussion on what we need. One >>> thing that has been beaten into me by painful experience over many >>> years is that it's best to start with the simplest possible solution >>> that meets enough of the use cases to be useful, and build on that >>> after gaining experience. I've seen this approach work, whereas >>> creating a more complex solution that tries to meet all or most >>> anticipated use cases often fails due to being too difficult to >>> implement. >> >>>> >>>> 1. Coding of unspecified language but specific mode. >>>> I expect that in many cases it is merely the modality that is of >>>> interest to negotiate, rather than the exact language. There is >>>> often a default language in a specific area, and as long as you use >>>> that, you will feel that it is a burden to specify that exactly, >>>> but rather indicate in what medium you want the language exchange. >>>> You may want to use text for language exchange and audio to convey >>>> the sound from a location. >>>> So, you would like to specify your preference for spoken, >>>> listened, written, read, visualized and seen. And for signed and >>>> perceiving sign languages. Regardless of exact language. >>>> So, some codes to use in place of specific languages for these >>>> kinds of general modalities could be needed. >>> >>> We can discuss this in the group. We already have the ability to >>> negotiate media with no language expression, which might be >>> sufficient for the basic use cases. Adding a new tag for the >>> default language wouldn't be a huge burden, but I'd like to see >>> discussion on why it's needed before proceeding. >>> >>>> >>>> 2. Relative preference between media. >>>> I think it can be important to have a coding for preference >>>> between media, to express for example if I prefer to speak but can >>>> accept to type. >>>> We have an order of preference indication between languages in >>>> the same medium in the draft, but not between media. >>> >>> This would be worth discussing in the group as well. My question >>> would be if the incremental value of being able to specify this >>> would result in any real-world benefit, that is, would it change the >>> result of the negotiation over what we have now? >>> >>>> >>>> 3. Absolute versus relative preference between languages. >>>> We have a relative order of preference indication between >>>> languages in the same medium in the draft. >>>> I can see cases when it is instead an absolute preference that >>>> would be of importance. >>>> E.g. I am equally happy to get spoken German or spoken French in >>>> this call, but may as the last resort do with spoken English. >>>> Or, same thing between media: >>>> One case can be: I strongly prefer to use spoken French, but can >>>> as the last resort accept to use written French. >>>> Another can be: I must receive both spoken French and French text. >>> >>> I would expect that the called party would have a set of language >>> and media capabilities (either in-house or by bridging in >>> translation, relay, or interpreter services) and would want to >>> support the caller's needs. I doubt that getting fancy with >>> preferences would change the result very much. >>> >>>> >>>> 4. Same media conveyed under different media types >>>> The current draft specifies SDP as the base for the language >>>> declarations. How do we resolve the cases when the same language >>>> modality can be conveyed under different media types? >>>> Text is conveyed in real time under the media type text. But it >>>> is possible to have some near real-time exchange of text under >>>> media type message (MSRP). How do we express that these might be >>>> alternatives for carrying the same written language? >>>> That question also surfaces the problem that in the language >>>> register there are no good way to express if it is a spoken use of >>>> the language or a written use of the language we want to specify. >>>> There are separate language tags for sign languages but not for >>>> spoken varsus written. (there are some sub-tags for scripts, but >>>> they should only be used when it is important to select between >>>> script variants )(There is even an SDP-less way to carry text, in >>>> the SIP MESSAGE method. There will be no way to express that as an >>>> alternative way to convey language when we base the method on SDP.) >>> >>> I'm happy to look at non-SDP and/or non-SIP mechanisms once we have >>> the SDP-and-SIP one done. Since emergency calling is based on SDP >>> and SIP, I think we need to start there. >>> >>>> >>>> 3. Slow start of SIP. >>>> We can in SIP have INVITE without SDP offer, and let the >>>> responding party send the offer with SDP. >>>> With the negotiation mechanism based on SDP, does this slow start >>>> cause any restrictions for us regarding the possiblilities to >>>> express and negotiate language? >>> >>> I think we need to focus initially on what's needed for emergency >>> calling and similar use cases. We can expand after we get something >>> done. >>> >>>> >>>> I do not want to cause eternal discussions about border cases, >>>> and I do not want to extend the method into unmanageable >>>> complexity. I just want us to take good decisions on the mechanism >>>> so that it covers the cases we want it to cover with a method that >>>> is not too complex. >>> >>> Thank you, that's good to hear. >>> >>>> >>>> Christian, maybe in your question was also how the intended work >>>> differs from language negotiation methods already available in RFC:s? >>>> The current draft, section 6 has a discussion about that. One >>>> difference is that there is today no way to indicate order of >>>> preference between languages. Another is the one I described >>>> above; the Language tag as such does not indicate the difference >>>> between spoken and written. >>>> >>>> /Gunnar >>>> >>>> >>>> Christian Groves skrev den 2015-03-05 01:49: >>>>> Hello Randall, >>>>> >>>>> I agree with Paul that it does seem optimistic. >>>>> >>>>> In the question text its mentions the caller's "media needs". >>>>> I'm pretty sure I under the scope of "language needs" but "media >>>>> needs" could be a little open ended. What sort of enhancements do >>>>> you see to the existing negotiation methods? >>>>> >>>>> Regards, Christian >>>>> >>>>> On 5/03/2015 9:00 AM, Paul Kyzivat wrote: >>>>>> I support this. >>>>>> >>>>>> But I find the schedule vastly overoptimistic, especially for >>>>>> real-time. Add a year or two. >>>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> >>>>>> On 3/3/15 6:33 PM, Randall Gellens wrote: >>>>>>> Hi SLIM people, >>>>>>> >>>>>>> Here is a revised proposed charter. The intent is to focus on >>>>>>> the two >>>>>>> current drafts and get those completed. >>>>>>> >>>>>>> ---------- >>>>>>> >>>>>>> SLIM: Selection of Language for Internet Media >>>>>>> >>>>>>> Description of Working Group: >>>>>>> >>>>>>> A mutually comprehensible language is helpful for human >>>>>>> communication. >>>>>>> This is true across a range of circumstances and environments. In >>>>>>> general, the problem is most acute in situations where there >>>>>>> is not a >>>>>>> clear choice for a single language, such as environments lacking >>>>>>> contextual or out-of-band information regarding the identity >>>>>>> of the >>>>>>> parties and the language to be used. >>>>>>> >>>>>>> The group will address two specific cases that most urgently >>>>>>> need a >>>>>>> technical solution: One problem space is non-real-time >>>>>>> communication, >>>>>>> specifically email for one-to-many or where the set of >>>>>>> recipients is >>>>>>> dynamic or different recipients require different languages; >>>>>>> the other >>>>>>> is real-time communication, specifically emergency calling, >>>>>>> preferably >>>>>>> also useful for other cases where the parties may not know >>>>>>> each other >>>>>>> personally or where one party wishes to accommodate people >>>>>>> with varying >>>>>>> language and media needs. >>>>>>> >>>>>>> In the real-time communication case, language and media are >>>>>>> intrinsically linked, for example, signed languages require a >>>>>>> video media. >>>>>>> >>>>>>> While the two use cases are in different contexts (real time and >>>>>>> non-real-time), the fundamental goal is the same: to enable >>>>>>> selection of >>>>>>> the best-fit language(s) for a specific situation. Some of the >>>>>>> details >>>>>>> will also be in common across the cases. Having a single WG >>>>>>> address >>>>>>> both cases makes it clear that these are two aspects of the >>>>>>> same basic >>>>>>> problem. A single WG also makes it easier to maximize >>>>>>> similarities and >>>>>>> avoid unnecessary fragmentation of the solutions. >>>>>>> >>>>>>> The group will produce two documents, one for email, and one for >>>>>>> real-time communications. >>>>>>> >>>>>>> In the email case, the group will produce a MIME content type >>>>>>> specification that enables a single email message to contain >>>>>>> multiple >>>>>>> language versions of the content, with provisions to help >>>>>>> clients select >>>>>>> a best fit version. >>>>>>> >>>>>>> In the real-time communication case, the group will produce a >>>>>>> specification enabling negotiation of a human language per media >>>>>>> stream. The specification must be suitable for use in emergency >>>>>>> communications as specified in RFC 6443 and RFC 6881; it is >>>>>>> desirable to >>>>>>> also be suitable for use in non-emergency real-time >>>>>>> communications that >>>>>>> share the same call set-up and media negotiation protocols. The >>>>>>> mechanism will permit the caller's media and language needs and >>>>>>> preferences to be matched against what the called party is >>>>>>> able to >>>>>>> provide. The mechanism will permit resources (e.g., >>>>>>> translation, relay, >>>>>>> media) to be allocated or engaged as early as possible in the >>>>>>> call >>>>>>> set-up or for the call to be routed or handled specially >>>>>>> (e.g., routed >>>>>>> to a resource able to provide a needed language and/or media). >>>>>>> >>>>>>> Goals and Milestones: >>>>>>> >>>>>>> June 2015 -- Submit "Multiple Language Content Type" to the >>>>>>> IESG for >>>>>>> consideration as a Standards Track RFC >>>>>>> June 2015 -- Submit "Negotiating Human Language in Real-Time >>>>>>> Communications" to the IESG for consideration as a Standards >>>>>>> Track RFC >>>>>>> >>>>>>> ---------- >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>> >>> >>> >> >> _______________________________________________ >> SLIM mailing list >> SLIM@ietf.org >> https://www.ietf.org/mailman/listinfo/slim > > > From nobody Tue Mar 10 10:08:42 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4C121A0130 for ; Tue, 10 Mar 2015 09:01:44 -0700 (PDT) X-Quarantine-ID: <5GokO7MYwiYZ> 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: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5GokO7MYwiYZ for ; Tue, 10 Mar 2015 09:01:37 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9619F1A1A91 for ; Tue, 10 Mar 2015 09:01:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1426003298; x=1457539298; h=message-id:date:to:from:subject; bh=zT3rDe/FzLxOYYsaKFGsvEw1YG7/U6aWdY4TBsmC7oo=; b=M4XDrwkcimhVgjz9Fa2qJv6QIgstDwQgDW9p00JvAB+PyTQl1kE5dIn2 cNDgK68DBY4u1hrCA4PsyhIaZXAkGKpLcPg0xngDgkVFmfYCxFD2vTjxL dUGRMQIEvmi0RH/rPTcxFpPfrO7jb5hYObcRCivy5U4c4vj6H7LCGAaig g=; X-IronPort-AV: E=McAfee;i="5600,1067,7735"; a="107200813" Received: from ironmsg02-l.qualcomm.com ([172.30.48.16]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Mar 2015 09:01:38 -0700 X-IronPort-AV: E=Sophos;i="5.11,375,1422950400"; d="scan'208";a="428606896" Received: from plus.qualcomm.com ([10.52.255.8]) by ironmsg02-L.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Mar 2015 09:01:36 -0700 Received: from ironmsg02-L.qualcomm.com (ironmsg02-L.qualcomm.com [172.30.48.16]) by plus.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id t2AG1VAr000928; Tue, 10 Mar 2015 09:01:32 -0700 X-IronPort-AV: E=Sophos;i="5.11,375,1422950400"; d="scan'208";a="428606837" X-ojodefuego: yes Received: from unknown (HELO [99.111.97.136]) ([10.64.228.81]) by ironmsg02-L.qualcomm.com with ESMTP; 10 Mar 2015 09:01:28 -0700 Mime-Version: 1.0 Message-Id: X-Mailer: Eudora for Mac OS X Date: Tue, 10 Mar 2015 09:01:27 -0700 To: slim@ietf.org, Harald Alvestrand , Gunnar Hellstrom , John C Klensin , "Flemming Andreasen" , Brian Rosen , "Peter Saint-Andre" , Keith Drage , Brian Rosen , "Ari Keranen" , Pete Resnick , Alexey Melnikov , Eric Burger , Eric Burger , "Hutton, Andrew" , Nathaniel Borenstein , "Nik Tomkinson" , , Chris Newman 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 X-Random-Sig-Tag: 1.0b28 Archived-At: X-Mailman-Approved-At: Tue, 10 Mar 2015 10:08:41 -0700 Subject: [Slim] SLIM (human language) meet-up in Dallas X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 16:01:45 -0000 Hi SLIMmers, Please let me know your preferred days and times for a meeting on SLIM (the human language work) in Dallas. I'll then send out a Doodle poll with the most promising slots. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- The whole aim of practical politics is to keep the populace alarmed (and hence clamorous to be led to safety) by an endless series of hobgoblins, most of them imaginary. --H.L. Mencken From nobody Tue Mar 10 19:50:35 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F6421A8707 for ; Tue, 10 Mar 2015 11:15:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.821 X-Spam-Level: X-Spam-Status: No, score=-1.821 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zTXxXt-8TX-h for ; Tue, 10 Mar 2015 11:15:52 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) (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 D54E21A8703 for ; Tue, 10 Mar 2015 11:15:51 -0700 (PDT) Received: by qcyl6 with SMTP id l6so4035700qcy.10 for ; Tue, 10 Mar 2015 11:15:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=xGXh1aR3DHje8kriSZdJOQLKXwIAqDVTz/wYxahS5Ko=; b=R0SAasFEx28Qad3RhbKgJKXIVSUEJN0zkZoDLVZr5oS8GWwbJ2t25mZOmGlTaLzKQr 7pKA9ETh+0/NAPbl1j6waB7A6P3rGN5Spnk8WBZkmQYBr7MNJQYVSmKL7SGvtwFUaSA+ fL8Ebkw0IVx7SiKz4cjaJqPte28NAC1hKoCDEQl8x/GP3wk47sdLi4tt5xvfgU2DpNT4 WqlQu2lDoI1e1//hkpEquskzr5jEMK7qEV/MifxrI53NNI9bx5cbbgR0rgTeo/WExH5X 55J4XPaO3MnyUXM+55hT2apcofgMO/pir7t3Yw+fHnvxLaNlVOjAZmxYXBrV8CCVGfEH rKWQ== X-Gm-Message-State: ALoCoQnK9zjn2WbrIfAGp0p7s1Iv+CF8N1dsfS7G5tOi3liBqk5kWDFsUHDzdyx/0NpS7aN86sYu X-Received: by 10.55.55.85 with SMTP id e82mr20065347qka.2.1426011351187; Tue, 10 Mar 2015 11:15:51 -0700 (PDT) Received: from fesp-ltw7.cis.neustar.com (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id k195sm862860qhk.27.2015.03.10.11.15.48 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 10 Mar 2015 11:15:50 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Brian Rosen In-Reply-To: Date: Tue, 10 Mar 2015 13:15:48 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Randall Gellens X-Mailer: Apple Mail (2.2070.6) Archived-At: X-Mailman-Approved-At: Tue, 10 Mar 2015 19:50:34 -0700 Cc: slim@ietf.org, hannes.tschofenig@gmx.net, Ari Keranen , Andrew Hutton , Eric Burger , Chris Newman , Pete Resnick , Keith Drage , Gunnar Hellstrom , Nathaniel Borenstein , Flemming Andreasen , Harald Tveit Alvestrand , Peter Saint-Andre , John C Klensin , Alexey Melnikov , Nik Tomkinson Subject: Re: [Slim] SLIM (human language) meet-up in Dallas X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 18:15:53 -0000 Hmmm Before Thursday afternoon Not Monday lunch, or Tuesday evening. So, Monday evening, Wednesday evening, Wednesday lunch, Thursday lunch. > On Mar 10, 2015, at 11:01 AM, Randall Gellens = wrote: >=20 > Hi SLIMmers, >=20 > Please let me know your preferred days and times for a meeting on=20 > SLIM (the human language work) in Dallas. I'll then send out a=20 > Doodle poll with the most promising slots. >=20 > --=20 > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself = only > -------------- Randomly selected tag: --------------- > The whole aim of practical politics is to keep the populace alarmed > (and hence clamorous to be led to safety) by an endless series of > hobgoblins, most of them imaginary. > --H.L. Mencken From nobody Wed Mar 11 12:26:01 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 085D11A00C7 for ; Wed, 11 Mar 2015 12:25:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rm7-GhXH3wsV for ; Wed, 11 Mar 2015 12:25:57 -0700 (PDT) Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 836731A024E for ; Wed, 11 Mar 2015 12:25:55 -0700 (PDT) Received: by qgea108 with SMTP id a108so12660095qge.8 for ; Wed, 11 Mar 2015 12:25:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=fpZ8LAaAFUamxJlFYxgqeHdAIB3QoeDu5bEnNcsBkOo=; b=At2V8NLpK/s6wYmRnPEFqWbHv+rQytc+dARIU4jADBSkLKxmX/moeFlzqsU+kScZr0 w4s4OK567RYb8oCctPMJHhKJ2WJG2UUoCutJteRuMmMx0kF1QjPMu68H1mM09EeGdANL qxDJTPlfNX7ZfaRFH7PQc5P3BYbwAVGTZEgtp4uSzfikXFgNEO5TKadmAxFqO6mNLAbN Uum27OAfTXO+x756xYaQ+AxsgQkQ9UM2B42kDRQ0YPuHm5h52cpQuekExiOI+u6q2vo+ TV73zgokn6SfGCO90wdWsQcssJa5TiIgI/dj7putmkH/HvIoDnfnVqlRfxD5Q+eZwFpB 06yA== MIME-Version: 1.0 X-Received: by 10.140.91.71 with SMTP id y65mr47973311qgd.90.1426101954738; Wed, 11 Mar 2015 12:25:54 -0700 (PDT) Received: by 10.229.230.3 with HTTP; Wed, 11 Mar 2015 12:25:54 -0700 (PDT) In-Reply-To: References: Date: Wed, 11 Mar 2015 19:25:54 +0000 Message-ID: From: Nik Tomkinson To: slim@ietf.org Content-Type: multipart/alternative; boundary=001a113a335e6d00630511083c54 Archived-At: Subject: Re: [Slim] SLIM (human language) meet-up in Dallas X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 19:25:59 -0000 --001a113a335e6d00630511083c54 Content-Type: text/plain; charset=UTF-8 Hi, I will be dialling in from the UK so early on in the day would be good but any day should be ok for me. As long as there is Skype available then I should be able to join without issues. Nik. On 10 March 2015 at 18:15, Brian Rosen wrote: > Hmmm > > Before Thursday afternoon > Not Monday lunch, or Tuesday evening. > So, Monday evening, Wednesday evening, Wednesday lunch, Thursday lunch. > > > > On Mar 10, 2015, at 11:01 AM, Randall Gellens > wrote: > > > > Hi SLIMmers, > > > > Please let me know your preferred days and times for a meeting on > > SLIM (the human language work) in Dallas. I'll then send out a > > Doodle poll with the most promising slots. > > > > -- > > Randall Gellens > > Opinions are personal; facts are suspect; I speak for myself only > > -------------- Randomly selected tag: --------------- > > The whole aim of practical politics is to keep the populace alarmed > > (and hence clamorous to be led to safety) by an endless series of > > hobgoblins, most of them imaginary. > > --H.L. Mencken > > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim > -- ----------------------------------------------------------------- Multiple Language Content Type Internet Draft: http://datatracker.ietf.org/doc/draft-tomkinson-slim-multilangcontent/ ----------------------------------------------------------------- --001a113a335e6d00630511083c54 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I will be dialling in from the UK s= o early on in the day would be good but any day should be ok for me. As lon= g as there is Skype available then I should be able to join without issues.=

Nik.

On 10 March 2015 at 18:15, Brian Rosen <br@bria= nrosen.net> wrote:
Hmmm

Before Thursday afternoon
Not Monday lunch, or Tuesday evening.
So, Monday evening, Wednesday evening, Wednesday lunch, Thursday lunch.


> On Mar 10, 2015, at 11:01 AM, Randall Gellens <rg+ietf@qti.qualcomm.com> wrote:
>
> Hi SLIMmers,
>
> Please let me know your preferred days and times for a meeting on
> SLIM (the human language work) in Dallas.=C2=A0 I'll then send out= a
> Doodle poll with the most promising slots.
>
> --
> Randall Gellens
> Opinions are personal;=C2=A0 =C2=A0 facts are suspect;=C2=A0 =C2=A0 I = speak for myself only
> -------------- Randomly selected tag: ---------------
> The whole aim of practical politics is to keep the populace alarmed > (and hence clamorous to be led to safety) by an endless series of
> hobgoblins, most of them imaginary.
>=C2=A0 =C2=A0 --H.L. Mencken

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



--
= 
=
-------------------------=
----------------------------------------
Multiple Language Content Type =
Internet Draft:
http://datatracker.ietf.org/doc/draft= -tomkinson-slim-multilangcontent/
------------------------------------------------------=
-----------
--001a113a335e6d00630511083c54-- From nobody Wed Mar 11 17:10:50 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C50441A890C for ; Wed, 11 Mar 2015 15:57:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.2 X-Spam-Level: X-Spam-Status: No, score=-6.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uH9yOyltiJEe for ; Wed, 11 Mar 2015 15:57:48 -0700 (PDT) Received: from worker1.doodle.com (worker1.doodle.com [94.230.219.151]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 861EC1A891D for ; Wed, 11 Mar 2015 15:57:44 -0700 (PDT) Received: from worker1.doodle.com (localhost [127.0.0.1]) by worker1.doodle.com (Postfix) with ESMTP id 6AC6A104E1F4 for ; Wed, 11 Mar 2015 23:57:42 +0100 (CET) Date: Wed, 11 Mar 2015 23:57:42 +0100 (CET) From: "Randall Gellens (via Doodle)" To: Message-ID: <1653005226.1776993.1426114662435.POLL_INVITECONTACT_PARTICIPANT_INVITATION_WITH_MESSAGE.doodle@worker1> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1776992_599537289.1426114662435" Archived-At: X-Mailman-Approved-At: Wed, 11 Mar 2015 17:10:49 -0700 Subject: [Slim] SLIM (Human Language) informal discussion on progress X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randall Gellens List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 22:57:50 -0000 ------=_Part_1776992_599537289.1426114662435 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi there, Randall Gellens (doodle@randy.pensive.org) invites you to participate in the Doodle poll "SLIM (Human Language) informal discussion on progress." Randall Gellens says: Informal meeting for people interested in SLIM (human language) and how to make progress. Slots based on email discussion. Participate now https://doodle.com/zsdwk44skdaz76hn?tmail=3Dpoll_invitecontact_participant_= invitation_with_message&tlink=3Dpollbtn What is Doodle? Doodle is a web service that helps Randall Gellens to find a suitable date for meeting with a group of people. Learn more about how Doodle works. (https://doodle.com/main.html?tlink=3DcheckOutLink&tmail=3Dpoll_inviteconta= ct_participant_invitation_with_message) ---------------------------------------------------------------------- You have received this e-mail because "Randall Gellens" has invited you to participate in the Doodle poll "SLIM (Human Language) informal discussion on progress." ---- Doodle AG, Werdstrasse 21, 8021 Z=C3=BCrich ------=_Part_1776992_599537289.1426114662435 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =
=09
Randall Gellens invites you= to participate in the Doodle poll "SLIM (Human Language) informal dis= cussion on progress."
=09
=09 =09 =09
=09 =09=09 =09=09 =09=09=09=09=09=09=09 =09=09 =09=09=09=09=09 =09=09=09=09=09=09=09 =09=09=09=09=09=09=09=09 =09=09=09=09=09=09=09 =09=09=09=09=09=09=09=09 =09
=20 =20
=09=09 =09=09=09 =09=09=09=09 =09=09=09=09=09
=09=09=09=09=09=09
=09=09 =09=09=09 =09=09=09=09 =09=09=09=09=09 =09=09=09=09=09=09=09 =09=09=09=09=09=09=09=09 =09 =09=09=09=09=09=09=09 =09=09=09=09=09=09=09=09 =09 =09=09=09=09=09=09=09 =09=09=09=09=09=09=09=09 =09 =09=09=09=09=09=09=09 =09=09=09=09=09=09=09=09 =09 =09=09=09=09=09=09=09 =09=09=09=09=09=09=09=09 =20 =20 =09=09=09=09=09=09=09
=09=09=09=09=09=09
=09=09 =09=09 =09=09=09 =09=09=09=09 =09=09=09=09=09 =09=09=09=09 =09=09=09 =09=09
=09=09=09=09=09=09
"SLIM= (Human Language) informal discussion on progress." =09=09=09=09=09=09
=09=09=09=09=09
=09=09 =09
=09=09 =09=09=09 =09=09=09=09 =09=09=09=09=09 =09=09=09=09 =09=09=09 =09=09
=09=09=09=09=09=09
=09=09=09=09=09=09=09Randall Gellens says: =09=09=09=09=09=09
=09=09=09=09=09=09
=09=09=09=09=09=09=09Informal meeting for people interested in SLIM (human = language) and how to make progress. Slots based on email discussion. =09=09=09=09=09=09
=09=09=09=09=09
=20 =09
=09=09 =09=09=09 =09=09=09=09 =09=09=09=09=09 =09=09=09=09 =09=09=09=09 =09=09=09=09=09 =09=09=09=09 =09=09=09=09 =09=09=09=09=09 =09=09=09=09 =09=09=09 =09=09
=
=09=09=09=09=09=09 =09=09=09=09=09=09 =09=09=09=09=09=09 =09=09=09=09=09=09=09 =09=09=09=09=09=09 =09=09=09=09=09=09 =09=09=09=09=09=09 =09=09=09=09=09
=09=09=09=09=09=09=09=09Participate now =09=09=09=09=09=09=09
=09=09=09=09=09
=
=09
=09=09 =09=09=09 =09=09=09=09 =09=09=09=09=09 =09=09=09=09=09 =09=09=09=09 =09=09=09 =09=09
=09=09=09=09=09=09 =09=09=09=09=09 =09=09=09=09=09=09
=20 =09=09=09=09=09=09=09 What is Doodle? Doodle is a web service that helps Randall Gellens to find a suitable da= te for meeting with a group of people. Learn more about how Doodle works.
=20 =09=09=09=09=09=09
=09=09=09=09=09
=09
=09=09 =09=09 =09 =09=09 =09=09 =09=09 =09 =09=09 =09 =09=09 =09 =09=09 =09 =09=09 =09=09 =09=09 =09 =09=09 =09=09 =20 =09=09
=09=09 =09You have received this e-mail because "Randall Gellen= s" has invited you to participate in the Doodle poll "SLIM (Human= Language) informal discussion on progress." =09=09
=09
=20
Doodle AG, Werdstrasse 21, 8021 Z=C3=BCrich

------=_Part_1776992_599537289.1426114662435-- From nobody Wed Mar 11 22:02:40 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC42E1A8A5A for ; Wed, 11 Mar 2015 22:02:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 CSFfQJbmSDKZ for ; Wed, 11 Mar 2015 22:02:36 -0700 (PDT) Received: from bin-vsp-out-02.atm.binero.net (vsp-authed01.binero.net [195.74.38.224]) (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 5DA351A8A59 for ; Wed, 11 Mar 2015 22:02:36 -0700 (PDT) X-Halon-ID: ffddb2d3-c874-11e4-8eab-005056917f90 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.42] (unknown [77.53.231.174]) by bin-vsp-out-02.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Thu, 12 Mar 2015 06:02:36 +0100 (CET) Message-ID: <55011DE6.5030307@omnitor.se> Date: Thu, 12 Mar 2015 06:02:30 +0100 From: =?windows-1252?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: slim@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------050909080302080500000407" Archived-At: Subject: Re: [Slim] SLIM (human language) meet-up in Dallas X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 05:02:38 -0000 This is a multi-part message in MIME format. --------------050909080302080500000407 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit I am also interested to participate if it will be possible with remote dial-in. Will it? Gunnar -------------------------------------------------- Nik Tomkinson skrev den 2015-03-11 20:25: > Hi, > > I will be dialling in from the UK so early on in the day would be good > but any day should be ok for me. As long as there is Skype available > then I should be able to join without issues. > > Nik. > > On 10 March 2015 at 18:15, Brian Rosen > wrote: > > Hmmm > > Before Thursday afternoon > Not Monday lunch, or Tuesday evening. > So, Monday evening, Wednesday evening, Wednesday lunch, Thursday > lunch. > > > > On Mar 10, 2015, at 11:01 AM, Randall Gellens > > wrote: > > > > Hi SLIMmers, > > > > Please let me know your preferred days and times for a meeting on > > SLIM (the human language work) in Dallas. I'll then send out a > > Doodle poll with the most promising slots. > > > > -- > > Randall Gellens > > Opinions are personal; facts are suspect; I speak for > myself only > > -------------- Randomly selected tag: --------------- > > The whole aim of practical politics is to keep the populace alarmed > > (and hence clamorous to be led to safety) by an endless series of > > hobgoblins, most of them imaginary. > > --H.L. Mencken > > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim > > > > > -- > ----------------------------------------------------------------- > Multiple Language Content Type Internet Draft: > http://datatracker.ietf.org/doc/draft-tomkinson-slim-multilangcontent/ > ----------------------------------------------------------------- > > > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim -- --------------050909080302080500000407 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit I am also interested to participate if it will be possible with remote dial-in.
Will it?

Gunnar
--------------------------------------------------
Nik Tomkinson skrev den 2015-03-11 20:25:
Hi,

I will be dialling in from the UK so early on in the day would be good but any day should be ok for me. As long as there is Skype available then I should be able to join without issues.

Nik.

On 10 March 2015 at 18:15, Brian Rosen <br@brianrosen.net> wrote:
Hmmm

Before Thursday afternoon
Not Monday lunch, or Tuesday evening.
So, Monday evening, Wednesday evening, Wednesday lunch, Thursday lunch.


> On Mar 10, 2015, at 11:01 AM, Randall Gellens <rg+ietf@qti.qualcomm.com> wrote:
>
> Hi SLIMmers,
>
> Please let me know your preferred days and times for a meeting on
> SLIM (the human language work) in Dallas.  I'll then send out a
> Doodle poll with the most promising slots.
>
> --
> Randall Gellens
> Opinions are personal;    facts are suspect;    I speak for myself only
> -------------- Randomly selected tag: ---------------
> The whole aim of practical politics is to keep the populace alarmed
> (and hence clamorous to be led to safety) by an endless series of
> hobgoblins, most of them imaginary.
>    --H.L. Mencken

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



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



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


--
--------------050909080302080500000407-- From nobody Fri Mar 13 10:26:36 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 762C91A908B for ; Fri, 13 Mar 2015 10:26:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.711 X-Spam-Level: X-Spam-Status: No, score=-6.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Xb2zZ26L65G for ; Fri, 13 Mar 2015 10:26:33 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 649791A906B for ; Fri, 13 Mar 2015 10:26:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1426267593; x=1457803593; h=message-id:in-reply-to:references:date:to:from:subject: mime-version:content-transfer-encoding; bh=vXgGcJbLiPea0acScN04SzxFw7M423iJXX5ET2mGki4=; b=AKo8fk0Oc/aZabtVbcITru8iqGnm+0V4u62QHhwop0g0PaWq3pFK3sl+ CKTVaDYm76uo95DX5d/qvol/wQPR8NjfGzPTN+TN9uZnwSo2gfMWApDnl rkaFDl6iMR0Tn3SrrvuIe7EyCANzYwxbLeEnGs7j3EB10DPXigMRHVDH9 I=; X-IronPort-AV: E=McAfee;i="5600,1067,7739"; a="84945473" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by sabertooth01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Mar 2015 10:26:32 -0700 X-IronPort-AV: E=Sophos;i="5.11,395,1422950400"; d="scan'208";a="861370814" Received: from nasanexm02f.na.qualcomm.com ([10.85.0.87]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 13 Mar 2015 10:26:32 -0700 Received: from [99.111.97.136] (10.80.80.8) by nasanexm02f.na.qualcomm.com (10.85.0.87) with Microsoft SMTP Server (TLS) id 15.0.995.29; Fri, 13 Mar 2015 10:26:31 -0700 Message-ID: In-Reply-To: <55011DE6.5030307@omnitor.se> References: <55011DE6.5030307@omnitor.se> X-Mailer: Eudora for Mac OS X Date: Fri, 13 Mar 2015 10:25:37 -0700 To: 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-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanexm01a.na.qualcomm.com (10.85.0.81) To nasanexm02f.na.qualcomm.com (10.85.0.87) Archived-At: Subject: Re: [Slim] SLIM (human language) meet-up in Dallas X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 17:26:35 -0000 At 6:02 AM +0100 3/12/15, Gunnar Hellstr=F6m wrote: > I am also interested to participate if it will=20 > be possible with remote dial-in. > Will it? We'll try and have Skype running. There are a=20 few people who expressed interest in remote=20 participation. I don't now how well remote=20 people will be able to hear those in the room,=20 but we can try to speak into whichever device is=20 running Skype. > -------------------------------------------------- > > Nik Tomkinson skrev den 2015-03-11 20:25: > >> Hi, >> >> I will be dialling in from the UK so early on=20 >> in the day would be good but any day should be=20 >> ok for me. As long as there is Skype available=20 >> then I should be able to join without issues. >> >> Nik. >> >> On 10 March 2015 at 18:15, Brian Rosen=20 >> <br@brianrosen.net>=20 >> wrote: >> >> Hmmm >> >> Before Thursday afternoon >> Not Monday lunch, or Tuesday evening. >> So, Monday evening, Wednesday evening, Wednesday lunch, Thursday lunch. >> >> >> >>> On Mar 10, 2015, at 11:01 AM, Randall Gellens=20 >>> <rg+ietf@qti.qualcomm.com>=20 >>> wrote: >>> >>> Hi SLIMmers, >>> >>> Please let me know your preferred days and times for a meeting on >>> SLIM (the human language work) in Dallas. I'll then send out a >>> Doodle poll with the most promising slots. >>> >>> -- >>> Randall Gellens >>> Opinions are personal; facts are suspect; I speak for myself only >>> -------------- Randomly selected tag: --------------- >>> The whole aim of practical politics is to keep the populace alarmed >>> (and hence clamorous to be led to safety) by an endless series of >>> hobgoblins, most of them imaginary. >>> --H.L. Mencken >> >> _______________________________________________ >> SLIM mailing list >> SLIM@ietf.org >>=20 >> https://www.ietf.org/mailman/= listinfo/slim >> >> >> >> >> -- >> >> ----------------------------------------------------------------- >> Multiple Language Content Type Internet Draft: >>=20 >> http:/= /datatracker.ietf.org/doc/draft-tomkinson-slim-multilangcontent/ >> ----------------------------------------------------------------- >> >> >> >> _______________________________________________ >> 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: --------------- The mind of a bigot is like the pupil of the eye. The more light you shine on it, the more it contracts. --Oliver Wendell Holmes, Jr. From nobody Fri Mar 13 10:52:34 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E3EE1A0174 for ; Fri, 13 Mar 2015 10:52:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CgEdJRjo5v80 for ; Fri, 13 Mar 2015 10:52:30 -0700 (PDT) Received: from p3plwbeout03-05.prod.phx3.secureserver.net (p3plsmtp03-05-2.prod.phx3.secureserver.net [72.167.218.217]) by ietfa.amsl.com (Postfix) with ESMTP id D85D61A0024 for ; Fri, 13 Mar 2015 10:52:30 -0700 (PDT) Received: from localhost ([72.167.218.243]) by p3plwbeout03-05.prod.phx3.secureserver.net with bizsmtp id 35sW1q0045FgiYg015sWN6; Fri, 13 Mar 2015 10:52:30 -0700 X-SID: 35sW1q0045FgiYg01 Received: (qmail 24722 invoked by uid 99); 13 Mar 2015 17:52:30 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 208.51.143.189 User-Agent: Workspace Webmail 5.10.1 Message-Id: <20150313105228.665a7a7059d7ee80bb4d670165c8327d.bce2fa2bc6.wbe@email03.secureserver.net> From: "Doug Ewell" To: slim@ietf.org Date: Fri, 13 Mar 2015 10:52:28 -0700 Mime-Version: 1.0 Archived-At: Cc: Randall Gellens Subject: Re: [Slim] SLIM (human language) meet-up in Dallas X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 17:52:32 -0000 Randall Gellens wrote:=0A=0A> Please le= t me know your preferred days and times for a meeting on=0A> SLIM (the huma= n language work) in Dallas. I'll then send out a=0A> Doodle poll with the m= ost promising slots.=0A=0AIn keeping with recent discussions on the IETF li= st, please make sure=0Aany decisions reached at the face-to-face meeting ar= e reflected and=0Aconfirmed on the mailing list, for the benefit of those o= f us who can't=0Aphysically attend.=0A=0A--=0ADoug Ewell | http://ewellic.o= rg | Thornton, CO =F0=9F=87=BA=F0=9F=87=B8 =F0=9F=95=A6 From nobody Fri Mar 13 13:30:59 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 925A11A1B6D; Fri, 13 Mar 2015 13:30:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AO_5gicedD-H; Fri, 13 Mar 2015 13:30:55 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 5EEE41A6F2A; Fri, 13 Mar 2015 13:30:55 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t2DKUiD9058740 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Mar 2015 15:30:54 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] From: "Ben Campbell" To: slim@ietf.org Date: Fri, 13 Mar 2015 15:30:44 -0500 Message-ID: <0A4E9A96-56C9-4D15-81AE-5D8285654080@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9r5066) Archived-At: Cc: IESG Subject: [Slim] Comments on proposed SLIM charter X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 20:30:57 -0000 Hi, For the record, I support this work. But I have some concerns about the proposed charter at https://datatracker.ietf.org/doc/charter-ietf-slim . Apologies if this rehashes old discussions; I have only recently joined the mailing list (I did scan the archive, but likely missed things.) I don't find the charter text motivating the linkage between the mail problem and the real-time problem very convincing. I'm not saying it's wrong; just that it hasn't convinced me. The text suggests a single work group to reinforce commonality in the solutions. That seems backwards to me; I'd like to see more on why people think the problems benefit from a common solution. Do you think there will be mechanism in common, beyond the use of language tags? Do you see a common implementor community? A common protocol development community? I'd like to see something about why people don't think the real-time problem is at least partially solved by RFCs 3840 and 3841. If that's a forgone conclusion, the charter needs to clearly motivate it. The draft is slightly more helpful here in mentioning that 3840/3841 were considered but discarded, but that's not obvious from the proposed charter text. Part of this may be that I am not sure if this is looking at a call-routing problem (i.e. getting the call to an appropriate destination for a language) and/or a language negotiation problem (i.e. deciding what language you are going to use once the call is established. The first is mentioned, although the text about invoking translators, etc, might also imply the second. The charter should clearly describe the problem. If the idea is to finish the existing drafts, the charter should say that. Even so, the schedule seems optimistic, unless you expect those drafts to go to WGLC right after the charter is approved. I find paragraph 2 a bit hard to follow--it seems to be a single complex sentence. Thanks! Ben. From nobody Fri Mar 13 13:57:33 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C3871A8854 for ; Fri, 13 Mar 2015 13:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.587 X-Spam-Level: X-Spam-Status: No, score=-3.587 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable 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 WNz3rqw30ipE for ; Fri, 13 Mar 2015 13:57:30 -0700 (PDT) Received: from buckwheat.cc.columbia.edu (buckwheat.cc.columbia.edu [128.59.72.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8675E1A879E for ; Fri, 13 Mar 2015 13:57:30 -0700 (PDT) Received: from hazelnut (hazelnut.cc.columbia.edu [128.59.213.250]) by buckwheat.cc.columbia.edu (8.13.8/8.13.8) with ESMTP id t2DKth8I027732 for ; Fri, 13 Mar 2015 16:57:29 -0400 Received: from hazelnut (localhost.localdomain [127.0.0.1]) by hazelnut (Postfix) with ESMTP id 77B766D for ; Fri, 13 Mar 2015 16:57:29 -0400 (EDT) Received: from salak.cc.columbia.edu (salak.cc.columbia.edu [128.59.29.6]) by hazelnut (Postfix) with ESMTP id 189A77E for ; Fri, 13 Mar 2015 16:57:29 -0400 (EDT) Received: from mail-qc0-f176.google.com (mail-qc0-f176.google.com [209.85.216.176]) by salak.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id t2DKvSV3019156 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 13 Mar 2015 16:57:28 -0400 (EDT) Received: by qcrw7 with SMTP id w7so29678020qcr.8 for ; Fri, 13 Mar 2015 13:57:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=0vblxR74h2Kt46JMjHEEpb5At02Tn0jhh3tA5w360rM=; b=B/MSFblYd9K4v96m2kAC2sVGR7RD/LrJNVmHiit5Sp1XnIWK7PTfC3jGvTIGDIi9Lq 5dxjbGuSUAUgt77d+yaxxXlj2tNQmivSxsyibGNNTpazZYvJBydlqCTLNQ+w1V9ERRJp c1gGD/8mDkJDSidR1aPYL5c6Is2R+yoDLta2N3RHNcbz6pLT7Y8vWoAsB8wTkD813IVC L5BhR6E6PDcSe2jnassHHY1UsapDa0jGheSvVDMyT9FKDpVfV22uYf/dhmwof8TR/Nxn gjWOwQ7jWJRellVFIAAW870nrUcjlQnefwyQPQ972dvmlas3oN/hKF/B0gqEEdKJZNg5 CRig== X-Gm-Message-State: ALoCoQmQqVxUbBTc6eXkEmzbHdlxX/DtgorohECaX1ENxtqnBNVLWuAjeXIMSK2bgToqyaCzZQ5zvdSeLy+YSLx5rpbLn7NBrKgsJDLmJ1uf/OrifwJrsFTps+JKuCo6jM3tP57G0bgl X-Received: by 10.55.31.94 with SMTP id f91mr47400618qkf.94.1426280248631; Fri, 13 Mar 2015 13:57:28 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.55.31.94 with SMTP id f91mr47400602qkf.94.1426280248466; Fri, 13 Mar 2015 13:57:28 -0700 (PDT) Received: by 10.140.250.2 with HTTP; Fri, 13 Mar 2015 13:57:28 -0700 (PDT) In-Reply-To: <0A4E9A96-56C9-4D15-81AE-5D8285654080@nostrum.com> References: <0A4E9A96-56C9-4D15-81AE-5D8285654080@nostrum.com> Date: Fri, 13 Mar 2015 16:57:28 -0400 Message-ID: From: Henning G Schulzrinne To: Ben Campbell Content-Type: multipart/alternative; boundary=001a114792428f6e29051131bfb8 X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.6 Archived-At: Cc: slim@ietf.org, IESG Subject: Re: [Slim] Comments on proposed SLIM charter X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 20:57:32 -0000 --001a114792428f6e29051131bfb8 Content-Type: text/plain; charset=UTF-8 And, for the record, I continue to disagree with the current choice of discarding a 3840-like (not necessarily the protocol itself) approach. I consider this a call routing problem which is not appropriate for an SDP solution, just by standard SIP architectural layering. Henning On Fri, Mar 13, 2015 at 4:30 PM, Ben Campbell wrote: > Hi, > > For the record, I support this work. But I have some concerns about the > proposed charter at https://datatracker.ietf.org/doc/charter-ietf-slim . > Apologies if this rehashes old discussions; I have only recently joined the > mailing list (I did scan the archive, but likely missed things.) > > I don't find the charter text motivating the linkage between the mail > problem and the real-time problem very convincing. I'm not saying it's > wrong; just that it hasn't convinced me. > > The text suggests a single work group to reinforce commonality in the > solutions. That seems backwards to me; I'd like to see more on why people > think the problems benefit from a common solution. Do you think there will > be mechanism in common, beyond the use of language tags? Do you see a > common implementor community? A common protocol development community? > > I'd like to see something about why people don't think the real-time > problem is at least partially solved by RFCs 3840 and 3841. If that's a > forgone conclusion, the charter needs to clearly motivate it. The draft is > slightly more helpful here in mentioning that 3840/3841 were considered but > discarded, but that's not obvious from the proposed charter text. > > Part of this may be that I am not sure if this is looking at a > call-routing problem (i.e. getting the call to an appropriate destination > for a language) and/or a language negotiation problem (i.e. deciding what > language you are going to use once the call is established. The first is > mentioned, although the text about invoking translators, etc, might also > imply the second. The charter should clearly describe the problem. > > If the idea is to finish the existing drafts, the charter should say that. > Even so, > the schedule seems optimistic, unless you expect those drafts to go to > WGLC right after > the charter is approved. > > I find paragraph 2 a bit hard to follow--it seems to be a single complex > sentence. > > Thanks! > > Ben. > > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim > --001a114792428f6e29051131bfb8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
And, for the record, I continue to disagree with the curre= nt choice of discarding a 3840-like (not necessarily the protocol itself) a= pproach. I consider this a call routing problem which is not appropriate fo= r an SDP solution, just by standard SIP architectural layering.

Henning

On Fri, Mar 13, 2015 at 4:30 PM, Ben Campbell &= lt;ben@nostrum.com= > wrote:
Hi,

For the record, I support this work. But I have some concerns about the pro= posed charter at https://datatracker.ietf.org/doc/charter-ietf= -slim . Apologies if this rehashes old discussions; I have only recentl= y joined the mailing list (I did scan the archive, but likely missed things= .)

I don't find the charter text motivating the linkage between the mail p= roblem and the real-time problem very convincing. I'm not saying it'= ;s wrong; just that it hasn't convinced me.

The text suggests a single work group to reinforce commonality in the solut= ions. That seems backwards to me; I'd like to see more on why people th= ink the problems benefit from a common solution. Do you think there will be= mechanism in common, beyond the use of language tags? Do you see a common = implementor community? A common protocol development community?

I'd like to see something about why people don't think the real-tim= e problem is at least partially solved by RFCs 3840 and 3841. If that's= a forgone conclusion, the charter needs to clearly motivate it. The draft = is slightly more helpful here in mentioning that 3840/3841 were considered = but discarded, but that's not obvious from the proposed charter text.
Part of this may be that I am not sure if this is looking at a call-routing= problem (i.e. getting the call to an appropriate destination for a languag= e) and/or a language negotiation problem (i.e. deciding what language you a= re going to use once the call is established. The first is mentioned, altho= ugh the text about invoking translators, etc, might also imply the second. = The charter should clearly describe the problem.

If the idea is to finish the existing drafts, the charter should say that. = Even so,
the schedule seems optimistic, unless you expect those drafts to go to WGLC= right after
the charter is approved.

I find paragraph 2 a bit hard to follow--it seems to be a single complex se= ntence.

Thanks!

Ben.

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

--001a114792428f6e29051131bfb8-- From nobody Fri Mar 13 14:25:26 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 753961A8886 for ; Fri, 13 Mar 2015 14:25:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 lPYQmid_nOWy for ; Fri, 13 Mar 2015 14:25:22 -0700 (PDT) Received: from bin-vsp-out-01.atm.binero.net (vsp-authed01.binero.net [195.74.38.224]) (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 A0C851A8873 for ; Fri, 13 Mar 2015 14:25:21 -0700 (PDT) X-Halon-ID: 735f22a8-c9c7-11e4-8274-005056917a89 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.42] (unknown [77.53.231.174]) by bin-vsp-out-01.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Fri, 13 Mar 2015 22:25:19 +0100 (CET) Message-ID: <550355BB.8060907@omnitor.se> Date: Fri, 13 Mar 2015 22:25:15 +0100 From: =?windows-1252?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: slim@ietf.org References: <0A4E9A96-56C9-4D15-81AE-5D8285654080@nostrum.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060909080802020106090803" Archived-At: Subject: Re: [Slim] Comments on proposed SLIM charter X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 21:25:24 -0000 This is a multi-part message in MIME format. --------------060909080802020106090803 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Henning G Schulzrinne skrev den 2015-03-13 21:57: > And, for the record, I continue to disagree with the current choice of > discarding a 3840-like (not necessarily the protocol itself) approach. > I consider this a call routing problem which is not appropriate for an > SDP solution, just by standard SIP architectural layering. I agree. When I made the user to user call use case, I tried to make it implementable with the language indications in SDP, but it really felt like an unreliable hack. Either asking the called terminal to make the analysis and invoke any needed translation, or having an ACD to request OPTIONS to the destination and then peek into SDP to find out if translation is needed. No one of these solutions are pleasant. The draft also talks about policy-based routing as a solution. The work with policy based routing has not progressed as hoped at least as far as I know. It seems to be defined only for checking if one destination is open and if not select a replacement. Not any kind of "ACD" based on media capabilities and similar factors. One problem we had with a RFC 3840 /3841 based method was that we did not know any way to differentiate between written language and spoken language tags. But we have now learned that that should be doable ( still to be clearly specified ) Servers are already supporting storage and comparison and routing based on RFC 3840 /3841 so it is very tempting to use that mechanism or an extension of it. Gunnar > > Henning > > On Fri, Mar 13, 2015 at 4:30 PM, Ben Campbell > wrote: > > Hi, > > For the record, I support this work. But I have some concerns > about the proposed charter at > https://datatracker.ietf.org/doc/charter-ietf-slim . Apologies if > this rehashes old discussions; I have only recently joined the > mailing list (I did scan the archive, but likely missed things.) > > I don't find the charter text motivating the linkage between the > mail problem and the real-time problem very convincing. I'm not > saying it's wrong; just that it hasn't convinced me. > > The text suggests a single work group to reinforce commonality in > the solutions. That seems backwards to me; I'd like to see more on > why people think the problems benefit from a common solution. Do > you think there will be mechanism in common, beyond the use of > language tags? Do you see a common implementor community? A common > protocol development community? > > I'd like to see something about why people don't think the > real-time problem is at least partially solved by RFCs 3840 and > 3841. If that's a forgone conclusion, the charter needs to clearly > motivate it. The draft is slightly more helpful here in mentioning > that 3840/3841 were considered but discarded, but that's not > obvious from the proposed charter text. > > Part of this may be that I am not sure if this is looking at a > call-routing problem (i.e. getting the call to an appropriate > destination for a language) and/or a language negotiation problem > (i.e. deciding what language you are going to use once the call is > established. The first is mentioned, although the text about > invoking translators, etc, might also imply the second. The > charter should clearly describe the problem. > > If the idea is to finish the existing drafts, the charter should > say that. Even so, > the schedule seems optimistic, unless you expect those drafts to > go to WGLC right after > the charter is approved. > > I find paragraph 2 a bit hard to follow--it seems to be a single > complex sentence. > > Thanks! > > Ben. > > _______________________________________________ > 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 --------------060909080802020106090803 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Henning G Schulzrinne skrev den 2015-03-13 21:57:
And, for the record, I continue to disagree with the current choice of discarding a 3840-like (not necessarily the protocol itself) approach. I consider this a call routing problem which is not appropriate for an SDP solution, just by standard SIP architectural layering.
I agree.
When I made the user to user call use case, I tried to make it implementable with the language indications in SDP, but it really felt like an unreliable hack.
Either asking the called terminal to make the analysis and invoke any needed translation, or having an ACD to request OPTIONS to the destination and then peek into SDP to find out if translation is needed. No one of these solutions are pleasant.

The draft also talks about policy-based routing as a solution. The work with policy based routing has not progressed as hoped at least as far as I know. It seems to be defined only for checking if one destination is open and if not select a replacement. Not any kind of "ACD" based on media capabilities and similar factors.

One problem we had with a RFC 3840 /3841 based method was that we did not know any way to differentiate between written language and spoken language tags. But we have now learned that that should be doable ( still to be clearly specified )

Servers are already supporting storage and comparison and routing based on RFC 3840 /3841  so it is very tempting to use that mechanism or an extension of it.

Gunnar



Henning

On Fri, Mar 13, 2015 at 4:30 PM, Ben Campbell <ben@nostrum.com> wrote:
Hi,

For the record, I support this work. But I have some concerns about the proposed charter at https://datatracker.ietf.org/doc/charter-ietf-slim . Apologies if this rehashes old discussions; I have only recently joined the mailing list (I did scan the archive, but likely missed things.)

I don't find the charter text motivating the linkage between the mail problem and the real-time problem very convincing. I'm not saying it's wrong; just that it hasn't convinced me.

The text suggests a single work group to reinforce commonality in the solutions. That seems backwards to me; I'd like to see more on why people think the problems benefit from a common solution. Do you think there will be mechanism in common, beyond the use of language tags? Do you see a common implementor community? A common protocol development community?

I'd like to see something about why people don't think the real-time problem is at least partially solved by RFCs 3840 and 3841. If that's a forgone conclusion, the charter needs to clearly motivate it. The draft is slightly more helpful here in mentioning that 3840/3841 were considered but discarded, but that's not obvious from the proposed charter text.

Part of this may be that I am not sure if this is looking at a call-routing problem (i.e. getting the call to an appropriate destination for a language) and/or a language negotiation problem (i.e. deciding what language you are going to use once the call is established. The first is mentioned, although the text about invoking translators, etc, might also imply the second. The charter should clearly describe the problem.

If the idea is to finish the existing drafts, the charter should say that. Even so,
the schedule seems optimistic, unless you expect those drafts to go to WGLC right after
the charter is approved.

I find paragraph 2 a bit hard to follow--it seems to be a single complex sentence.

Thanks!

Ben.

_______________________________________________
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
--------------060909080802020106090803-- From nobody Fri Mar 13 14:40:30 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DED3B1A8911 for ; Fri, 13 Mar 2015 14:40:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 kJUS4S7_3ZbQ for ; Fri, 13 Mar 2015 14:40:26 -0700 (PDT) Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:37]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CD5B1A711A for ; Fri, 13 Mar 2015 14:40:26 -0700 (PDT) Received: from resomta-ch2-04v.sys.comcast.net ([69.252.207.100]) by resqmta-ch2-05v.sys.comcast.net with comcast id 39gN1q0042AWL2D019gRgo; Fri, 13 Mar 2015 21:40:25 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-04v.sys.comcast.net with comcast id 39gR1q0073Ge9ey019gRx2; Fri, 13 Mar 2015 21:40:25 +0000 Message-ID: <55035948.2070404@alum.mit.edu> Date: Fri, 13 Mar 2015 17:40:24 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: slim@ietf.org References: <0A4E9A96-56C9-4D15-81AE-5D8285654080@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1426282825; bh=w0pAvj6hBewYjBpi9rmbV9IIv5wECfRXsUKVQdVj5k0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=PZp/6ciKcn/iL2babxF2GU1vkCjCfdJdS2+8Dp61eG2MN8bnW83W075Wbz3cZanEc o2pXAey0DIIfwA+6SmRL/ycChiWSEQamKwpvFyiBGE9KP613xBsBsuycu8XJ5RXn/p QfDpWTFfOzL71LoQtoCzxXHbXPnTOXXVHomOgPu3TM8GYTRHVTTAO0cdppciX+JVsp o1p0qzu4HKzqh90WJuilfrjDkMEJmtaf/Kt403B6SChfpEp2eBdAQyTMws1MoevqdF yl36gdhTpGoU7ijBNdNWEL18UUwx1vOAhoEYK7NKmh3MoTEqHw3jB3RcShTbxymrIP EVo/w3Hng5dyA== Archived-At: Subject: Re: [Slim] Comments on proposed SLIM charter X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 21:40:28 -0000 On 3/13/15 4:57 PM, Henning G Schulzrinne wrote: > And, for the record, I continue to disagree with the current choice of > discarding a 3840-like (not necessarily the protocol itself) approach. I > consider this a call routing problem which is not appropriate for an SDP > solution, just by standard SIP architectural layering. In principle I agree with you. But to make it solely into a call routing problem ignores the need to consider capabilities of both the caller and the callee, and then if they don't match, do some extra stuff to bring a "transcoder" into the session. That *could* be viewed as a call routing problem if it is always a "receiver makes it right" solution. For that, an intermediary at the callee's end (the callee's home proxy) would need to know the capabilities of the callee and the callee's devices before routing to a callee device, and pull in a transcoder. But practically speaking we can't always count on the callee to take responsibility for this. The caller, or an agent for the caller, can do it, but must know the capabilities of the callee before doing so. I guess the caller (or a B2BUA intermediary on behalf of the caller) can do it after the call is accepted, based callee caps in the callee's Contact header. But it isn't really quite a conventional call routing case then. Thanks, Paul > Henning > > On Fri, Mar 13, 2015 at 4:30 PM, Ben Campbell > wrote: > > Hi, > > For the record, I support this work. But I have some concerns about > the proposed charter at > https://datatracker.ietf.org/__doc/charter-ietf-slim > . Apologies if > this rehashes old discussions; I have only recently joined the > mailing list (I did scan the archive, but likely missed things.) > > I don't find the charter text motivating the linkage between the > mail problem and the real-time problem very convincing. I'm not > saying it's wrong; just that it hasn't convinced me. > > The text suggests a single work group to reinforce commonality in > the solutions. That seems backwards to me; I'd like to see more on > why people think the problems benefit from a common solution. Do you > think there will be mechanism in common, beyond the use of language > tags? Do you see a common implementor community? A common protocol > development community? > > I'd like to see something about why people don't think the real-time > problem is at least partially solved by RFCs 3840 and 3841. If > that's a forgone conclusion, the charter needs to clearly motivate > it. The draft is slightly more helpful here in mentioning that > 3840/3841 were considered but discarded, but that's not obvious from > the proposed charter text. > > Part of this may be that I am not sure if this is looking at a > call-routing problem (i.e. getting the call to an appropriate > destination for a language) and/or a language negotiation problem > (i.e. deciding what language you are going to use once the call is > established. The first is mentioned, although the text about > invoking translators, etc, might also imply the second. The charter > should clearly describe the problem. > > If the idea is to finish the existing drafts, the charter should say > that. Even so, > the schedule seems optimistic, unless you expect those drafts to go > to WGLC right after > the charter is approved. > > I find paragraph 2 a bit hard to follow--it seems to be a single > complex sentence. > > Thanks! > > Ben. > > _________________________________________________ > 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 Fri Mar 13 15:20:29 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 652EC1A8984 for ; Fri, 13 Mar 2015 15:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.587 X-Spam-Level: X-Spam-Status: No, score=-3.587 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J9-JaohmU3Ei for ; Fri, 13 Mar 2015 15:20:23 -0700 (PDT) Received: from buckwheat.cc.columbia.edu (buckwheat.cc.columbia.edu [128.59.72.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E9F21A1E0B for ; Fri, 13 Mar 2015 15:20:22 -0700 (PDT) Received: from hazelnut (hazelnut.cc.columbia.edu [128.59.213.250]) by buckwheat.cc.columbia.edu (8.13.8/8.13.8) with ESMTP id t2DMHROq025045 for ; Fri, 13 Mar 2015 18:20:22 -0400 Received: from hazelnut (localhost.localdomain [127.0.0.1]) by hazelnut (Postfix) with ESMTP id CCF0D6D for ; Fri, 13 Mar 2015 18:20:21 -0400 (EDT) Received: from rambutan.cc.columbia.edu (rambutan.cc.columbia.edu [128.59.29.5]) by hazelnut (Postfix) with ESMTP id 866C280 for ; Fri, 13 Mar 2015 18:20:21 -0400 (EDT) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by rambutan.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id t2DMKKqQ011118 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 13 Mar 2015 18:20:21 -0400 (EDT) Received: by qcbkw5 with SMTP id kw5so323188qcb.2 for ; Fri, 13 Mar 2015 15:20:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=8VEyyMpgI5gdJNzjRCZTRGg75Cb0ZP3dS9grA0KDF2c=; b=VmGZPZSylKrrL/zMxYre5mkEx+46iguV0EJK8MXSBoEtjLW8jw4/OEqQ51+9YtUtV2 SMkPSDjjEWcVO0nWr7bYcI/X481P9FS2MSgydwHyATLYYpsOGFMO9teUYfZIvjqO6NEM 8V1MuD5Uq6iz6tkhsawnYR5UfMOkxWjq3tsttP02aEva07wbl9C1rw5wBU/fizyZ8TiY u5kcEh2a7QTZH/O80Qo+GYWBaOanMTvlyHeO17MRuIHGmyIe00no5YEZsJBIBwLVTrFo xhnNJFZ3Pye7SkIxqPxuDP1+SipYRZHxH+B4KJW/v8EkCAzfU5GUdDfd3xqaSgppIOaF tMiQ== X-Gm-Message-State: ALoCoQnznKgarODTv3Xifrb64v5IhKp5HBCttnXwFe8Rut/cO+tkwW3jqCGJvUpo+GC/f7qnySUujRdBu+E+IjBDayS309DmQfbJO+GpH5KfiX9+TLJZ1QC1L7dflb6lvoPagDJdIuk7 X-Received: by 10.55.55.81 with SMTP id e78mr99739437qka.107.1426285220945; Fri, 13 Mar 2015 15:20:20 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.55.55.81 with SMTP id e78mr99739428qka.107.1426285220841; Fri, 13 Mar 2015 15:20:20 -0700 (PDT) Received: by 10.140.250.2 with HTTP; Fri, 13 Mar 2015 15:20:20 -0700 (PDT) In-Reply-To: <55035948.2070404@alum.mit.edu> References: <0A4E9A96-56C9-4D15-81AE-5D8285654080@nostrum.com> <55035948.2070404@alum.mit.edu> Date: Fri, 13 Mar 2015 18:20:20 -0400 Message-ID: From: Henning G Schulzrinne To: Paul Kyzivat Content-Type: multipart/alternative; boundary=001a11490ac8efdf0b051132e73f X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.5 Archived-At: Cc: slim@ietf.org Subject: Re: [Slim] Comments on proposed SLIM charter X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 22:20:27 -0000 --001a11490ac8efdf0b051132e73f Content-Type: text/plain; charset=UTF-8 Good point. To reduce the complexity, this would seem to have three phases: (1) Discovery - The caller tells the other side all it can do, with our without intermediate "help" (human or machine). Probably an OPTIONS request, but maybe something else. (2) Response - The callee provides its possible options from that list, maybe preference-ordered, or a "sorry, I cannot do this, Dave". (3) Call - Assuming that there's a meeting of the minds, the caller tries again, with its preferred approach. In general, having something that doesn't require keeping state across phases would seem most robust. Henning On Fri, Mar 13, 2015 at 5:40 PM, Paul Kyzivat wrote: > On 3/13/15 4:57 PM, Henning G Schulzrinne wrote: > >> And, for the record, I continue to disagree with the current choice of >> discarding a 3840-like (not necessarily the protocol itself) approach. I >> consider this a call routing problem which is not appropriate for an SDP >> solution, just by standard SIP architectural layering. >> > > In principle I agree with you. But to make it solely into a call routing > problem ignores the need to consider capabilities of both the caller and > the callee, and then if they don't match, do some extra stuff to bring a > "transcoder" into the session. > > That *could* be viewed as a call routing problem if it is always a > "receiver makes it right" solution. For that, an intermediary at the > callee's end (the callee's home proxy) would need to know the capabilities > of the callee and the callee's devices before routing to a callee device, > and pull in a transcoder. > > But practically speaking we can't always count on the callee to take > responsibility for this. The caller, or an agent for the caller, can do it, > but must know the capabilities of the callee before doing so. I guess the > caller (or a B2BUA intermediary on behalf of the caller) can do it after > the call is accepted, based callee caps in the callee's Contact header. But > it isn't really quite a conventional call routing case then. > > Thanks, > Paul > > Henning >> >> On Fri, Mar 13, 2015 at 4:30 PM, Ben Campbell > > wrote: >> >> Hi, >> >> For the record, I support this work. But I have some concerns about >> the proposed charter at >> https://datatracker.ietf.org/__doc/charter-ietf-slim >> . Apologies if >> this rehashes old discussions; I have only recently joined the >> mailing list (I did scan the archive, but likely missed things.) >> >> I don't find the charter text motivating the linkage between the >> mail problem and the real-time problem very convincing. I'm not >> saying it's wrong; just that it hasn't convinced me. >> >> The text suggests a single work group to reinforce commonality in >> the solutions. That seems backwards to me; I'd like to see more on >> why people think the problems benefit from a common solution. Do you >> think there will be mechanism in common, beyond the use of language >> tags? Do you see a common implementor community? A common protocol >> development community? >> >> I'd like to see something about why people don't think the real-time >> problem is at least partially solved by RFCs 3840 and 3841. If >> that's a forgone conclusion, the charter needs to clearly motivate >> it. The draft is slightly more helpful here in mentioning that >> 3840/3841 were considered but discarded, but that's not obvious from >> the proposed charter text. >> >> Part of this may be that I am not sure if this is looking at a >> call-routing problem (i.e. getting the call to an appropriate >> destination for a language) and/or a language negotiation problem >> (i.e. deciding what language you are going to use once the call is >> established. The first is mentioned, although the text about >> invoking translators, etc, might also imply the second. The charter >> should clearly describe the problem. >> >> If the idea is to finish the existing drafts, the charter should say >> that. Even so, >> the schedule seems optimistic, unless you expect those drafts to go >> to WGLC right after >> the charter is approved. >> >> I find paragraph 2 a bit hard to follow--it seems to be a single >> complex sentence. >> >> Thanks! >> >> Ben. >> >> _________________________________________________ >> 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 > --001a11490ac8efdf0b051132e73f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Good point. To reduce the complexity, this would seem to h= ave three phases:

(1) Discovery - The caller tells the o= ther side all it can do, with our without intermediate "help" (hu= man or machine). Probably an OPTIONS request, but maybe something else.

(2) Response - The callee provides its possible optio= ns from that list, maybe preference-ordered, or a "sorry, I cannot do = this, Dave".

(3) Call - Assuming that there&#= 39;s a meeting of the minds, the caller tries again, with its preferred app= roach.

In general, having something that doesn'= ;t require keeping state across phases would seem most robust.
Henning

On Fri, Mar 13, 2015 at 5:40 PM, Paul Kyzivat <pkyziv= at@alum.mit.edu> wrote:
On = 3/13/15 4:57 PM, Henning G Schulzrinne wrote:
And, for the record, I continue to disagree with the current choice of
discarding a 3840-like (not necessarily the protocol itself) approach. I consider this a call routing problem which is not appropriate for an SDP solution, just by standard SIP architectural layering.

In principle I agree with you. But to make it solely into a call routing pr= oblem ignores the need to consider capabilities of both the caller and the = callee, and then if they don't match, do some extra stuff to bring a &q= uot;transcoder" into the session.

That *could* be viewed as a call routing problem if it is always a "re= ceiver makes it right" solution. For that, an intermediary at the call= ee's end (the callee's home proxy) would need to know the capabilit= ies of the callee and the callee's devices before routing to a callee d= evice, and pull in a transcoder.

But practically speaking we can't always count on the callee to take re= sponsibility for this. The caller, or an agent for the caller, can do it, b= ut must know the capabilities of the callee before doing so. I guess the ca= ller (or a B2BUA intermediary on behalf of the caller) can do it after the = call is accepted, based callee caps in the callee's Contact header. But= it isn't really quite a conventional call routing case then.

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

Henning

On Fri, Mar 13, 2015 at 4:30 PM, Ben Campbell <ben@nostrum.com
<mailto:ben@nostrum= .com>> wrote:

=C2=A0 =C2=A0 Hi,

=C2=A0 =C2=A0 For the record, I support this work. But I have some concerns= about
=C2=A0 =C2=A0 the proposed charter at
=C2=A0 =C2=A0 https://datatracker.ietf.org/__doc/charter-iet= f-slim
=C2=A0 =C2=A0 <https://datatracker.ietf.org/doc/charter-iet= f-slim> . Apologies if
=C2=A0 =C2=A0 this rehashes old discussions; I have only recently joined th= e
=C2=A0 =C2=A0 mailing list (I did scan the archive, but likely missed thing= s.)

=C2=A0 =C2=A0 I don't find the charter text motivating the linkage betw= een the
=C2=A0 =C2=A0 mail problem and the real-time problem very convincing. I'= ;m not
=C2=A0 =C2=A0 saying it's wrong; just that it hasn't convinced me.<= br>
=C2=A0 =C2=A0 The text suggests a single work group to reinforce commonalit= y in
=C2=A0 =C2=A0 the solutions. That seems backwards to me; I'd like to se= e more on
=C2=A0 =C2=A0 why people think the problems benefit from a common solution.= Do you
=C2=A0 =C2=A0 think there will be mechanism in common, beyond the use of la= nguage
=C2=A0 =C2=A0 tags? Do you see a common implementor community? A common pro= tocol
=C2=A0 =C2=A0 development community?

=C2=A0 =C2=A0 I'd like to see something about why people don't thin= k the real-time
=C2=A0 =C2=A0 problem is at least partially solved by RFCs 3840 and 3841. I= f
=C2=A0 =C2=A0 that's a forgone conclusion, the charter needs to clearly= motivate
=C2=A0 =C2=A0 it. The draft is slightly more helpful here in mentioning tha= t
=C2=A0 =C2=A0 3840/3841 were considered but discarded, but that's not o= bvious from
=C2=A0 =C2=A0 the proposed charter text.

=C2=A0 =C2=A0 Part of this may be that I am not sure if this is looking at = a
=C2=A0 =C2=A0 call-routing problem (i.e. getting the call to an appropriate=
=C2=A0 =C2=A0 destination for a language) and/or a language negotiation pro= blem
=C2=A0 =C2=A0 (i.e. deciding what language you are going to use once the ca= ll is
=C2=A0 =C2=A0 established. The first is mentioned, although the text about<= br> =C2=A0 =C2=A0 invoking translators, etc, might also imply the second. The c= harter
=C2=A0 =C2=A0 should clearly describe the problem.

=C2=A0 =C2=A0 If the idea is to finish the existing drafts, the charter sho= uld say
=C2=A0 =C2=A0 that. Even so,
=C2=A0 =C2=A0 the schedule seems optimistic, unless you expect those drafts= to go
=C2=A0 =C2=A0 to WGLC right after
=C2=A0 =C2=A0 the charter is approved.

=C2=A0 =C2=A0 I find paragraph 2 a bit hard to follow--it seems to be a sin= gle
=C2=A0 =C2=A0 complex sentence.

=C2=A0 =C2=A0 Thanks!

=C2=A0 =C2=A0 Ben.

=C2=A0 =C2=A0 _________________________________________________
=C2=A0 =C2=A0 SLIM mailing list
=C2=A0 =C2=A0 SLIM@ietf.= org <mailto:SLIM@= ietf.org>
=C2=A0 =C2=A0 https://www.ietf.org/mailman/__listinfo/slim
=C2=A0 =C2=A0 <https://www.ietf.org/mailman/listinfo/slim>



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


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

--001a11490ac8efdf0b051132e73f-- From nobody Sat Mar 14 00:17:06 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93B201AC417 for ; Sat, 14 Mar 2015 00:17:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 RUIDIjpXlInz for ; Sat, 14 Mar 2015 00:17:01 -0700 (PDT) Received: from bin-vsp-out-04.atm.binero.net (vsp-unauthed01.binero.net [195.74.38.225]) (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 9DDEB1AC412 for ; Sat, 14 Mar 2015 00:17:00 -0700 (PDT) X-Halon-ID: 1a3594ab-ca1a-11e4-ace6-005056917c0c Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.42] (unknown [77.53.231.174]) by bin-vsp-out-04.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Sat, 14 Mar 2015 08:16:58 +0100 (CET) Message-ID: <5503E065.5030602@omnitor.se> Date: Sat, 14 Mar 2015 08:16:53 +0100 From: =?windows-1252?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: slim@ietf.org References: <0A4E9A96-56C9-4D15-81AE-5D8285654080@nostrum.com> <55035948.2070404@alum.mit.edu> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050104050101000406070005" Archived-At: Subject: Re: [Slim] Comments on proposed SLIM charter X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2015 07:17:04 -0000 This is a multi-part message in MIME format. --------------050104050101000406070005 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Yes, it is good to have a view of how a possible routing and adding of extra resources can be made. We have two goals. 1. Decide which of a number of available callees we route the call to that gives the best match. 2. Decide if additional resources are needed in the call to interpret between the endpoints. A mechanism for pulling in extra resources for interpretation when needed can be located at the caller end, in the middle or at the called end. In a call-center type application, it is possible that the SLIM mechanism for conveying information about language and modality capabilities and preferences is used just from the caller to the ACD. The custom ACD then looks with other than SIP/SDP mechanisms at available call-taker profiles and selects the best match for whom to send the call to. That type of routing can be based on information in any part of the INVITE. It is when we want to do more automatic selection and routing with SIP based mechanisms that we see that we need to either store the capability information from registration or fetch it before the decision is made. RFC 3840/3841 information is already stored in the sip server from registration time and there is a selection and routing mechanism specified. For an SDP based mechanism, I can imagine using OPTIONS to all possible callees at call time and comparing the results using a new specified mechanism or being left for the implementor. The policy-based routing that is sometimes talked about in relation to emergency calling could include such mechanisms and be used also outside the emergency service scope. Having a box in the middle to take decision on including a third party in a call for translation can be made by having the translation services being included among the range of possible callees with a URI-list including the translation service and the original destination callee. The result when the best match is found to be a translation service is then that a multi-party call is set up. This works if it is the callees who has the agreement with the translation service to invoke them when needed. But how can it be handled if it is the caller who has the agreement? A couple of comments below: Henning G Schulzrinne skrev den 2015-03-13 23:20: > Good point. To reduce the complexity, this would seem to have three > phases: > > (1) Discovery - The caller tells the other side all it can do, with > our without intermediate "help" (human or machine). Probably an > OPTIONS request, but maybe something else. Right, but what is the response on an OPTIONS request to a call center? > > (2) Response - The callee provides its possible options from that > list, maybe preference-ordered, or a "sorry, I cannot do this, Dave". > > (3) Call - Assuming that there's a meeting of the minds, the caller > tries again, with its preferred approach. > > In general, having something that doesn't require keeping state across > phases would seem most robust. Yes, but cause a lot of traffic for interrogation of capabilities in the call center case(?) > > Henning > > On Fri, Mar 13, 2015 at 5:40 PM, Paul Kyzivat > wrote: > > On 3/13/15 4:57 PM, Henning G Schulzrinne wrote: > > And, for the record, I continue to disagree with the current > choice of > discarding a 3840-like (not necessarily the protocol itself) > approach. I > consider this a call routing problem which is not appropriate > for an SDP > solution, just by standard SIP architectural layering. > > > In principle I agree with you. But to make it solely into a call > routing problem ignores the need to consider capabilities of both > the caller and the callee, and then if they don't match, do some > extra stuff to bring a "transcoder" into the session. > > That *could* be viewed as a call routing problem if it is always a > "receiver makes it right" solution. For that, an intermediary at > the callee's end (the callee's home proxy) would need to know the > capabilities of the callee and the callee's devices before routing > to a callee device, and pull in a transcoder. > And that is what is done at registration time with RFC 3841. > > > But practically speaking we can't always count on the callee to > take responsibility for this. The caller, or an agent for the > caller, can do it, but must know the capabilities of the callee > before doing so. I guess the caller (or a B2BUA intermediary on > behalf of the caller) can do it after the call is accepted, based > callee caps in the callee's Contact header. But it isn't really > quite a conventional call routing case then. > > Thanks, > Paul > > Henning > > On Fri, Mar 13, 2015 at 4:30 PM, Ben Campbell > >> wrote: > > Hi, > > For the record, I support this work. But I have some > concerns about > the proposed charter at > https://datatracker.ietf.org/__doc/charter-ietf-slim > . > Apologies if > this rehashes old discussions; I have only recently joined the > mailing list (I did scan the archive, but likely missed > things.) > > I don't find the charter text motivating the linkage > between the > mail problem and the real-time problem very convincing. > I'm not > saying it's wrong; just that it hasn't convinced me. > > The text suggests a single work group to reinforce > commonality in > the solutions. That seems backwards to me; I'd like to see > more on > why people think the problems benefit from a common > solution. Do you > think there will be mechanism in common, beyond the use of > language > tags? Do you see a common implementor community? A common > protocol > development community? > > I'd like to see something about why people don't think the > real-time > problem is at least partially solved by RFCs 3840 and 3841. If > that's a forgone conclusion, the charter needs to clearly > motivate > it. The draft is slightly more helpful here in mentioning that > 3840/3841 were considered but discarded, but that's not > obvious from > the proposed charter text. > > Part of this may be that I am not sure if this is looking at a > call-routing problem (i.e. getting the call to an appropriate > destination for a language) and/or a language negotiation > problem > (i.e. deciding what language you are going to use once the > call is > established. The first is mentioned, although the text about > invoking translators, etc, might also imply the second. > The charter > should clearly describe the problem. > > If the idea is to finish the existing drafts, the charter > should say > that. Even so, > the schedule seems optimistic, unless you expect those > drafts to go > to WGLC right after > the charter is approved. > > I find paragraph 2 a bit hard to follow--it seems to be a > single > complex sentence. > > Thanks! > > Ben. > > _________________________________________________ > 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 > > > > > _______________________________________________ > 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 --------------050104050101000406070005 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Yes, it is good to have a view of how a possible routing and adding of extra resources can be made.

We have two goals.
1. Decide which of a number of available callees we route the call to that gives the best match.

2. Decide if additional resources are needed in the call to interpret between the endpoints.

A mechanism for pulling in extra resources for interpretation when needed can be located at the caller end, in the middle or at the called end.

In a call-center type application, it is possible that the SLIM mechanism for conveying information about language and modality capabilities and preferences is used just from the caller to the ACD. The custom ACD then looks with other than SIP/SDP mechanisms at available call-taker profiles and selects the best match for whom to send the call to. That type of routing can be based on information in any part of the INVITE.

It is when we want to do more automatic selection and routing with SIP based mechanisms that we see that we need to either store the capability information from registration or fetch it before the decision is made.

RFC 3840/3841 information is already stored in the sip server from registration time and there is a selection and routing mechanism specified.
For an SDP based mechanism, I can imagine using OPTIONS to all possible callees at call time and comparing the results using a new specified mechanism or being left for the implementor. The policy-based routing that is sometimes talked about in relation to emergency calling could include such mechanisms and be used also outside the emergency service scope.

Having a box in the middle to take decision on including a third party in a call for translation can be made by having the translation services being included among the range of possible callees with a URI-list including the translation service and the original destination callee. The result when the best match is found to be a translation service is then that a multi-party call is set up. 

This works if it is the callees who has the agreement with the translation service to invoke them when needed. But how can it be handled if it is the caller who has the agreement?

A couple of comments below:
Henning G Schulzrinne skrev den 2015-03-13 23:20:
Good point. To reduce the complexity, this would seem to have three phases:

(1) Discovery - The caller tells the other side all it can do, with our without intermediate "help" (human or machine). Probably an OPTIONS request, but maybe something else.
Right, but what is the response on an OPTIONS request to a call center?

(2) Response - The callee provides its possible options from that list, maybe preference-ordered, or a "sorry, I cannot do this, Dave".

(3) Call - Assuming that there's a meeting of the minds, the caller tries again, with its preferred approach.

In general, having something that doesn't require keeping state across phases would seem most robust.
Yes, but cause a lot of traffic for interrogation of capabilities in the call center case(?)

Henning

On Fri, Mar 13, 2015 at 5:40 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
On 3/13/15 4:57 PM, Henning G Schulzrinne wrote:
And, for the record, I continue to disagree with the current choice of
discarding a 3840-like (not necessarily the protocol itself) approach. I
consider this a call routing problem which is not appropriate for an SDP
solution, just by standard SIP architectural layering.

In principle I agree with you. But to make it solely into a call routing problem ignores the need to consider capabilities of both the caller and the callee, and then if they don't match, do some extra stuff to bring a "transcoder" into the session.

That *could* be viewed as a call routing problem if it is always a "receiver makes it right" solution. For that, an intermediary at the callee's end (the callee's home proxy) would need to know the capabilities of the callee and the callee's devices before routing to a callee device, and pull in a transcoder.
And that is what is done at registration time with RFC 3841.

But practically speaking we can't always count on the callee to take responsibility for this. The caller, or an agent for the caller, can do it, but must know the capabilities of the callee before doing so. I guess the caller (or a B2BUA intermediary on behalf of the caller) can do it after the call is accepted, based callee caps in the callee's Contact header. But it isn't really quite a conventional call routing case then.

        Thanks,
        Paul

Henning

On Fri, Mar 13, 2015 at 4:30 PM, Ben Campbell <ben@nostrum.com
<mailto:ben@nostrum.com>> wrote:

    Hi,

    For the record, I support this work. But I have some concerns about
    the proposed charter at
    https://datatracker.ietf.org/__doc/charter-ietf-slim
    <https://datatracker.ietf.org/doc/charter-ietf-slim> . Apologies if
    this rehashes old discussions; I have only recently joined the
    mailing list (I did scan the archive, but likely missed things.)

    I don't find the charter text motivating the linkage between the
    mail problem and the real-time problem very convincing. I'm not
    saying it's wrong; just that it hasn't convinced me.

    The text suggests a single work group to reinforce commonality in
    the solutions. That seems backwards to me; I'd like to see more on
    why people think the problems benefit from a common solution. Do you
    think there will be mechanism in common, beyond the use of language
    tags? Do you see a common implementor community? A common protocol
    development community?

    I'd like to see something about why people don't think the real-time
    problem is at least partially solved by RFCs 3840 and 3841. If
    that's a forgone conclusion, the charter needs to clearly motivate
    it. The draft is slightly more helpful here in mentioning that
    3840/3841 were considered but discarded, but that's not obvious from
    the proposed charter text.

    Part of this may be that I am not sure if this is looking at a
    call-routing problem (i.e. getting the call to an appropriate
    destination for a language) and/or a language negotiation problem
    (i.e. deciding what language you are going to use once the call is
    established. The first is mentioned, although the text about
    invoking translators, etc, might also imply the second. The charter
    should clearly describe the problem.

    If the idea is to finish the existing drafts, the charter should say
    that. Even so,
    the schedule seems optimistic, unless you expect those drafts to go
    to WGLC right after
    the charter is approved.

    I find paragraph 2 a bit hard to follow--it seems to be a single
    complex sentence.

    Thanks!

    Ben.

    _________________________________________________
    SLIM mailing list
    SLIM@ietf.org <mailto:SLIM@ietf.org>
    https://www.ietf.org/mailman/__listinfo/slim
    <https://www.ietf.org/mailman/listinfo/slim>




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


_______________________________________________
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
--------------050104050101000406070005-- From nobody Sat Mar 14 15:18:32 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B39EF1A0275 for ; Sat, 14 Mar 2015 15:18:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.288 X-Spam-Level: X-Spam-Status: No, score=-3.288 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ISEyzv2kPctZ for ; Sat, 14 Mar 2015 15:18:28 -0700 (PDT) Received: from millet.cc.columbia.edu (millet.cc.columbia.edu [128.59.72.250]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4A251A017A for ; Sat, 14 Mar 2015 15:18:27 -0700 (PDT) Received: from hazelnut (hazelnut.cc.columbia.edu [128.59.213.250]) by millet.cc.columbia.edu (8.13.8/8.13.8) with ESMTP id t2EMI2oY028971 for ; Sat, 14 Mar 2015 18:18:26 -0400 Received: from hazelnut (localhost.localdomain [127.0.0.1]) by hazelnut (Postfix) with ESMTP id BA2C16D for ; Sat, 14 Mar 2015 18:18:26 -0400 (EDT) Received: from rambutan.cc.columbia.edu (rambutan.cc.columbia.edu [128.59.29.5]) by hazelnut (Postfix) with ESMTP id 83FAF6D for ; Sat, 14 Mar 2015 18:18:26 -0400 (EDT) Received: from mail-qg0-f45.google.com (mail-qg0-f45.google.com [209.85.192.45]) by rambutan.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id t2EMIQu3017999 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sat, 14 Mar 2015 18:18:26 -0400 (EDT) Received: by qgfa8 with SMTP id a8so13600157qgf.0 for ; Sat, 14 Mar 2015 15:18:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=m8lErjfmk/IamT0VvOpwVLuZHL/rFsSMHyBlPIDNl9U=; b=YVjwwwIFcxhAtPvBsH+aUfXoB2Gn+gMm/rDbyYLKyDjWyVklt9twBrwsoj1/DzmQhy 83WKFNY9GiaeYSu5glUfVrMPpMlhiORPwSeP9JUHHgV6jKmwTukZg3QeMu4GRheIX6r2 9N9ynsbubybiZDUgYh+OVbWsGDkQk+vfQjc3/snaS7MZCurhgWmWA8MPQNauL/PbvIgu OKONjVo2bnK+5gvJL1px17Vtsv+swQtNna/1iUnz5mUjkOXQ3ZXLKdF62w3HbngdiRAw bQq8dJ9y6rkZilGzHyPp7Qp2lhdXTYllo1+5FBLm6Nu/z6zvP+z1x+4rlnNuM3J4w20e y8bQ== X-Gm-Message-State: ALoCoQkbAdzTZPO/oKCepWsuX/EvmYw1HZFJT9dtmZpogAUeD7suk+1jkcwZ7g3eWy/it4ngtVItbPh7dCvaw4wvUahT3DW1mG9F8CtKNgDO3JF5CnMQl3U8144OCuDr6EFckcHNejd6 X-Received: by 10.140.23.134 with SMTP id 6mr65960362qgp.84.1426371506070; Sat, 14 Mar 2015 15:18:26 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.140.23.134 with SMTP id 6mr65960359qgp.84.1426371505991; Sat, 14 Mar 2015 15:18:25 -0700 (PDT) Received: by 10.140.250.2 with HTTP; Sat, 14 Mar 2015 15:18:25 -0700 (PDT) In-Reply-To: <5503E065.5030602@omnitor.se> References: <0A4E9A96-56C9-4D15-81AE-5D8285654080@nostrum.com> <55035948.2070404@alum.mit.edu> <5503E065.5030602@omnitor.se> Date: Sat, 14 Mar 2015 18:18:25 -0400 Message-ID: From: Henning G Schulzrinne To: =?UTF-8?Q?Gunnar_Hellstr=C3=B6m?= Content-Type: multipart/alternative; boundary=001a11c12306eec9d3051146fe02 X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.5 Archived-At: Cc: slim@ietf.org Subject: Re: [Slim] Comments on proposed SLIM charter X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2015 22:18:30 -0000 --001a11c12306eec9d3051146fe02 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable First, I'm not particularly worried about call signaling overhead. This is likely to be trivial compared to all the other SIP signaling, let alone media. I'm having a hard time picturing an ACD that would care about call signaling volume. The registration piece is separable - that was meant for relatively simple situations where an end system indicated its capabilities. For the call center, a program is likely to generate the current set of capabilities, e.g., based on time of day ("Chinese-speaking CSRs are only available during 9-5 business hours since they don't get enough calls at night.") and other policies ("Platinum status customers get a real-time translation service if needed, so all languages are supported.") Something like (with completely bogus pseudo syntax): OPTIONS Preferred-Languages: ase; en (text); de (audio spoken, text) which would indicate something like "can do ASL (video, naturally), English (text only), German (speak, but not listen or text), in that order of preference." The call center would reply with some permutation of that, as in: 200 Preferred-Languages: ase; en (text) Alternatively, the ACD could just respond to the OPTIONS request with all of its capabilities, without the caller sending its preferences. Easier to implement, but the list is likely longer. In case the ACD can't do the requested media directly, it could redirect the request using the standard SIP mechanism, e.g., to a VRS provider. I'm trying to avoid fancy "q" parameters since I have never seen them used in any real way, except as ordering indicator. Based on the 3840/41 experience, as well as other attempts to do fancy things in SIP, my guess is that all but trivially-easy negotiation won't be implemented at all or will not interoperate. Thus, my bias is towards solving 80% of the problem if the remaining 20% increase the complexity. Henning On Sat, Mar 14, 2015 at 3:16 AM, Gunnar Hellstr=C3=B6m < gunnar.hellstrom@omnitor.se> wrote: > Yes, it is good to have a view of how a possible routing and adding of > extra resources can be made. > > We have two goals. > 1. Decide which of a number of available callees we route the call to tha= t > gives the best match. > > 2. Decide if additional resources are needed in the call to interpret > between the endpoints. > > A mechanism for pulling in extra resources for interpretation when needed > can be located at the caller end, in the middle or at the called end. > > In a call-center type application, it is possible that the SLIM mechanism > for conveying information about language and modality capabilities and > preferences is used just from the caller to the ACD. The custom ACD then > looks with other than SIP/SDP mechanisms at available call-taker profiles > and selects the best match for whom to send the call to. That type of > routing can be based on information in any part of the INVITE. > > It is when we want to do more automatic selection and routing with SIP > based mechanisms that we see that we need to either store the capability > information from registration or fetch it before the decision is made. > > RFC 3840/3841 information is already stored in the sip server from > registration time and there is a selection and routing mechanism specifie= d. > For an SDP based mechanism, I can imagine using OPTIONS to all possible > callees at call time and comparing the results using a new specified > mechanism or being left for the implementor. The policy-based routing tha= t > is sometimes talked about in relation to emergency calling could include > such mechanisms and be used also outside the emergency service scope. > > Having a box in the middle to take decision on including a third party in > a call for translation can be made by having the translation services bei= ng > included among the range of possible callees with a URI-list including th= e > translation service and the original destination callee. The result when > the best match is found to be a translation service is then that a > multi-party call is set up. > > This works if it is the callees who has the agreement with the translatio= n > service to invoke them when needed. But how can it be handled if it is th= e > caller who has the agreement? > > A couple of comments below: > Henning G Schulzrinne skrev den 2015-03-13 23:20: > > Good point. To reduce the complexity, this would seem to have three > phases: > > (1) Discovery - The caller tells the other side all it can do, with our > without intermediate "help" (human or machine). Probably an OPTIONS > request, but maybe something else. > > Right, but what is the response on an OPTIONS request to a call center? > > > (2) Response - The callee provides its possible options from that list, > maybe preference-ordered, or a "sorry, I cannot do this, Dave". > > (3) Call - Assuming that there's a meeting of the minds, the caller > tries again, with its preferred approach. > > In general, having something that doesn't require keeping state across > phases would seem most robust. > > Yes, but cause a lot of traffic for interrogation of capabilities in the > call center case(?) > > > Henning > > On Fri, Mar 13, 2015 at 5:40 PM, Paul Kyzivat > wrote: > >> On 3/13/15 4:57 PM, Henning G Schulzrinne wrote: >> >>> And, for the record, I continue to disagree with the current choice of >>> discarding a 3840-like (not necessarily the protocol itself) approach. = I >>> consider this a call routing problem which is not appropriate for an SD= P >>> solution, just by standard SIP architectural layering. >>> >> >> In principle I agree with you. But to make it solely into a call routing >> problem ignores the need to consider capabilities of both the caller and >> the callee, and then if they don't match, do some extra stuff to bring a >> "transcoder" into the session. >> >> That *could* be viewed as a call routing problem if it is always a >> "receiver makes it right" solution. For that, an intermediary at the >> callee's end (the callee's home proxy) would need to know the capabiliti= es >> of the callee and the callee's devices before routing to a callee device= , >> and pull in a transcoder. >> > And that is what is done at registration time with RFC 3841. > --001a11c12306eec9d3051146fe02 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
First, I'm not particularly worried about call signali= ng overhead. This is likely to be trivial compared to all the other SIP sig= naling, let alone media. I'm having a hard time picturing an ACD that w= ould care about call signaling volume.

The registration = piece is separable - that was meant for relatively simple situations where = an end system indicated its capabilities. For the call center, a program is= likely to generate the current set of capabilities, e.g., based on time of= day ("Chinese-speaking CSRs are only available during 9-5 business ho= urs since they don't get enough calls at night.") and other polici= es ("Platinum status customers get a real-time translation service if = needed, so all languages are supported.")

Som= ething like (with completely bogus pseudo syntax):

OPTIONS
Preferred-Languages: ase; en (text); de (audio spoken, t= ext)

which would indicate something like "can= do ASL (video, naturally), English (text only), German (speak, but not lis= ten or text), in that order of preference."

T= he call center would reply with some permutation of that, as in:
=
200
Preferred-Languages: ase; en (text)
=
Alternatively, the ACD could just respond to the OPTIONS req= uest with all of its capabilities, without the caller sending its preferenc= es. Easier to implement, but the list is likely longer.

In case the ACD can't do the requested media directly, it could r= edirect the request using the standard SIP mechanism, e.g., to a VRS provid= er.

I'm trying to avoid fancy "q" pa= rameters since I have never seen them used in any real way, except as order= ing indicator.

Based on the 3840/41 experience, as= well as other attempts to do fancy things in SIP, my guess is that all but= trivially-easy=C2=A0negotiation won't be implemented at all or will no= t interoperate. Thus, my bias is towards solving 80% of the problem if the = remaining 20% increase the complexity.

Henning

On Sat, Ma= r 14, 2015 at 3:16 AM, Gunnar Hellstr=C3=B6m <gunnar.hellstrom@= omnitor.se> wrote:
=20 =20 =20
Yes, it is good to have a view of how a possible routing and adding of extra resources can be made.

We have two goals.
1. Decide which of a number of available callees we route the call to that gives the best match.

2. Decide if additional resources are needed in the call to interpret between the endpoints.

A mechanism for pulling in extra resources for interpretation when needed can be located at the caller end, in the middle or at the called end.

In a call-center type application, it is possible that the SLIM mechanism for conveying information about language and modality capabilities and preferences is used just from the caller to the ACD. The custom ACD then looks with other than SIP/SDP mechanisms at available call-taker profiles and selects the best match for whom to send the call to. That type of routing can be based on information in any part of the INVITE.

It is when we want to do more automatic selection and routing with SIP based mechanisms that we see that we need to either store the capability information from registration or fetch it before the decision is made.

RFC 3840/3841 information is already stored in the sip server from registration time and there is a selection and routing mechanism specified.
For an SDP based mechanism, I can imagine using OPTIONS to all possible callees at call time and comparing the results using a new specified mechanism or being left for the implementor. The policy-based routing that is sometimes talked about in relation to emergency calling could include such mechanisms and be used also outside the emergency service scope.

Having a box in the middle to take decision on including a third party in a call for translation can be made by having the translation services being included among the range of possible callees with a URI-list including the translation service and the original destination callee. The result when the best match is found to be a translation service is then that a multi-party call is set up.=C2=A0

This works if it is the callees who has the agreement with the translation service to invoke them when needed. But how can it be handled if it is the caller who has the agreement?

A couple of comments below:
Henning G Schulzrinne skrev den 2015-03-13 23:20:
Good point. To reduce the complexity, this would seem to have three phases:

(1) Discovery - The caller tells the other side all it can do, with our without intermediate "help" (human or mach= ine). Probably an OPTIONS request, but maybe something else.
Right, but what is the response on an OPTIONS request to a call center?

(2) Response - The callee provides its possible options from that list, maybe preference-ordered, or a "sorry, I cannot do this, Dave".

(3) Call - Assuming that there's a meeting of the minds, the caller tries again, with its preferred approach.

In general, having something that doesn't require keeping state across phases would seem most robust.
Yes, but cause a lot of traffic for interrogation of capabilities in the call center case(?)

Henning

On Fri, Mar 13, 2015 at 5:40 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
On 3/13/15 4:57 PM, Henning G Schulzrinne wrote:
And, for the record, I continue to disagree with the current choice of
discarding a 3840-like (not necessarily the protocol itself) approach. I
consider this a call routing problem which is not appropriate for an SDP
solution, just by standard SIP architectural layering.

In principle I agree with you. But to make it solely into a call routing problem ignores the need to consider capabilities of both the caller and the callee, and then if they don't match, do some extra stuff to bring a "transcoder" into the session.

That *could* be viewed as a call routing problem if it is always a "receiver makes it right" solution. For that= , an intermediary at the callee's end (the callee's home pro= xy) would need to know the capabilities of the callee and the callee's devices before routing to a callee device, and pul= l in a transcoder.
And that is what is done at registration time with RFC 3841.

--001a11c12306eec9d3051146fe02-- From nobody Sun Mar 15 15:43:53 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE92B1A1BAC for ; Sun, 15 Mar 2015 15:43:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.299 X-Spam-Level: X-Spam-Status: No, score=0.299 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 KEpAEnbL8LBJ for ; Sun, 15 Mar 2015 15:43:48 -0700 (PDT) Received: from bin-vsp-out-02.atm.binero.net (vsp-authed01.binero.net [195.74.38.224]) (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 B742D1A0377 for ; Sun, 15 Mar 2015 15:43:47 -0700 (PDT) X-Halon-ID: bce7ae29-cb64-11e4-8eab-005056917f90 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.42] (unknown [77.53.231.174]) by bin-vsp-out-02.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Sun, 15 Mar 2015 23:43:45 +0100 (CET) Message-ID: <55060B1C.5040802@omnitor.se> Date: Sun, 15 Mar 2015 23:43:40 +0100 From: =?UTF-8?B?R3VubmFyIEhlbGxzdHLDtm0=?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Henning G Schulzrinne References: <0A4E9A96-56C9-4D15-81AE-5D8285654080@nostrum.com> <55035948.2070404@alum.mit.edu> <5503E065.5030602@omnitor.se> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030106030001010303080909" Archived-At: Cc: slim@ietf.org Subject: Re: [Slim] Comments on proposed SLIM charter X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Mar 2015 22:43:51 -0000 This is a multi-part message in MIME format. --------------030106030001010303080909 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Henning G Schulzrinne skrev den 2015-03-14 23:18: > First, I'm not particularly worried about call signaling overhead. > This is likely to be trivial compared to all the other SIP signaling, > let alone media. I'm having a hard time picturing an ACD that would > care about call signaling volume. > > The registration piece is separable - that was meant for relatively > simple situations where an end system indicated its capabilities. For > the call center, a program is likely to generate the current set of > capabilities, e.g., based on time of day ("Chinese-speaking CSRs are > only available during 9-5 business hours since they don't get enough > calls at night.") and other policies ("Platinum status customers get a > real-time translation service if needed, so all languages are supported.") > > Something like (with completely bogus pseudo syntax): > > OPTIONS > Preferred-Languages: ase; en (text); de (audio spoken, text) > > which would indicate something like "can do ASL (video, naturally), > English (text only), German (speak, but not listen or text), in that > order of preference." > > The call center would reply with some permutation of that, as in: > > 200 > Preferred-Languages: ase; en (text) > > Alternatively, the ACD could just respond to the OPTIONS request with > all of its capabilities, without the caller sending its preferences. > Easier to implement, but the list is likely longer. > > In case the ACD can't do the requested media directly, it could > redirect the request using the standard SIP mechanism, e.g., to a VRS > provider. > > I'm trying to avoid fancy "q" parameters since I have never seen them > used in any real way, except as ordering indicator. > > Based on the 3840/41 experience, as well as other attempts to do fancy > things in SIP, my guess is that all but trivially-easy negotiation > won't be implemented at all or will not interoperate. Thus, my bias is > towards solving 80% of the problem if the remaining 20% increase the > complexity. So you suggest that we just extend the language and media feature tags, so that we can differentiate written from spoken language and so that we can code what is decided to be included from the directionality and the relative or absolute priority within a medium and between media. We then gain that it is much easier to insert and extract the information from the SIP message rather than the SDP, while we instead might get problems to indicate which media stream we intend with each language and modality indication if the device has multiple media streams of the same kind. For that situation, we might look at defining some interaction with the media-content RFC 4796. And we do not specify any negotiation mechanism. /Gunnar > > Henning > > On Sat, Mar 14, 2015 at 3:16 AM, Gunnar Hellström > > wrote: > > Yes, it is good to have a view of how a possible routing and > adding of extra resources can be made. > > We have two goals. > 1. Decide which of a number of available callees we route the call > to that gives the best match. > > 2. Decide if additional resources are needed in the call to > interpret between the endpoints. > > A mechanism for pulling in extra resources for interpretation when > needed can be located at the caller end, in the middle or at the > called end. > > In a call-center type application, it is possible that the SLIM > mechanism for conveying information about language and modality > capabilities and preferences is used just from the caller to the > ACD. The custom ACD then looks with other than SIP/SDP mechanisms > at available call-taker profiles and selects the best match for > whom to send the call to. That type of routing can be based on > information in any part of the INVITE. > > It is when we want to do more automatic selection and routing with > SIP based mechanisms that we see that we need to either store the > capability information from registration or fetch it before the > decision is made. > > RFC 3840/3841 information is already stored in the sip server from > registration time and there is a selection and routing mechanism > specified. > For an SDP based mechanism, I can imagine using OPTIONS to all > possible callees at call time and comparing the results using a > new specified mechanism or being left for the implementor. The > policy-based routing that is sometimes talked about in relation to > emergency calling could include such mechanisms and be used also > outside the emergency service scope. > > Having a box in the middle to take decision on including a third > party in a call for translation can be made by having the > translation services being included among the range of possible > callees with a URI-list including the translation service and the > original destination callee. The result when the best match is > found to be a translation service is then that a multi-party call > is set up. > > This works if it is the callees who has the agreement with the > translation service to invoke them when needed. But how can it be > handled if it is the caller who has the agreement? > > A couple of comments below: > Henning G Schulzrinne skrev den 2015-03-13 23:20: >> Good point. To reduce the complexity, this would seem to have >> three phases: >> >> (1) Discovery - The caller tells the other side all it can do, >> with our without intermediate "help" (human or machine). Probably >> an OPTIONS request, but maybe something else. > Right, but what is the response on an OPTIONS request to a call > center? >> >> (2) Response - The callee provides its possible options from that >> list, maybe preference-ordered, or a "sorry, I cannot do this, Dave". >> >> (3) Call - Assuming that there's a meeting of the minds, the >> caller tries again, with its preferred approach. >> >> In general, having something that doesn't require keeping state >> across phases would seem most robust. > Yes, but cause a lot of traffic for interrogation of capabilities > in the call center case(?) >> >> Henning >> >> On Fri, Mar 13, 2015 at 5:40 PM, Paul Kyzivat >> > wrote: >> >> On 3/13/15 4:57 PM, Henning G Schulzrinne wrote: >> >> And, for the record, I continue to disagree with the >> current choice of >> discarding a 3840-like (not necessarily the protocol >> itself) approach. I >> consider this a call routing problem which is not >> appropriate for an SDP >> solution, just by standard SIP architectural layering. >> >> >> In principle I agree with you. But to make it solely into a >> call routing problem ignores the need to consider >> capabilities of both the caller and the callee, and then if >> they don't match, do some extra stuff to bring a "transcoder" >> into the session. >> >> That *could* be viewed as a call routing problem if it is >> always a "receiver makes it right" solution. For that, an >> intermediary at the callee's end (the callee's home proxy) >> would need to know the capabilities of the callee and the >> callee's devices before routing to a callee device, and pull >> in a transcoder. >> > And that is what is done at registration time with RFC 3841. > > -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 --------------030106030001010303080909 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Henning G Schulzrinne skrev den 2015-03-14 23:18:
First, I'm not particularly worried about call signaling overhead. This is likely to be trivial compared to all the other SIP signaling, let alone media. I'm having a hard time picturing an ACD that would care about call signaling volume.

The registration piece is separable - that was meant for relatively simple situations where an end system indicated its capabilities. For the call center, a program is likely to generate the current set of capabilities, e.g., based on time of day ("Chinese-speaking CSRs are only available during 9-5 business hours since they don't get enough calls at night.") and other policies ("Platinum status customers get a real-time translation service if needed, so all languages are supported.")

Something like (with completely bogus pseudo syntax):

OPTIONS
Preferred-Languages: ase; en (text); de (audio spoken, text)

which would indicate something like "can do ASL (video, naturally), English (text only), German (speak, but not listen or text), in that order of preference."

The call center would reply with some permutation of that, as in:

200
Preferred-Languages: ase; en (text)

Alternatively, the ACD could just respond to the OPTIONS request with all of its capabilities, without the caller sending its preferences. Easier to implement, but the list is likely longer.

In case the ACD can't do the requested media directly, it could redirect the request using the standard SIP mechanism, e.g., to a VRS provider.

I'm trying to avoid fancy "q" parameters since I have never seen them used in any real way, except as ordering indicator.

Based on the 3840/41 experience, as well as other attempts to do fancy things in SIP, my guess is that all but trivially-easy negotiation won't be implemented at all or will not interoperate. Thus, my bias is towards solving 80% of the problem if the remaining 20% increase the complexity.
So you suggest that we just extend the language and media feature tags, so that we can differentiate written from spoken language and so that we can code what is decided to be included from the directionality and the relative or absolute priority within a medium and between media.

We then gain that it is much easier to insert and extract the information from the SIP message rather than the SDP, while we instead might get problems to indicate which media stream we intend with each language and modality indication if the device has multiple media streams of the same kind.

For that situation, we might look at defining some interaction with the media-content RFC 4796.

And we do not specify any negotiation mechanism.

/Gunnar




 

Henning

On Sat, Mar 14, 2015 at 3:16 AM, Gunnar Hellström <gunnar.hellstrom@omnitor.se> wrote:
Yes, it is good to have a view of how a possible routing and adding of extra resources can be made.

We have two goals.
1. Decide which of a number of available callees we route the call to that gives the best match.

2. Decide if additional resources are needed in the call to interpret between the endpoints.

A mechanism for pulling in extra resources for interpretation when needed can be located at the caller end, in the middle or at the called end.

In a call-center type application, it is possible that the SLIM mechanism for conveying information about language and modality capabilities and preferences is used just from the caller to the ACD. The custom ACD then looks with other than SIP/SDP mechanisms at available call-taker profiles and selects the best match for whom to send the call to. That type of routing can be based on information in any part of the INVITE.

It is when we want to do more automatic selection and routing with SIP based mechanisms that we see that we need to either store the capability information from registration or fetch it before the decision is made.

RFC 3840/3841 information is already stored in the sip server from registration time and there is a selection and routing mechanism specified.
For an SDP based mechanism, I can imagine using OPTIONS to all possible callees at call time and comparing the results using a new specified mechanism or being left for the implementor. The policy-based routing that is sometimes talked about in relation to emergency calling could include such mechanisms and be used also outside the emergency service scope.

Having a box in the middle to take decision on including a third party in a call for translation can be made by having the translation services being included among the range of possible callees with a URI-list including the translation service and the original destination callee. The result when the best match is found to be a translation service is then that a multi-party call is set up. 

This works if it is the callees who has the agreement with the translation service to invoke them when needed. But how can it be handled if it is the caller who has the agreement?

A couple of comments below:
Henning G Schulzrinne skrev den 2015-03-13 23:20:
Good point. To reduce the complexity, this would seem to have three phases:

(1) Discovery - The caller tells the other side all it can do, with our without intermediate "help" (human or machine). Probably an OPTIONS request, but maybe something else.
Right, but what is the response on an OPTIONS request to a call center?

(2) Response - The callee provides its possible options from that list, maybe preference-ordered, or a "sorry, I cannot do this, Dave".

(3) Call - Assuming that there's a meeting of the minds, the caller tries again, with its preferred approach.

In general, having something that doesn't require keeping state across phases would seem most robust.
Yes, but cause a lot of traffic for interrogation of capabilities in the call center case(?)

Henning

On Fri, Mar 13, 2015 at 5:40 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
On 3/13/15 4:57 PM, Henning G Schulzrinne wrote:
And, for the record, I continue to disagree with the current choice of
discarding a 3840-like (not necessarily the protocol itself) approach. I
consider this a call routing problem which is not appropriate for an SDP
solution, just by standard SIP architectural layering.

In principle I agree with you. But to make it solely into a call routing problem ignores the need to consider capabilities of both the caller and the callee, and then if they don't match, do some extra stuff to bring a "transcoder" into the session.

That *could* be viewed as a call routing problem if it is always a "receiver makes it right" solution. For that, an intermediary at the callee's end (the callee's home proxy) would need to know the capabilities of the callee and the callee's devices before routing to a callee device, and pull in a transcoder.
And that is what is done at registration time with RFC 3841.


-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288
--------------030106030001010303080909-- From nobody Sun Mar 15 17:20:31 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44DC41A1BFF for ; Sun, 15 Mar 2015 17:20:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wA17NNdITjH5 for ; Sun, 15 Mar 2015 17:20:27 -0700 (PDT) Received: from millet.cc.columbia.edu (millet.cc.columbia.edu [128.59.72.250]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 747EF1A1BFE for ; Sun, 15 Mar 2015 17:20:27 -0700 (PDT) Received: from hazelnut (hazelnut.cc.columbia.edu [128.59.213.250]) by millet.cc.columbia.edu (8.13.8/8.13.8) with ESMTP id t2G0G1Wd005918 for ; Sun, 15 Mar 2015 20:20:26 -0400 Received: from hazelnut (localhost.localdomain [127.0.0.1]) by hazelnut (Postfix) with ESMTP id 291156D for ; Sun, 15 Mar 2015 20:20:26 -0400 (EDT) Received: from tarap.cc.columbia.edu (tarap.cc.columbia.edu [128.59.29.7]) by hazelnut (Postfix) with ESMTP id D09466D for ; Sun, 15 Mar 2015 20:20:25 -0400 (EDT) Received: from mail-qc0-f179.google.com (mail-qc0-f179.google.com [209.85.216.179]) by tarap.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id t2G0KP98021643 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sun, 15 Mar 2015 20:20:25 -0400 (EDT) Received: by qcbkw5 with SMTP id kw5so31164907qcb.2 for ; Sun, 15 Mar 2015 17:20:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=GGTF4gwy9OCGJ5YDZSkj7ejvS/jg1E8mpY3YfyJIAnM=; b=KPKXNO8SS+gtIoX9SxF0z80Yi2nHK7zFeDBxjzAi70ePPw99YgPq7JmT5cXEhi/0u5 n+yGw2n/y+yHNscDmKXHdVoiSYmFtKM88tp/d/y71eRzK+lfCTgq+1V1xMmMxtgmKvq2 hxKhwyQ1FBWRByoEMkMdbFns7t8gRO6BQFGI94Fi5Nfd6WrF+WaG+04Qcpc3n6JGJkL9 MCa4kSdvuhqWJh4E4xY9YNgo/bR2P+nNwb1Vu+0kJDdJotNL+KyExhCI4b0n5Wx1JHYu rnrOUssqgl23iD74FL15D9pZdqNAepn8tZua7KZ3MeBooeTk0dTvo67gU6f/9EYVEve0 fRgQ== X-Gm-Message-State: ALoCoQmwFzXJoGPB7xkx9Ma2VsYx0D1IRD2vxFvIIFAm/x1U8Oku6jo7edRnRBHWFWNN6D2cHbq/REOt2sMosl+OTnrEuQtTR/f1e9w0Ry8gGsUvMuxY/7MdMXoCnNbHvGfmpQjsQoDb X-Received: by 10.140.109.164 with SMTP id l33mr70387000qgf.91.1426465225396; Sun, 15 Mar 2015 17:20:25 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.140.109.164 with SMTP id l33mr70386997qgf.91.1426465225289; Sun, 15 Mar 2015 17:20:25 -0700 (PDT) Received: by 10.140.250.2 with HTTP; Sun, 15 Mar 2015 17:20:25 -0700 (PDT) In-Reply-To: <55060B1C.5040802@omnitor.se> References: <0A4E9A96-56C9-4D15-81AE-5D8285654080@nostrum.com> <55035948.2070404@alum.mit.edu> <5503E065.5030602@omnitor.se> <55060B1C.5040802@omnitor.se> Date: Sun, 15 Mar 2015 20:20:25 -0400 Message-ID: From: Henning Schulzrinne To: =?UTF-8?Q?Gunnar_Hellstr=C3=B6m?= Content-Type: multipart/alternative; boundary=001a113a304e09bd4905115cd127 X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.7 Archived-At: Cc: slim@ietf.org Subject: Re: [Slim] Comments on proposed SLIM charter X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 00:20:29 -0000 --001a113a304e09bd4905115cd127 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, Mar 15, 2015 at 6:43 PM, Gunnar Hellstr=C3=B6m < gunnar.hellstrom@omnitor.se> wrote: > > So you suggest that we just extend the language and media feature tags, so > that we can differentiate written from spoken language and so that we can > code what is decided to be included from the directionality and the > relative or absolute priority within a medium and between media. > Indeed - whatever the minimum necessary to route the call and determine what assistance is needed. > > We then gain that it is much easier to insert and extract the information > from the SIP message rather than the SDP, while we instead might get > problems to indicate which media stream we intend with each language and > modality indication if the device has multiple media streams of the same > kind. > > That may well be a separable problem, and may be easier to solve with a limited scope. > For that situation, we might look at defining some interaction with the > media-content RFC 4796. > Indeed; as long as we only need to indicate, rather than negotiate, a straightforward extension of that model with something like a:language:ase would seem to be useful. In that case, each media entry would (typically?) only have one language, although one can probably come up with scenarios where multiple languages make sense (for example, I think there are MPEG transport streams with multiple languages). > > And we do not specify any negotiation mechanism. > I'm inclined to leave that to implementations, as long as everybody knows what the header fields mean, but the "how did we get those" can be magic in a black box. Obviously, you can get non-sensical responses (Caller: I speak only English; Callee: Great, let's converse in Swedish), but I doubt that spelling this out in detail will help avoid these. I think a reasonable goal is to make sure that end points can deal with the common scenarios and know what to do. I've yet to see a UA that offers a higher-level programming abstraction (such as CPL), so this is likely to be hard-coded into the UA anyway, with limited configurability. > > /Gunnar > Henning --001a113a304e09bd4905115cd127 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Mar 15, 2015 at 6:43 PM, Gunnar Hellstr=C3=B6m <gunn= ar.hellstrom@omnitor.se> wrote:
=20 =20 =20
=C2=A0
So y= ou suggest that we just extend the language and media feature tags, so that we can differentiate written from spoken language and so that we can code what is decided to be included from the directionality and the relative or absolute priority within a medium and between media.

Indeed - w= hatever the minimum necessary to route the call and determine what assistan= ce is needed.

=C2=A0

We then gain that it is much easier to insert and extract the information from the SIP message rather than the SDP, while we instead might get problems to indicate which media stream we intend with each language and modality indication if the device has multiple media streams of the same kind.


That may well be a separable= problem, and may be easier to solve with a limited scope.
=C2=A0=
For that situation, we might look at defining some interaction with the media-content RFC 4796.

I= ndeed; as long as we only need to indicate, rather than negotiate, a straig= htforward extension of that model with something like

<= div>a:language:ase

would seem to be useful. In tha= t case, each media entry would (typically?) only have one language, althoug= h one can probably come up with scenarios where multiple languages make sen= se (for example, I think there are MPEG transport streams with multiple lan= guages).
=C2=A0

And we do not specify any negotiation mechanism.

I'm inclined to leave that to implementations, as = long as everybody knows what the header fields mean, but the "how did = we get those" can be magic in a black box. Obviously, you can get non-= sensical responses (Caller: I speak only English; Callee: Great, let's = converse in Swedish), but I doubt that spelling this out in detail will hel= p avoid these. I think a reasonable goal is to make sure that end points ca= n deal with the common scenarios and know what to do. I've yet to see a= UA that offers a higher-level programming abstraction (such as CPL), so th= is is likely to be hard-coded into the UA anyway, with limited configurabil= ity.=C2=A0
=C2=A0

/Gunnar

Henning=C2=A0
<= /div>
--001a113a304e09bd4905115cd127-- From nobody Mon Mar 16 00:19:46 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C15B1A1F70 for ; Mon, 16 Mar 2015 00:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 c-xjtD8YdbZw for ; Mon, 16 Mar 2015 00:19:43 -0700 (PDT) Received: from bin-vsp-out-01.atm.binero.net (vsp-authed01.binero.net [195.74.38.224]) (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 E2F851A1F1D for ; Mon, 16 Mar 2015 00:19:42 -0700 (PDT) X-Halon-ID: d08e85c1-cbac-11e4-8274-005056917a89 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.42] (unknown [77.53.231.174]) by bin-vsp-out-01.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Mon, 16 Mar 2015 08:19:42 +0100 (CET) Message-ID: <55068407.6040807@omnitor.se> Date: Mon, 16 Mar 2015 08:19:35 +0100 From: =?windows-1252?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: slim@ietf.org References: <0A4E9A96-56C9-4D15-81AE-5D8285654080@nostrum.com> <55035948.2070404@alum.mit.edu> <5503E065.5030602@omnitor.se> <55060B1C.5040802@omnitor.se> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040108050909020905090201" Archived-At: Subject: Re: [Slim] Comments on proposed SLIM charter X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 07:19:45 -0000 This is a multi-part message in MIME format. --------------040108050909020905090201 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Henning Schulzrinne skrev den 2015-03-16 01:20: > > > On Sun, Mar 15, 2015 at 6:43 PM, Gunnar Hellström > > wrote: > > > So you suggest that we just extend the language and media feature > tags, so that we can differentiate written from spoken language > and so that we can code what is decided to be included from the > directionality and the relative or absolute priority within a > medium and between media. > > > Indeed - whatever the minimum necessary to route the call and > determine what assistance is needed. > > > We then gain that it is much easier to insert and extract the > information from the SIP message rather than the SDP, while we > instead might get problems to indicate which media stream we > intend with each language and modality indication if the device > has multiple media streams of the same kind. > > > That may well be a separable problem, and may be easier to solve with > a limited scope. > > For that situation, we might look at defining some interaction > with the media-content RFC 4796. > > > Indeed; as long as we only need to indicate, rather than negotiate, a > straightforward extension of that model with something like > > a:language:ase > > would seem to be useful. In that case, each media entry would > (typically?) only have one language, although one can probably come up > with scenarios where multiple languages make sense (for example, I > think there are MPEG transport streams with multiple languages). I meant this scenario: If we in SIP headers declare humintlang-audio: de, fr And in SDP, there is m=audio 7000 AVP/RTP 0 m=audio 8000 AVP/RTP 0 Then there is no indication for which audio stream we indicate language. This starts to get into CLUE domains, so we should be careful not to go too far into such complications. We can have a default assignment between the language declarations and the RFC 4796 Content attribute saying that the language declaration is for the stream marked with the "main" attribute if more than one stream of the same media type is started. m=audio 7000 AVP/RTP 0 a=content:main m=audio 8000 AVP/RTP 0 But the added complexity by this maybe already outweighs what we gain by having the language declaration in SIP headers rather than SDP. > > And we do not specify any negotiation mechanism. > > > I'm inclined to leave that to implementations, as long as everybody > knows what the header fields mean, but the "how did we get those" can > be magic in a black box. Obviously, you can get non-sensical responses > (Caller: I speak only English; Callee: Great, let's converse in > Swedish), but I doubt that spelling this out in detail will help avoid > these. I think a reasonable goal is to make sure that end points can > deal with the common scenarios and know what to do. I've yet to see a > UA that offers a higher-level programming abstraction (such as CPL), > so this is likely to be hard-coded into the UA anyway, with limited > configurability. > > > /Gunnar > > > Henning > /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 --------------040108050909020905090201 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Henning Schulzrinne skrev den 2015-03-16 01:20:


On Sun, Mar 15, 2015 at 6:43 PM, Gunnar Hellström <gunnar.hellstrom@omnitor.se> wrote:
 
So you suggest that we just extend the language and media feature tags, so that we can differentiate written from spoken language and so that we can code what is decided to be included from the directionality and the relative or absolute priority within a medium and between media.

Indeed - whatever the minimum necessary to route the call and determine what assistance is needed.

 

We then gain that it is much easier to insert and extract the information from the SIP message rather than the SDP, while we instead might get problems to indicate which media stream we intend with each language and modality indication if the device has multiple media streams of the same kind.


That may well be a separable problem, and may be easier to solve with a limited scope.
 
For that situation, we might look at defining some interaction with the media-content RFC 4796.

Indeed; as long as we only need to indicate, rather than negotiate, a straightforward extension of that model with something like

a:language:ase

would seem to be useful. In that case, each media entry would (typically?) only have one language, although one can probably come up with scenarios where multiple languages make sense (for example, I think there are MPEG transport streams with multiple languages).
I meant this scenario:
If we in SIP headers declare  humintlang-audio: de, fr
And in SDP, there is
m=audio 7000 AVP/RTP 0
m=audio 8000 AVP/RTP 0

Then there is no indication for which audio stream we indicate language.

This starts to get into CLUE domains, so we should be careful not to go too far into such complications.

We can have a default assignment between the language declarations and the RFC 4796 Content attribute saying that the language declaration is for the stream marked with the "main" attribute if more than one stream of the same media type is started.
m=audio 7000 AVP/RTP 0
a=content:main
m=audio 8000 AVP/RTP 0

But the added complexity by this maybe already outweighs what we gain by having the language declaration in SIP headers rather than SDP.


 

And we do not specify any negotiation mechanism.

I'm inclined to leave that to implementations, as long as everybody knows what the header fields mean, but the "how did we get those" can be magic in a black box. Obviously, you can get non-sensical responses (Caller: I speak only English; Callee: Great, let's converse in Swedish), but I doubt that spelling this out in detail will help avoid these. I think a reasonable goal is to make sure that end points can deal with the common scenarios and know what to do. I've yet to see a UA that offers a higher-level programming abstraction (such as CPL), so this is likely to be hard-coded into the UA anyway, with limited configurability. 
 

/Gunnar

Henning 

/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
--------------040108050909020905090201-- From nobody Mon Mar 16 05:46:14 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 420F91A8715 for ; Mon, 16 Mar 2015 05:46:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.288 X-Spam-Level: X-Spam-Status: No, score=-3.288 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2zlnZwcLBJmW for ; Mon, 16 Mar 2015 05:46:05 -0700 (PDT) Received: from millet.cc.columbia.edu (millet.cc.columbia.edu [128.59.72.250]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C1D71A8718 for ; Mon, 16 Mar 2015 05:46:05 -0700 (PDT) Received: from hazelnut (hazelnut.cc.columbia.edu [128.59.213.250]) by millet.cc.columbia.edu (8.13.8/8.13.8) with ESMTP id t2GCjJJo010203 for ; Mon, 16 Mar 2015 08:46:04 -0400 Received: from hazelnut (localhost.localdomain [127.0.0.1]) by hazelnut (Postfix) with ESMTP id 04DC56D for ; Mon, 16 Mar 2015 08:46:04 -0400 (EDT) Received: from rambutan.cc.columbia.edu (rambutan.cc.columbia.edu [128.59.29.5]) by hazelnut (Postfix) with ESMTP id C52CE6D for ; Mon, 16 Mar 2015 08:46:03 -0400 (EDT) Received: from mail-qg0-f50.google.com (mail-qg0-f50.google.com [209.85.192.50]) by rambutan.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id t2GCk37r022098 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 16 Mar 2015 08:46:03 -0400 (EDT) Received: by qgez64 with SMTP id z64so38320417qge.2 for ; Mon, 16 Mar 2015 05:46:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=9bY3/fO9dwXVXjPAPQRt4UJYQ3tyMCYcuBvZbuzsJrE=; b=Pc688KQmzCYb8gbQYCEy99ConPh9Aoz4ao74FiLbcQr+6yvyIj4hLZWocYdNN42/ox xTZe4UDjwMUSUG4eU7PvBKqkAv94QlHbyxNiVjCGOeuEfurimgFWyHLT69+mhwdAkQRt IWxb43lDFJyNmimzDf3PJbxZVuVWNENVZ0zT+5pDUz1nEVlRvpTFRzYkZaLdUuaKWoiI If3Fpxrk22MWXHnmdMR9FggyYPpxnh1FljQmcr8EVNH8Ue7mThwa7/xU4KB56ixvpWcQ Z2wD+Jzlv7ZH73W8S3zfs79GuCKjO5+xORPl09JR/SJdAn78C6kRXxMuKsFp3Wdt3gX8 uB3g== X-Gm-Message-State: ALoCoQkpzJOHN0p4z75s5A+wvxGwBhEbrmE1OCDDCSi3aTQt2TVMcgJR5K8G/tFGjcTCLqgdhhGFagb3Ux6rJGWrUkQZuFAu3op2Y4zEAqp3HW5foLR/+kC6hBk+l1M2rYTVrIUzVA11 X-Received: by 10.229.84.68 with SMTP id i4mr45614262qcl.24.1426509963259; Mon, 16 Mar 2015 05:46:03 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.229.84.68 with SMTP id i4mr45614257qcl.24.1426509963181; Mon, 16 Mar 2015 05:46:03 -0700 (PDT) Received: by 10.140.250.2 with HTTP; Mon, 16 Mar 2015 05:46:03 -0700 (PDT) In-Reply-To: <55068407.6040807@omnitor.se> References: <0A4E9A96-56C9-4D15-81AE-5D8285654080@nostrum.com> <55035948.2070404@alum.mit.edu> <5503E065.5030602@omnitor.se> <55060B1C.5040802@omnitor.se> <55068407.6040807@omnitor.se> Date: Mon, 16 Mar 2015 08:46:03 -0400 Message-ID: From: Henning Schulzrinne To: =?UTF-8?Q?Gunnar_Hellstr=C3=B6m?= Content-Type: multipart/alternative; boundary=001a1133b5b49fce440511673bc2 X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.5 Archived-At: Cc: slim@ietf.org Subject: Re: [Slim] Comments on proposed SLIM charter X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 12:46:13 -0000 --001a1133b5b49fce440511673bc2 Content-Type: text/plain; charset=UTF-8 I suspect we're talking past each other. My suggestion, following your comments, is to do two orthogonal things: (1) A high-level declaration of media capabilities sufficient for call routing, found in the SIP header. It does not rely on SDP and simply provides (language, media direction, media type) tuples. (2) A per-media description of the language used by a media stream, in SDP. No preferences, just declaration, similar to the RFC 4796 model. This is useful also for multi-stream sessions, e.g., where one audio stream is in the original language, another is the simultaneous translation. The SDP one seems trivial to describe as long as there's no notion of negotiation or matching at the protocol-spec level. (Obviously, SDP end points can do whatever they like, including dropping media streams they have no use for.) Does that make sense? Henning --001a1133b5b49fce440511673bc2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I suspect we're talking past each other. My suggestion= , following your comments, is to do two orthogonal things:

(1) A high-level declaration of media capabilities sufficient for call r= outing, found in the SIP header. It does not rely on SDP and simply provide= s (language, media direction, media type) tuples.

= (2) A per-media description of the language used by a media stream, in SDP.= No preferences, just declaration, similar to the RFC 4796 model. This is u= seful also for multi-stream sessions, e.g., where one audio stream is in th= e original language, another is the simultaneous translation.
The SDP one seems trivial to describe as long as there's no= notion of negotiation or matching at the protocol-spec level. (Obviously, = SDP end points can do whatever they like, including dropping media streams = they have no use for.)

Does that make sense?
=

Henning

--001a1133b5b49fce440511673bc2-- From nobody Mon Mar 16 09:42:19 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C3FF1A8790 for ; Mon, 16 Mar 2015 07:30:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q5HzO0uY9KFY for ; Mon, 16 Mar 2015 07:30:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 07C6C1A87A8 for ; Mon, 16 Mar 2015 07:30:36 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150316143036.14278.81416.idtracker@ietfa.amsl.com> Date: Mon, 16 Mar 2015 07:30:36 -0700 From: IETF Secretariat Archived-At: X-Mailman-Approved-At: Mon, 16 Mar 2015 09:42:18 -0700 Subject: [Slim] State changed: charter-ietf-slim-00-01 X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 14:30:42 -0000 State changed to Internal review. URL: http://datatracker.ietf.org/doc/charter-ietf-slim/ From nobody Mon Mar 16 09:47:20 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C14411A88C9 for ; Mon, 16 Mar 2015 09:47:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.588 X-Spam-Level: X-Spam-Status: No, score=-3.588 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable 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 t7fC2ZFr6LGm for ; Mon, 16 Mar 2015 09:47:08 -0700 (PDT) Received: from buckwheat.cc.columbia.edu (buckwheat.cc.columbia.edu [128.59.72.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D1CD1A88CA for ; Mon, 16 Mar 2015 09:47:08 -0700 (PDT) Received: from hazelnut (hazelnut.cc.columbia.edu [128.59.213.250]) by buckwheat.cc.columbia.edu (8.13.8/8.13.8) with ESMTP id t2GGhkXC018217 for ; Mon, 16 Mar 2015 12:47:07 -0400 Received: from hazelnut (localhost.localdomain [127.0.0.1]) by hazelnut (Postfix) with ESMTP id 95A207E for ; Mon, 16 Mar 2015 12:47:07 -0400 (EDT) Received: from tarap.cc.columbia.edu (tarap.cc.columbia.edu [128.59.29.7]) by hazelnut (Postfix) with ESMTP id 7415C80 for ; Mon, 16 Mar 2015 12:47:07 -0400 (EDT) Received: from mail-qg0-f43.google.com (mail-qg0-f43.google.com [209.85.192.43]) by tarap.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id t2GGl7oG025960 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 16 Mar 2015 12:47:07 -0400 (EDT) Received: by qgfa8 with SMTP id a8so45322459qgf.0 for ; Mon, 16 Mar 2015 09:47:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=+nxqxiIkOBUmD6Or3ktIlcx4EP3toEmNWPk9d2LMaKI=; b=R52+kUG2I7vCFmXnZvqaaHaU9JOtSMfO+VkTXqZkxC34inrPm0aNbfU1M0WHgD7hpn Cc04d+q8go+P0VofrYGV7jYypBVfVVEgdFPBiIoZEORG0F1rGsYWuDnIy4KS+q5Jr4TW 2q8HN+tDJOnSpK/k3OVIyaqIVgexTdTMCC9AvFSr7pIY8qz8ilpmYTTHXRFv8L0izrhC 2XUK69j0xy57f4SigLn9N+owyyuzrtsJlPkI2r38xIZc02C35XQuGzjd8x5bkX3osSz4 VNp+Lf/dG5pTGtq0rdwwd5O/YRBysl4TDZmdbsitFRSWRgrU6fBKPI6zdrzPJfUimLgZ verw== X-Gm-Message-State: ALoCoQnXYkXmLRRWD2nCrxq/gjCCBX8Cso8LX/Gxyehj8710hg7cQs6DCZ1HNASprvrGrWZEK4xdpW7MdQhrLWGef7fyETENDYiyWo1+GHUuwtah3RtjrQPFj2NJvqluKoWWVdWaT7tp X-Received: by 10.229.84.68 with SMTP id i4mr47109421qcl.24.1426524426988; Mon, 16 Mar 2015 09:47:06 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.229.84.68 with SMTP id i4mr47109408qcl.24.1426524426858; Mon, 16 Mar 2015 09:47:06 -0700 (PDT) Received: by 10.140.250.2 with HTTP; Mon, 16 Mar 2015 09:47:06 -0700 (PDT) In-Reply-To: References: <0A4E9A96-56C9-4D15-81AE-5D8285654080@nostrum.com> Date: Mon, 16 Mar 2015 12:47:06 -0400 Message-ID: From: Henning Schulzrinne To: Randall Gellens Content-Type: multipart/alternative; boundary=001a1133b5b4ba035b05116a9946 X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.7 Archived-At: Cc: slim@ietf.org, IESG Subject: Re: [Slim] Comments on proposed SLIM charter X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 16:47:14 -0000 --001a1133b5b4ba035b05116a9946 Content-Type: text/plain; charset=UTF-8 I have stated the reason multiple times - it is fundamentally the wrong architectural level. It's like asking why we should put email addresses in IP headers and route packets based on that - yes, it can work technically, but it's still a bad idea. In any event, we seem to be having a productive discussion among some of the SLIM participants about a rough solution outline that avoids some of these architectural issues, so the debate may be somewhat overtaken by events. Henning On Mon, Mar 16, 2015 at 12:40 PM, Randall Gellens wrote: > At 4:57 PM -0400 3/13/15, Henning G Schulzrinne wrote: > > And, for the record, I continue to disagree with the current choice of >> discarding a 3840-like (not necessarily the protocol itself) approach. I >> consider this a call routing problem which is not appropriate for an SDP >> solution, just by standard SIP architectural layering. >> > > There has been significant work over the years on trying to resolve the > SDP vs SIP issue. First as a small and very informal group prior to and > following the Orlando IETF. The conclusion there was that SDP made more > sense for the emergency calling case, so the work progressed along that > route. Then, in Berlin, Henning made his case that SDP was the wrong > choice, and Gunner volunteered to see if the SIP-only approach could work. > We went through email discussions (before there was a list, but Henning and > the other SIP-only proponents were in the distribution list but did not > actively participate) and worked through the cases. I published revisions > of the draft showing both as candidate solutions. Finally, as the draft > tries to make clear, we eventually reached the conclusion that neither > approach is ideal, both have benefits and problems, but either could be > made to work. There are reasons why the SDP approach makes more sense, > especially for the emergency services case, and the SIP case has a few more > problems, but fundamentally, this more a stylistic/preference/religion > debate than just technical aspects. We've spent much time and effort trying > to make the best technical evaluation, and I believe we are moving forward > on that basis. I therefore don't have much patience for reopening the > debate a third time, especially when it comes down to personal preference > and not technical problems. If we are going to ever get anything completed > that can be implemented and deployed, we need to move forward. > > Therefore, I suggest that unless anyone can point to reasons why the SDP > approach will not work, we should accept the conclusion and move forward. > > > On Fri, Mar 13, 2015 at 4:30 PM, Ben Campbell < >> ben@nostrum.com> wrote: >> >> Hi, >> >> For the record, I support this work. But I have some concerns about the >> proposed charter at >> https://datatracker.ietf.org/doc/charter-ietf-slim . Apologies if this >> rehashes old discussions; I have only recently joined the mailing list (I >> did scan the archive, but likely missed things.) >> >> I don't find the charter text motivating the linkage between the mail >> problem and the real-time problem very convincing. I'm not saying it's >> wrong; just that it hasn't convinced me. >> >> The text suggests a single work group to reinforce commonality in the >> solutions. That seems backwards to me; I'd like to see more on why people >> think the problems benefit from a common solution. Do you think there will >> be mechanism in common, beyond the use of language tags? Do you see a >> common implementor community? A common protocol development community? >> >> I'd like to see something about why people don't think the real-time >> problem is at least partially solved by RFCs 3840 and 3841. If that's a >> forgone conclusion, the charter needs to clearly motivate it. The draft is >> slightly more helpful here in mentioning that 3840/3841 were considered but >> discarded, but that's not obvious from the proposed charter text. >> >> Part of this may be that I am not sure if this is looking at a >> call-routing problem (i.e. getting the call to an appropriate destination >> for a language) and/or a language negotiation problem (i.e. deciding what >> language you are going to use once the call is established. The first is >> mentioned, although the text about invoking translators, etc, might also >> imply the second. The charter should clearly describe the problem. >> >> If the idea is to finish the existing drafts, the charter should say >> that. Even so, >> the schedule seems optimistic, unless you expect those drafts to go to >> WGLC right after >> the charter is approved. >> >> I find paragraph 2 a bit hard to follow--it seems to be a single complex >> sentence. >> >> Thanks! >> >> Ben. >> >> _______________________________________________ >> 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: --------------- > Did you know... > That no one ever reads these things? > --001a1133b5b4ba035b05116a9946 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have stated the reason multiple times - it is fundamenta= lly the wrong architectural level. It's like asking why we should put e= mail addresses in IP headers and route packets based on that - yes, it can = work technically, but it's still a bad idea.

In any = event, we seem to be having a productive discussion among some of the SLIM = participants about a rough solution outline that avoids some of these archi= tectural issues, so the debate may be somewhat overtaken by events.

Henning

On Mon, Mar 16, 2015 at 12:40 PM, Randall Gellens <= rg+ieee@qti.qualcomm.com> wrote:
At 4:57 PM -0400 3/13/15, Henning G Schulzrinne wrote:

=C2=A0And, for the record, I continue to disagree with the current choice o= f discarding a 3840-like (not necessarily the protocol itself) approach. I = consider this a call routing problem which is not appropriate for an SDP so= lution, just by standard SIP architectural layering.

There has been significant work over the years on trying to resolve the SDP= vs SIP issue.=C2=A0 First as a small and very informal group prior to and = following the Orlando IETF.=C2=A0 The conclusion there was that SDP made mo= re sense for the emergency calling case, so the work progressed along that = route.=C2=A0 Then, in Berlin, Henning made his case that SDP was the wrong = choice, and Gunner volunteered to see if the SIP-only approach could work.= =C2=A0 We went through email discussions (before there was a list, but Henn= ing and the other SIP-only proponents were in the distribution list but did= not actively participate) and worked through the cases.=C2=A0 I published = revisions of the draft showing both as candidate solutions.=C2=A0 Finally, = as the draft tries to make clear, we eventually reached the conclusion that= neither approach is ideal, both have benefits and problems, but either cou= ld be made to work.=C2=A0 There are reasons why the SDP approach makes more= sense, especially for the emergency services case, and the SIP case has a = few more problems, but fundamentally, this more a stylistic/preference/reli= gion debate than just technical aspects. We've spent much time and effo= rt trying to make the best technical evaluation, and I believe we are movin= g forward on that basis.=C2=A0 I therefore don't have much patience for= reopening the debate a third time, especially when it comes down to person= al preference and not technical problems.=C2=A0 If we are going to ever get= anything completed that can be implemented and deployed, we need to move f= orward.

Therefore, I suggest that unless anyone can point to reasons why the SDP ap= proach will not work, we should accept the conclusion and move forward.


=C2=A0On Fri, Mar 13, 2015 at 4:30 PM, Ben Campbell <<mailto:ben@nostrum.com>ben@nostrum.com&g= t; wrote:

=C2=A0Hi,

=C2=A0For the record, I support this work. But I have some concerns about t= he proposed charter at <https://datatracker.ietf.org/doc/ch= arter-ietf-slim>https://datatracker.ietf.org/doc/charter-ietf-slim . Apologies if this rehashes old discussions; I have= only recently joined the mailing list (I did scan the archive, but likely = missed things.)

=C2=A0I don't find the charter text motivating the linkage between the = mail problem and the real-time problem very convincing. I'm not saying = it's wrong; just that it hasn't convinced me.

=C2=A0The text suggests a single work group to reinforce commonality in the= solutions. That seems backwards to me; I'd like to see more on why peo= ple think the problems benefit from a common solution. Do you think there w= ill be mechanism in common, beyond the use of language tags? Do you see a c= ommon implementor community? A common protocol development community?

=C2=A0I'd like to see something about why people don't think the re= al-time problem is at least partially solved by RFCs 3840 and 3841. If that= 's a forgone conclusion, the charter needs to clearly motivate it. The = draft is slightly more helpful here in mentioning that 3840/3841 were consi= dered but discarded, but that's not obvious from the proposed charter t= ext.

=C2=A0Part of this may be that I am not sure if this is looking at a call-r= outing problem (i.e. getting the call to an appropriate destination for a l= anguage) and/or a language negotiation problem (i.e. deciding what language= you are going to use once the call is established. The first is mentioned,= although the text about invoking translators, etc, might also imply the se= cond. The charter should clearly describe the problem.

=C2=A0If the idea is to finish the existing drafts, the charter should say = that. Even so,
=C2=A0the schedule seems optimistic, unless you expect those drafts to go t= o WGLC right after
=C2=A0the charter is approved.

=C2=A0I find paragraph 2 a bit hard to follow--it seems to be a single comp= lex sentence.

=C2=A0Thanks!

=C2=A0Ben.

=C2=A0_______________________________________________
=C2=A0SLIM mailing list
=C2=A0<mailto:SLIM@ie= tf.org>SLIM@ietf.org

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



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



--
Randall Gellens
Opinions are personal;=C2=A0 =C2=A0 facts are suspect;=C2=A0 =C2=A0 I speak= for myself only
-------------- Randomly selected tag: ---------------
Did you know...
That no one ever reads these things?

--001a1133b5b4ba035b05116a9946-- From nobody Mon Mar 16 10:12:48 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8486E1A88EF; Mon, 16 Mar 2015 10:12:43 -0700 (PDT) X-Quarantine-ID: <2DwT8_YRAbNu> 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: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2DwT8_YRAbNu; Mon, 16 Mar 2015 10:12:40 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 431BC1A878E; Mon, 16 Mar 2015 10:12:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1426525960; x=1458061960; h=message-id:date:to:from:subject:cc; bh=3QAkNKOyswsn6WuG7vDzmFep8egIjg41sEFAQ5NkINY=; b=OxPc6vgejcpacHG+DvjeG7atQo5wKIEEBJnv4WJpgd7umUseS3cPgkrI rOSqICCBiYr6AxEHnFmvpLyMaYQjNY4PSyPN+RzQrOzPe9bRelCbN2orh ZMgvZFAOjeSyn3ptaMLHDGoFkOnThIdvUpOdB1zAfBdDXwY0+7Fju5Zk7 I=; X-IronPort-AV: E=McAfee;i="5600,1067,7741"; a="108614672" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Mar 2015 10:12:39 -0700 X-IronPort-AV: E=Sophos;i="5.11,410,1422950400"; d="scan'208";a="926537639" Received: from plus.qualcomm.com ([10.52.255.8]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Mar 2015 10:12:39 -0700 Received: from Ironmsg04-R.qualcomm.com (ironmsg04-R.qualcomm.com [172.30.46.18]) by plus.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id t2GHCcIE015393; Mon, 16 Mar 2015 10:12:39 -0700 X-IronPort-AV: E=Sophos;i="5.11,410,1422950400"; d="scan'208";a="926537610" X-ojodefuego: yes Received: from unknown (HELO [99.111.97.136]) ([10.64.229.252]) by Ironmsg04-R.qualcomm.com with ESMTP; 16 Mar 2015 10:12:36 -0700 Mime-Version: 1.0 Message-Id: X-Mailer: Eudora for Mac OS X Date: Mon, 16 Mar 2015 10:12:33 -0700 To: Henning G Schulzrinne 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 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 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, IESG Subject: Re: [Slim] Comments on proposed SLIM charter X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 17:12:43 -0000 At 4:57 PM -0400 3/13/15, Henning G Schulzrinne wrote: > And, for the record, I continue to disagree with the current choice > of discarding a 3840-like (not necessarily the protocol itself) > approach. I consider this a call routing problem which is not > appropriate for an SDP solution, just by standard SIP architectural > layering. There has been significant work over the years on trying to resolve the SDP vs SIP issue. First as a small and very informal group prior to and following the Orlando IETF. The conclusion there was that SDP made more sense for the emergency calling case, so the work progressed along that route. Then, in Berlin, Henning made his case that SDP was the wrong choice, and Gunner volunteered to see if the SIP-only approach could work. We went through email discussions (before there was a list, but Henning and the other SIP-only proponents were in the distribution list but did not actively participate) and worked through the cases. I published revisions of the draft showing both as candidate solutions. Finally, as the draft tries to make clear, we eventually reached the conclusion that neither approach is ideal, both have benefits and problems, but either could be made to work. There are reasons why the SDP approach makes more sense, especially for the emergency services case, and the SIP case has a few more problems, but fundamentally, this more a stylistic/preference/religion debate than just technical aspects. We've spent much time and effort trying to make the best technical evaluation, and I believe we are moving forward on that basis. I therefore don't have much patience for reopening the debate a third time, especially when it comes down to personal preference and not technical problems. If we are going to ever get anything completed that can be implemented and deployed, we need to move forward. Therefore, I suggest that unless anyone can point to reasons why the SDP approach will not work, we should accept the conclusion and move forward. > On Fri, Mar 13, 2015 at 4:30 PM, Ben Campbell > <ben@nostrum.com> wrote: > > Hi, > > For the record, I support this work. But I have some concerns about > the proposed charter at > https://datatracker.ietf.org/doc/charter-ietf-slim > . Apologies if this rehashes old discussions; I have only recently > joined the mailing list (I did scan the archive, but likely missed > things.) > > I don't find the charter text motivating the linkage between the > mail problem and the real-time problem very convincing. I'm not > saying it's wrong; just that it hasn't convinced me. > > The text suggests a single work group to reinforce commonality in > the solutions. That seems backwards to me; I'd like to see more on > why people think the problems benefit from a common solution. Do > you think there will be mechanism in common, beyond the use of > language tags? Do you see a common implementor community? A common > protocol development community? > > I'd like to see something about why people don't think the > real-time problem is at least partially solved by RFCs 3840 and > 3841. If that's a forgone conclusion, the charter needs to clearly > motivate it. The draft is slightly more helpful here in mentioning > that 3840/3841 were considered but discarded, but that's not > obvious from the proposed charter text. > > Part of this may be that I am not sure if this is looking at a > call-routing problem (i.e. getting the call to an appropriate > destination for a language) and/or a language negotiation problem > (i.e. deciding what language you are going to use once the call is > established. The first is mentioned, although the text about > invoking translators, etc, might also imply the second. The charter > should clearly describe the problem. > > If the idea is to finish the existing drafts, the charter should > say that. Even so, > the schedule seems optimistic, unless you expect those drafts to go > to WGLC right after > the charter is approved. > > I find paragraph 2 a bit hard to follow--it seems to be a single > complex sentence. > > Thanks! > > Ben. > > _______________________________________________ > 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: --------------- There are some micro-organisms that exhibit characteristics of both plants and animals. When exposed to light they undergo photosynthesis; and when the lights go out, they turn into animals. But then again, don't we all? From nobody Mon Mar 16 12:34:18 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A08181A8F4B; Mon, 16 Mar 2015 12:34:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZSQOuJoVvtMv; Mon, 16 Mar 2015 12:34:08 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 8B1901A8F4F; Mon, 16 Mar 2015 12:34:06 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t2GJXtYG036082 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Mar 2015 14:34:06 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] From: "Ben Campbell" To: slim@ietf.org Date: Mon, 16 Mar 2015 14:33:55 -0500 Message-ID: <6A925F93-EDCD-48EE-8D71-67DA93AED066@nostrum.com> In-Reply-To: <0A4E9A96-56C9-4D15-81AE-5D8285654080@nostrum.com> References: <0A4E9A96-56C9-4D15-81AE-5D8285654080@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9r5066) Archived-At: Cc: IESG Subject: Re: [Slim] Comments on proposed SLIM charter X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 19:34:09 -0000 On 13 Mar 2015, at 15:30, Ben Campbell wrote: > I don't find the charter text motivating the linkage between the mail > problem and the real-time problem very convincing. I'm not saying it's > wrong; just that it hasn't convinced me. > > The text suggests a single work group to reinforce commonality in the > solutions. That seems backwards to me; I'd like to see more on why > people think the problems benefit from a common solution. Do you think > there will be mechanism in common, beyond the use of language tags? Do > you see a common implementor community? A common protocol development > community? Hi SLIM list participants: I see that one of my comments has generated some discussion (namely the SIP vs SDP discussion.) Does anyone have thoughts on my other comment (quoted above)? Thanks! Ben. From nobody Mon Mar 16 12:48:09 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CBFB1A9055 for ; Mon, 16 Mar 2015 12:48:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.588 X-Spam-Level: X-Spam-Status: No, score=-3.588 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6_Jk0rORAJxn for ; Mon, 16 Mar 2015 12:48:05 -0700 (PDT) Received: from millet.cc.columbia.edu (millet.cc.columbia.edu [128.59.72.250]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F1921A904D for ; Mon, 16 Mar 2015 12:47:54 -0700 (PDT) Received: from hazelnut (hazelnut.cc.columbia.edu [128.59.213.250]) by millet.cc.columbia.edu (8.13.8/8.13.8) with ESMTP id t2GJiKn0026127 for ; Mon, 16 Mar 2015 15:47:53 -0400 Received: from hazelnut (localhost.localdomain [127.0.0.1]) by hazelnut (Postfix) with ESMTP id 2AF2C6D for ; Mon, 16 Mar 2015 15:47:53 -0400 (EDT) Received: from paneer.cc.columbia.edu (paneer.cc.columbia.edu [128.59.29.4]) by hazelnut (Postfix) with ESMTP id E6F416D for ; Mon, 16 Mar 2015 15:47:52 -0400 (EDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by paneer.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id t2GJlqAN003085 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 16 Mar 2015 15:47:52 -0400 (EDT) Received: by qcyi15 with SMTP id i15so54239724qcy.0 for ; Mon, 16 Mar 2015 12:47:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=rO2BYwpeMpBdHYZe/wFNci+MbZvoPT4aogU2F7h5TKM=; b=JkPvz1MtBwrC4mT/q+7BPCNvPLTm65Ge0bVbCqJALaUxU4Xb8jtg30ProtenwA0hSB 2o0bfgeBt3NaGNBLgNfdmTPJq/GNLiRz/tGckPXPXYpymph5jL5f2saml1nkAy3Jkr4Q qjp6qCRBtkWGiPViFMukgHqjROeLP3tcXOB3a1nvyAyrke7Aql0FiO+sV3R5xDgN6uT+ UOP0Jf9DJEYFeSbO1y85rkSrSAFw1BieROtm8NHab14TRVj+MEV43NskLb1w+2jSX5fl eJEe8hLlmyWrJlGkDpKLM+/BO9rsCiaYRxWJdPwzV/LD3ON1v54tCtCfiHVDIO4IPjSj dwTA== X-Gm-Message-State: ALoCoQl8hHzIt9wsKiM3dmEOwE+nOB38qff+CZVEduQyZIH3H39sNbT71mUZgzlPtjtjycuM544upzxb+3EuJtsIq+QKRLq2jXuxz3t0wNCHZ8tmy/hiCUllH2LMJyUqkY4ijoRdgxtM X-Received: by 10.229.226.71 with SMTP id iv7mr45194439qcb.13.1426535272480; Mon, 16 Mar 2015 12:47:52 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.229.226.71 with SMTP id iv7mr45194430qcb.13.1426535272406; Mon, 16 Mar 2015 12:47:52 -0700 (PDT) Received: by 10.140.250.2 with HTTP; Mon, 16 Mar 2015 12:47:51 -0700 (PDT) In-Reply-To: <6A925F93-EDCD-48EE-8D71-67DA93AED066@nostrum.com> References: <0A4E9A96-56C9-4D15-81AE-5D8285654080@nostrum.com> <6A925F93-EDCD-48EE-8D71-67DA93AED066@nostrum.com> Date: Mon, 16 Mar 2015 15:47:51 -0400 Message-ID: From: Henning Schulzrinne To: Ben Campbell Content-Type: multipart/alternative; boundary=001a1134ad1c2bfca805116d2054 X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.4 Archived-At: Cc: slim@ietf.org, IESG Subject: Re: [Slim] Comments on proposed SLIM charter X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 19:48:07 -0000 --001a1134ad1c2bfca805116d2054 Content-Type: text/plain; charset=UTF-8 So far, at least, I'm not seeing much in common. Among other differences, the one-way (largely) nature of email seems rather different from the OPTIONS-style model in SIP, and the media division doesn't seem to apply as naturally. Also, many of the typical email attachments may already have language attributes, e.g., via the lang HTML tag, format-specific attributes embedded in Word and PDF files, or the RFC 3282 Content-Language header. Henning On Mon, Mar 16, 2015 at 3:33 PM, Ben Campbell wrote: > On 13 Mar 2015, at 15:30, Ben Campbell wrote: > > I don't find the charter text motivating the linkage between the mail >> problem and the real-time problem very convincing. I'm not saying it's >> wrong; just that it hasn't convinced me. >> >> The text suggests a single work group to reinforce commonality in the >> solutions. That seems backwards to me; I'd like to see more on why people >> think the problems benefit from a common solution. Do you think there will >> be mechanism in common, beyond the use of language tags? Do you see a >> common implementor community? A common protocol development community? >> > > Hi SLIM list participants: > > I see that one of my comments has generated some discussion (namely the > SIP vs SDP discussion.) Does anyone have thoughts on my other comment > (quoted above)? > > Thanks! > > Ben. > > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim > --001a1134ad1c2bfca805116d2054 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
So far, at least, I'm not seeing much in common. Among= other differences, the one-way (largely) nature of email seems rather diff= erent from the OPTIONS-style model in SIP, and the media division doesn'= ;t seem to apply as naturally. Also, many of the typical email attachments = may already have language attributes, e.g., via the lang HTML tag, format-s= pecific attributes embedded in Word and PDF files, or the RFC 3282 Content-= Language header.

Henning

On Mon, Mar 16, 2015 at 3:= 33 PM, Ben Campbell <ben@nostrum.com> wrote:
On 13 Mar 2015, at 15:30, Ben Campbell wrote:

I don't find the charter text motivating the linkage between the mail p= roblem and the real-time problem very convincing. I'm not saying it'= ;s wrong; just that it hasn't convinced me.

The text suggests a single work group to reinforce commonality in the solut= ions. That seems backwards to me; I'd like to see more on why people th= ink the problems benefit from a common solution. Do you think there will be= mechanism in common, beyond the use of language tags? Do you see a common = implementor community? A common protocol development community?

Hi SLIM list participants:

I see that one of my comments has generated some discussion (namely the SIP= vs SDP discussion.) Does anyone have thoughts on my other comment (quoted = above)?

Thanks!

Ben.

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

--001a1134ad1c2bfca805116d2054-- From nobody Mon Mar 16 15:21:27 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 234A31AC3BC for ; Mon, 16 Mar 2015 15:21:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 53aEJX4i0aiu for ; Mon, 16 Mar 2015 15:21:25 -0700 (PDT) Received: from bin-vsp-out-01.atm.binero.net (vsp-authed01.binero.net [195.74.38.224]) (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 928E61AC3B8 for ; Mon, 16 Mar 2015 15:21:24 -0700 (PDT) X-Halon-ID: c7caa06c-cc2a-11e4-8274-005056917a89 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.42] (unknown [77.53.231.174]) by bin-vsp-out-01.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Mon, 16 Mar 2015 23:21:24 +0100 (CET) Message-ID: <55075760.2010408@omnitor.se> Date: Mon, 16 Mar 2015 23:21:20 +0100 From: =?UTF-8?B?R3VubmFyIEhlbGxzdHLDtm0=?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Henning Schulzrinne References: <0A4E9A96-56C9-4D15-81AE-5D8285654080@nostrum.com> <55035948.2070404@alum.mit.edu> <5503E065.5030602@omnitor.se> <55060B1C.5040802@omnitor.se> <55068407.6040807@omnitor.se> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: slim@ietf.org Subject: Re: [Slim] Comments on proposed SLIM charter X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 22:21:26 -0000 Henning Schulzrinne skrev den 2015-03-16 13:46: > I suspect we're talking past each other. My suggestion, following your > comments, is to do two orthogonal things: > > (1) A high-level declaration of media capabilities sufficient for call > routing, found in the SIP header. It does not rely on SDP and simply > provides (language, media direction, media type) tuples. > > (2) A per-media description of the language used by a media stream, in > SDP. No preferences, just declaration, similar to the RFC 4796 model. > This is useful also for multi-stream sessions, e.g., where one audio > stream is in the original language, another is the simultaneous > translation. Ah, yes, I saw it as a limited functionality duplication of the SIP information. But, yes, it makes sense. > > The SDP one seems trivial to describe as long as there's no notion of > negotiation or matching at the protocol-spec level. (Obviously, SDP > end points can do whatever they like, including dropping media streams > they have no use for.) > > Does that make sense? Yes. > > Henning > Gunnar -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 From nobody Wed Mar 18 07:32:17 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08C321A0187 for ; Wed, 18 Mar 2015 07:32:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 nKqV6WIwnQr8 for ; Wed, 18 Mar 2015 07:32:15 -0700 (PDT) Received: from resqmta-ch2-01v.sys.comcast.net (resqmta-ch2-01v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:33]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E106F1A00BE for ; Wed, 18 Mar 2015 07:32:14 -0700 (PDT) Received: from resomta-ch2-17v.sys.comcast.net ([69.252.207.113]) by resqmta-ch2-01v.sys.comcast.net with comcast id 52Y01q0072TL4Rh012YE7C; Wed, 18 Mar 2015 14:32:14 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-17v.sys.comcast.net with comcast id 52YD1q00P3Ge9ey012YDEs; Wed, 18 Mar 2015 14:32:14 +0000 Message-ID: <55098C6C.50003@alum.mit.edu> Date: Wed, 18 Mar 2015 10:32:12 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: slim@ietf.org References: <0A4E9A96-56C9-4D15-81AE-5D8285654080@nostrum.com> <6A925F93-EDCD-48EE-8D71-67DA93AED066@nostrum.com> In-Reply-To: <6A925F93-EDCD-48EE-8D71-67DA93AED066@nostrum.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1426689134; bh=Ssp6vqE36piyPPY6Ba292fZzwm4ZZSvwnjBxcYtKpf8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=GYhmkwUnSWX42NwCST/F4wEg/0XWPObSB4vO5VTnT4TLhIcYxKizfhzNN3QmNeVFO sTmSv4PJrYvRxn5EtM6anAnzpEqT9ftosakvRsYhRpJLLGVJQxykRqXqXQ/4Ni787a BDmmDw9OE38K7hBNrdn2r8QOM3Xk280mmKlYRBfKXkgmFGx9lOkAtKTSweVJth8QAy /S3h8ASO8yLef1K0HQ7M21SayNais3chcl40nRG4o1l7YzMJVBJuSGYYcDkMn1y4Xv RelusmBS9tBfrK5mBpGbBWEC069GCeP1aMDkXhI0agIKlRdrTxup0FINQJEQmCFiYm D79IA5mYsYGWQ== Archived-At: Subject: Re: [Slim] Comments on proposed SLIM charter X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 14:32:16 -0000 On 3/16/15 3:33 PM, Ben Campbell wrote: > On 13 Mar 2015, at 15:30, Ben Campbell wrote: > >> I don't find the charter text motivating the linkage between the mail >> problem and the real-time problem very convincing. I'm not saying it's >> wrong; just that it hasn't convinced me. >> >> The text suggests a single work group to reinforce commonality in the >> solutions. That seems backwards to me; I'd like to see more on why >> people think the problems benefit from a common solution. Do you think >> there will be mechanism in common, beyond the use of language tags? Do >> you see a common implementor community? A common protocol development >> community? > > Hi SLIM list participants: > > I see that one of my comments has generated some discussion (namely the > SIP vs SDP discussion.) Does anyone have thoughts on my other comment > (quoted above)? I don't see much commonality. I have suspicion that there will be distinct bodies of people interested in working on these two things. Thanks, Paul From nobody Thu Mar 19 10:52:34 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E20B1A6F0E for ; Thu, 19 Mar 2015 10:14:54 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -9.011 X-Spam-Level: X-Spam-Status: No, score=-9.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_INVITATION=-2, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DkMM5W5L-dEI for ; Thu, 19 Mar 2015 10:14:52 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAF841A3BA6 for ; Thu, 19 Mar 2015 10:14:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1426785291; x=1458321291; h=message-id:in-reply-to:references:date:to:from:subject: content-transfer-encoding; bh=/EaEpV1/3ohEe64LgOoO2MUScNqYtIbk3nHGHTDc4kA=; b=dhODodfmypCzhmVgg+XHoICaYSLK6NNBhIgXECPExhy9BEquof0WMwIl DzhfgZ/BKJIl29bbLqj8uM2wYN58gmxoBb1Wc7+lpqgi6EUgjjDoL3cTm 0KRM/nAIQl7rDvYO+ebH+mCwfIZfbk6KfFT3De4SCYiJwGXqERDVTuCuc U=; X-IronPort-AV: E=McAfee;i="5600,1067,7745"; a="85348807" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by sabertooth01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Mar 2015 10:14:51 -0700 X-IronPort-AV: E=Sophos;i="5.11,430,1422950400"; d="scan'208";a="875431444" Received: from plus.qualcomm.com ([10.52.255.8]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Mar 2015 10:14:51 -0700 Received: from Ironmsg04-L.qualcomm.com (ironmsg04-L.qualcomm.com [172.30.48.19]) by plus.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id t2JHEjOU003918; Thu, 19 Mar 2015 10:14:46 -0700 X-IronPort-AV: E=Sophos;i="5.11,430,1422950400"; d="scan'208";a="841191828" X-ojodefuego: yes Received: from unknown (HELO [99.111.97.136]) ([10.64.234.127]) by Ironmsg04-L.qualcomm.com with ESMTP; 19 Mar 2015 10:14:43 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <1653005226.1776993.1426114662435.POLL_INVITECONTACT_PARTICIPANT_INVIT ATION_WITH_MESSAGE.doodle@worker1> References: <1653005226.1776993.1426114662435.POLL_INVITECONTACT_PARTICIPANT_INVIT ATION_WITH_MESSAGE.doodle@worker1> X-Mailer: Eudora for Mac OS X Date: Thu, 19 Mar 2015 10:14:39 -0700 To: slim@ietf.org, Harald Alvestrand , Gunnar Hellstrom , John C Klensin , "Flemming Andreasen" , Brian Rosen , "Peter Saint-Andre" , Keith Drage , Brian Rosen , "Ari Keranen" , Pete Resnick , Alexey Melnikov , Eric Burger , Eric Burger , "Hutton, Andrew" , Nathaniel Borenstein , "Nik Tomkinson" , , Chris Newman 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 X-Random-Sig-Tag: 1.0b28 Archived-At: X-Mailman-Approved-At: Thu, 19 Mar 2015 10:52:33 -0700 Subject: Re: [Slim] SLIM (human language) meet-up in Dallas, etc. X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 17:14:54 -0000 The Doodle poll shows Tuesday or Thursday 10-11=20 AM look best. Unless things have changed and=20 someone now can't make it, let's meet Tuesday at=20 10:00 AM. I'll see if I can find us somewhere to=20 meet. At 9:01 AM -0700 3/10/15, Randall Gellens wrote: > Hi SLIMmers, > > Please let me know your preferred days and=20 > times for a meeting on SLIM (the human language=20 > work) in Dallas. I'll then send out a Doodle=20 > poll with the most promising slots. At 11:57 PM +0100 3/11/15, Randall Gellens (via Doodle) wrote: > Randall Gellens invites you to participate in=20 > the Doodle poll "SLIM (Human Language) informal=20 > discussion on progress." > > > > >=20 > > > > Hi there, > > > > > > > > Randall Gellens=20 > (doodle@randy.pensive.org) invites you to=20 > participate in the Doodle poll "SLIM (Human=20 > Language) informal discussion on progress." > > > > Randall Gellens says: > > Informal meeting for=20 > people interested in SLIM (human language) and=20 > how to make progress. Slots based on email=20 > discussion. > > > >=20 > =20 > =20 > Participate now=20 > > > > > What is Doodle?=20 > Doodle is a web service that helps Randall=20 > Gellens to find a suitable date for meeting=20 > with a group of people.=20 > Learn=20 > more about how Doodle works. > > > >=20 > You have=20 > received this e-mail because "Randall Gellens"=20 > has invited you to participate in the Doodle=20 > poll "SLIM (Human Language) informal discussion=20 > on progress." > > Doodle AG, Werdstrasse 21, 8021 Z=FCrich > > > > _______________________________________________ > 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: --------------- razbliuto (ros-blee-OO-toe; Russian; noun): the feeling a person retains for someone he or she once loved. From nobody Thu Mar 19 10:52:36 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E725F1A6F20 for ; Thu, 19 Mar 2015 10:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.011 X-Spam-Level: X-Spam-Status: No, score=-9.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_INVITATION=-2, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aIV74yjr26fx for ; Thu, 19 Mar 2015 10:18:08 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A9E91A6F1E for ; Thu, 19 Mar 2015 10:18:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1426785488; x=1458321488; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=svi660pQ4V4uRvCatzbB9nRpQ9oDxv/PocLXt2O3L6g=; b=WLcAZPS+bhpEMWUhlq7QV56KqeyxLGll2rOB5Ek3f4eFt43+wfAVflQa GxHhy6++yJXcpAD0btOZqPlMihbhPQ/WOvoqCt8xy2Co2qdKUn2Zvys8e KvazjvN/tgblmC9tTZ1pK7MQYyR4GR0mewJg7Z6Q7VR+RIN/2nMh/+1jR g=; X-IronPort-AV: E=McAfee;i="5600,1067,7745"; a="109276765" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Mar 2015 10:18:07 -0700 X-IronPort-AV: E=Sophos;i="5.11,430,1422950400"; d="scan'208";a="929041702" Received: from nasanexm01f.na.qualcomm.com ([10.85.0.32]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 19 Mar 2015 10:18:07 -0700 Received: from presnick-mac.local (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.85.0.32) with Microsoft SMTP Server (TLS) id 15.0.995.29; Thu, 19 Mar 2015 10:18:04 -0700 Message-ID: <550B04CB.5070507@qti.qualcomm.com> Date: Thu, 19 Mar 2015 12:18:03 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Randall Gellens References: <1653005226.1776993.1426114662435.POLL_INVITECONTACT_PARTICIPANT_INVIT ATION_WITH_MESSAGE.doodle@worker1> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01F.na.qualcomm.com (10.85.0.32) To NASANEXM01F.na.qualcomm.com (10.85.0.32) Archived-At: X-Mailman-Approved-At: Thu, 19 Mar 2015 10:52:33 -0700 Cc: slim@ietf.org, hannes.tschofenig@gmx.net, Ari Keranen , "Hutton, Andrew" , Eric Burger , Alexey Melnikov , Chris Newman , Keith Drage , Gunnar Hellstrom , Nathaniel Borenstein , Flemming Andreasen , Harald Alvestrand , Peter Saint-Andre , Brian Rosen , John C Klensin , Brian Rosen , Nik Tomkinson Subject: Re: [Slim] SLIM (human language) meet-up in Dallas, etc. X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 17:18:10 -0000 Tuesday 10am is not one of the choices. I think you are looking at it in Pacific Time instead of Central Time. pr On 3/19/15 12:14 PM, Randall Gellens wrote: > The Doodle poll shows Tuesday or Thursday 10-11 AM look best. Unless > things have changed and someone now can't make it, let's meet Tuesday > at 10:00 AM. I'll see if I can find us somewhere to meet. > > > At 9:01 AM -0700 3/10/15, Randall Gellens wrote: > >> Hi SLIMmers, >> >> Please let me know your preferred days and times for a meeting on >> SLIM (the human language work) in Dallas. I'll then send out a >> Doodle poll with the most promising slots. > > At 11:57 PM +0100 3/11/15, Randall Gellens (via Doodle) wrote: > >> Randall Gellens invites you to participate in the Doodle poll "SLIM >> (Human Language) informal discussion on progress." >> >> >> >> >> >> >> >> >> >> Hi there, >> >> >> >> >> >> >> Randall Gellens >> (doodle@randy.pensive.org) invites you to participate in the Doodle >> poll "SLIM (Human Language) informal discussion on progress." >> >> >> >> Randall Gellens says: >> >> Informal meeting for people interested >> in SLIM (human language) and how to make progress. Slots based on >> email discussion. >> >> >> >> >> >> >> Participate >> now >> >> >> >> What is Doodle? Doodle is a web service >> that helps Randall Gellens to find a suitable date for meeting with a >> group of people. >> Learn >> more about how Doodle works. >> >> >> >> >> You have received this e-mail >> because "Randall Gellens" has invited you to participate in the >> Doodle poll "SLIM (Human Language) informal discussion on progress." >> >> Doodle AG, Werdstrasse 21, 8021 Zürich >> >> >> >> _______________________________________________ >> SLIM mailing list >> SLIM@ietf.org >> https://www.ietf.org/mailman/listinfo/slim > > -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Thu Mar 19 11:06:56 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E35A1A88F9 for ; Thu, 19 Mar 2015 10:56:14 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -9.011 X-Spam-Level: X-Spam-Status: No, score=-9.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_INVITATION=-2, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c71JU4P4a_ma for ; Thu, 19 Mar 2015 10:56:11 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE3841A88FF for ; Thu, 19 Mar 2015 10:56:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1426787770; x=1458323770; h=message-id:date:to:from:subject: content-transfer-encoding; bh=VIbqExpm45uljFbIlgqvPPiULweuThZYirvmoZPX/70=; b=hymdv6D71oyy/3XbaQKZpjZSG6ehcva3nT56r5fqkXfJx/Jxc0VJh0+v Crgg7YKHZpEYKbQ+x1VVyXD4rYhUPBTqz7rycpp5aGAUXgLFvY9AbhA0I SPbp4t1kAqu7fyx26GqPKSbVVpuZhjJm6niy2j6/gdWUAm3SV3E1VyaAp 8=; X-IronPort-AV: E=McAfee;i="5600,1067,7745"; a="201414495" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Mar 2015 10:55:49 -0700 X-IronPort-AV: E=Sophos;i="5.11,431,1422950400"; d="scan'208";a="866559096" X-ojodefuego: yes Received: from unknown (HELO [99.111.97.136]) ([10.64.234.127]) by Ironmsg03-L.qualcomm.com with ESMTP; 19 Mar 2015 10:55:41 -0700 Mime-Version: 1.0 Message-Id: X-Mailer: Eudora for Mac OS X Date: Thu, 19 Mar 2015 10:55:38 -0700 To: , Harald Alvestrand , "Gunnar Hellstrom" , John C Klensin , "Flemming Andreasen" , Brian Rosen , "Peter Saint-Andre" , Keith Drage , Brian Rosen , "Ari Keranen" , Pete Resnick , Alexey Melnikov , Eric Burger , Eric Burger , "Hutton, Andrew" , Nathaniel Borenstein , "Nik Tomkinson" , , Chris Newman 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 Archived-At: X-Mailman-Approved-At: Thu, 19 Mar 2015 11:06:55 -0700 Subject: Re: [Slim] SLIM (human language) meet-up in Dallas, etc. X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 17:56:14 -0000 The Doodle poll shows Tuesday or Thursday 12=20 Noon-1 PM look best. Unless things have changed=20 and someone now can't make it, let's meet Tuesday=20 at 12 Noon. Should we meet in the hotel restaurant and try to=20 do the conference at a table, or would a more=20 quiet place be better? Please let me know your=20 preferences. At 9:01 AM -0700 3/10/15, Randall Gellens wrote: > Hi SLIMmers, > > Please let me know your preferred days and=20 > times for a meeting on SLIM (the human language=20 > work) in Dallas. I'll then send out a Doodle=20 > poll with the most promising slots. At 11:57 PM +0100 3/11/15, Randall Gellens (via Doodle) wrote: > Randall Gellens invites you to participate in=20 > the Doodle poll "SLIM (Human Language) informal=20 > discussion on progress." > > > > > >=20 > > > > Hi there, > > > > > > > > Randall Gellens=20 > (doodle@randy.pensive.org) invites you to=20 > participate in the Doodle poll "SLIM (Human=20 > Language) informal discussion on progress." > > > > Randall Gellens says: > > Informal meeting for=20 > people interested in SLIM (human language) and=20 > how to make progress. Slots based on email=20 > discussion. > > > > >=20 > Participate=20 > now > > > > What is Doodle?=20 > Doodle is a web service that helps Randall=20 > Gellens to find a suitable date for meeting=20 > with a group of people.=20 > Learn=20 > more about how Doodle works. > > > > > You have=20 > received this e-mail because "Randall Gellens"=20 > has invited you to participate in the Doodle=20 > poll "SLIM (Human Language) informal discussion=20 > on progress." > > Doodle AG, Werdstrasse 21, 8021 Z=FCrich > > > > _______________________________________________ > 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: --------------- razbliuto (ros-blee-OO-toe; Russian; noun): the feeling a person retains for someone he or she once loved. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- When the plane you are on is late, the plane you want to transfer to is on time. From nobody Thu Mar 19 11:27:44 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BB631A87E3 for ; Thu, 19 Mar 2015 11:07:06 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -9.011 X-Spam-Level: X-Spam-Status: No, score=-9.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_INVITATION=-2, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RJxQY6xZ66uB for ; Thu, 19 Mar 2015 11:07:01 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 877A91A8743 for ; Thu, 19 Mar 2015 11:06:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1426788410; x=1458324410; h=message-id:in-reply-to:references:date:to:from:subject: cc:content-transfer-encoding; bh=KqUBn9GQRCS1hLLc+AkeaOhsKKpmnycHFZNLXFgO/W4=; b=Z2mxI3T4oZuBndd3R3B1btkatjBcx+fHkF/PXp1JrXgNoOt21lareMBs hZUu/pjRr2XIMA7dv0n+E1rGpkxs7RHAYACBgpML2geyHHhALIWioZBCW pBokwuNc7OKVoja1q5It/pdrnSwDAkGpnEnfZqA3RXwZSCc9bzIdbPIsz A=; X-IronPort-AV: E=McAfee;i="5600,1067,7745"; a="109283108" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Mar 2015 11:06:49 -0700 X-IronPort-AV: E=Sophos;i="5.11,430,1422950400"; d="scan'208";a="929069569" Received: from plus.qualcomm.com ([10.52.255.8]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Mar 2015 11:06:49 -0700 Received: from Ironmsg04-L.qualcomm.com (ironmsg04-L.qualcomm.com [172.30.48.19]) by plus.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id t2JI6i5m008092; Thu, 19 Mar 2015 11:06:45 -0700 X-IronPort-AV: E=Sophos;i="5.11,431,1422950400"; d="scan'208";a="841225200" X-ojodefuego: yes Received: from unknown (HELO [99.111.97.136]) ([10.64.234.127]) by Ironmsg04-L.qualcomm.com with ESMTP; 19 Mar 2015 11:06:34 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <550B04CB.5070507@qti.qualcomm.com> References: <1653005226.1776993.1426114662435.POLL_INVITECONTACT_PARTICIPANT_INVIT ATION_WITH_MESSAGE.doodle@worker1> <550B04CB.5070507@qti.qualcomm.com> X-Mailer: Eudora for Mac OS X Date: Thu, 19 Mar 2015 11:06:33 -0700 To: Pete Resnick 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 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 Archived-At: X-Mailman-Approved-At: Thu, 19 Mar 2015 11:27:42 -0700 Cc: slim@ietf.org, Nik Tomkinson , Ari Keranen , "Hutton, Andrew" , Harald Alvestrand , Chris Newman , Keith Drage , Gunnar Hellstrom , Nathaniel Borenstein , Flemming Andreasen , Eric Burger , Brian Rosen , Peter Saint-Andre , Brian Rosen , John C Klensin , Alexey Melnikov , hannes.tschofenig@gmx.net Subject: Re: [Slim] SLIM (human language) meet-up in Dallas, etc. X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 18:07:06 -0000 Yes, thank you for catching it. 12 Noon it is. At 12:18 PM -0500 3/19/15, Pete Resnick wrote: > Tuesday 10am is not one of the choices. I think=20 > you are looking at it in Pacific Time instead=20 > of Central Time. > > pr > > On 3/19/15 12:14 PM, Randall Gellens wrote: >> The Doodle poll shows Tuesday or Thursday=20 >> 10-11 AM look best. Unless things have=20 >> changed and someone now can't make it, let's=20 >> meet Tuesday at 10:00 AM. I'll see if I can=20 >> find us somewhere to meet. >> >> >> At 9:01 AM -0700 3/10/15, Randall Gellens wrote: >> >>> Hi SLIMmers, >>> >>> Please let me know your preferred days and=20 >>> times for a meeting on SLIM (the human=20 >>> language work) in Dallas. I'll then send out=20 >>> a Doodle poll with the most promising slots. >> >> At 11:57 PM +0100 3/11/15, Randall Gellens (via Doodle) wrote: >> >>> Randall Gellens invites you to participate=20 >>> in the Doodle poll "SLIM (Human Language)=20 >>> informal discussion on progress." >>> >>> >>> >>> >>> >>>=20 >>> >>> >>> >>> Hi there, >>> >>> >>> >>> >>> >>> >>> Randall Gellens=20 >>> (doodle@randy.pensive.org) invites you to=20 >>> participate in the Doodle poll "SLIM (Human=20 >>> Language) informal discussion on progress." >>> >>> >>> >>> Randall Gellens says: >>> >>> Informal meeting=20 >>> for people interested in SLIM (human=20 >>> language) and how to make progress. Slots=20 >>> based on email discussion. >>> >>> >>> >>> >>> >>> >>>=20 >>> Participate=20 >>> now >>> >>> >>> >>> What is Doodle?=20 >>> Doodle is a web service that helps Randall=20 >>> Gellens to find a suitable date for meeting=20 >>> with a group of people.=20 >>> Learn=20 >>> more about how Doodle works. >>> >>> >>> >>> >>> You=20 >>> have received this e-mail because "Randall=20 >>> Gellens" has invited you to participate in=20 >>> the Doodle poll "SLIM (Human Language)=20 >>> informal discussion on progress." >>> >>> Doodle AG, Werdstrasse 21, 8021 Z=FCrich >>> >>> >>> >>> _______________________________________________ >>> SLIM mailing list >>> SLIM@ietf.org >>> https://www.ietf.org/mailman/listinfo/slim >> >> > > -- > Pete Resnick > Qualcomm Technologies, Inc. - +1 (858)651-4478 > > _______________________________________________ > 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 the employees come first, then they are happy. A motivated employee treats the customer well. The customer is happy so they keep coming back, which pleases the shareholders. It's not one of the enduring Green mysteries of all time, it is just the way it works. --Herb Kelleher, Southwest Airlines CEO, 1994 From nobody Thu Mar 19 11:27:45 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2EA61A8778 for ; Thu, 19 Mar 2015 11:07:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aQyR_F43c7Li for ; Thu, 19 Mar 2015 11:07:15 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80F0F1A88F6 for ; Thu, 19 Mar 2015 11:07:15 -0700 (PDT) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YYeqS-000POC-C0; Thu, 19 Mar 2015 14:07:00 -0400 Date: Thu, 19 Mar 2015 14:06:55 -0400 From: John C Klensin To: Randall Gellens Message-ID: <0F508E4CEF46BF2164108406@JcK-HP8200.jck.com> In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: X-Mailman-Approved-At: Thu, 19 Mar 2015 11:27:42 -0700 Cc: slim@ietf.org, hannes.tschofenig@gmx.net, Ari Keranen , "Hutton, Andrew" , Eric Burger , Alexey Melnikov , Chris Newman , Pete Resnick , Keith Drage , Gunnar Hellstrom , Nathaniel Borenstein , Flemming Andreasen , Harald Alvestrand , Peter Saint-Andre , Brian Rosen , Brian Rosen , Nik Tomkinson Subject: Re: [Slim] SLIM (human language) meet-up in Dallas, etc. X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 18:07:19 -0000 --On Thursday, March 19, 2015 10:55 -0700 Randall Gellens wrote: > The Doodle poll shows Tuesday or Thursday 12 Noon-1 PM look > best. Unless things have changed and someone now can't make > it, let's meet Tuesday at 12 Noon. > > Should we meet in the hotel restaurant and try to do the > conference at a table, or would a more quiet place be better? > Please let me know your preferences. I am definitely not available, even remotely, Tuesday noon Dallas time. Thurday noon probably would work, but only if you can make remote partication arrangements, which are probably impractical if you are planning a lunch meeting. Have a good meeting; I'll look forward to hearing about the results. best, john From nobody Sat Mar 21 09:45:16 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FBAA1A87D2 for ; Fri, 20 Mar 2015 19:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.011 X-Spam-Level: X-Spam-Status: No, score=-9.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_INVITATION=-2, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4dCDp-tnUQcT for ; Fri, 20 Mar 2015 19:22:07 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 305821A87C7 for ; Fri, 20 Mar 2015 19:22:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1426904527; x=1458440527; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version:content-transfer-encoding; bh=ki2M5ppmtHb5Daf0ayGc55ngy3bQ0i+/DUI9QzN4xqM=; b=rGIM2SkAwEYfCq0sdkaZz9gzwmOI1fMwF8geyTa9CXWB3zyBovkK7qwW 7j8loKAlUxgu98QvAiXKJT2PGYf5bQ+JHoqsmO/kP96ythBZevu5kJ7eK Kcrscbk/0Z/oUffw3WRw0mNMZbNU80Jc+HFAOpggttOpHchklnQOv+AkA A=; X-IronPort-AV: E=McAfee;i="5600,1067,7746"; a="85445773" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by sabertooth01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Mar 2015 19:22:06 -0700 X-IronPort-AV: E=Sophos;i="5.11,440,1422950400"; d="scan'208";a="867747042" Received: from nasanexm02f.na.qualcomm.com ([10.85.0.87]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 20 Mar 2015 19:21:54 -0700 Received: from [99.111.97.136] (10.80.80.8) by nasanexm02f.na.qualcomm.com (10.85.0.87) with Microsoft SMTP Server (TLS) id 15.0.995.29; Fri, 20 Mar 2015 19:21:53 -0700 Message-ID: In-Reply-To: References: <1653005226.1776993.1426114662435.POLL_INVITECONTACT_PARTICIPANT_INVIT ATION_WITH_MESSAGE.doodle@worker1> <550B04CB.5070507@qti.qualcomm.com> X-Mailer: Eudora for Mac OS X Date: Fri, 20 Mar 2015 19:21:51 -0700 To: Nik Tomkinson , Ari Keranen , "Hutton, Andrew" , Harald Alvestrand , Chris Newman , Keith Drage , Gunnar Hellstrom , Nathaniel Borenstein , Flemming Andreasen , Eric Burger , Brian Rosen , Peter Saint-Andre , Brian Rosen , John C Klensin , Alexey Melnikov , , Pete Resnick 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-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01E.na.qualcomm.com (10.85.0.31) To nasanexm02f.na.qualcomm.com (10.85.0.87) Archived-At: X-Mailman-Approved-At: Sat, 21 Mar 2015 09:45:15 -0700 Cc: slim@ietf.org Subject: Re: [Slim] SLIM (human language) meet-up in Dallas, etc. X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2015 02:22:09 -0000 Are people Ok with making this a brown-bag=20 meeting (i.e., if you want food, bring your own)?=20 If so, I think we may be able to snag a room with=20 Wi-Fi, which in theory will make it possible for=20 people to participate remotely. At 11:06 AM -0700 3/19/15, Randall Gellens wrote: > Yes, thank you for catching it. 12 Noon it is. > > > At 12:18 PM -0500 3/19/15, Pete Resnick wrote: > >> Tuesday 10am is not one of the choices. I=20 >> think you are looking at it in Pacific Time=20 >> instead of Central Time. >> >> pr >> >> On 3/19/15 12:14 PM, Randall Gellens wrote: >>> The Doodle poll shows Tuesday or Thursday=20 >>> 10-11 AM look best. Unless things have=20 >>> changed and someone now can't make it, let's=20 >>> meet Tuesday at 10:00 AM. I'll see if I can=20 >>> find us somewhere to meet. >>> >>> >>> At 9:01 AM -0700 3/10/15, Randall Gellens wrote: >>> >>>> Hi SLIMmers, >>>> >>>> Please let me know your preferred days and=20 >>>> times for a meeting on SLIM (the human=20 >>>> language work) in Dallas. I'll then send=20 >>>> out a Doodle poll with the most promising=20 >>>> slots. >>> >>> At 11:57 PM +0100 3/11/15, Randall Gellens (via Doodle) wrote: >>> >>>> Randall Gellens invites you to participate=20 >>>> in the Doodle poll "SLIM (Human Language)=20 >>>> informal discussion on progress." >>>> >>>> >>>> >>>> >>>> >>>> >>>>=20 >>>> >>>> >>>> >>>> Hi there, >>>> >>>> >>>> >>>> >>>> >>>> >>>> Randall=20 >>>> Gellens (doodle@randy.pensive.org) invites=20 >>>> you to participate in the Doodle poll "SLIM=20 >>>> (Human Language) informal discussion on=20 >>>> progress." >>>> >>>> >>>> >>>> Randall Gellens says: >>>> >>>> Informal=20 >>>> meeting for people interested in SLIM (human=20 >>>> language) and how to make progress. Slots=20 >>>> based on email discussion. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>=20 >>>> Participate=20 >>>> now >>>> >>>> >>>> >>>> What is=20 >>>> Doodle? Doodle is a web service that helps=20 >>>> Randall Gellens to find a suitable date for=20 >>>> meeting with a group of people.=20 >>>> Learn=20 >>>> more about how Doodle works. >>>> >>>> >>>> >>>> >>>> You=20 >>>> have received this e-mail because "Randall=20 >>>> Gellens" has invited you to participate in=20 >>>> the Doodle poll "SLIM (Human Language)=20 >>>> informal discussion on progress." >>>> >>>> Doodle AG, Werdstrasse 21, 8021 Z=FCrich >>>> >>>> >>>> >>>> _______________________________________________ >>>> SLIM mailing list >>>> SLIM@ietf.org >>>> https://www.ietf.org/mailman/listinfo/slim >>> >>> >> >> -- >> Pete Resnick >> Qualcomm Technologies, Inc. - +1 (858)651-4478 >> >> _______________________________________________ >> 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 the employees come first, then they are happy. A motivated > employee treats the customer well. The customer is happy so they > keep coming back, which pleases the shareholders. It's not one of > the enduring Green mysteries of all time, it is just the way it > works. --Herb Kelleher, Southwest Airlines CEO, 1994 > > _______________________________________________ > 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: --------------- Police Begin Campaign to Run Down Jaywalkers --Newspaper headline From nobody Sat Mar 21 09:45:17 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9242D1A92A9 for ; Sat, 21 Mar 2015 04:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.198 X-Spam-Level: X-Spam-Status: No, score=-3.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iMOmE03Mldha for ; Sat, 21 Mar 2015 04:50:35 -0700 (PDT) Received: from mail-pd0-f171.google.com (mail-pd0-f171.google.com [209.85.192.171]) (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 0DEA81A924B for ; Sat, 21 Mar 2015 04:50:35 -0700 (PDT) Received: by pdbni2 with SMTP id ni2so134687658pdb.1 for ; Sat, 21 Mar 2015 04:50:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=6xgKiDzbCA3fBTwkWAleXduosU0LeTCwKvNsGSyxzzU=; b=a/7NH2e6hilYnzgO3Pt2qElGOuh7Wd84k+6SchktNYe8jR/VYKWEb/2saZUbfeTe91 cwzcYyASkNu+nxkJdvHWIiftzYO8uAukVu+mL2oG3SCUKYaANZfNjtX5wdFwclO+GdDF nbFtqG9q7gv/jMB6hmVQS9sCLOClrEh2KAtpsUHlyBafOWMgiAp0X8Yl257IHvHmQbhY HYLgwv8HctmDOScde8G+RRse2bm/rQQOJmJ0ZJ2ChxwsUP/6pAFkwWcuiEo6ZbyV93EO jN63cBX07f4eMGD4i0P99ab3zF1pp/Qp9ScY2EKRESeXfOh5lls1VijxqCIlEX1ukaLp Zp8Q== X-Gm-Message-State: ALoCoQkYsgezmlg47dA+37UP5e7FNn6JiliMaSL2e83zyC58GU9s1G421UbqoerpxmW55yXp+XPx MIME-Version: 1.0 X-Received: by 10.70.90.81 with SMTP id bu17mr10354386pdb.105.1426938634666; Sat, 21 Mar 2015 04:50:34 -0700 (PDT) Received: by 10.70.97.105 with HTTP; Sat, 21 Mar 2015 04:50:34 -0700 (PDT) X-Originating-IP: [24.101.113.231] In-Reply-To: References: <550B04CB.5070507@qti.qualcomm.com> Date: Sat, 21 Mar 2015 07:50:34 -0400 Message-ID: From: Brian Rosen To: Randall Gellens Content-Type: multipart/alternative; boundary=001a11c218d46f9fb30511cb0ac3 Archived-At: X-Mailman-Approved-At: Sat, 21 Mar 2015 09:45:15 -0700 Cc: "hannes.tschofenig@gmx.net" , "slim@ietf.org" , Ari Keranen , "Hutton, Andrew" , Eric Burger , Chris Newman , Pete Resnick , Keith Drage , Gunnar Hellstrom , Nik Tomkinson , Flemming Andreasen , Harald Alvestrand , Peter Saint-Andre , Alexey Melnikov , John C Klensin , Brian Rosen , Nathaniel Borenstein Subject: Re: [Slim] SLIM (human language) meet-up in Dallas, etc. X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2015 11:50:37 -0000 --001a11c218d46f9fb30511cb0ac3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sure On Friday, March 20, 2015, Randall Gellens wrote: > Are people Ok with making this a brown-bag meeting (i.e., if you want > food, bring your own)? If so, I think we may be able to snag a room with > Wi-Fi, which in theory will make it possible for people to participate > remotely. > > At 11:06 AM -0700 3/19/15, Randall Gellens wrote: > > Yes, thank you for catching it. 12 Noon it is. >> >> >> At 12:18 PM -0500 3/19/15, Pete Resnick wrote: >> >> Tuesday 10am is not one of the choices. I think you are looking at it >>> in Pacific Time instead of Central Time. >>> >>> pr >>> >>> On 3/19/15 12:14 PM, Randall Gellens wrote: >>> >>>> The Doodle poll shows Tuesday or Thursday 10-11 AM look best. Unles= s >>>> things have changed and someone now can't make it, let's meet Tuesday = at >>>> 10:00 AM. I'll see if I can find us somewhere to meet. >>>> >>>> >>>> At 9:01 AM -0700 3/10/15, Randall Gellens wrote: >>>> >>>> Hi SLIMmers, >>>>> >>>>> Please let me know your preferred days and times for a meeting on >>>>> SLIM (the human language work) in Dallas. I'll then send out a Doodl= e poll >>>>> with the most promising slots. >>>>> >>>> >>>> At 11:57 PM +0100 3/11/15, Randall Gellens (via Doodle) wrote: >>>> >>>> Randall Gellens invites you to participate in the Doodle poll "SLI= M >>>>> (Human Language) informal discussion on progress." >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> participant_invitation_with_message&tlink=3Dlogo> >>>>> >>>>> >>>>> Hi there, >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Randall Gellens ( >>>>> doodle@randy.pensive.org) invites you to participate in the Doodle >>>>> poll "SLIM (Human Language) informal discussion on progress." >>>>> >>>>> >>>>> >>>>> Randall Gellens says: >>>>> >>>>> Informal meeting for people interested >>>>> in SLIM (human language) and how to make progress. Slots based on ema= il >>>>> discussion. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> invitecontact_participant_invitation_with_message&tlink=3Dpollbtn>Par= ticipate >>>>> now >>>>> >>>>> >>>>> >>>>> What is Doodle? Doodle is a web >>>>> service that helps Randall Gellens to find a suitable date for meetin= g with >>>>> a group of people. >>>> tlink=3DcheckOutLink&tmail=3Dpoll_invitecontact_participant_ >>>>> invitation_with_message>Learn more about how Doodle works. >>>>> >>>>> >>>>> >>>>> >>>>> You have received this >>>>> e-mail because "Randall Gellens" has invited you to participate in th= e >>>>> Doodle poll "SLIM (Human Language) informal discussion on progress." >>>>> >>>>> Doodle AG, Werdstrasse 21, 8021 Z=C3=BCrich >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> SLIM mailing list >>>>> SLIM@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/slim >>>>> >>>> >>>> >>>> >>> -- >>> Pete Resnick >>> Qualcomm Technologies, Inc. - +1 (858)651-4478 >>> >>> _______________________________________________ >>> 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 the employees come first, then they are happy. A motivated >> employee treats the customer well. The customer is happy so they >> keep coming back, which pleases the shareholders. It's not one of >> the enduring Green mysteries of all time, it is just the way it >> works. --Herb Kelleher, Southwest Airlines CEO, 1994 >> >> _______________________________________________ >> 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: --------------- > Police Begin Campaign to Run Down Jaywalkers > --Newspaper headline > --001a11c218d46f9fb30511cb0ac3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sure

On Friday, March 20, 2015, Randall Gellens <randy@qti.qualcomm.com> wrote= :
Are people Ok with making this a brown-= bag meeting (i.e., if you want food, bring your own)? If so, I think we may= be able to snag a room with Wi-Fi, which in theory will make it possible f= or people to participate remotely.

At 11:06 AM -0700 3/19/15, Randall Gellens wrote:

=C2=A0Yes, thank you for catching it.=C2=A0 12 Noon it is.


=C2=A0At 12:18 PM -0500 3/19/15, Pete Resnick wrote:

=C2=A0 Tuesday 10am is not one of the choices. I think you are looking at i= t in Pacific Time instead of Central Time.

=C2=A0 pr

=C2=A0 On 3/19/15 12:14 PM, Randall Gellens wrote:
=C2=A0 The Doodle poll shows Tuesday or Thursday 10-11 AM look best.=C2=A0 = Unless things have changed and someone now can't make it, let's mee= t Tuesday at 10:00 AM.=C2=A0 I'll see if I can find us somewhere to mee= t.


=C2=A0 At 9:01 AM -0700 3/10/15, Randall Gellens wrote:

=C2=A0 =C2=A0Hi SLIMmers,

=C2=A0 =C2=A0Please let me know your preferred days and times for a meeting= on SLIM (the human language work) in Dallas.=C2=A0 I'll then send out = a Doodle poll with the most promising slots.

=C2=A0 At 11:57 PM +0100 3/11/15, Randall Gellens (via Doodle) wrote:

=C2=A0 =C2=A0Randall Gellens invites you to participate in the Doodle poll = "SLIM (Human Language) informal discussion on progress."







<https://doodle.c= om/?tmail=3Dpoll_invitecontact_participant_invitation_with_message&tlink=3Dlogo>


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Hi there,






=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Randall Gellens (doodle@randy.pens= ive.org) invites you to participate in the Doodle poll "SLIM (Huma= n Language) informal discussion on progress."



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Randall Gellens says:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Informal meeting for people intereste= d in SLIM (human language) and how to make progress. Slots based on email d= iscussion.








<https://doodle.com/zsdwk44skdaz76hn?tmail=3Dpoll_invitecon= tact_participant_invitation_with_message&tlink=3Dpollbtn<= /a>>Participate now



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 What is Doodle? Doodle is a web serv= ice that helps Randall Gellens to find a suitable date for meeting with a g= roup of people. <https://doodle.com/main.html?tlink=3DcheckOutLink&a= mp;tmail=3Dpoll_invitecontact_participant_invitation_with_mes= sage>Learn more about how Doodle works.




=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Y= ou have received this e-mail because "Randall Gellens" has invite= d you to participate in the Doodle poll "SLIM (Human Language) informa= l discussion on progress."

=C2=A0 =C2=A0Doodle AG, Werdstrasse 21, 8021 Z=C3=BCrich



=C2=A0 =C2=A0_______________________________________________
=C2=A0 =C2=A0SLIM mailing list
=C2=A0 =C2=A0SLIM@ietf.org
=C2=A0 =C2=A0https://www.ietf.org/mailman/listinfo/slim



=C2=A0 --
=C2=A0 Pete Resnick<http://www.qualcomm.com/~presnick/>
=C2=A0 Qualcomm Technologies, Inc. - +1 (858)651-4478

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



=C2=A0--
=C2=A0Randall Gellens
=C2=A0Opinions are personal;=C2=A0 =C2=A0 facts are suspect;=C2=A0 =C2=A0 I= speak for myself only
=C2=A0-------------- Randomly selected tag: ---------------
=C2=A0If the employees come first, then they are happy. A motivated
=C2=A0employee treats the customer well. The customer is happy so they
=C2=A0keep coming back, which pleases the shareholders.=C2=A0 It's not = one of
=C2=A0the enduring Green mysteries of all time, it is just the way it
=C2=A0works.=C2=A0 =C2=A0 =C2=A0 =C2=A0--Herb Kelleher, Southwest Airlines = CEO, 1994

=C2=A0_______________________________________________
=C2=A0SLIM mailing list
=C2=A0SLIM@ietf.org
=C2=A0https://www.ietf.org/mailman/listinfo/slim



--
Randall Gellens
Opinions are personal;=C2=A0 =C2=A0 facts are suspect;=C2=A0 =C2=A0 I speak= for myself only
-------------- Randomly selected tag: ---------------
Police Begin Campaign to Run Down Jaywalkers
--Newspaper headline
--001a11c218d46f9fb30511cb0ac3-- From nobody Mon Mar 23 08:05:01 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08BCC1A1B34 for ; Sun, 22 Mar 2015 20:06:50 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -5.611 X-Spam-Level: X-Spam-Status: No, score=-5.611 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iwbOb2RVsHTn for ; Sun, 22 Mar 2015 20:06:48 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EE3F1A8788 for ; Sun, 22 Mar 2015 20:06:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1427080008; x=1458616008; h=message-id:in-reply-to:references:date:to:from:subject: cc; bh=2TS51vUplkGWSSxQZaXUjYl0SbYQCCfszaY+f9Yn+N4=; b=A+y7N8WXCCi1cdAzDV+cXYkR0Ek/mIOU8i5UAAK0gGReoSojOxSuvTzB E9V5cDrqn43GZRISpshOcrdeh4Mata9a/3YiubcK77BlBGt0IXh0/VQZ2 j/73/rini/8Oln/qCqL1NsbuauqNzCI45FEnzO3chb5p7zXhMItJsasIP M=; X-IronPort-AV: E=McAfee;i="5600,1067,7748"; a="109698772" Received: from ironmsg02-l.qualcomm.com ([172.30.48.16]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Mar 2015 20:06:47 -0700 X-IronPort-AV: E=Sophos;i="5.11,449,1422950400"; d="scan'208";a="433018780" Received: from plus.qualcomm.com ([10.52.255.8]) by ironmsg02-L.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Mar 2015 20:06:47 -0700 Received: from Ironmsg04-L.qualcomm.com (ironmsg04-L.qualcomm.com [172.30.48.19]) by plus.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id t2N36hH1007790; Sun, 22 Mar 2015 20:06:44 -0700 X-IronPort-AV: E=Sophos;i="5.11,449,1422950400"; d="scan'208";a="843578610" X-ojodefuego: yes Received: from unknown (HELO dhcp-93ce.meeting.ietf.org) ([10.64.195.12]) by Ironmsg04-L.qualcomm.com with ESMTP; 22 Mar 2015 20:06:42 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <550B04CB.5070507@qti.qualcomm.com> X-Mailer: Eudora for Mac OS X Date: Sun, 22 Mar 2015 20:06:40 -0700 To: Brian Rosen 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 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 Archived-At: X-Mailman-Approved-At: Mon, 23 Mar 2015 08:04:59 -0700 Cc: "slim@ietf.org" , Ari Keranen , "Hutton, Andrew" , Harald Alvestrand , Chris Newman , Pete Resnick , Keith Drage , Gunnar Hellstrom , Nik Tomkinson , Flemming Andreasen , Eric Burger , Nathaniel Borenstein , Peter Saint-Andre , Brian Rosen , John C Klensin , Alexey Melnikov , "hannes.tschofenig@gmx.net" Subject: Re: [Slim] SLIM (human language) meet-up in Dallas, etc. X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 03:06:50 -0000 Hi SLIMers, We will meet Tuesday 12 noon in the Florentine room. Can someone volunteer to set up a Skype or other conference to allow remote people to join us? I know Eric and Henning have said they would like to participate remotely. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Ignorance is nothing more than indifference to what is before us; we have only to pay attention--and we are paying attention in a way, but to pretty noise, the newer the better. --Wyatt Mason, review of E.E. Cummings biography, Harper's May 2005. From nobody Mon Mar 23 09:16:04 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13E721AC3E4 for ; Mon, 23 Mar 2015 09:06:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.012 X-Spam-Level: X-Spam-Status: No, score=-1.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779, T_DKIM_INVALID=0.01] autolearn=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 8jfRYzOglBcP for ; Mon, 23 Mar 2015 09:06:00 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 142891AC3E3 for ; Mon, 23 Mar 2015 09:06:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To:From:Content-Type:Mime-Version:Subject; bh=vFUIJDiok9TpqWDIW3hzbN454Tcf5nGdBzOuL3PxnNA=; b=RRTLotfFNZL3m0j55e5zHlU4gH20tfuO2/cHpahXEZOTmu/KVNxW5WKpuga0bjCFPLY2+fpPqrkaT8vHqJz7JAgLXMiZHdB1NDg+UEfatdP7PPIlhhlykMjumqoH1hdUycm6p3epw9GwJCZvoelko6XqzL9dijz4/AQiGVpNmh0=; Received: from ip68-100-197-30.dc.dc.cox.net ([68.100.197.30]:64376 helo=[192.168.15.136]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1Ya4rO-0006UM-N9; Mon, 23 Mar 2015 09:05:53 -0700 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_7C664F98-B9CF-436A-A3BA-DD6D718AF39F"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail 2.5b6 From: Eric Burger In-Reply-To: Date: Mon, 23 Mar 2015 12:05:47 -0400 Message-Id: <0A3E4F96-BC43-4634-BEF4-1DEE0B291FA6@standardstrack.com> References: <550B04CB.5070507@qti.qualcomm.com> To: Randall Gellens X-Mailer: Apple Mail (2.2070.6) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed Archived-At: X-Mailman-Approved-At: Mon, 23 Mar 2015 09:16:03 -0700 Cc: "slim@ietf.org" , Tschofenig Hannes , Ari Keranen , "Hutton, Andrew" , Melnikov Alexey , Chris Newman , Resnick Pete , Keith Drage , Gunnar Hellstrom , Nik Tomkinson , Andreasen Flemming , Alvestrand Harald Tveit , Saint-Andre Peter , Rosen Brian , Klensin John , Rosen Brian , Nathaniel Borenstein Subject: Re: [Slim] SLIM (human language) meet-up in Dallas, etc. X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 16:06:01 -0000 --Apple-Mail=_7C664F98-B9CF-436A-A3BA-DD6D718AF39F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Let me know coordinates. I=E2=80=99ll be on from noon - 12:30pm. I was = asleep at the wheel - Thursday would have been better as I will be at = the IETF then, but if you have 24 people setup for tomorrow, tomorrow it = is. > On Mar 22, 2015, at 11:06 PM, Randall Gellens = wrote: >=20 > Hi SLIMers, >=20 > We will meet Tuesday 12 noon in the Florentine room. >=20 > Can someone volunteer to set up a Skype or other conference to allow = remote people to join us? I know Eric and Henning have said they would = like to participate remotely. >=20 >=20 > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself = only > -------------- Randomly selected tag: --------------- > Ignorance is nothing more than indifference to what is before us; > we have only to pay attention--and we are paying attention in a way, > but to pretty noise, the newer the better. > --Wyatt Mason, review of E.E. Cummings biography, Harper's May 2005. >=20 > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim --Apple-Mail=_7C664F98-B9CF-436A-A3BA-DD6D718AF39F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVEDnbAAoJEDY/T2tCIPW3A+QP/0msAuzUxY4Pan4Mb+fuCyBb faE6pbVdgLEOC/jCaWORkYFEfNs4KTTW5EpIm9Jy7AQCsYPOnfmZgTH/4JfkdiLl sQz/RBC3FoSLmo8pSQD9+nqQYZi+ze4gUpL4ZgnKRoCZVU17yoZINniqKTWaNAuU 6zyhYgLpB3LLcR5H6m/LF7raxPp+6DjMFpDMVyLxvUrpmVrTgFWDmlZarfaEcTNA 38YGSpCyZq5TzB2STb7mv2dVnOp4jyNGnIcSlsvdNQLZs973K9g0OLfqAPi6BZ35 tNyXRzMh1gqfFwxj6aU7o/99V0Kd+A+LWqvIKAOESlrb0ot73Sy8LWG2FYwhnpnw 58TPv7POwZPo4xWhvMltTNc8uArn2wqTtRx0lyqrZWjSYI1HSKRfKIccmfr8ptKL FwcpCkX6j/2MmnprFG5BnFJwX55oBjn59h8iCFoU7SU+t9I72lBkt2tC4RpXzzls vbeytENDovs6TdwNbIW23GLQXv2ELq9SPFW6JvblDCFHpmwLMMDZlWWpwkwiwqJP VDxG9+jWekgvuRd00c2GkJv5nQ5drUCQ4Mu/NzZGVXjs2y3wzrLi9qs/T/JCTVfJ frtT4mMwLQiKv01KpK2Wgcx0HMFcN0mfWSXOckzNMO+8PoWsdC6hgUeXHqfSOARS bXLDvXrWzhiA2MGZL1+L =axl1 -----END PGP SIGNATURE----- --Apple-Mail=_7C664F98-B9CF-436A-A3BA-DD6D718AF39F-- From nobody Mon Mar 23 20:28:01 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52CBA1B2C29 for ; Mon, 23 Mar 2015 20:27:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ULQ0F_igfunw for ; Mon, 23 Mar 2015 20:27:57 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3A9C1A877C for ; Mon, 23 Mar 2015 20:27:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1427167676; x=1458703676; h=message-id:in-reply-to:references:date:to:from:subject: mime-version; bh=NYjRX692VeLLdRplUyS15eHSDClyaTUrxmKWtUY2af0=; b=og2JH0TTol+SK5YM03Y4Uwqp3IAo+d40PVgVW6wwq++iGmNqA75K0g5i CYHiwRfWhsoafxGhsLfy75YQMwpQ+UygztJX3zeITRga0Pi2zE2aiY4jY bx+mq3HoE/0BCdeU4dAxZLHgGsf5f8aIPdUl+dRX9nUsUWy/8Uw/0BTgu g=; X-IronPort-AV: E=McAfee;i="5600,1067,7749"; a="86495304" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by sabertooth02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 23 Mar 2015 20:27:56 -0700 X-IronPort-AV: E=Sophos;i="5.11,456,1422950400"; d="scan'208";a="878478457" Received: from nasanexm02f.na.qualcomm.com ([10.85.0.87]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 23 Mar 2015 20:27:54 -0700 Received: from dhcp-93ce.meeting.ietf.org (10.80.80.8) by nasanexm02f.na.qualcomm.com (10.85.0.87) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Mon, 23 Mar 2015 20:27:53 -0700 Message-ID: In-Reply-To: <55098C6C.50003@alum.mit.edu> References: <0A4E9A96-56C9-4D15-81AE-5D8285654080@nostrum.com> <6A925F93-EDCD-48EE-8D71-67DA93AED066@nostrum.com> <55098C6C.50003@alum.mit.edu> X-Mailer: Eudora for Mac OS X Date: Mon, 23 Mar 2015 20:22:21 -0700 To: Paul Kyzivat , 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-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01F.na.qualcomm.com (10.85.0.32) To nasanexm02f.na.qualcomm.com (10.85.0.87) Archived-At: Subject: Re: [Slim] Comments on proposed SLIM charter X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 03:27:59 -0000 At 10:32 AM -0400 3/18/15, Paul Kyzivat wrote: > On 3/16/15 3:33 PM, Ben Campbell wrote: >> On 13 Mar 2015, at 15:30, Ben Campbell wrote: >> >>> I don't find the charter text motivating the linkage between the mail >>> problem and the real-time problem very convincing. I'm not saying it's >>> wrong; just that it hasn't convinced me. >>> >>> The text suggests a single work group to reinforce commonality in the >>> solutions. That seems backwards to me; I'd like to see more on why >>> people think the problems benefit from a common solution. Do you think >>> there will be mechanism in common, beyond the use of language tags? Do >>> you see a common implementor community? A common protocol development >>> community? >> >> Hi SLIM list participants: >> >> I see that one of my comments has generated some discussion (namely the >> SIP vs SDP discussion.) Does anyone have thoughts on my other comment >> (quoted above)? > > I don't see much commonality. I have suspicion that there will be > distinct bodies of people interested in working on these two things. There are some people who are only interested in one of the two areas, while others are interested in both. Obviously, different solutions are needed for the two problem spaces, and we have two drafts that each solve one of the two problems. The work could be done in two groups, but given that both are aspects of the basic issue of facilitating communication among people who may use different languages, it also makes sense to do them in the same group. I see some benefit and no harm. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- The most savage controversies are those about matters as to which there is no good evidence either way. --Bertrand Russell From nobody Tue Mar 24 10:56:38 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A89591AC41C; Tue, 24 Mar 2015 10:56:36 -0700 (PDT) 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, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 786SQWySIsOb; Tue, 24 Mar 2015 10:56:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B25B21AC3EF; Tue, 24 Mar 2015 10:56:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150324175635.1248.53557.idtracker@ietfa.amsl.com> Date: Tue, 24 Mar 2015 10:56:35 -0700 From: IETF Secretariat Archived-At: Subject: [Slim] Telechat update notice: X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 17:56:36 -0000 Removed from agenda for telechat ID Tracker URL: http://datatracker.ietf.org/doc/charter-ietf-slim/