From mary.ietf.barnes@gmail.com Thu Jan 5 15:31:55 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D13B11E8074 for ; Thu, 5 Jan 2012 15:31:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.254 X-Spam-Level: X-Spam-Status: No, score=-103.254 tagged_above=-999 required=5 tests=[AWL=-1.145, BAYES_05=-1.11, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tk35A20V-56m for ; Thu, 5 Jan 2012 15:31:54 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6ABC311E8080 for ; Thu, 5 Jan 2012 15:31:54 -0800 (PST) Received: by vbbfo1 with SMTP id fo1so887758vbb.31 for ; Thu, 05 Jan 2012 15:31:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=rJbncm5LBPi2TDBwB2g4R70cu2G2DC31kuvfJ7LX+/k=; b=MllqkAY7uz7tiNVpp4feam8tTzPzZQxAq7L/b1LfCpiWkW+VWHXeRUlHawCyebBoiR isvO0G3hoHP1JGiQwJ4UgbRfsrElPU9+NAEV2S+kkUBVDO6zK8KW9wf/yLDtW32x7SFp g57uXgEXyzeJqPJ1/HmYY/zY85gL5eCjjrWHg= MIME-Version: 1.0 Received: by 10.52.35.13 with SMTP id d13mr1913160vdj.55.1325806312843; Thu, 05 Jan 2012 15:31:52 -0800 (PST) Received: by 10.52.108.196 with HTTP; Thu, 5 Jan 2012 15:31:52 -0800 (PST) Date: Thu, 5 Jan 2012 17:31:52 -0600 Message-ID: From: Mary Barnes To: CLUE Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [clue] Deadlines: CLUE WG Interim meeting - Feb. 15-16, 2012 in Andover, Mass X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 23:31:55 -0000 Hi folks, In anticipation of the upcoming interim meeting, we would like to set a deadline of Feb.3rd (5pm Pacific) for documents/topics for discussion. We will then post a preliminary agenda by 5pm on the 6th to allow folks time to review docs before the meeting. We will certainly try to be flexible - if you run into problems, please let the chairs know and we'll see if we can work things in. Priority will of course be given to WG documents, but it would be excellent to see some progress on some of the individual docs that were discussed in Taipei. For folks that need a context reset after the holidays, the CLUE meeting minutes are available here: http://www.ietf.org/proceedings/82/minutes/clue.html Thanks, Mary. On Mon, Dec 5, 2011 at 2:03 PM, Mary Barnes wr= ote: > I was waiting for the results of the RTCWEB poll to fix the dates, as > we would have needed to be meeting on Thurs/Friday (16/17) to > accommodate the full week of Interim meetings if they were in Boston > area. =A0 Now that it's been determined that the RTCWEB meeting will be > January 31st-Feb. 1st in San Jose, the CLUE WG interim will be on Feb. > 15th and 16th at the Polycom facility in Andover (same location as the > October interim meeting). =A0 The logistics and a preliminary agenda are > available on the wiki: > http://trac.tools.ietf.org/wg/clue/trac/wiki/WikiStart > > Also, if you are planning to attend and have not responded to the > doodle, if you could please do so that we can ensure that there is > adequate seating and refreshments (note, you'll be on your own for > lunch, but there is a cafeteria on the premises). > http://doodle.com/d86zeaqng28eh3ie > > Regards, > Mary. > > On Mon, Dec 5, 2011 at 1:25 PM, Marshall Eubanks > wrote: >> Dear Mary; >> >> where do we stand with these dates ? >> >> Regards >> Marshall >> From internet-drafts@ietf.org Fri Jan 6 14:47:57 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D458A21F86C3; Fri, 6 Jan 2012 14:47:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h0Cbx8iAk6MI; Fri, 6 Jan 2012 14:47:57 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C71C21F8694; Fri, 6 Jan 2012 14:47:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120106224757.22622.57341.idtracker@ietfa.amsl.com> Date: Fri, 06 Jan 2012 14:47:57 -0800 Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-framework-02.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 22:47:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the ControLling mUltiple streams for tEle= presence Working Group of the IETF. Title : Framework for Telepresence Multi-Streams Author(s) : Allyn Romanow Mark Duckworth Andrew Pepperell Brian Baldino Filename : draft-ietf-clue-framework-02.txt Pages : 37 Date : 2012-01-06 This memo offers a framework for a protocol that enables devices in a telepresence conference to interoperate by specifying the relationships between multiple RTP streams. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-clue-framework-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-clue-framework-02.txt From Mark.Duckworth@polycom.com Fri Jan 6 14:51:43 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02CC11F0C57 for ; Fri, 6 Jan 2012 14:51:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n71oz9TECaf2 for ; Fri, 6 Jan 2012 14:51:42 -0800 (PST) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id F23C11F0C3F for ; Fri, 6 Jan 2012 14:51:39 -0800 (PST) Received: from Crpmboxprd01.polycom.com ([fe80::ad68:5a0:c919:66b6]) by crpehubprd02.polycom.com ([fe80::5efe:10.236.0.154%12]) with mapi; Fri, 6 Jan 2012 14:51:39 -0800 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Fri, 6 Jan 2012 14:51:37 -0800 Thread-Topic: Updates in framework-02 Thread-Index: AczMxVqqdkntgE2oTNql2+0ws/lubg== Message-ID: <44C6B6B2D0CF424AA90B6055548D7A6102FAC9013A@CRPMBOXPRD01.polycom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_44C6B6B2D0CF424AA90B6055548D7A6102FAC9013ACRPMBOXPRD01p_" MIME-Version: 1.0 Subject: [clue] Updates in framework-02 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 22:51:43 -0000 --_000_44C6B6B2D0CF424AA90B6055548D7A6102FAC9013ACRPMBOXPRD01p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The framework-02 document has updates to the sections about describing spat= ial relationships, using a coordinate system and attributes for area of cap= ture and point of capture. This is based on the presentation and discussio= n at the Taipei meeting, and email list discussion. Please review and post= comments. Mark Duckworth --_000_44C6B6B2D0CF424AA90B6055548D7A6102FAC9013ACRPMBOXPRD01p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The framework-02= document has updates to the sections about describing spatial relationship= s, using a coordinate system and attributes for area of capture and point o= f capture.  This is based on the presentation and discussion at the Ta= ipei meeting, and email list discussion.  Please review and post comme= nts.

 

Mark Duckworth

= --_000_44C6B6B2D0CF424AA90B6055548D7A6102FAC9013ACRPMBOXPRD01p_-- From internet-drafts@ietf.org Mon Jan 9 08:49:17 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7F6221F85B0; Mon, 9 Jan 2012 08:49:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TzOyGtpRnP4Z; Mon, 9 Jan 2012 08:49:13 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6549521F8593; Mon, 9 Jan 2012 08:49:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120109164913.3837.52010.idtracker@ietfa.amsl.com> Date: Mon, 09 Jan 2012 08:49:13 -0800 Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-telepresence-use-cases-02.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 16:49:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the ControLling mUltiple streams for tEle= presence Working Group of the IETF. Title : Use Cases for Telepresence Multi-streams Author(s) : Allyn Romanow Stephen Botzko Mark Duckworth Roni Even Iformata Communications Filename : draft-ietf-clue-telepresence-use-cases-02.txt Pages : 16 Date : 2012-01-09 Telepresence conferencing systems seek to create the sense of really being present for the participants. A number of techniques for handling audio and video streams are used to create this experience. When these techniques are not similar, interoperability between different systems is difficult at best, and often not possible. Conveying information about the relationships between multiple streams of media would allow senders and receivers to make choices to allow telepresence systems to interwork. This memo describes the most typical and important use cases for sending multiple streams in a telepresence conference. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-clue-telepresence-use-cases-= 02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-clue-telepresence-use-cases-0= 2.txt From ron.even.tlv@gmail.com Tue Jan 10 01:27:07 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B37CE21F86E5; Tue, 10 Jan 2012 01:27:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tViiY3Oopp2i; Tue, 10 Jan 2012 01:27:07 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9198421F8631; Tue, 10 Jan 2012 01:27:06 -0800 (PST) Received: by eekd41 with SMTP id d41so7795eek.31 for ; Tue, 10 Jan 2012 01:27:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=FBCf7Z8Cq5w7GJehqOqGglm9q5qRH2jGxF4wwvXwnQA=; b=rBaxAp6Fuj6nG0V981X6uipjbtnxVqwT8ySEGPabsaUjbOVg2qOAO2oyO4COZIK1Nw sQcB2c40f7EHmXlm+iLl0+yNcIFo/3H25HDWzks6S/CKfnyptdHCdKOc9BYsmARYHhwH SDk/OR4PQMR95Lrl+DyBvyI8fGAxsinb4IVXE= Received: by 10.14.51.193 with SMTP id b41mr7410136eec.76.1326187625596; Tue, 10 Jan 2012 01:27:05 -0800 (PST) Received: from windows8d787f9 (bzq-79-180-198-96.red.bezeqint.net. [79.180.198.96]) by mx.google.com with ESMTPS id a60sm302040799eeb.4.2012.01.10.01.27.02 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 10 Jan 2012 01:27:03 -0800 (PST) From: "Roni Even" To: , References: <20120106224757.22622.57341.idtracker@ietfa.amsl.com> In-Reply-To: <20120106224757.22622.57341.idtracker@ietfa.amsl.com> Date: Tue, 10 Jan 2012 11:23:38 +0200 Message-ID: <4f0c0467.d4260e0a.49db.16b3@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AczMxUCF1Fccr9KqQzyqLYw4G9PIZgCs5Vjw Content-Language: en-us Cc: clue@ietf.org Subject: Re: [clue] I-D Action: draft-ietf-clue-framework-02.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 09:27:07 -0000 Hi, I intend to read the new version this week but at a first glance I noticed that the section on encoding groups was not changed to explain the encoding groups, the current text is unclear and I doubt if this should be part of the basic data model or an extension. Another thing that is missing is the data model in some structured representation like XML which is needed in order to progress with the CLUE transport decision. I was under the impression that the editors of the draft mentioned that they are working on it and we will have it before the interim meeting, is this still the case. Thanks Roni Even > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: Saturday, January 07, 2012 12:48 AM > To: i-d-announce@ietf.org > Cc: clue@ietf.org > Subject: [clue] I-D Action: draft-ietf-clue-framework-02.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the ControLling mUltiple > streams for tElepresence Working Group of the IETF. > > Title : Framework for Telepresence Multi-Streams > Author(s) : Allyn Romanow > Mark Duckworth > Andrew Pepperell > Brian Baldino > Filename : draft-ietf-clue-framework-02.txt > Pages : 37 > Date : 2012-01-06 > > This memo offers a framework for a protocol that enables devices in > a > telepresence conference to interoperate by specifying the > relationships between multiple RTP streams. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-clue-framework-02.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-clue-framework-02.txt > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From ron.even.tlv@gmail.com Tue Jan 10 06:34:45 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60E1021F8504 for ; Tue, 10 Jan 2012 06:34:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pepdwYr2Jv6j for ; Tue, 10 Jan 2012 06:34:44 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 70E5A21F84A3 for ; Tue, 10 Jan 2012 06:34:44 -0800 (PST) Received: by eekd41 with SMTP id d41so165983eek.31 for ; Tue, 10 Jan 2012 06:34:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:x-mailer:thread-index:content-language; bh=0kQcZ0SwN3Fu/nh8ZlviUdXGv0QqVPIa8jesV2lUISM=; b=NeFL3FS+LaRZFat8v5B/GT8Xft9W6HNFVSyRQq105YNzM2IWhz5TpcIsp9rnuEczCK caSDm41dS2h3004ShbY8itzArR74yVpEvglfHK+M1PXcSuE2VJEStf+mBvBbLq/KbZae wCxFIC9YqxtbcVBwv7flzFYGQWZpcdedLKCqk= Received: by 10.213.29.131 with SMTP id q3mr427016ebc.65.1326206082308; Tue, 10 Jan 2012 06:34:42 -0800 (PST) Received: from windows8d787f9 (bzq-79-180-198-96.red.bezeqint.net. [79.180.198.96]) by mx.google.com with ESMTPS id s16sm304910857eef.2.2012.01.10.06.34.39 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 10 Jan 2012 06:34:40 -0800 (PST) From: "Roni Even" To: "'Duckworth, Mark'" , References: <44C6B6B2D0CF424AA90B6055548D7A6102FAC9013A@CRPMBOXPRD01.polycom.com> In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A6102FAC9013A@CRPMBOXPRD01.polycom.com> Date: Tue, 10 Jan 2012 16:31:14 +0200 Message-ID: <4f0c4c80.10610e0a.01e0.ffffa799@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0139_01CCCFB5.4741DA30" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AczMxVqqdkntgE2oTNql2+0ws/lubgC3wcIA Content-Language: en-us Subject: Re: [clue] Updates in framework-02 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 14:34:45 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0139_01CCCFB5.4741DA30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Mrak, Just to clarify, you are asking for review of sections 5.3 till 5.6.2 Roni From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark Sent: Saturday, January 07, 2012 12:52 AM To: clue@ietf.org Subject: [clue] Updates in framework-02 The framework-02 document has updates to the sections about describing spatial relationships, using a coordinate system and attributes for area of capture and point of capture. This is based on the presentation and discussion at the Taipei meeting, and email list discussion. Please review and post comments. Mark Duckworth ------=_NextPart_000_0139_01CCCFB5.4741DA30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Mrak,

Just to clarify, you are = asking for review of sections 5.3 till 5.6.2

Roni

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Duckworth, Mark
Sent: Saturday, January 07, 2012 12:52 = AM
To: clue@ietf.org
Subject: [clue] Updates in = framework-02

 

The = framework-02 document has updates to the sections about describing = spatial relationships, using a coordinate system and attributes for area = of capture and point of capture.  This is based on the presentation = and discussion at the Taipei meeting, and email list discussion.  = Please review and post comments.

 

Mark = Duckworth

------=_NextPart_000_0139_01CCCFB5.4741DA30-- From trac+clue@trac.tools.ietf.org Tue Jan 10 09:40:04 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9984921F864B for ; Tue, 10 Jan 2012 09:40:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hiio+N34tpzI for ; Tue, 10 Jan 2012 09:40:04 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 20C2521F864A for ; Tue, 10 Jan 2012 09:40:03 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1Rkffx-0000nu-VN; Tue, 10 Jan 2012 12:39:58 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "clue issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: pkyzivat@alum.mit.edu X-Trac-Project: clue Date: Tue, 10 Jan 2012 17:39:57 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/1 Message-ID: <063.f447b18f549ba1007355125cf872394b@trac.tools.ietf.org> X-Trac-Ticket-ID: 1 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: pkyzivat@alum.mit.edu, jonathan@vidyo.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Tue, 10 Jan 2012 11:20:24 -0800 Cc: jonathan@vidyo.com, clue@ietf.org Subject: [clue] #1: Source Selection Use Case X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 17:40:04 -0000 #1: Source Selection Use Case Jonathan Lennox to post Source Selection Use Case on List (by 11/28) -- ------------------------------------+----------------------------- Reporter: pkyzivat@… | Owner: Jonathan Lennox Type: enhancement | Status: new Priority: major | Milestone: Component: telepresence-use-cases | Version: Severity: Active WG Document | Keywords: ------------------------------------+----------------------------- Ticket URL: clue From trac+clue@trac.tools.ietf.org Tue Jan 10 10:15:45 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3D7E21F860E for ; Tue, 10 Jan 2012 10:15:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wKdwbQN7HNJx for ; Tue, 10 Jan 2012 10:15:44 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id A17D021F84F5 for ; Tue, 10 Jan 2012 10:15:43 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RkgEK-00081P-3B; Tue, 10 Jan 2012 13:15:28 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "clue issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: pkyzivat@alum.mit.edu X-Trac-Project: clue Date: Tue, 10 Jan 2012 18:15:28 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/2 Message-ID: <063.9b81af3c175d186140d57829d721bd2b@trac.tools.ietf.org> X-Trac-Ticket-ID: 2 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: pkyzivat@alum.mit.edu, Even.roni@huawei.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Tue, 10 Jan 2012 11:20:24 -0800 Cc: clue@ietf.org Subject: [clue] #2: Use cases for selecting composed captures X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 18:15:45 -0000 #2: Use cases for selecting composed captures Roni Even to post use cases for selecting composed captures, on the mailing list. -- ------------------------------------+----------------------- Reporter: pkyzivat@… | Owner: Roni Even Type: task | Status: new Priority: major | Milestone: Component: telepresence-use-cases | Version: Severity: Active WG Document | Keywords: ------------------------------------+----------------------- Ticket URL: clue From trac+clue@trac.tools.ietf.org Tue Jan 10 10:19:27 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07D5421F8498 for ; Tue, 10 Jan 2012 10:19:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nqBTWc+ZtUnG for ; Tue, 10 Jan 2012 10:19:26 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 8DB0221F848B for ; Tue, 10 Jan 2012 10:19:26 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RkgHy-0003bQ-2I; Tue, 10 Jan 2012 13:19:14 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "clue issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-clue-telepresence-use-cases@tools.ietf.org, pkyzivat@alum.mit.edu X-Trac-Project: clue Date: Tue, 10 Jan 2012 18:19:14 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://ebook.tools.ietf.org/wg/clue/trac/ticket/3 Message-ID: <063.989fef5c8859eb1ed5eaeeaac3cf1759@trac.tools.ietf.org> X-Trac-Ticket-ID: 3 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-clue-telepresence-use-cases@tools.ietf.org, pkyzivat@alum.mit.edu, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120110181926.8DB0221F848B@ietfa.amsl.com> Resent-Date: Tue, 10 Jan 2012 10:19:26 -0800 (PST) Resent-From: trac+clue@trac.tools.ietf.org X-Mailman-Approved-At: Tue, 10 Jan 2012 11:20:24 -0800 Cc: clue@ietf.org Subject: [clue] #3: Use case for an RTCWEB client X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 18:19:27 -0000 #3: Use case for an RTCWEB client CLUE should have a use case for an RTCWEB client. -- -------------------------+------------------------------------------------- Reporter: pkyzivat@… | Owner: draft-ietf-clue-telepresence-use- Type: task | cases@… Priority: major | Status: new Component: | Milestone: telepresence-use- | Version: cases | Keywords: Severity: Active WG | Document | -------------------------+------------------------------------------------- Ticket URL: clue From trac+clue@trac.tools.ietf.org Tue Jan 10 10:22:37 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8FAE21F86A5 for ; Tue, 10 Jan 2012 10:22:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VSO37RwdOg8I for ; Tue, 10 Jan 2012 10:22:37 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 4B67021F8691 for ; Tue, 10 Jan 2012 10:22:37 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RkgLD-0001Jj-BM; Tue, 10 Jan 2012 13:22:35 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "clue issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-clue-framework@tools.ietf.org, pkyzivat@alum.mit.edu X-Trac-Project: clue Date: Tue, 10 Jan 2012 18:22:35 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://ebook.tools.ietf.org/wg/clue/trac/ticket/4 Message-ID: <063.c25c26d18d12df129eb97ad25ea6bc92@trac.tools.ietf.org> X-Trac-Ticket-ID: 4 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-clue-framework@tools.ietf.org, pkyzivat@alum.mit.edu, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120110182237.4B67021F8691@ietfa.amsl.com> Resent-Date: Tue, 10 Jan 2012 10:22:37 -0800 (PST) Resent-From: trac+clue@trac.tools.ietf.org X-Mailman-Approved-At: Tue, 10 Jan 2012 11:20:24 -0800 Cc: clue@ietf.org Subject: [clue] #4: Share CLUE metadata with W3C X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 18:22:37 -0000 #4: Share CLUE metadata with W3C CLUE should submit or socialize the metadata with W3C. -- ------------------------+----------------------------------------- Reporter: pkyzivat@… | Owner: draft-ietf-clue-framework@… Type: task | Status: new Priority: major | Milestone: Component: framework | Version: Severity: - | Keywords: ------------------------+----------------------------------------- Ticket URL: clue From trac+clue@trac.tools.ietf.org Tue Jan 10 10:31:31 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5573E21F862D for ; Tue, 10 Jan 2012 10:31:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aWR9f4Scf6gP for ; Tue, 10 Jan 2012 10:31:30 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id CB66A21F8686 for ; Tue, 10 Jan 2012 10:31:30 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RkgTl-0003pO-Ld; Tue, 10 Jan 2012 13:31:25 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "clue issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-clue-framework@tools.ietf.org, pkyzivat@alum.mit.edu X-Trac-Project: clue Date: Tue, 10 Jan 2012 18:31:25 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://ebook.tools.ietf.org/wg/clue/trac/ticket/5 Message-ID: <063.a37bc5dd4fc60cc1fce0e69ad3a0e316@trac.tools.ietf.org> X-Trac-Ticket-ID: 5 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-clue-framework@tools.ietf.org, pkyzivat@alum.mit.edu, Stephan@vidyo.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120110183130.CB66A21F8686@ietfa.amsl.com> Resent-Date: Tue, 10 Jan 2012 10:31:30 -0800 (PST) Resent-From: trac+clue@trac.tools.ietf.org X-Mailman-Approved-At: Tue, 10 Jan 2012 11:20:24 -0800 Cc: Stephan@vidyo.com, clue@ietf.org Subject: [clue] #5: Describe composed captures X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 18:31:31 -0000 #5: Describe composed captures Stephan Wenger to make proposal for describing composed captures, by mid December, 2011. -- --------------------------------+----------------------------------------- Reporter: pkyzivat@… | Owner: draft-ietf-clue-framework@… Type: task | Status: new Priority: major | Milestone: Component: framework | Version: Severity: Active WG Document | Keywords: --------------------------------+----------------------------------------- Ticket URL: clue From trac+clue@trac.tools.ietf.org Tue Jan 10 10:50:07 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E57A021F86A3 for ; Tue, 10 Jan 2012 10:50:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v6ZZjTo7mJ5W for ; Tue, 10 Jan 2012 10:50:07 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 74FC021F864A for ; Tue, 10 Jan 2012 10:50:07 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1Rkglq-0006ge-A9; Tue, 10 Jan 2012 13:50:06 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "clue issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: pkyzivat@alum.mit.edu X-Trac-Project: clue Date: Tue, 10 Jan 2012 18:50:06 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/6 Message-ID: <063.a981a21c6f207209c3de907f8f4365d5@trac.tools.ietf.org> X-Trac-Ticket-ID: 6 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: pkyzivat@alum.mit.edu, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Tue, 10 Jan 2012 11:20:24 -0800 Cc: clue@ietf.org Subject: [clue] #6: Ensure source selection is in scope of charter X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 18:50:08 -0000 #6: Ensure source selection is in scope of charter Revisit charter to ensure requirements for source selection are in scope. -- ---------------------------------------+----------------------- Reporter: pkyzivat@… | Owner: Paul/Mary Type: task | Status: new Priority: minor | Milestone: Component: telepresence-requirements | Version: Severity: - | Keywords: ---------------------------------------+----------------------- Ticket URL: clue From trac+clue@trac.tools.ietf.org Tue Jan 10 11:02:57 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D28E421F8613 for ; Tue, 10 Jan 2012 11:02:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y4hWlhIAcw4f for ; Tue, 10 Jan 2012 11:02:57 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 62AB921F85EE for ; Tue, 10 Jan 2012 11:02:56 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RkgyF-00007h-Rg; Tue, 10 Jan 2012 14:02:55 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "clue issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: pkyzivat@alum.mit.edu X-Trac-Project: clue Date: Tue, 10 Jan 2012 19:02:55 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://wiki.tools.ietf.org/wg/clue/trac/ticket/6#comment:1 Message-ID: <078.295009f5e179f595750cfc4b66262697@trac.tools.ietf.org> References: <063.a981a21c6f207209c3de907f8f4365d5@trac.tools.ietf.org> X-Trac-Ticket-ID: 6 In-Reply-To: <063.a981a21c6f207209c3de907f8f4365d5@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: pkyzivat@alum.mit.edu, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Tue, 10 Jan 2012 11:20:24 -0800 Cc: clue@ietf.org Subject: Re: [clue] #6: Ensure source selection is in scope of charter X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 19:02:57 -0000 #6: Ensure source selection is in scope of charter Changes (by pkyzivat@…): * component: telepresence-requirements => charter -- ------------------------+------------------------ Reporter: pkyzivat@… | Owner: Paul/Mary Type: task | Status: new Priority: minor | Milestone: Component: charter | Version: Severity: - | Resolution: Keywords: | ------------------------+------------------------ Ticket URL: clue From Even.roni@huawei.com Tue Jan 10 11:26:48 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2A9921F87FA for ; Tue, 10 Jan 2012 11:26:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.533 X-Spam-Level: X-Spam-Status: No, score=-106.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vDi80Y765zMC for ; Tue, 10 Jan 2012 11:26:48 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 2582421F87FD for ; Tue, 10 Jan 2012 11:26:48 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LXL00F1JKOH4Q@szxga05-in.huawei.com> for clue@ietf.org; Wed, 11 Jan 2012 03:26:41 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LXL008Z8KOHEW@szxga05-in.huawei.com> for clue@ietf.org; Wed, 11 Jan 2012 03:26:41 +0800 (CST) Received: from szxeml206-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGF75822; Wed, 11 Jan 2012 03:26:40 +0800 Received: from SZXEML421-HUB.china.huawei.com (10.82.67.160) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 11 Jan 2012 03:26:35 +0800 Received: from SZXEML519-MBS.china.huawei.com ([169.254.7.136]) by szxeml421-hub.china.huawei.com ([10.82.67.160]) with mapi id 14.01.0323.003; Wed, 11 Jan 2012 03:26:34 +0800 Date: Tue, 10 Jan 2012 19:26:33 +0000 From: Roni even In-reply-to: <063.9b81af3c175d186140d57829d721bd2b@trac.tools.ietf.org> X-Originating-IP: [172.24.1.69] To: clue issue tracker , "pkyzivat@alum.mit.edu" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=Windows-1252 Content-language: en-US Content-transfer-encoding: quoted-printable Accept-Language: en-US, zh-CN Thread-topic: [clue] #2: Use cases for selecting composed captures Thread-index: AQHMz8Pn6s41OiKYw0CGHKnxxgqL05YF9UTb X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <063.9b81af3c175d186140d57829d721bd2b@trac.tools.ietf.org> Cc: "clue@ietf.org" Subject: Re: [clue] #2: Use cases for selecting composed captures X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 19:26:48 -0000 Hi, I do not understand why you this issue is still on my name. I sent previous= emails to the list about the use cases. I hope this is my last email for t= he tracker on the issue and it will start the discussion. The current description of composed in section 5.4.2 is =20 "A Boolean variable to indicate whether the MC is a mix or composition of other MCs or Streams. (This could indicate for example a continuous presence view of multiple images in a grid, or a large image with smaller picture-in-picture images in it. When applied to an audio capture, it indicates a composition of ACs by some mixing algorithm) This attribute is not intended to differentiate between different ways of composing or mixing images. For possible extension of the framework, additional attributes could be defined to distinguish between different ways of composing or mixing captures. For example, with different video layout arrangements of composing multiple images into one, or different audio mixing algorithms." Note that it says that there can be different composition options and the e= ditors decided that the attribute should not differentiate between them and= do it only in extensions. So the issue is not what are the use cases since= the draft talk about different cases but whether the cases should be speci= fied here and provide more options for the provider to propose different mi= xes allowing the consumer to select between them. I can give again the most obvious use case which is the support for site sw= itch and segment switch modes that are part of the use cases draft. The provider should be able to specify if the video capture is based on sit= e switch or segment switch or say that it can support one of them or both. = The consumer should be able to ask for a specific view based on the mixed p= olicy. For point to point calls that use case for the provider to specify what is = being offered. Examples of different options may be a view of current speak= er with a PiP that has the previous speaker, or the whole room or a mix of = the other capture devices. Another option is a mix of the active speaker wi= th the center capture device if the speaker is not in the center.=20 All these options cannot be specified by a Boolean called composed. The current description of auto switch in term of capture area does not pro= vide any information about the actual size of each view. Note that auto swi= tch algorithm is not defined and is not meant to be unique. (voice activate= d is an option) other options are switch input every 30 seconds, ... Roni Even=20 ________________________________________ From: clue issue tracker [trac+clue@gamay.tools.ietf.org] Sent: Tuesday, January 10, 2012 20:15 To: pkyzivat@alum.mit.edu Cc: clue@ietf.org; Roni even Subject: [clue] #2: Use cases for selecting composed captures #2: Use cases for selecting composed captures Roni Even to post use cases for selecting composed captures, on the mailing list. -- ------------------------------------+----------------------- Reporter: pkyzivat@=85 | Owner: Roni Even Type: task | Status: new Priority: major | Milestone: Component: telepresence-use-cases | Version: Severity: Active WG Document | Keywords: ------------------------------------+----------------------- Ticket URL: clue = From Even.roni@huawei.com Tue Jan 10 11:30:12 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01DDC21F86F4 for ; Tue, 10 Jan 2012 11:30:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.555 X-Spam-Level: X-Spam-Status: No, score=-106.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zZ5hpuRZWPIs for ; Tue, 10 Jan 2012 11:30:11 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 5AF4F21F864B for ; Tue, 10 Jan 2012 11:30:11 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LXL002JYKU96L@szxga04-in.huawei.com> for clue@ietf.org; Wed, 11 Jan 2012 03:30:10 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LXL00HJMKU9B9@szxga04-in.huawei.com> for clue@ietf.org; Wed, 11 Jan 2012 03:30:09 +0800 (CST) Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGI90358; Wed, 11 Jan 2012 03:30:09 +0800 Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 11 Jan 2012 03:30:03 +0800 Received: from SZXEML519-MBS.china.huawei.com ([169.254.7.136]) by szxeml403-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Wed, 11 Jan 2012 03:30:01 +0800 Date: Tue, 10 Jan 2012 19:30:00 +0000 From: Roni even In-reply-to: <063.c25c26d18d12df129eb97ad25ea6bc92@trac.tools.ietf.org> X-Originating-IP: [172.24.1.69] To: clue issue tracker , "draft-ietf-clue-framework@tools.ietf.org" , "pkyzivat@alum.mit.edu" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=Windows-1252 Content-language: en-US Content-transfer-encoding: quoted-printable Accept-Language: en-US, zh-CN Thread-topic: [clue] #4: Share CLUE metadata with W3C Thread-index: AQHMz8z1SxIHBrq5HkmWvsY7tZrRjZYF/JzJ X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <063.c25c26d18d12df129eb97ad25ea6bc92@trac.tools.ietf.org> Cc: "clue@ietf.org" Subject: Re: [clue] #4: Share CLUE metadata with W3C X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 19:30:12 -0000 Hi, I think we need first to discuss the metadata which does not exist in CLUE,= before sending to W3C Roni ________________________________________ From: clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of clue issue= tracker [trac+clue@gamay.tools.ietf.org] Sent: Tuesday, January 10, 2012 20:22 To: draft-ietf-clue-framework@tools.ietf.org; pkyzivat@alum.mit.edu Cc: clue@ietf.org Subject: [clue] #4: Share CLUE metadata with W3C #4: Share CLUE metadata with W3C CLUE should submit or socialize the metadata with W3C. -- ------------------------+----------------------------------------- Reporter: pkyzivat@=85 | Owner: draft-ietf-clue-framework@=85 Type: task | Status: new Priority: major | Milestone: Component: framework | Version: Severity: - | Keywords: ------------------------+----------------------------------------- Ticket URL: clue _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue= From pkyzivat@alum.mit.edu Tue Jan 10 11:32:01 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DA7B21F8757 for ; Tue, 10 Jan 2012 11:32:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JpJ8j3lmgc4g for ; Tue, 10 Jan 2012 11:32:00 -0800 (PST) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by ietfa.amsl.com (Postfix) with ESMTP id 8AEFE21F8755 for ; Tue, 10 Jan 2012 11:32:00 -0800 (PST) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta07.westchester.pa.mail.comcast.net with comcast id Kqg41i0051YDfWL57vY1nP; Tue, 10 Jan 2012 19:32:01 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta20.westchester.pa.mail.comcast.net with comcast id KvY01i01w07duvL3gvY0ay; Tue, 10 Jan 2012 19:32:01 +0000 Message-ID: <4F0C922F.2030301@alum.mit.edu> Date: Tue, 10 Jan 2012 14:31:59 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: CLUE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [clue] Issue Tracker guidelines X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 19:32:01 -0000 I just posted issues in issue tracker for the relevant action items from Taipei. This is the first use of the issue tracker in this wg. Its gotten very confusing in some other working groups, so Mary and I want to take it slowly while we work out appropriate conventions. For now, we would like to reserve entering and updating issues to the chairs, based on work done in meetings and on the list. Please discuss these issues on the list, and when doing so, please reference the issue number, preferably in the subject of your email. If you are the owner of an issue, please report your action on the list and Mary or I will update to issue accordingly. If this process turns out to be too cumbersome we will certainly entertain changing how we do it. Thanks, Paul From pkyzivat@alum.mit.edu Tue Jan 10 11:49:09 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E20221F8806 for ; Tue, 10 Jan 2012 11:49:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wSgAUvMokB3X for ; Tue, 10 Jan 2012 11:49:08 -0800 (PST) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by ietfa.amsl.com (Postfix) with ESMTP id 9C8B221F8797 for ; Tue, 10 Jan 2012 11:49:08 -0800 (PST) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by QMTA11.westchester.pa.mail.comcast.net with comcast id KvLv1i00127AodY5Bvp9Ay; Tue, 10 Jan 2012 19:49:09 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta19.westchester.pa.mail.comcast.net with comcast id Kvp51i01707duvL3fvp5LM; Tue, 10 Jan 2012 19:49:09 +0000 Message-ID: <4F0C962F.5070401@alum.mit.edu> Date: Tue, 10 Jan 2012 14:49:03 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Roni even References: <063.c25c26d18d12df129eb97ad25ea6bc92@trac.tools.ietf.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "draft-ietf-clue-framework@tools.ietf.org" , "clue@ietf.org" , clue issue tracker Subject: Re: [clue] #4: Share CLUE metadata with W3C X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 19:49:09 -0000 On 1/10/12 2:30 PM, Roni even wrote: > Hi, > I think we need first to discuss the metadata which does not exist in CLUE, before sending to W3C > Roni I agree. The issue is just a reminder. Clearly we need to have something well defined before we can share it. So this ticket is likely to be open for some time. Thanks, Paul > ________________________________________ > From: clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of clue issue tracker [trac+clue@gamay.tools.ietf.org] > Sent: Tuesday, January 10, 2012 20:22 > To: draft-ietf-clue-framework@tools.ietf.org; pkyzivat@alum.mit.edu > Cc: clue@ietf.org > Subject: [clue] #4: Share CLUE metadata with W3C > > #4: Share CLUE metadata with W3C > > CLUE should submit or socialize the metadata with W3C. > > -- > ------------------------+----------------------------------------- > Reporter: pkyzivat@… | Owner: draft-ietf-clue-framework@… > Type: task | Status: new > Priority: major | Milestone: > Component: framework | Version: > Severity: - | Keywords: > ------------------------+----------------------------------------- > > Ticket URL: > clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From Mark.Duckworth@polycom.com Tue Jan 10 19:30:36 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36A3A21F858F for ; Tue, 10 Jan 2012 19:30:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yi0Cl6y6bQBr for ; Tue, 10 Jan 2012 19:30:35 -0800 (PST) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 09B4B21F8584 for ; Tue, 10 Jan 2012 19:30:33 -0800 (PST) Received: from Crpmboxprd01.polycom.com ([fe80::ad68:5a0:c919:66b6]) by Crpehubprd01.polycom.com ([fe80::5efe:10.236.0.158%14]) with mapi; Tue, 10 Jan 2012 19:30:33 -0800 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Tue, 10 Jan 2012 19:30:31 -0800 Thread-Topic: [clue] I-D Action: draft-ietf-clue-framework-02.txt Thread-Index: AczMxUCF1Fccr9KqQzyqLYw4G9PIZgCs5VjwACYCtVA= Message-ID: <44C6B6B2D0CF424AA90B6055548D7A6102FAC90B97@CRPMBOXPRD01.polycom.com> References: <20120106224757.22622.57341.idtracker@ietfa.amsl.com> <4f0c0467.d4260e0a.49db.16b3@mx.google.com> In-Reply-To: <4f0c0467.d4260e0a.49db.16b3@mx.google.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [clue] I-D Action: draft-ietf-clue-framework-02.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 03:30:36 -0000 Hi Roni, We are working on additional improvements to the framework draft, including= a better explanation of the encoding groups. We expect this to be include= d in a new draft within a couple of weeks. I'm not sure when we will have a structured representation like XML, we hav= en't talked about that since the last meeting. Regards, Mark -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Ron= i Even Sent: Tuesday, January 10, 2012 4:24 AM To: internet-drafts@ietf.org; i-d-announce@ietf.org Cc: clue@ietf.org Subject: Re: [clue] I-D Action: draft-ietf-clue-framework-02.txt Hi, I intend to read the new version this week but at a first glance I noticed = that the section on encoding groups was not changed to explain the encoding= groups, the current text is unclear and I doubt if this should be part of = the basic data model or an extension. Another thing that is missing is the data model in some structured represen= tation like XML which is needed in order to progress with the CLUE transpor= t decision. I was under the impression that the editors of the draft mentio= ned that they are working on it and we will have it before the interim meet= ing, is this still the case. Thanks Roni Even > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf=20 > Of internet-drafts@ietf.org > Sent: Saturday, January 07, 2012 12:48 AM > To: i-d-announce@ietf.org > Cc: clue@ietf.org > Subject: [clue] I-D Action: draft-ietf-clue-framework-02.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts=20 > directories. This draft is a work item of the ControLling mUltiple=20 > streams for tElepresence Working Group of the IETF. >=20 > Title : Framework for Telepresence Multi-Streams > Author(s) : Allyn Romanow > Mark Duckworth > Andrew Pepperell > Brian Baldino > Filename : draft-ietf-clue-framework-02.txt > Pages : 37 > Date : 2012-01-06 >=20 > This memo offers a framework for a protocol that enables devices in=20 > a > telepresence conference to interoperate by specifying the > relationships between multiple RTP streams. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-clue-framework-02.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-clue-framework-02.txt >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From Mark.Duckworth@polycom.com Tue Jan 10 19:43:22 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A570811E8072 for ; Tue, 10 Jan 2012 19:43:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xIyCVvSHWOFD for ; Tue, 10 Jan 2012 19:43:18 -0800 (PST) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 69CCA11E8088 for ; Tue, 10 Jan 2012 19:43:16 -0800 (PST) Received: from Crpmboxprd01.polycom.com ([fe80::ad68:5a0:c919:66b6]) by crpehubprd02.polycom.com ([fe80::5efe:10.236.0.154%12]) with mapi; Tue, 10 Jan 2012 19:43:15 -0800 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Tue, 10 Jan 2012 19:43:14 -0800 Thread-Topic: [clue] Updates in framework-02 Thread-Index: AczMxVqqdkntgE2oTNql2+0ws/lubgC3wcIAABtXwlA= Message-ID: <44C6B6B2D0CF424AA90B6055548D7A6102FAC90B98@CRPMBOXPRD01.polycom.com> References: <44C6B6B2D0CF424AA90B6055548D7A6102FAC9013A@CRPMBOXPRD01.polycom.com> <4f0c4c80.10610e0a.01e0.ffffa799@mx.google.com> In-Reply-To: <4f0c4c80.10610e0a.01e0.ffffa799@mx.google.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_44C6B6B2D0CF424AA90B6055548D7A6102FAC90B98CRPMBOXPRD01p_" MIME-Version: 1.0 Subject: Re: [clue] Updates in framework-02 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 03:43:22 -0000 --_000_44C6B6B2D0CF424AA90B6055548D7A6102FAC90B98CRPMBOXPRD01p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Roni, The relevant parts to review are these sections: 5.3. Describing Spatial Relations 5.4.4. Area of capture 5.4.5. Point of capture 5.6. Attributes for Capture Sets 5.6.2 Area Scale Millimeters (I think the name should be changed to just "= area scale") 9. Using the Framework This link to the differences might be useful to help you review what has ch= anged: http://tools.ietf.org/wg/clue/draft-ietf-clue-framework/draft-ietf-clue-fra= mework-02-from-01.diff.html Regards, Mark From: Roni Even [mailto:ron.even.tlv@gmail.com] Sent: Tuesday, January 10, 2012 9:31 AM To: Duckworth, Mark; clue@ietf.org Subject: RE: [clue] Updates in framework-02 Hi Mrak, Just to clarify, you are asking for review of sections 5.3 till 5.6.2 Roni From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Duc= kworth, Mark Sent: Saturday, January 07, 2012 12:52 AM To: clue@ietf.org Subject: [clue] Updates in framework-02 The framework-02 document has updates to the sections about describing spat= ial relationships, using a coordinate system and attributes for area of cap= ture and point of capture. This is based on the presentation and discussio= n at the Taipei meeting, and email list discussion. Please review and post= comments. Mark Duckworth --_000_44C6B6B2D0CF424AA90B6055548D7A6102FAC90B98CRPMBOXPRD01p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Roni,

 

The relevant parts to review are these sections:

5.3. = Describing Spatial Relations

5.4.4. Area of capture

5.4.5. Point of capture<= /o:p>

5.6. Att= ributes for Capture Sets

5.6.2 Area Scale Millimeters  (I think the name = should be changed to just “area scale”)

9. Using the Framework

&= nbsp;

Th= is link to the differences might be useful to help you review what has chan= ged:

http://tools.ietf.org/wg/clue/draft-ietf-clue-framework/draft-i= etf-clue-framework-02-from-01.diff.html

 

Regards,

Mark

 

=

 =

From: Roni Even [mailto:ron.even.tlv@g= mail.com]
Sent: Tuesday, January 10, 2012 9:31 AM
To: = Duckworth, Mark; clue@ietf.org
Subject: RE: [clue] Updates in fra= mework-02

 =

Hi Mrak,<= /o:p>

Just to = clarify, you are asking for review of sections 5.3 till 5.6.2

Roni<= /span>

 

From: clue-bounces@ie= tf.org [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, MarkSent: Saturday, January 07, 2012 12:52 AM
To: clue@ietf.= org
Subject: [clue] Updates in framework-02

=

 

= The framework-02 document has updates to the sections about describing spat= ial relationships, using a coordinate system and attributes for area of cap= ture and point of capture.  This is based on the presentation and disc= ussion at the Taipei meeting, and email list discussion.  Please revie= w and post comments.

 

Mark Duckworth

= --_000_44C6B6B2D0CF424AA90B6055548D7A6102FAC90B98CRPMBOXPRD01p_-- From pkyzivat@alum.mit.edu Wed Jan 11 11:12:35 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04DF911E8094 for ; Wed, 11 Jan 2012 11:12:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uZszK2BW2T8f for ; Wed, 11 Jan 2012 11:12:34 -0800 (PST) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by ietfa.amsl.com (Postfix) with ESMTP id 1B0C511E8073 for ; Wed, 11 Jan 2012 11:12:33 -0800 (PST) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta06.westchester.pa.mail.comcast.net with comcast id LJu51i0040Fqzac56KCagj; Wed, 11 Jan 2012 19:12:34 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta08.westchester.pa.mail.comcast.net with comcast id LKCZ1i00R07duvL3UKCZuF; Wed, 11 Jan 2012 19:12:34 +0000 Message-ID: <4F0DDF21.2070706@alum.mit.edu> Date: Wed, 11 Jan 2012 14:12:33 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Roni even References: <063.9b81af3c175d186140d57829d721bd2b@trac.tools.ietf.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "clue@ietf.org" Subject: Re: [clue] #2: Use cases for selecting composed captures X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 19:12:35 -0000 On 1/10/12 2:26 PM, Roni even wrote: > Hi, > I do not understand why you this issue is still on my name. I sent previous emails to the list about the use cases. I hope this is my last email for the tracker on the issue and it will start the discussion. From the minutes on the discussion of the framework in Taipei: | Selecting Composed Captures: | | Options- | | · do nothing | | · attempt to define a few specific policies | | Charles Eckel - "hints" in prev. framework draft may be sufficient. | | Jonathan Lennox - do we have details on policies? | | Stephen Botzko - lots of different conference/composition policies, very difficult to structure this information meaningfully. | | Allyn Romanow - agrees this is difficult, would rather postpone this | | Roni Even - sees distinction between requesting and selecting | | Mary Barnes - "Policy" word is scary, XCON struggled with a similar issue. | | Action - Roni Even to provide use cases on list for discussion. | | Conclusion: there is agreement that source selection work needs to continue, at least as requirements. Actual mechanism might be handed off to another group. This is the source of the action item. The option to do nothing was discarded, leaving the need to do something more. I don't find anything on the list subsequent to this session directly addressing this subject. The goal was to initiate more discussion towards what to specify. Maybe this mail will at least start that discussion. Thanks, Paul > The current description of composed in section 5.4.2 is > "A Boolean variable to indicate whether the MC is a mix or composition > of other MCs or Streams. (This could indicate for example a > continuous presence view of multiple images in a grid, or a large > image with smaller picture-in-picture images in it. When applied to > an audio capture, it indicates a composition of ACs by some mixing > algorithm) > This attribute is not intended to differentiate between different > ways of composing or mixing images. For possible extension of the > framework, additional attributes could be defined to distinguish > between different ways of composing or mixing captures. For example, > with different video layout arrangements of composing multiple images > into one, or different audio mixing algorithms." > > Note that it says that there can be different composition options and the editors decided that the attribute should not differentiate between them and do it only in extensions. So the issue is not what are the use cases since the draft talk about different cases but whether the cases should be specified here and provide more options for the provider to propose different mixes allowing the consumer to select between them. > > I can give again the most obvious use case which is the support for site switch and segment switch modes that are part of the use cases draft. > The provider should be able to specify if the video capture is based on site switch or segment switch or say that it can support one of them or both. The consumer should be able to ask for a specific view based on the mixed policy. > > For point to point calls that use case for the provider to specify what is being offered. Examples of different options may be a view of current speaker with a PiP that has the previous speaker, or the whole room or a mix of the other capture devices. Another option is a mix of the active speaker with the center capture device if the speaker is not in the center. > All these options cannot be specified by a Boolean called composed. > > The current description of auto switch in term of capture area does not provide any information about the actual size of each view. Note that auto switch algorithm is not defined and is not meant to be unique. (voice activated is an option) other options are switch input every 30 seconds, ... > > Roni Even > > ________________________________________ > From: clue issue tracker [trac+clue@gamay.tools.ietf.org] > Sent: Tuesday, January 10, 2012 20:15 > To: pkyzivat@alum.mit.edu > Cc: clue@ietf.org; Roni even > Subject: [clue] #2: Use cases for selecting composed captures > > #2: Use cases for selecting composed captures > > Roni Even to post use cases for selecting composed captures, on the > mailing list. > > -- > ------------------------------------+----------------------- > Reporter: pkyzivat@… | Owner: Roni Even > Type: task | Status: new > Priority: major | Milestone: > Component: telepresence-use-cases | Version: > Severity: Active WG Document | Keywords: > ------------------------------------+----------------------- > > Ticket URL: > clue From pkyzivat@alum.mit.edu Wed Jan 11 11:14:50 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93A0621F8627 for ; Wed, 11 Jan 2012 11:14:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dSHTf3hJWt3I for ; Wed, 11 Jan 2012 11:14:49 -0800 (PST) Received: from qmta01.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by ietfa.amsl.com (Postfix) with ESMTP id B116A21F8592 for ; Wed, 11 Jan 2012 11:14:49 -0800 (PST) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta01.westchester.pa.mail.comcast.net with comcast id LBiX1i00227AodY51KEqll; Wed, 11 Jan 2012 19:14:50 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta19.westchester.pa.mail.comcast.net with comcast id LKEp1i01407duvL3fKEpgK; Wed, 11 Jan 2012 19:14:50 +0000 Message-ID: <4F0DDFAA.2050102@alum.mit.edu> Date: Wed, 11 Jan 2012 14:14:50 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: clue@ietf.org References: <4F0C922F.2030301@alum.mit.edu> In-Reply-To: <4F0C922F.2030301@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] Issue Tracker guidelines X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 19:14:50 -0000 Another thing to keep in mind, that I just discovered: If you reply to a message sent by the issue tracker, you should remove the address of the issue tracker from the recipient list. I'm not sure what happens if you reply to it, but I don't think we want it. Thanks, Paul On 1/10/12 2:31 PM, Paul Kyzivat wrote: > I just posted issues in issue tracker for the relevant action items from > Taipei. > > This is the first use of the issue tracker in this wg. Its gotten very > confusing in some other working groups, so Mary and I want to take it > slowly while we work out appropriate conventions. > > For now, we would like to reserve entering and updating issues to the > chairs, based on work done in meetings and on the list. Please discuss > these issues on the list, and when doing so, please reference the issue > number, preferably in the subject of your email. If you are the owner of > an issue, please report your action on the list and Mary or I will > update to issue accordingly. > > If this process turns out to be too cumbersome we will certainly > entertain changing how we do it. > > Thanks, > Paul > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From mary.ietf.barnes@gmail.com Thu Jan 12 09:39:37 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EEEF21F8631 for ; Thu, 12 Jan 2012 09:39:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.695 X-Spam-Level: X-Spam-Status: No, score=-103.695 tagged_above=-999 required=5 tests=[AWL=-0.096, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mltXlwlB4Um9 for ; Thu, 12 Jan 2012 09:39:37 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id ECC5921F85B6 for ; Thu, 12 Jan 2012 09:39:36 -0800 (PST) Received: by vbbfc21 with SMTP id fc21so592809vbb.31 for ; Thu, 12 Jan 2012 09:39:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=U2Be0BwoPmxedIe6eTZAE3UZFMHYSvDWem/AnzE9yFA=; b=AkObODrLzhz5HdoDlBZ/3UaPDT6QaKWtsItf3wdAcjQwuWOZogIkThAMxttLosNzUh 3hC01cCq6zZ6EQYHhmJzzEbuCVVA6wWPDCO9GRsd4R8HhV1bRCNJJEUcbBGgxyL174n5 fffhSejua6mBKe+I093uIrj9ujNejABId9ZEo= MIME-Version: 1.0 Received: by 10.52.67.35 with SMTP id k3mr2240252vdt.38.1326389976500; Thu, 12 Jan 2012 09:39:36 -0800 (PST) Received: by 10.52.108.196 with HTTP; Thu, 12 Jan 2012 09:39:36 -0800 (PST) Date: Thu, 12 Jan 2012 11:39:36 -0600 Message-ID: From: Mary Barnes To: CLUE Content-Type: text/plain; charset=ISO-8859-1 Subject: [clue] CLUE open design team online meeting - Tuesdays, 9am-10 am Central - starts on Jan 17th X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 17:39:37 -0000 Hi all, We are scheduling a weekly online meeting for the CLUE WG. The objective is to discuss open issues in the WG documents and any other key topics being discussed on the mailing list. We will have these weekly up to the interim meeting and then assess the effectiveness. If you are interested in joining the meetings, please let me know so that I can ensure you get the logistics. Thanks, Mary and Paul. CLUE WG co-chairs From wwwrun@ietfa.amsl.com Thu Jan 12 12:09:59 2012 Return-Path: X-Original-To: clue@ietf.org Delivered-To: clue@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 30) id D848D21F84CE; Thu, 12 Jan 2012 12:09:58 -0800 (PST) From: IESG Secretary To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20120112200958.D848D21F84CE@ietfa.amsl.com> Date: Thu, 12 Jan 2012 12:09:58 -0800 (PST) Cc: clue@ietf.org Subject: [clue] CLUE Working Group Interim Meeting, February 15-16, 2012, Andover, MA, USA X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 20:09:59 -0000 Hi Folks, A face-to-face interim meeting is being scheduled for the CLUE WG. Date: Feb 15-16, 2012 (two full days) Location: Polycom, 100 Minuteman Road, Andover, Massachusetts, USA. Hotel information and other logistics are available on the CLUE WG wiki: http://trac.tools.ietf.org/wg/clue/trac/wiki We will also post the Webex information for remote participants when it is available (on the mailing list and on the wiki). The materials for the meeting will be available on the WG wiki (and will be submitted to the IETF-83 meeting material repository). Note that the deadline for documents to be discussed at the meeting is Feb 3rd, 17:00 Pacific. The draft agenda is as follows: Day 1: --------- 9:00-9:10 Chair - status, agenda bash 9:10-09:50 Discussion of any remaining open issues for the use cases and framework 09:50-10:00 Short coffee break 10:00-11:30 Framework open issues 11:30-13:00 Lunch 13:30-15:00 Framework open issues 15:00-15:20 Break 15:20-17:00 Review/Discussion of CLUE "metadata" 17:00-18:00 Summary and identification of key items for discussion on day 2. Day 2 (note this agenda will be finalized based on the outcome of the day 1 meeting) -------- 9:00-9:10 Chair - status, agenda bash 9:10-10:15 Signaling for CLUE 10:15-10:30 Short coffee break 10:30-11:30 RTP Usage for CLUE 11:30-13:00 Lunch 13:30-15:00 Discussion based on key items identified on day 1. 15:00-15:20 Break 15:20-17:00 Discussion based on key items identified on day 1. 17:00-18:00 Discussion of way forward and summary of action items Regards, Mary Barnes, Paul Kyzivat CLUE WG chairs From ron.even.tlv@gmail.com Fri Jan 13 10:22:49 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8B5C21F8559 for ; Fri, 13 Jan 2012 10:22:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ywlP+nS86lLa for ; Fri, 13 Jan 2012 10:22:45 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 387BF21F8554 for ; Fri, 13 Jan 2012 10:22:44 -0800 (PST) Received: by eeit10 with SMTP id t10so246745eei.31 for ; Fri, 13 Jan 2012 10:22:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:x-mailer:content-language:thread-index; bh=EOgx11+R5znSsgz0U+Fgp++gzFY4TrFB80QbapJGR3w=; b=NIgt5r3Z+yOjohLLA8fKEyi5+K1kaapxPPvvtfTtoYcGMFg5Dn4e3EjDU+2EEPzInM 9gSP3BBwRyvyD/EOjfMUv0I5kTs6G1uDQ+QO2IaRqGy17qErdNd4o68zYB4ocGcfrfBB m0c4Z+8At1zlxWJLytuF8SBhkiVkhrdu5FsCM= Received: by 10.213.33.202 with SMTP id i10mr225279ebd.4.1326478963651; Fri, 13 Jan 2012 10:22:43 -0800 (PST) Received: from windows8d787f9 (bzq-79-180-198-96.red.bezeqint.net. [79.180.198.96]) by mx.google.com with ESMTPS id b49sm32487290eec.9.2012.01.13.10.22.40 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 13 Jan 2012 10:22:42 -0800 (PST) From: "Roni Even" To: "'Duckworth, Mark'" , References: <44C6B6B2D0CF424AA90B6055548D7A6102FAC9013A@CRPMBOXPRD01.polycom.com> <4f0c4c80.10610e0a.01e0.ffffa799@mx.google.com> <44C6B6B2D0CF424AA90B6055548D7A6102FAC90B98@CRPMBOXPRD01.polycom.com> In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A6102FAC90B98@CRPMBOXPRD01.polycom.com> Date: Fri, 13 Jan 2012 20:19:12 +0200 Message-ID: <4f107672.c9330e0a.16d4.fffff935@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002E_01CCD230.9ED69D30" X-Mailer: Microsoft Office Outlook 12.0 Content-language: en-us Thread-Index: AczMxVqqdkntgE2oTNql2+0ws/lubgC3wcIAABtXwlAAgEnK8A== Subject: Re: [clue] Updates in framework-02 - section 5 review. X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 18:22:50 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_002E_01CCD230.9ED69D30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I read the draft again till section 6 in order to review the parts you mentioned. It is better than 01 but I still have some comments. I will list all of them in this email and afterwards we can cut out the ones that remain open if any? Some of them are editorial. I will comment on all section 5. 1 The second sentence in section 5 says "figure" no number and no number to the figure. 2. The figure in section 5 need to show that capture set is composed of rows and each row is made from media captures. 3. The second sentence in 5.1 is not needed you just need to use the term and not repeat part of the definition. 4. We need a term for the "row of media captures inside a capture set" 5. In 5.1 fourth paragraph change to "Media Captures may also be associated with data constructs that capture encoding aspects of the streams" . 6. In 5.2 fourth paragraph suggest adding "may be" to become "A media capture is described by Attributes and may be associated with an Encode Group, and Simultaneous Transmission Set." 7. In 5.3 first paragraph I suggest changing to "Within a capture set, a coordinate system should be used to model relative or absolute positions of its constituent media captures. This can allow precise physical sizes to be determined if required, as well as the order in which media captures that form a group should be rendered. " The co-ordinate system is needed if you want to describe the spatial relations. I also changed the "displayed" to "rendered" 8. In 5.3 second bullet suggest to change to "for example it shall provide co-ordinate information for 3 side-by-side participant .". . it does not matter if absolute or relative or no scale but it is needed to describe the spatial relations. 9. In 5.3 in the third bullet, No physical scale means no spatial relation or is it to provide some way to describe the rendering order (e.g. for MCU case). 10. Audience front at the end of section 5.3 is not specified, there is front and back in section 3 11. In section 5.4 first paragraph what do you mean by static, Is media capture describing a static aspect of a stream? My view is that attribute are not static but may define some range, like maximum value or a model for switching. 12. In 5.4 second paragraph you mention "most common use case" what are those, maybe these is why we are discussing what attributes and values should be specified here. 13. in 5.4.1 I am not sure what main is and what should not be main, I can understand the logic in RFC 4796. For example can we specify "speaker" as a purpose. As for main I can see a media capture that shows the whole room as main yet a VC1 that shows left side of a room is not main, I will see as main a "row" that has (VC1 - left, VC2-middle, VC3-right). So should we have VC1 with purpose main even when stands by itself. 14. On 5.4.2 we are having a separate discussion about what should be defined in this document. 15. in 5.4.4 first paragraph "By comparing the area of capture for different media captures, " I think you need to add of the same capture scene or capture set. 16. in 5.4.4 third paragraph you say that the planes should intersect, why is that, I think that there can be a gap between the planes at the area of capture. The area of captures are in the area of scene defined later. 17. In 5.4.4 you mention 4 points but not the order they are listed, in the example in section 9 you give a table but the headers are not part of the definition, maybe specify from top left clockwise direction. 18. Suggest to change the start of the last paragraph in 5.4.4 to "If the area of capture attribute is specified, it must include X, Y, Z .". I do not like the use of "optional" in the current sentence. 19. Section 5.4.5 suggest to change the beginning to " The point_of_capture attribute is used to describe the location of a capture device or pseudo-device. A use case is if there are multiple captures ." 20. We have a separate open issue on 5.4.6. 21. In 5.5 the first two paragraph use capture set and capture scene, we need to clarify the relation between them, maybe in section3. We discussed it in Taipei. For example are the two capture sets in the example in the second paragraph one or two capture scenes. 22. in 5.5 ""Media Captures of the same media type are associated with each other by grouping them together in a single row of a Capture Set" . I think that the grouping in a single row means simultaneous, does the grouping imply any other association without using any attribute? If not maybe say " simultaneous" 23. In 5.5 " Association between audio and video can be made by finding audio and video captures which share overlapping areas of capture." I think this requires that they will use the same origin, I did not see it required. 24. In 5.5 " A media consumer could choose one row of each media type (e.g., audio and video) from a capture set. For example a three stream consumer could choose the first video row plus the audio row, while a single stream consumer could choose the second or third video row plus the audio row. An MCU consumer might choose to receive multiple rows." A single stream consumer may also choose VC0 or VC1 or VC2, maybe clarify it since it is the non obvious case. 25. I think that the last paragraph in section 5.5 should be removed and discussed when you define the Simultaneous Transmission Sets and Encoding Groups, it is out of context here and this is why I cannot even discuss it when talking about this section. 26. 5.6 talks about attributes of capture set while the first bullet is about capture scene. This is again about the lack of clarity about these two terms. 27. In 5.6.1 I suggest adding the following sentence in the end "The area of captures specified for this capture set must use the same co-ordinate system (same origin)" This is the end of my long list Roni Even From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark Sent: Wednesday, January 11, 2012 5:43 AM To: clue@ietf.org Subject: Re: [clue] Updates in framework-02 Hi Roni, The relevant parts to review are these sections: 5.3. Describing Spatial Relations 5.4.4. Area of capture 5.4.5. Point of capture 5.6. Attributes for Capture Sets 5.6.2 Area Scale Millimeters (I think the name should be changed to just "area scale") 9. Using the Framework This link to the differences might be useful to help you review what has changed: http://tools.ietf.org/wg/clue/draft-ietf-clue-framework/draft-ietf-clue-fram ework-02-from-01.diff.html Regards, Mark _____ ------=_NextPart_000_002E_01CCD230.9ED69D30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

I read the draft again = till section 6 in order to review the parts you mentioned. It is better = than 01 but I still have some comments.  

I will list all of them = in this email and afterwards we can cut out the ones that remain open if = any? Some of them are editorial. I will comment on all section = 5.

 

1 The second sentence in = section 5 says "figure" no number and no number to the = figure.

 

2. The figure in section = 5 need to show that capture set is composed of rows and each row is made = from media captures.

 

3. The second sentence = in 5.1 is not needed you just need to use the term and not repeat part = of the definition.

 

4. We need a term for = the "row of media captures inside a capture = set"

 

5. In 5.1 = fourth paragraph  change to "Media = Captures may also be associated with data constructs that capture  = encoding aspects of the streams" .

 =

6. =  In 5.2 fourth paragraph suggest adding "may be" =  to  become "A media capture is described by Attributes = and may be associated with an  Encode Group, and Simultaneous = Transmission Set."

 =

7. In 5.3 = first paragraph I suggest changing to "Within a capture set, a = coordinate system should be used to  model relative or absolute = positions of its constituent media

  = ; captures.  This can allow precise physical sizes to be determined = if  required, as well as the order in which media captures that = form a   group should be rendered. = "

The = co-ordinate system is needed if you want to describe the spatial = relations. I also changed the "displayed" to = "rendered"

 =

8. In 5.3 = second bullet suggest to change to "for example it shall provide =  co-ordinate information for 3 = side-by-side participant …". . it does not matter if absolute = or relative or no scale but it is needed to describe the spatial = relations.

 =

9. In 5.3 = in the third bullet, No physical scale means no spatial relation or is = it to provide some way to describe the rendering order (e.g. for MCU = case).

 =

10. = Audience front at the end of section 5.3 is not specified, there is = front and back in section 3

 =

11. In = section 5.4 first paragraph what do you mean by static, Is media capture = describing a static aspect of a stream? My view is that attribute are = not static but may define some range, like maximum value or a model for = switching.

 =

12. In 5.4 = second paragraph you mention "most common use case" what are = those, maybe these is why we are discussing what attributes and values = should be specified here.

 =

13. in = 5.4.1 I am not sure what main is and what should not be main, I can = understand the logic in RFC 4796. For example can we specify = "speaker" as a purpose.  

As for = main I can see a media capture that shows the whole room as main yet a = VC1 that shows left side of a room is not main, I will see as main a = "row" that has (VC1 - left, VC2-middle, VC3-right). So should = we have VC1 with purpose main even when stands by = itself.

 =

14. On = 5.4.2 we are having a separate discussion about what should be defined = in this document.=

 =

15. in = 5.4.4 first paragraph "By comparing the area of   capture = for different media captures, " I think you need to add of the same = capture scene or capture set.

 =

16. in = 5.4.4 third paragraph you say that the planes should intersect, why is = that, I think that there can be a gap between the planes at the area of = capture.  The area of captures are in the area of scene defined = later.

 =

17. In = 5.4.4 you mention 4 points but not the order they are listed, in the = example in section 9 you give a table but the headers are not part of = the definition, maybe specify from top left clockwise = direction.

 =

18. = Suggest to change the start of the last paragraph in 5.4.4 to "If = the area of capture attribute is specified, it must include X, Y, Z = …". I do not like the use of "optional" in the = current sentence.

 =

19. = Section 5.4.5 suggest to change the beginning to " The = point_of_capture attribute is used to describe the location  of a = capture device or pseudo-device. A use case is if there are multiple = captures …"

 =

20. We = have a separate open issue on 5.4.6.

 =

21. In 5.5 = the first two paragraph use capture set and capture scene, we need to = clarify the relation between them, maybe in section3. We discussed it in = Taipei. For example are the two capture sets in the example in the = second paragraph one or two capture scenes.

 =

22. in 5.5 = ""Media Captures of the same media type are associated with = each other  by grouping them together in a single row of a Capture = Set" .  I think that the grouping in a single row means = simultaneous, does the grouping imply any other association without = using any attribute? If not maybe say " = simultaneous"

 =

23. In 5.5 = " Association between audio and video can be made by finding audio = and   video captures which share overlapping areas of = capture." I think this requires that they will use the same origin, = I did not see it required.

 =

24. In 5.5 = " A media consumer could choose one row of each media type (e.g., = audio  and video) from a capture set.  For example a three = stream consumer  could choose the first video row plus the audio = row, while a single

  = ; stream consumer could choose the second or third video row plus = the  audio row.  An MCU consumer might choose to receive = multiple rows."  A single stream consumer may also choose VC0 = or VC1 or VC2, maybe clarify it since it is the non obvious = case.

 =

25. I = think that the last paragraph in section 5.5 should be removed and = discussed when you define the Simultaneous Transmission Sets and = Encoding Groups, it is out of context here and this is why I cannot even = discuss it when talking about this section.

 =

26. 5.6 = talks about attributes of capture set while the first bullet is about = capture scene. This is again about the lack of clarity about these two = terms.

 =

27. In = 5.6.1 I suggest adding the following sentence in the end "The area = of captures specified for this capture set must use the same co-ordinate = system (same origin)"

 =

 =

 =

This is = the end of my long list

 =

Roni Even =

 =

 =

 =

 =

 =

=

 =

 =

 =

 

 =

 

 

 

 

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Duckworth, Mark
Sent: Wednesday, January 11, 2012 5:43 = AM
To: clue@ietf.org
Subject: Re: [clue] Updates in = framework-02

 

Hi Roni,

 

The relevant parts to = review are these sections:

5.3. Describing Spatial = Relations

5.4.4. Area of capture

5.4.5. Point of = capture

5.6. Attributes for Capture = Sets

5.6.2 Area Scale Millimeters  (I think the = name should be changed to just “area = scale”)

9. Using the Framework

 

This link to the = differences might be useful to help you review what has = changed:

http://tools.ietf.org/wg/clue/draf= t-ietf-clue-framework/draft-ietf-clue-framework-02-from-01.diff.html<= o:p>

 

Regards,

Mark

 

------=_NextPart_000_002E_01CCD230.9ED69D30-- From Mark.Duckworth@polycom.com Mon Jan 16 16:01:10 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B29121F84C4 for ; Mon, 16 Jan 2012 16:01:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17zWAsmN7c05 for ; Mon, 16 Jan 2012 16:01:03 -0800 (PST) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 940E121F86DB for ; Mon, 16 Jan 2012 16:00:55 -0800 (PST) Received: from Crpmboxprd01.polycom.com ([fe80::ad68:5a0:c919:66b6]) by Crpehubprd01.polycom.com ([fe80::5efe:10.236.0.158%14]) with mapi; Mon, 16 Jan 2012 16:00:54 -0800 From: "Duckworth, Mark" To: Roni Even , "clue@ietf.org" Date: Mon, 16 Jan 2012 16:00:52 -0800 Thread-Topic: [clue] Updates in framework-02 - section 5 review. Thread-Index: AczMxVqqdkntgE2oTNql2+0ws/lubgC3wcIAABtXwlAAgEnK8ACUO8kA Message-ID: <44C6B6B2D0CF424AA90B6055548D7A6102FADC4369@CRPMBOXPRD01.polycom.com> References: <44C6B6B2D0CF424AA90B6055548D7A6102FAC9013A@CRPMBOXPRD01.polycom.com> <4f0c4c80.10610e0a.01e0.ffffa799@mx.google.com> <44C6B6B2D0CF424AA90B6055548D7A6102FAC90B98@CRPMBOXPRD01.polycom.com> <4f107672.c9330e0a.16d4.fffff935@mx.google.com> In-Reply-To: <4f107672.c9330e0a.16d4.fffff935@mx.google.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_44C6B6B2D0CF424AA90B6055548D7A6102FADC4369CRPMBOXPRD01p_" MIME-Version: 1.0 Subject: Re: [clue] Updates in framework-02 - section 5 review. X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 00:01:10 -0000 --_000_44C6B6B2D0CF424AA90B6055548D7A6102FADC4369CRPMBOXPRD01p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Roni, Thanks for the suggestions, this is very useful. We will use these for the= next version, which is in progress now. I have a few questions and comments on some of your items. And I answered = some of your questions. If an item is not listed here, it means I agree wi= th it. 3. The second sentence in 5.1 is not needed you just need to use the term a= nd not repeat part of the definition. Markd> I assume you mean the second sentence in the second paragraph, corre= ct? "As defined, a capture scene is the source scene that is captured by m= edia devices"? 4. We need a term for the "row of media captures inside a capture set" Markd> How about "Capture Set View"? I agree a more descriptive term rathe= r than "row" would be good. 5. In 5.1 fourth paragraph change to "Media Captures may also be associate= d with data constructs that capture encoding aspects of the streams" . 6. In 5.2 fourth paragraph suggest adding "may be" to become "A media ca= pture is described by Attributes and may be associated with an Encode Grou= p, and Simultaneous Transmission Set." Markd> I think these need more discussion, about what is optional and what = is required regarding the encode groups. It sounds like you would like it = to be optional, while the authors are thinking it is mandatory. 9. In 5.3 in the third bullet, No physical scale means no spatial relation = or is it to provide some way to describe the rendering order (e.g. for MCU = case). Markd> We can clarify this. Even with no physical scale, it still can repr= esent a spatial relation between media captures. 11. In section 5.4 first paragraph what do you mean by static, Is media cap= ture describing a static aspect of a stream? My view is that attribute are = not static but may define some range, like maximum value or a model for swi= tching. Markd> Good question, I've been questioning this myself. I don't see any a= ttribute where a maximum value makes sense. Is a model for switching still= a static attribute value? I think it can be. One way to look at it is th= is - can an attribute value change "on the fly" without a new message excha= nge between consumer and producer, with producer advertising the new attrib= ute values and the consumer then making a choice to receive some streams? = I have been thinking no, the attribute values can not change without this e= xchange. I would call this static, to an extent, but maybe that is not a g= ood word to use here. 12. In 5.4 second paragraph you mention "most common use case" what are tho= se, maybe these is why we are discussing what attributes and values should = be specified here. Markd> Good point. Does the framework support all the use cases in the use= case document? I'm not sure. 13. in 5.4.1 I am not sure what main is and what should not be main, I can = understand the logic in RFC 4796. For example can we specify "speaker" as a= purpose. As for main I can see a media capture that shows the whole room as main yet= a VC1 that shows left side of a room is not main, I will see as main a "ro= w" that has (VC1 - left, VC2-middle, VC3-right). So should we have VC1 with= purpose main even when stands by itself. Markd> Yes, VC1 is intended to be "main" in this case. A "row" does not ha= ve attributes (although people have mentioned maybe there should be attribu= tes for a "row"). Maybe we need some additional values for purpose? Can t= here be more than one value for a particular media capture? 16. in 5.4.4 third paragraph you say that the planes should intersect, why = is that, I think that there can be a gap between the planes at the area of = capture. The area of captures are in the area of scene defined later. Markd> We can clarify this. It means the infinite planes should intersect,= but the areas of capture (quadrilaterals in the planes) may or may not int= ersect. 21. In 5.5 the first two paragraph use capture set and capture scene, we ne= ed to clarify the relation between them, maybe in section3. We discussed it= in Taipei. For example are the two capture sets in the example in the seco= nd paragraph one or two capture scenes. Markd> Different scenes. I suggest there is a one to one correspondence be= tween a capture scene and a capture set. That's how I've been thinking of = it. 22. in 5.5 ""Media Captures of the same media type are associated with each= other by grouping them together in a single row of a Capture Set" . I th= ink that the grouping in a single row means simultaneous, does the grouping= imply any other association without using any attribute? If not maybe say = " simultaneous" Markd> Yes it means simultaneous. It is also a suggestion from the provide= r, intending to make the consumers job of selecting captures to receive eas= ier, if it wants to follow the suggestion. Mark From: Roni Even [mailto:ron.even.tlv@gmail.com] Sent: Friday, January 13, 2012 1:19 PM To: Duckworth, Mark; clue@ietf.org Subject: RE: [clue] Updates in framework-02 - section 5 review. Hi, I read the draft again till section 6 in order to review the parts you ment= ioned. It is better than 01 but I still have some comments. I will list all of them in this email and afterwards we can cut out the one= s that remain open if any? Some of them are editorial. I will comment on al= l section 5. 1 The second sentence in section 5 says "figure" no number and no number to= the figure. 2. The figure in section 5 need to show that capture set is composed of row= s and each row is made from media captures. 3. The second sentence in 5.1 is not needed you just need to use the term a= nd not repeat part of the definition. 4. We need a term for the "row of media captures inside a capture set" 5. In 5.1 fourth paragraph change to "Media Captures may also be associate= d with data constructs that capture encoding aspects of the streams" . 6. In 5.2 fourth paragraph suggest adding "may be" to become "A media ca= pture is described by Attributes and may be associated with an Encode Grou= p, and Simultaneous Transmission Set." 7. In 5.3 first paragraph I suggest changing to "Within a capture set, a co= ordinate system should be used to model relative or absolute positions of = its constituent media captures. This can allow precise physical sizes to be determined if re= quired, as well as the order in which media captures that form a group sh= ould be rendered. " The co-ordinate system is needed if you want to describe the spatial relati= ons. I also changed the "displayed" to "rendered" 8. In 5.3 second bullet suggest to change to "for example it shall provide = co-ordinate information for 3 side-by-side participant ...". . it does not= matter if absolute or relative or no scale but it is needed to describe th= e spatial relations. 9. In 5.3 in the third bullet, No physical scale means no spatial relation = or is it to provide some way to describe the rendering order (e.g. for MCU = case). 10. Audience front at the end of section 5.3 is not specified, there is fro= nt and back in section 3 11. In section 5.4 first paragraph what do you mean by static, Is media cap= ture describing a static aspect of a stream? My view is that attribute are = not static but may define some range, like maximum value or a model for swi= tching. 12. In 5.4 second paragraph you mention "most common use case" what are tho= se, maybe these is why we are discussing what attributes and values should = be specified here. 13. in 5.4.1 I am not sure what main is and what should not be main, I can = understand the logic in RFC 4796. For example can we specify "speaker" as a= purpose. As for main I can see a media capture that shows the whole room as main yet= a VC1 that shows left side of a room is not main, I will see as main a "ro= w" that has (VC1 - left, VC2-middle, VC3-right). So should we have VC1 with= purpose main even when stands by itself. 14. On 5.4.2 we are having a separate discussion about what should be defin= ed in this document. 15. in 5.4.4 first paragraph "By comparing the area of capture for differ= ent media captures, " I think you need to add of the same capture scene or = capture set. 16. in 5.4.4 third paragraph you say that the planes should intersect, why = is that, I think that there can be a gap between the planes at the area of = capture. The area of captures are in the area of scene defined later. 17. In 5.4.4 you mention 4 points but not the order they are listed, in the= example in section 9 you give a table but the headers are not part of the = definition, maybe specify from top left clockwise direction. 18. Suggest to change the start of the last paragraph in 5.4.4 to "If the a= rea of capture attribute is specified, it must include X, Y, Z ...". I do n= ot like the use of "optional" in the current sentence. 19. Section 5.4.5 suggest to change the beginning to " The point_of_capture= attribute is used to describe the location of a capture device or pseudo-= device. A use case is if there are multiple captures ..." 20. We have a separate open issue on 5.4.6. 21. In 5.5 the first two paragraph use capture set and capture scene, we ne= ed to clarify the relation between them, maybe in section3. We discussed it= in Taipei. For example are the two capture sets in the example in the seco= nd paragraph one or two capture scenes. 22. in 5.5 ""Media Captures of the same media type are associated with each= other by grouping them together in a single row of a Capture Set" . I th= ink that the grouping in a single row means simultaneous, does the grouping= imply any other association without using any attribute? If not maybe say = " simultaneous" 23. In 5.5 " Association between audio and video can be made by finding aud= io and video captures which share overlapping areas of capture." I think = this requires that they will use the same origin, I did not see it required= . 24. In 5.5 " A media consumer could choose one row of each media type (e.g.= , audio and video) from a capture set. For example a three stream consume= r could choose the first video row plus the audio row, while a single stream consumer could choose the second or third video row plus the aud= io row. An MCU consumer might choose to receive multiple rows." A single = stream consumer may also choose VC0 or VC1 or VC2, maybe clarify it since i= t is the non obvious case. 25. I think that the last paragraph in section 5.5 should be removed and di= scussed when you define the Simultaneous Transmission Sets and Encoding Gro= ups, it is out of context here and this is why I cannot even discuss it whe= n talking about this section. 26. 5.6 talks about attributes of capture set while the first bullet is abo= ut capture scene. This is again about the lack of clarity about these two t= erms. 27. In 5.6.1 I suggest adding the following sentence in the end "The area o= f captures specified for this capture set must use the same co-ordinate sys= tem (same origin)" This is the end of my long list Roni Even From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Duc= kworth, Mark Sent: Wednesday, January 11, 2012 5:43 AM To: clue@ietf.org Subject: Re: [clue] Updates in framework-02 Hi Roni, The relevant parts to review are these sections: 5.3. Describing Spatial Relations 5.4.4. Area of capture 5.4.5. Point of capture 5.6. Attributes for Capture Sets 5.6.2 Area Scale Millimeters (I think the name should be changed to just "= area scale") 9. Using the Framework This link to the differences might be useful to help you review what has ch= anged: http://tools.ietf.org/wg/clue/draft-ietf-clue-framework/draft-ietf-clue-fra= mework-02-from-01.diff.html Regards, Mark --_000_44C6B6B2D0CF424AA90B6055548D7A6102FADC4369CRPMBOXPRD01p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Roni,

 

Thank= s for the suggestions, this is very useful.  We will use these for the= next version, which is in progress now.

 

I have a few questions and comme= nts on some of your items.  And I answered some of your questions.&nbs= p; If an item is not listed here, it means I agree with it.

<= p class=3DMsoNormal> 

3. The second sentence in 5.1 is not needed you just need to use the t= erm and not repeat part of the definition.

Markd> I assume you mean th= e second sentence in the second paragraph, correct? "As  defi= ned, a capture scene is the source scene that is captured by media devices<= b>"?

 

4. We need a term for the "row of media ca= ptures inside a capture set"

Markd> How about "Capture Set V= iew"?  I agree a more descriptive term rather than "row"= ; would be good.

 

5. In 5.1 fourth paragraph  change to "Media Captures= may also be associated with data constructs that capture  encoding as= pects of the streams" .

6. =  In 5.2 fourth paragraph suggest adding "may be"  to&nb= sp; become "A media capture is described by Attributes and may be asso= ciated with an  Encode Group, and Simultaneous Transmission Set."=

Markd> I think these need more discussion, about what is optional and= what is required regarding the encode groups.  It sounds like you wou= ld like it to be optional, while the authors are thinking it is mandatory.<= /span>

 

9. In= 5.3 in the third bullet, No physical scale means no spatial relation or is= it to provide some way to describe the rendering order (e.g. for MCU case)= .

Markd> We can clarify this.  Even with no physical scale, it s= till can represent a spatial relation between media captures.

 

11. In section 5.4= first paragraph what do you mean by static, Is media capture describing a = static aspect of a stream? My view is that attribute are not static but may= define some range, like maximum value or a model for switching.=

Markd>= ; Good question, I've been questioning this myself.  I don't see any a= ttribute where a maximum value makes sense.  Is a model for switching = still a static attribute value?  I think it can be.  One way to l= ook at it is this - can an attribute value change "on the fly" wi= thout a new message exchange between consumer and producer, with producer a= dvertising the new attribute values and the consumer then making a choice t= o receive some streams?  I have been thinking no, the attribute values= can not change without this exchange.  I would call this static, to a= n extent, but maybe that is not a good word to use here.<= o:p>

&= nbsp;

12. In 5.= 4 second paragraph you mention "most common use case" what are th= ose, maybe these is why we are discussing what attributes and values should= be specified here.

Markd> Good point.  Does the framework suppor= t all the use cases in the use case document?  I'm not sure.

 =

13. in 5.4.1 I= am not sure what main is and what should not be main, I can understand the= logic in RFC 4796. For example can we specify "speaker" as a pur= pose.  

As= for main I can see a media capture that shows the whole room as main yet a= VC1 that shows left side of a room is not main, I will see as main a "= ;row" that has (VC1 - left, VC2-middle, VC3-right). So should we have = VC1 with purpose main even when stands by itself.

Markd> Yes, VC1 is i= ntended to be "main" in this case.  A "row" does n= ot have attributes (although people have mentioned maybe there should be at= tributes for a "row").  Maybe we need some additional values= for purpose?  Can there be more than one value for a particular media= capture?

 

16. in 5.4.4 third paragraph you say that the planes should intersect,= why is that, I think that there can be a gap between the planes at the are= a of capture.  The area of captures are in the area of scene defined l= ater.

Markd> We can clarify this.  It means the infinite planes s= hould intersect, but the areas of capture (quadrilaterals in the planes) ma= y or may not intersect.

 

21. In 5.5 the first two paragraph use capture set and c= apture scene, we need to clarify the relation between them, maybe in sectio= n3. We discussed it in Taipei. For example are the two capture sets in the = example in the second paragraph one or two capture scenes.

Markd> Diff= erent scenes.  I suggest there is a one to one correspondence between = a capture scene and a capture set.  That's how I've been thinking of i= t.

 

22= . in 5.5 ""Media Captures of the same media type are associated w= ith each other  by grouping them together in a single row of a Capture= Set" .  I think that the grouping in a single row means simultan= eous, does the grouping imply any other association without using any attri= bute? If not maybe say " simultaneous"

Markd> Yes it means s= imultaneous.  It is also a suggestion from the provider, intending to = make the consumers job of selecting captures to receive easier, if it wants= to follow the suggestion.

 

Mark

 

From: Roni Even [mailto:ron.even.tlv@gmail.com]
= Sent: Friday, January 13, 2012 1:19 PM
To: Duckworth, Mark= ; clue@ietf.org
Subject: RE: [clue] Updates in framework-02 - sec= tion 5 review.

&= nbsp;

Hi,<= /o:p>

I read t= he draft again till section 6 in order to review the parts you mentioned. I= t is better than 01 but I still have some comments.  

I will list all of = them in this email and afterwards we can cut out the ones that remain open = if any? Some of them are editorial. I will comment on all section 5.

&nbs= p;

1 The= second sentence in section 5 says "figure" no number and no numb= er to the figure.

 

2. The figure in section 5 need to show that capture set= is composed of rows and each row is made from media captures.

 

3. The seco= nd sentence in 5.1 is not needed you just need to use the term and not repe= at part of the definition.

 

4. We need a term for the "row of media ca= ptures inside a capture set"

 

5.= In 5.1 fourth paragraph  change to "Media Captures= may also be associated with data constructs that capture  encoding as= pects of the streams" .

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>&nb= sp;

6.  In 5.2 fourth paragraph sugge= st adding "may be"  to  become "A media capture is= described by Attributes and may be associated with an  Encode Group, = and Simultaneous Transmission Set."

 

7. In 5.3 first paragraph = I suggest changing to "Within a capture set, a coordinate system shoul= d be used to  model relative or absolute positions of its constituent = media

   captures.  Th= is can allow precise physical sizes to be determined if  required, as = well as the order in which media captures that form a   group sho= uld be rendered. "

The co-ordina= te system is needed if you want to describe the spatial relations. I also c= hanged the "displayed" to "rendered"<= /p>

 

8. In 5.3 = second bullet suggest to change to "for example it shall provide  = ;co-ordinate information for 3 side-by-side participant …". . it= does not matter if absolute or relative or no scale but it is needed to de= scribe the spatial relations.

= &n= bsp;

9. In 5.3 in the third bullet, No phy= sical scale means no spatial relation or is it to provide some way to descr= ibe the rendering order (e.g. for MCU case).

 

10. Audience front at= the end of section 5.3 is not specified, there is front and back in sectio= n 3

 

11. In section 5.4 first paragraph what do you mean by static, = Is media capture describing a static aspect of a stream? My view is that at= tribute are not static but may define some range, like maximum value or a m= odel for switching.

 =

12. In 5.4 second paragraph you mention "m= ost common use case" what are those, maybe these is why we are discuss= ing what attributes and values should be specified here.<= /p>

 

13. in 5.4= .1 I am not sure what main is and what should not be main, I can understand= the logic in RFC 4796. For example can we specify "speaker" as a= purpose.  

As for main I can = see a media capture that shows the whole room as main yet a VC1 that shows = left side of a room is not main, I will see as main a "row" that = has (VC1 - left, VC2-middle, VC3-right). So should we have VC1 with purpose= main even when stands by itself.

 

14. On 5.4.2 we are having a sepa= rate discussion about what should be defined in this document.

 

15. = in 5.4.4 first paragraph "By comparing the area of   capture= for different media captures, " I think you need to add of the same c= apture scene or capture set.

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>&nb= sp;

16. in 5.4.4 third paragraph you say t= hat the planes should intersect, why is that, I think that there can be a g= ap between the planes at the area of capture.  The area of captures ar= e in the area of scene defined later.

 

17. In 5.4.4 you mention 4 po= ints but not the order they are listed, in the example in section 9 you giv= e a table but the headers are not part of the definition, maybe specify fro= m top left clockwise direction.

=  

18. Suggest to change the start of = the last paragraph in 5.4.4 to "If the area of capture attribute is sp= ecified, it must include X, Y, Z …". I do not like the use of &q= uot;optional" in the current sentence.

 

19. Section 5.4.5 sug= gest to change the beginning to " The point_of_capture attribute is us= ed to describe the location  of a capture device or pseudo-device. A u= se case is if there are multiple captures …"

 

20. We have= a separate open issue on 5.4.6.

 

21. In 5.5 the first two paragraph= use capture set and capture scene, we need to clarify the relation between= them, maybe in section3. We discussed it in Taipei. For example are the tw= o capture sets in the example in the second paragraph one or two capture sc= enes.

 

22. in 5.5 ""Media Captures of the same media type = are associated with each other  by grouping them together in a single = row of a Capture Set" .  I think that the grouping in a single ro= w means simultaneous, does the grouping imply any other association without= using any attribute? If not maybe say " simultaneous"=

 

23= . In 5.5 " Association between audio and video can be made by finding = audio and   video captures which share overlapping areas of captu= re." I think this requires that they will use the same origin, I did n= ot see it required.

 =

24. In 5.5 " A media consumer could choose= one row of each media type (e.g., audio  and video) from a capture se= t.  For example a three stream consumer  could choose the first v= ideo row plus the audio row, while a single

   stream consumer could choose the second or third vide= o row plus the  audio row.  An MCU consumer might choose to recei= ve multiple rows."  A single stream consumer may also choose VC0 = or VC1 or VC2, maybe clarify it since it is the non obvious case.

 

2= 5. I think that the last paragraph in section 5.5 should be removed and dis= cussed when you define the Simultaneous Transmission Sets and Encoding Grou= ps, it is out of context here and this is why I cannot even discuss it when= talking about this section.

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>&nb= sp;

26. 5.6 talks about attributes of capt= ure set while the first bullet is about capture scene. This is again about = the lack of clarity about these two terms.

 

27. In 5.6.1 I suggest a= dding the following sentence in the end "The area of captures specifie= d for this capture set must use the same co-ordinate system (same origin)&q= uot;

 

 

 =

This is the end of my long list

 

= Roni Ev= en

 

 

 <= /span>

 

 

 

 

 <= /span>

 

 

<= p class=3DMsoPlainText> 

 

 

<= p class=3DMsoNormal> <= /p>

 

 =

From: clue-bounces@ietf.= org [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark
<= b>Sent: Wednesday, January 11, 2012 5:43 AM
To: clue@ietf.org=
Subject: Re: [clue] Updates in framework-02

 

Hi Roni,

 

The relevant parts to review are= these sections:

5.3. Describing Spatial Relations

5.4.4. Area of capture

5.4.5. Poi= nt of capture

5.6. Attributes for Capture Sets

5.6.2 Area Scale Millimeters&nbs= p; (I think the name should be changed to just “area scale”)

9. Us= ing the Framework

 

This link to the differences might be useful to help you= review what has changed:

http://tools.ietf.org/wg/clue/draft-ietf-c= lue-framework/draft-ietf-clue-framework-02-from-01.diff.html=

 

Regards,=

Mark=

&n= bsp;

= --_000_44C6B6B2D0CF424AA90B6055548D7A6102FADC4369CRPMBOXPRD01p_-- From ron.even.tlv@gmail.com Mon Jan 16 23:52:39 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2D2F21F8575 for ; Mon, 16 Jan 2012 23:52:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n3iHfDaHRsYj for ; Mon, 16 Jan 2012 23:52:39 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id DAE8721F85AE for ; Mon, 16 Jan 2012 23:52:38 -0800 (PST) Received: by eeit10 with SMTP id t10so1196160eei.31 for ; Mon, 16 Jan 2012 23:52:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :content-language:thread-index; bh=OsUWm/RZj+dnRReYtO+ekAZI3ynyQakzmcMVCAezG7U=; b=ea9r0WcxUKg6qazmjWKVOKub/EFWGsl6eqxnBZP0uZBo/Wkb6bgs+r+ollJXFlqeWb IWB3j53ahdT8no6xUpJakEI5/hNaejLEg/ygDIOu3LnlmKLAfntkJw25/ArF8CygKSqk Jw9vjGO6SuIbDM3o6IGsioSvUETWoIaFbGx+g= Received: by 10.213.34.2 with SMTP id j2mr3852638ebd.21.1326786756833; Mon, 16 Jan 2012 23:52:36 -0800 (PST) Received: from windows8d787f9 (bzq-79-180-198-96.red.bezeqint.net. [79.180.198.96]) by mx.google.com with ESMTPS id y12sm82812444eeb.11.2012.01.16.23.52.34 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 16 Jan 2012 23:52:35 -0800 (PST) From: "Roni Even" To: "'clue issue tracker'" , References: <063.9b81af3c175d186140d57829d721bd2b@trac.tools.ietf.org> In-Reply-To: <063.9b81af3c175d186140d57829d721bd2b@trac.tools.ietf.org> Date: Tue, 17 Jan 2012 09:49:02 +0200 Message-ID: <4f1528c3.0c320e0a.0d09.ffff90c9@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Content-language: en-us Thread-index: AczPzOwzpAhlrZzdR6KzveCV6Fgx4wFH2XMQ Cc: clue@ietf.org Subject: Re: [clue] #2: Use cases for selecting composed captures - update the issue tracker X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 07:52:39 -0000 Hi, I posted an email that addresses this issue = http://www.ietf.org/mail-archive/web/clue/current/msg00950.html=20 How and when will the issue tracker be updated Roni > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf = Of > clue issue tracker > Sent: Tuesday, January 10, 2012 8:15 PM > To: pkyzivat@alum.mit.edu > Cc: clue@ietf.org > Subject: [clue] #2: Use cases for selecting composed captures >=20 > #2: Use cases for selecting composed captures >=20 > Roni Even to post use cases for selecting composed captures, on the > mailing list. >=20 > -- > ------------------------------------+----------------------- > Reporter: pkyzivat@=E2=80=A6 | Owner: Roni Even > Type: task | Status: new > Priority: major | Milestone: > Component: telepresence-use-cases | Version: > Severity: Active WG Document | Keywords: > ------------------------------------+----------------------- >=20 > Ticket URL: > clue >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From ron.even.tlv@gmail.com Tue Jan 17 00:41:22 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEC2B21F84DC for ; Tue, 17 Jan 2012 00:41:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iz9CIRD+Tfbw for ; Tue, 17 Jan 2012 00:41:14 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id A1F1E21F84A2 for ; Tue, 17 Jan 2012 00:41:13 -0800 (PST) Received: by eaai13 with SMTP id i13so615621eaa.31 for ; Tue, 17 Jan 2012 00:41:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:x-mailer:content-language:thread-index; bh=8Ws1X3EsEaMwv49JBzOjTXjF6MKEx6OrucFNhaxJAVs=; b=Aq8tRidp3vfPefq51e8WpoGYbg5G2Hx+pRbtf8clUYjE3LYAdol5r5oETBIuap/9k/ RnblvIa26Hhim3zxpcJnQZZiKabRBJ5E7YokpvWqN/zRa07cAnnh1xvb+DJyyZ881KPR LNBcyyzhwRi6c8l6feMw+mfYc2rEK8Pz2cvEA= Received: by 10.213.23.1 with SMTP id p1mr4097459ebb.0.1326789671338; Tue, 17 Jan 2012 00:41:11 -0800 (PST) Received: from windows8d787f9 (bzq-79-180-198-96.red.bezeqint.net. [79.180.198.96]) by mx.google.com with ESMTPS id y12sm83263331eeb.11.2012.01.17.00.41.06 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 17 Jan 2012 00:41:09 -0800 (PST) From: "Roni Even" To: "'Duckworth, Mark'" , References: <44C6B6B2D0CF424AA90B6055548D7A6102FAC9013A@CRPMBOXPRD01.polycom.com> <4f0c4c80.10610e0a.01e0.ffffa799@mx.google.com> <44C6B6B2D0CF424AA90B6055548D7A6102FAC90B98@CRPMBOXPRD01.polycom.com> <4f107672.c9330e0a.16d4.fffff935@mx.google.com> <44C6B6B2D0CF424AA90B6055548D7A6102FADC4369@CRPMBOXPRD01.polycom.com> In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A6102FADC4369@CRPMBOXPRD01.polycom.com> Date: Tue, 17 Jan 2012 10:37:34 +0200 Message-ID: <4f153425.0c320e0a.0d09.ffffa3c2@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001A_01CCD504.0833A6D0" X-Mailer: Microsoft Office Outlook 12.0 Content-language: en-us Thread-index: AczMxVqqdkntgE2oTNql2+0ws/lubgC3wcIAABtXwlAAgEnK8ACUO8kAACJFQlA= Subject: Re: [clue] Updates in framework-02 - section 5 review. X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 08:41:22 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_001A_01CCD504.0833A6D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Mark, Thanks, I assume by agreeing they will be addressed in the next revision for the editorial ones. Inline for your questions Roni From: Duckworth, Mark [mailto:Mark.Duckworth@polycom.com] Sent: Tuesday, January 17, 2012 2:01 AM To: Roni Even; clue@ietf.org Subject: RE: [clue] Updates in framework-02 - section 5 review. Hi Roni, Thanks for the suggestions, this is very useful. We will use these for the next version, which is in progress now. I have a few questions and comments on some of your items. And I answered some of your questions. If an item is not listed here, it means I agree with it. 3. The second sentence in 5.1 is not needed you just need to use the term and not repeat part of the definition. Markd> I assume you mean the second sentence in the second paragraph, correct? "As defined, a capture scene is the source scene that is captured by media devices"? Roni>Yes , the one starting with "as defined ." 4. We need a term for the "row of media captures inside a capture set" Markd> How about "Capture Set View"? I agree a more descriptive term rather than "row" would be good. Roni> The name sounds OK but it will make sense to define it in the definition section. 5. In 5.1 fourth paragraph change to "Media Captures may also be associated with data constructs that capture encoding aspects of the streams" . 6. In 5.2 fourth paragraph suggest adding "may be" to become "A media capture is described by Attributes and may be associated with an Encode Group, and Simultaneous Transmission Set." Markd> I think these need more discussion, about what is optional and what is required regarding the encode groups. It sounds like you would like it to be optional, while the authors are thinking it is mandatory. Roni> I can start a thread on encoding groups while I think that simultaneous transmission sets are optional since the provider may send just one row like {vc1, vc2,vc3}. Looking at this section again maybe it will make sense to divide it to two sections one about the model description which references also the other sections of the document and one that defines the attributes. 9. In 5.3 in the third bullet, No physical scale means no spatial relation or is it to provide some way to describe the rendering order (e.g. for MCU case). Markd> We can clarify this. Even with no physical scale, it still can represent a spatial relation between media captures. Roni> I am not sure, in 5.6 for area of scale we have physical scale which provide real units like mm, unknown which provides a scale but is not physical just numbers that can be used to understand the scale and no scale. On the no scale I see two types. The first is that there is some spatial order and the renderer should display them accordingly, example is MCU wanting to enforce which stream will go to which monitor at the receiver even if they represent different rooms, the other is where the provider do not want to enforce any specific render order like an MCU sending three streams each from a different system but does not care for the render order. Maybe we need four options and not three. 11. In section 5.4 first paragraph what do you mean by static, Is media capture describing a static aspect of a stream? My view is that attribute are not static but may define some range, like maximum value or a model for switching. Markd> Good question, I've been questioning this myself. I don't see any attribute where a maximum value makes sense. Is a model for switching still a static attribute value? I think it can be. One way to look at it is this - can an attribute value change "on the fly" without a new message exchange between consumer and producer, with producer advertising the new attribute values and the consumer then making a choice to receive some streams? I have been thinking no, the attribute values can not change without this exchange. I would call this static, to an extent, but maybe that is not a good word to use here. Roni> I think that attribute values are static in a sense that to change the current value it need to be negotiated. Now the value itself can specify a range but this should be part of the value definition. I think we need to clarify what is meant by static (value and not attribute) 12. In 5.4 second paragraph you mention "most common use case" what are those, maybe these is why we are discussing what attributes and values should be specified here. Markd> Good point. Does the framework support all the use cases in the use case document? I'm not sure. Roni>maybe just as an editorial change delete this part and start the sentence with the fact that new attribute can be added based on use cases. 13. in 5.4.1 I am not sure what main is and what should not be main, I can understand the logic in RFC 4796. For example can we specify "speaker" as a purpose. As for main I can see a media capture that shows the whole room as main yet a VC1 that shows left side of a room is not main, I will see as main a "row" that has (VC1 - left, VC2-middle, VC3-right). So should we have VC1 with purpose main even when stands by itself. Markd> Yes, VC1 is intended to be "main" in this case. A "row" does not have attributes (although people have mentioned maybe there should be attributes for a "row"). Maybe we need some additional values for purpose? Can there be more than one value for a particular media capture? Roni> I am not sure that in the case of a row {VC1, VC2, VC3} I will have VC1 as main always. Since my understanding is that a consumer can decide it wants to take only one of the captures in the row it may make sense for the provider to say for example that VC1 is more important than the other two. I think we need more values initially and this is why I referenced RFC 4796. 16. in 5.4.4 third paragraph you say that the planes should intersect, why is that, I think that there can be a gap between the planes at the area of capture. The area of captures are in the area of scene defined later. Markd> We can clarify this. It means the infinite planes should intersect, but the areas of capture (quadrilaterals in the planes) may or may not intersect. Roni> This is what I meant. 21. In 5.5 the first two paragraph use capture set and capture scene, we need to clarify the relation between them, maybe in section3. We discussed it in Taipei. For example are the two capture sets in the example in the second paragraph one or two capture scenes. Markd> Different scenes. I suggest there is a one to one correspondence between a capture scene and a capture set. That's how I've been thinking of it. Roni> We should have it as an open issue that needs to be clarified since I heard other opinions. 22. in 5.5 ""Media Captures of the same media type are associated with each other by grouping them together in a single row of a Capture Set" . I think that the grouping in a single row means simultaneous, does the grouping imply any other association without using any attribute? If not maybe say " simultaneous" Markd> Yes it means simultaneous. It is also a suggestion from the provider, intending to make the consumers job of selecting captures to receive easier, if it wants to follow the suggestion. Roni> This was an editorial comment that if associated means simultaneous than it should say so. In the past it also meant spatial order but we are now using explicit spatial relation which means according to my understanding that {VC1, VC2, VC3} is the same as {VC2, VC1, VC3} Mark From: Roni Even [mailto:ron.even.tlv@gmail.com] Sent: Friday, January 13, 2012 1:19 PM To: Duckworth, Mark; clue@ietf.org Subject: RE: [clue] Updates in framework-02 - section 5 review. Hi, I read the draft again till section 6 in order to review the parts you mentioned. It is better than 01 but I still have some comments. I will list all of them in this email and afterwards we can cut out the ones that remain open if any? Some of them are editorial. I will comment on all section 5. 1 The second sentence in section 5 says "figure" no number and no number to the figure. 2. The figure in section 5 need to show that capture set is composed of rows and each row is made from media captures. 3. The second sentence in 5.1 is not needed you just need to use the term and not repeat part of the definition. 4. We need a term for the "row of media captures inside a capture set" 5. In 5.1 fourth paragraph change to "Media Captures may also be associated with data constructs that capture encoding aspects of the streams" . 6. In 5.2 fourth paragraph suggest adding "may be" to become "A media capture is described by Attributes and may be associated with an Encode Group, and Simultaneous Transmission Set." 7. In 5.3 first paragraph I suggest changing to "Within a capture set, a coordinate system should be used to model relative or absolute positions of its constituent media captures. This can allow precise physical sizes to be determined if required, as well as the order in which media captures that form a group should be rendered. " The co-ordinate system is needed if you want to describe the spatial relations. I also changed the "displayed" to "rendered" 8. In 5.3 second bullet suggest to change to "for example it shall provide co-ordinate information for 3 side-by-side participant .". . it does not matter if absolute or relative or no scale but it is needed to describe the spatial relations. 9. In 5.3 in the third bullet, No physical scale means no spatial relation or is it to provide some way to describe the rendering order (e.g. for MCU case). 10. Audience front at the end of section 5.3 is not specified, there is front and back in section 3 11. In section 5.4 first paragraph what do you mean by static, Is media capture describing a static aspect of a stream? My view is that attribute are not static but may define some range, like maximum value or a model for switching. 12. In 5.4 second paragraph you mention "most common use case" what are those, maybe these is why we are discussing what attributes and values should be specified here. 13. in 5.4.1 I am not sure what main is and what should not be main, I can understand the logic in RFC 4796. For example can we specify "speaker" as a purpose. As for main I can see a media capture that shows the whole room as main yet a VC1 that shows left side of a room is not main, I will see as main a "row" that has (VC1 - left, VC2-middle, VC3-right). So should we have VC1 with purpose main even when stands by itself. 14. On 5.4.2 we are having a separate discussion about what should be defined in this document. 15. in 5.4.4 first paragraph "By comparing the area of capture for different media captures, " I think you need to add of the same capture scene or capture set. 16. in 5.4.4 third paragraph you say that the planes should intersect, why is that, I think that there can be a gap between the planes at the area of capture. The area of captures are in the area of scene defined later. 17. In 5.4.4 you mention 4 points but not the order they are listed, in the example in section 9 you give a table but the headers are not part of the definition, maybe specify from top left clockwise direction. 18. Suggest to change the start of the last paragraph in 5.4.4 to "If the area of capture attribute is specified, it must include X, Y, Z .". I do not like the use of "optional" in the current sentence. 19. Section 5.4.5 suggest to change the beginning to " The point_of_capture attribute is used to describe the location of a capture device or pseudo-device. A use case is if there are multiple captures ." 20. We have a separate open issue on 5.4.6. 21. In 5.5 the first two paragraph use capture set and capture scene, we need to clarify the relation between them, maybe in section3. We discussed it in Taipei. For example are the two capture sets in the example in the second paragraph one or two capture scenes. 22. in 5.5 ""Media Captures of the same media type are associated with each other by grouping them together in a single row of a Capture Set" . I think that the grouping in a single row means simultaneous, does the grouping imply any other association without using any attribute? If not maybe say " simultaneous" 23. In 5.5 " Association between audio and video can be made by finding audio and video captures which share overlapping areas of capture." I think this requires that they will use the same origin, I did not see it required. 24. In 5.5 " A media consumer could choose one row of each media type (e.g., audio and video) from a capture set. For example a three stream consumer could choose the first video row plus the audio row, while a single stream consumer could choose the second or third video row plus the audio row. An MCU consumer might choose to receive multiple rows." A single stream consumer may also choose VC0 or VC1 or VC2, maybe clarify it since it is the non obvious case. 25. I think that the last paragraph in section 5.5 should be removed and discussed when you define the Simultaneous Transmission Sets and Encoding Groups, it is out of context here and this is why I cannot even discuss it when talking about this section. 26. 5.6 talks about attributes of capture set while the first bullet is about capture scene. This is again about the lack of clarity about these two terms. 27. In 5.6.1 I suggest adding the following sentence in the end "The area of captures specified for this capture set must use the same co-ordinate system (same origin)" This is the end of my long list Roni Even From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark Sent: Wednesday, January 11, 2012 5:43 AM To: clue@ietf.org Subject: Re: [clue] Updates in framework-02 Hi Roni, The relevant parts to review are these sections: 5.3. Describing Spatial Relations 5.4.4. Area of capture 5.4.5. Point of capture 5.6. Attributes for Capture Sets 5.6.2 Area Scale Millimeters (I think the name should be changed to just "area scale") 9. Using the Framework This link to the differences might be useful to help you review what has changed: http://tools.ietf.org/wg/clue/draft-ietf-clue-framework/draft-ietf-clue-fram ework-02-from-01.diff.html Regards, Mark ------=_NextPart_000_001A_01CCD504.0833A6D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Mark,

Thanks, I assume by = agreeing they will be addressed in the next revision for the editorial = ones.

Inline for your = questions

Roni

 

From:= = Duckworth, Mark [mailto:Mark.Duckworth@polycom.com]
Sent: = Tuesday, January 17, 2012 2:01 AM
To: Roni Even; = clue@ietf.org
Subject: RE: [clue] Updates in framework-02 - = section 5 review.

 

Hi = Roni,

 

Thanks for the suggestions, this is very useful.  = We will use these for the next version, which is in progress = now.

 

I have a few questions and comments on some of your = items.  And I answered some of your questions.  If an item is = not listed here, it means I agree with it.

 

3. The = second sentence in 5.1 is not needed you just need to use the term and = not repeat part of the definition.

Markd> I assume you mean the second sentence in the second = paragraph, correct? "As  = defined, a capture scene is the source scene that is captured by media = devices"?

Roni>Yes , the one starting with "as defined = …"

 

 =

4. We need = a term for the "row of media captures inside a capture = set"

Markd> How about "Capture Set View"?  I agree a = more descriptive term rather than "row" would be = good.

Roni> The name sounds OK but it will make sense to define it in = the definition section.

 =

5. In 5.1 = fourth paragraph =  change to "Media Captures may also be associated with data = constructs that capture  encoding aspects of the streams" = .

6. =  In 5.2 fourth paragraph suggest adding "may be" =  to  become "A media capture is described by Attributes = and may be associated with an  Encode Group, and Simultaneous = Transmission Set."

Markd> I think these need more discussion, about what is optional = and what is required regarding the encode groups.  It sounds like = you would like it to be optional, while the authors are thinking it is = mandatory.

Roni> I can start a thread on encoding groups while I think that = simultaneous transmission sets are optional since the provider may send = just one row like {vc1, vc2,vc3}.

Looking at this section again maybe it will make sense to divide it = to two sections one about the model description which references also = the other sections of the document and  one that defines the = attributes.

 =

9. In 5.3 = in the third bullet, No physical scale means no spatial relation or is = it to provide some way to describe the rendering order (e.g. for MCU = case).

Markd> We can clarify this.  Even with no physical scale, it = still can represent a spatial relation between media = captures.

Roni> I am not sure,  in 5.6 for area of scale we have = physical scale which provide real units like mm,  unknown which = provides a scale but is not  physical just numbers that can be used = to understand the scale and  no scale.

On the no scale I see two types. The first is that there is some = spatial order and the renderer should display them accordingly, example = is MCU wanting to enforce which stream will go to which monitor at the = receiver even if they represent different rooms, the other is where the = provider do not want to enforce any specific render order like an MCU = sending three streams each from a different system but does not care for = the render order.

Maybe we need four options and not three.

 =

11. In = section 5.4 first paragraph what do you mean by static, Is media capture = describing a static aspect of a stream? My view is that attribute are = not static but may define some range, like maximum value or a model for = switching.

Markd> Good question, I've been questioning this myself.  I = don't see any attribute where a maximum value makes sense.  Is a = model for switching still a static attribute value?  I think it can = be.  One way to look at it is this - can an attribute value change = "on the fly" without a new message exchange between consumer = and producer, with producer advertising the new attribute values and the = consumer then making a choice to receive some streams?  I have been = thinking no, the attribute values can not change without this = exchange.  I would call this static, to an extent, but maybe that = is not a good word to use here.

Roni> I think that attribute values are static in a sense that to = change the current value it need to be negotiated. Now the value itself = can specify a range but this should be part of the value definition. I = think we need to clarify what is meant by static (value and not = attribute)

 

 

12. In 5.4 = second paragraph you mention "most common use case" what are = those, maybe these is why we are discussing what attributes and values = should be specified here.

Markd> Good point.  Does the framework support all the use = cases in the use case document?  I'm not = sure.

Roni>maybe just as an editorial change delete this part and start = the sentence with the fact that new attribute can be added based on use = cases.

 =

13. in = 5.4.1 I am not sure what main is and what should not be main, I can = understand the logic in RFC 4796. For example can we specify = "speaker" as a purpose.  

As for = main I can see a media capture that shows the whole room as main yet a = VC1 that shows left side of a room is not main, I will see as main a = "row" that has (VC1 - left, VC2-middle, VC3-right). So should = we have VC1 with purpose main even when stands by = itself.

Markd> Yes, VC1 is intended to be "main" in this = case.  A "row" does not have attributes (although people = have mentioned maybe there should be attributes for a = "row").  Maybe we need some additional values for = purpose?  Can there be more than one value for a particular media = capture?

Roni> I am not sure that in the case of a row {VC1, VC2, VC3} I = will have VC1 as main always. Since my understanding is that a consumer = can decide it wants to take only one of the captures in the row it may = make sense for the provider to say for example that VC1 is more = important than the other two.  I think we need more values = initially and this is why I referenced RFC 4796.

 =

16. in = 5.4.4 third paragraph you say that the planes should intersect, why is = that, I think that there can be a gap between the planes at the area of = capture.  The area of captures are in the area of scene defined = later.

Markd> We can clarify this.  It means the infinite planes = should intersect, but the areas of capture (quadrilaterals in the = planes) may or may not intersect.

Roni> This is what I meant.

 =

21. In 5.5 = the first two paragraph use capture set and capture scene, we need to = clarify the relation between them, maybe in section3. We discussed it in = Taipei. For example are the two capture sets in the example in the = second paragraph one or two capture scenes.

Markd> Different scenes.  I suggest there is a one to one = correspondence between a capture scene and a capture set.  That's = how I've been thinking of it.

Roni> We should have it as an open issue that needs to be = clarified since I heard other opinions.

 =

22. in 5.5 = ""Media Captures of the same media type are associated with = each other  by grouping them together in a single row of a Capture = Set" .  I think that the grouping in a single row means = simultaneous, does the grouping imply any other association without = using any attribute? If not maybe say " = simultaneous"

Markd> Yes it means simultaneous.  It is also a suggestion = from the provider, intending to make the consumers job of selecting = captures to receive easier, if it wants to follow the = suggestion.

Roni> This was an editorial comment that if associated means = simultaneous than it should say so. In the past it also meant spatial = order but we are now using explicit spatial relation which means = according to my understanding that {VC1, VC2, VC3} is the same as {VC2, = VC1, VC3}

 =

Mark

 

From:= = Roni Even [mailto:ron.even.tlv@gmail.com]=
Sent: Friday, January 13, 2012 1:19 PM
To: = Duckworth, Mark; clue@ietf.org
Subject: RE: = [clue] Updates in framework-02 - section 5 = review.

 

Hi,

I read the draft again = till section 6 in order to review the parts you mentioned. It is better = than 01 but I still have some comments.  

I will list all of them = in this email and afterwards we can cut out the ones that remain open if = any? Some of them are editorial. I will comment on all section = 5.

 

1 The second sentence in = section 5 says "figure" no number and no number to the = figure.

 

2. The figure in section = 5 need to show that capture set is composed of rows and each row is made = from media captures.

 

3. The second sentence = in 5.1 is not needed you just need to use the term and not repeat part = of the definition.

 

4. We need a term for = the "row of media captures inside a capture = set"

 

5. In 5.1 = fourth paragraph  change to "Media = Captures may also be associated with data constructs that capture  = encoding aspects of the streams" .

 =

6. =  In 5.2 fourth paragraph suggest adding "may be" =  to  become "A media capture is described by Attributes = and may be associated with an  Encode Group, and Simultaneous = Transmission Set."

 =

7. In 5.3 = first paragraph I suggest changing to "Within a capture set, a = coordinate system should be used to  model relative or absolute = positions of its constituent media

  = ; captures.  This can allow precise physical sizes to be determined = if  required, as well as the order in which media captures that = form a   group should be rendered. = "

The = co-ordinate system is needed if you want to describe the spatial = relations. I also changed the "displayed" to = "rendered"

 =

8. In 5.3 = second bullet suggest to change to "for example it shall provide =  co-ordinate information for 3 side-by-side participant = …". . it does not matter if absolute or relative or no scale = but it is needed to describe the spatial = relations.

 =

9. In 5.3 = in the third bullet, No physical scale means no spatial relation or is = it to provide some way to describe the rendering order (e.g. for MCU = case).

 =

10. = Audience front at the end of section 5.3 is not specified, there is = front and back in section 3

 =

11. In = section 5.4 first paragraph what do you mean by static, Is media capture = describing a static aspect of a stream? My view is that attribute are = not static but may define some range, like maximum value or a model for = switching.

 =

12. In 5.4 = second paragraph you mention "most common use case" what are = those, maybe these is why we are discussing what attributes and values = should be specified here.

 =

13. in = 5.4.1 I am not sure what main is and what should not be main, I can = understand the logic in RFC 4796. For example can we specify = "speaker" as a purpose.  

As for = main I can see a media capture that shows the whole room as main yet a = VC1 that shows left side of a room is not main, I will see as main a = "row" that has (VC1 - left, VC2-middle, VC3-right). So should = we have VC1 with purpose main even when stands by = itself.

 =

14. On = 5.4.2 we are having a separate discussion about what should be defined = in this document.

 =

15. in = 5.4.4 first paragraph "By comparing the area of   capture = for different media captures, " I think you need to add of the same = capture scene or capture set.

 =

16. in = 5.4.4 third paragraph you say that the planes should intersect, why is = that, I think that there can be a gap between the planes at the area of = capture.  The area of captures are in the area of scene defined = later.

 =

17. In = 5.4.4 you mention 4 points but not the order they are listed, in the = example in section 9 you give a table but the headers are not part of = the definition, maybe specify from top left clockwise = direction.

 =

18. = Suggest to change the start of the last paragraph in 5.4.4 to "If = the area of capture attribute is specified, it must include X, Y, Z = …". I do not like the use of "optional" in the = current sentence.

 =

19. = Section 5.4.5 suggest to change the beginning to " The = point_of_capture attribute is used to describe the location  of a = capture device or pseudo-device. A use case is if there are multiple = captures …"

 =

20. We = have a separate open issue on 5.4.6.

 =

21. In 5.5 = the first two paragraph use capture set and capture scene, we need to = clarify the relation between them, maybe in section3. We discussed it in = Taipei. For example are the two capture sets in the example in the = second paragraph one or two capture scenes.

 =

22. in 5.5 = ""Media Captures of the same media type are associated with = each other  by grouping them together in a single row of a Capture = Set" .  I think that the grouping in a single row means = simultaneous, does the grouping imply any other association without = using any attribute? If not maybe say " = simultaneous"

 =

23. In 5.5 = " Association between audio and video can be made by finding audio = and   video captures which share overlapping areas of = capture." I think this requires that they will use the same origin, = I did not see it required.

 =

24. In 5.5 = " A media consumer could choose one row of each media type (e.g., = audio  and video) from a capture set.  For example a three = stream consumer  could choose the first video row plus the audio = row, while a single

  = ; stream consumer could choose the second or third video row plus = the  audio row.  An MCU consumer might choose to receive = multiple rows."  A single stream consumer may also choose VC0 = or VC1 or VC2, maybe clarify it since it is the non obvious = case.

 =

25. I = think that the last paragraph in section 5.5 should be removed and = discussed when you define the Simultaneous Transmission Sets and = Encoding Groups, it is out of context here and this is why I cannot even = discuss it when talking about this section.

 =

26. 5.6 = talks about attributes of capture set while the first bullet is about = capture scene. This is again about the lack of clarity about these two = terms.

 =

27. In = 5.6.1 I suggest adding the following sentence in the end "The area = of captures specified for this capture set must use the same co-ordinate = system (same origin)"

 =

 =

 =

This is = the end of my long list

 =

Roni Even =

 =

 =

 =

 =

 =

 =

 =

 =

 =

 

 =

 

 

 

 

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] = On Behalf Of Duckworth, Mark
Sent: Wednesday, January = 11, 2012 5:43 AM
To: clue@ietf.org
Subject: Re: = [clue] Updates in framework-02

 

Hi Roni,

 

The relevant parts to = review are these sections:

5.3. Describing Spatial = Relations

5.4.4. Area of capture

5.4.5. Point of = capture

5.6. Attributes for Capture = Sets

5.6.2 Area Scale Millimeters  (I think the = name should be changed to just “area = scale”)

9. Using the Framework

 

This link to the = differences might be useful to help you review what has = changed:

http://tools.ietf.org/wg/clue/draf= t-ietf-clue-framework/draft-ietf-clue-framework-02-from-01.diff.html<= o:p>

 

Regards,

Mark

 

------=_NextPart_000_001A_01CCD504.0833A6D0-- From mary.ietf.barnes@gmail.com Fri Jan 20 14:15:37 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E418D21F84E6 for ; Fri, 20 Jan 2012 14:15:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.663 X-Spam-Level: X-Spam-Status: No, score=-103.663 tagged_above=-999 required=5 tests=[AWL=-0.064, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ONtGQmtrDitf for ; Fri, 20 Jan 2012 14:15:37 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id D582921F860B for ; Fri, 20 Jan 2012 14:15:36 -0800 (PST) Received: by vcbfk14 with SMTP id fk14so807009vcb.31 for ; Fri, 20 Jan 2012 14:15:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=BVfArta9EDm8HmOZ4+woVivYhh+kjz3scp8Egsuzv28=; b=kg/IehjbEqMA87Mv8SMwzFy7JmlzZxssaDtQobWrP64CC/WcRET0ARVaQ9+kv8ZsdQ wsNt6fKkj4kwzJ9MhzQFzMm3YdGkn54obKbps3lnutHaEo6JYe9PHvqc8wjnkMFKgaYS Tx3FIRSLhThTn5Z0qLl3yy4OKUOxBAvJkpKD0= MIME-Version: 1.0 Received: by 10.220.155.132 with SMTP id s4mr18781121vcw.38.1327097736401; Fri, 20 Jan 2012 14:15:36 -0800 (PST) Received: by 10.52.108.196 with HTTP; Fri, 20 Jan 2012 14:15:36 -0800 (PST) Date: Fri, 20 Jan 2012 16:15:36 -0600 Message-ID: From: Mary Barnes To: CLUE Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: [clue] Minutes: Design Team Meeting - Jan. 17th, 2012 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 22:15:38 -0000 Hi all, Below, please find the minutes from the design team meeting held on Jan 17th, 2012. The minutes are also on the wiki. Thanks to Marshall and John Leslie for taking notes. http://trac.tools.ietf.org/wg/clue/trac/wiki/Design-Team I will shortly forward Webex details for next Tuesday's call. Regards, Mary. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D CLUE WG Design Team Call January 17th, 2012 Chairs: Mary Barnes Attendees: Stephen Botzko Mark Duckworth Marshall Eubanks Roni Even Jonathan Lennox John Leslie Andy Pepperell Allyn Romanow Summary of action items: - Close Ticket #2, Open a new ticket for any changes to the framework that may be necessary based on WG consensus [Chairs] - Ticket #3. Assign Roni as the owner. [Chairs] - Ticket #5. Add link to Stephan's proposal: Update ticket to reflect that the issue is eliciting WG feedback on the proposal. [Chairs] Notes by Marshall Eubanks (starting at 10:14:42 EST): Administrivia. This call will repeat at the same time every Tuesday. The issue tracker link is in an email from Paul. Paul or Mary will edit the issue tracker, with links to relevant email post= s. Ticket 2 : Roni : The open issue on "my" action Action item to the chair is to update the ticket to reflect that the component is the framework document. Roni : Who is the owner ? Mary : The WG Chairs make the call. Mark would be the owner. Mark : If you do that, aren't you changing everything about the ticket. Stephan Wenger won't be doing this. Can't you close this one and open another? Mary : We can do that, to actually reflect the fact that there will a change to the framework. Mark : And we would need a discussion about this on the ML. Mary : Ticket # 3 : Use case to feed into RTCWEB. Do we have a volunteer ? Roni : I can draft a statement, but I am not sure what is the point. Stephen : It might impact the signaling design? Roni : That would be dependent on the transport we chose. Stephen : You have a short use case and that implies requirements on CLUE and RTCWEB. Roni : For the moment, all we can say is that it exists. I can't even describe how RTCWEB =A0clients work. =A0I will draft something and send it to the list. Stephen : Should it go to the RTCWEB list ? Mary : I would rather discuss it on the CLUE list first. Mary : Ticket 4 : We are going to identify all of the metadata used in clue= . Roni : That's the framework. That's the agreement as I understand it. ? : What is metadata ? Marshall : Data are things like bit rates, while metadata are things like spatial relationships. things not in most existing systems. Roni : I was under the impression that this is being worked on in the framework document. Mary : This is likely to be open for quite a while. Ticket 5 : Mark : There was discussions of this but I don't think that we came to conclusions. =A0We need to go back to the group Mary : Stephan made the proposal and we need to decide what we are going to do about it. Roni : This one is different - we need a proposal about what we are going about it. First, is this just a Boolean or not ? If not, what is the data structure we are going to give it. Allyn : I don't think that there is agreement as to whether or not this is a Boolean. Ticket 6: [MB] Jonathan : I will send an email. This is necessary work for telepresence. Roni : It is connected to ticket 1, for which Jonathan is the owner. He said that he would do that. Mary : I think we are done with the tickets. Roni : What about the editors who are supposed to rev the framework documen= t. Allyn : I am hoping by end of next week. We are trying to make it more accessible. Mark : Will Mary or Paul send out an agenda and a notice for the next call = ? Mary : Yes. Thanks everyone ! Call ended @ Tue Jan 17 10:46:58 EST 2012 Notes by John Leslie: 1010 Marshall agreed to take notes ? next call=85 every Tuesday, same time (potential conflict for Marshall) Mary: we could re-do the doodle=85 Mary: walk-through issue tracker, the WGCs will do any updates Roni: issue #2 is done=85 we're not clear what belongs in use-cases vs fram= eworks Mary: action. get this into framework Roni: not my action item anymore Mary: WGC to update ticket to say belongs to framework document -- action was initially for Roni to post Mark: are you changing everything? if so, suggest close & open a new ticket Mary: we can close this and open a new one Mark: discussion how framework handles use cases Mary: #3, should have use case to feed into RTCWEB; we need a physical pers= on Roni: I can draft something about RTCWEB, but what's the difference which client? Stephen: if RTCWEB needs to be CLUE-aware, that's a difference: short use-case implies requirements for both Roni: I'll draft something and send it to the (CLUE) list 1025 Mary: #4, not necessarily belongs to framework Roni: the metadata definition will be in the framework Mary: I'd have to check my notes, I'll take action to do that Mark: what is the "metadata" Roni: what we call data model Mary: all the information that has to be exchanges Marshall: I thought metadata was things like left vs. right channel; things most existing applications don't handle (like WebEx) Mark: people might contribute XML-like description; haven't seen any Stephen: I recall some reference (vaguely)=85 metadata-XML -- maybe cisco working on that Allyn: things have changed, but basically yes Mark: premature to get it to W3C Mary: do we need a separate ticket for detailing? Roni: we need to discuss on-list 1032 Mary: #5, Mark: discussed somewhat by Stephan Mary: will update with link to discussion Mark: need to discuss on-list to see what we agree on Mary: Stephan has made the proposal, should I thus close this ticket Marshall: it should be turned over to someone else, in other WGs they submerge in details, you may get 15 ticket changes in one day Mary: update to next-step WG discuss Roni: I think it's different -- how deeply we go into describing composed captures John: aren't different vendors going to do it differently anyway Stephen: think we need to discuss anyway, but limit the scope Allyn: some folks strongly want it to be (just) boolean Roni: point-to-point case; multipoint case=85 is this something we want to = discuss Mary: update: framework will be updated to reflect consensus 1040 Mary: #6 Roni: question arose whether this in in charter scope Jonathan: I'm mostly muted=85 I think this is necessary (confusion what ticket Jonathan is talking about) Mary: Paul & I will double-check ticket 6 Mary: 15 minutes left Roni: what about updates to other parts of the documents Allyn: hoping for next version by the end of next week=85 make it more acce= ssible Mark: keep the intent the same, explain better Allyn: end of next week should be possible Mark: that's the earliest Mary: latest is week of February 3rd Mark: for next week, will Mary/Paul send notice Mary: yes, by noon Monday=85 if no discussion, we might not hold it 1046 adjourn From mary.ietf.barnes@gmail.com Fri Jan 20 14:46:04 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00BE021F867C for ; Fri, 20 Jan 2012 14:46:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.659 X-Spam-Level: X-Spam-Status: No, score=-104.659 tagged_above=-999 required=5 tests=[AWL=0.940, BAYES_00=-2.599, GB_I_INVITATION=-2, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qv9Bh9Picc-4 for ; Fri, 20 Jan 2012 14:46:03 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 273CD21F8658 for ; Fri, 20 Jan 2012 14:46:03 -0800 (PST) Received: by vcbfk14 with SMTP id fk14so822185vcb.31 for ; Fri, 20 Jan 2012 14:46:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=LW5XEFZ1MkbHRB6/FUBAqRs7LipQ5oVhgSra8cylfoY=; b=Tu4prDGG56+zPlRlHlpQuBuGE76yucruA4PqFVQk11XbIy3Uy2D7f7vDTaa7YIbOMK oSr0XIVaCu+G0Q0qmEYB8RT33UNX4vigi5GypyRHbuy2h9GLuEUQLLwNfBq3semzhpXK /QN+WOvCUdIBKd9FDXhXb9ntuWvnZSFrenCUE= MIME-Version: 1.0 Received: by 10.220.155.212 with SMTP id t20mr18825106vcw.8.1327099562635; Fri, 20 Jan 2012 14:46:02 -0800 (PST) Received: by 10.52.108.196 with HTTP; Fri, 20 Jan 2012 14:46:02 -0800 (PST) Date: Fri, 20 Jan 2012 16:46:02 -0600 Message-ID: From: Mary Barnes To: CLUE Content-Type: text/plain; charset=ISO-8859-1 Subject: [clue] Meeting invitation: CLUE WG Design Team - Tuesday, Jan. 24, 2012 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 22:46:04 -0000 Hi all, Below are the details for the design team meeting next Tuesday. I'll post an agenda on the wiki by the end of the day on Monday. Thanks, Mary. ============================================================ Hello , Clue Working Group invites you to attend this online meeting. Topic: CLUE WG Design Team Date: Tuesday, January 24, 2012 Time: 9:00 am, Central Standard Time (Chicago, GMT-06:00) Meeting Number: 641 262 860 Meeting Password: 1234 ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://ietf.webex.com/ietf/j.php?ED=149179362&UID=1231315887&PW=NMWJhNWY5MGYy&RT=MiM3 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: 1234 4. Click "Join". To view in other time zones or languages, please click the link: https://ietf.webex.com/ietf/j.php?ED=149179362&UID=1231315887&PW=NMWJhNWY5MGYy&ORT=MiM3 ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- Call-in toll number (US/Canada): +1-408-600-3600 Access code:641 262 860 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://ietf.webex.com/ietf/mc 2. On the left navigation bar, click "Support". You can contact me at: clue-chairs@tools.ietf.org To add this meeting to your calendar program (for example Microsoft Outlook), click this link: https://ietf.webex.com/ietf/j.php?ED=149179362&UID=1231315887&ICS=MI&LD=1&RD=2&ST=1&SHA2=VsxL2SCiDz7xhhGwFl-yID1SYElSbKF4ybfKEASWhZY=&RT=MiM3 The playback of UCF (Universal Communications Format) rich media files requires appropriate players. To view this type of rich media files in the meeting, please check whether you have the players installed on your computer by going to https://ietf.webex.com/ietf/systemdiagnosis.php. Sign up for a free trial of WebEx http://www.webex.com/go/mcemfreetrial http://www.webex.com CCP:+14086003600x641262860# IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation. From Even.roni@huawei.com Fri Jan 20 15:29:06 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BC4521F8592 for ; Fri, 20 Jan 2012 15:29:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.566 X-Spam-Level: X-Spam-Status: No, score=-106.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rt4d+d97MmlJ for ; Fri, 20 Jan 2012 15:29:05 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id E9C6921F8548 for ; Fri, 20 Jan 2012 15:29:04 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LY400ECSEKBP0@szxga04-in.huawei.com> for clue@ietf.org; Sat, 21 Jan 2012 07:28:59 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LY400JOSEKBKY@szxga04-in.huawei.com> for clue@ietf.org; Sat, 21 Jan 2012 07:28:59 +0800 (CST) Received: from szxeml212-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGL71168; Sat, 21 Jan 2012 07:28:58 +0800 Received: from SZXEML417-HUB.china.huawei.com (10.82.67.156) by szxeml212-edg.china.huawei.com (172.24.2.181) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 21 Jan 2012 07:28:49 +0800 Received: from SZXEML536-MBS.china.huawei.com ([169.254.8.99]) by szxeml417-hub.china.huawei.com ([10.82.67.156]) with mapi id 14.01.0323.003; Sat, 21 Jan 2012 07:28:53 +0800 Date: Fri, 20 Jan 2012 23:28:53 +0000 From: Roni even In-reply-to: X-Originating-IP: [172.24.1.45] To: Mary Barnes , CLUE Message-id: MIME-version: 1.0 Content-type: text/plain; charset=Windows-1252 Content-language: en-US Content-transfer-encoding: quoted-printable Accept-Language: en-US, zh-CN Thread-topic: [clue] Minutes: Design Team Meeting - Jan. 17th, 2012 Thread-index: AQHM18ER0yq5moqEUUaDw1/vWVLY1JYV5kvc X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: Subject: Re: [clue] Minutes: Design Team Meeting - Jan. 17th, 2012 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 23:29:06 -0000 Hi Mary, The action item "Close Ticket #2, Open a new ticket for any changes to the = framework that may be necessary based on WG consensus [Chairs]" My understanding is that the new ticket will be about getting consensus abo= ut the compose attribute if it is a Boolean or a data structure describing = the composed image. Roni ________________________________________ From: clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Mary Barne= s [mary.ietf.barnes@gmail.com] Sent: Saturday, January 21, 2012 0:15 To: CLUE Subject: [clue] Minutes: Design Team Meeting - Jan. 17th, 2012 Hi all, Below, please find the minutes from the design team meeting held on Jan 17th, 2012. The minutes are also on the wiki. Thanks to Marshall and John Leslie for taking notes. http://trac.tools.ietf.org/wg/clue/trac/wiki/Design-Team I will shortly forward Webex details for next Tuesday's call. Regards, Mary. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D CLUE WG Design Team Call January 17th, 2012 Chairs: Mary Barnes Attendees: Stephen Botzko Mark Duckworth Marshall Eubanks Roni Even Jonathan Lennox John Leslie Andy Pepperell Allyn Romanow Summary of action items: - Close Ticket #2, Open a new ticket for any changes to the framework that may be necessary based on WG consensus [Chairs] - Ticket #3. Assign Roni as the owner. [Chairs] - Ticket #5. Add link to Stephan's proposal: Update ticket to reflect that the issue is eliciting WG feedback on the proposal. [Chairs] Notes by Marshall Eubanks (starting at 10:14:42 EST): Administrivia. This call will repeat at the same time every Tuesday. The issue tracker link is in an email from Paul. Paul or Mary will edit the issue tracker, with links to relevant email post= s. Ticket 2 : Roni : The open issue on "my" action Action item to the chair is to update the ticket to reflect that the component is the framework document. Roni : Who is the owner ? Mary : The WG Chairs make the call. Mark would be the owner. Mark : If you do that, aren't you changing everything about the ticket. Stephan Wenger won't be doing this. Can't you close this one and open another? Mary : We can do that, to actually reflect the fact that there will a change to the framework. Mark : And we would need a discussion about this on the ML. Mary : Ticket # 3 : Use case to feed into RTCWEB. Do we have a volunteer ? Roni : I can draft a statement, but I am not sure what is the point. Stephen : It might impact the signaling design? Roni : That would be dependent on the transport we chose. Stephen : You have a short use case and that implies requirements on CLUE and RTCWEB. Roni : For the moment, all we can say is that it exists. I can't even describe how RTCWEB clients work. I will draft something and send it to the list. Stephen : Should it go to the RTCWEB list ? Mary : I would rather discuss it on the CLUE list first. Mary : Ticket 4 : We are going to identify all of the metadata used in clue= . Roni : That's the framework. That's the agreement as I understand it. ? : What is metadata ? Marshall : Data are things like bit rates, while metadata are things like spatial relationships. things not in most existing systems. Roni : I was under the impression that this is being worked on in the framework document. Mary : This is likely to be open for quite a while. Ticket 5 : Mark : There was discussions of this but I don't think that we came to conclusions. We need to go back to the group Mary : Stephan made the proposal and we need to decide what we are going to do about it. Roni : This one is different - we need a proposal about what we are going about it. First, is this just a Boolean or not ? If not, what is the data structure we are going to give it. Allyn : I don't think that there is agreement as to whether or not this is a Boolean. Ticket 6: [MB] Jonathan : I will send an email. This is necessary work for telepresence. Roni : It is connected to ticket 1, for which Jonathan is the owner. He said that he would do that. Mary : I think we are done with the tickets. Roni : What about the editors who are supposed to rev the framework documen= t. Allyn : I am hoping by end of next week. We are trying to make it more accessible. Mark : Will Mary or Paul send out an agenda and a notice for the next call = ? Mary : Yes. Thanks everyone ! Call ended @ Tue Jan 17 10:46:58 EST 2012 Notes by John Leslie: 1010 Marshall agreed to take notes ? next call=85 every Tuesday, same time (potential conflict for Marshall) Mary: we could re-do the doodle=85 Mary: walk-through issue tracker, the WGCs will do any updates Roni: issue #2 is done=85 we're not clear what belongs in use-cases vs fram= eworks Mary: action. get this into framework Roni: not my action item anymore Mary: WGC to update ticket to say belongs to framework document -- action was initially for Roni to post Mark: are you changing everything? if so, suggest close & open a new ticket Mary: we can close this and open a new one Mark: discussion how framework handles use cases Mary: #3, should have use case to feed into RTCWEB; we need a physical pers= on Roni: I can draft something about RTCWEB, but what's the difference which client? Stephen: if RTCWEB needs to be CLUE-aware, that's a difference: short use-case implies requirements for both Roni: I'll draft something and send it to the (CLUE) list 1025 Mary: #4, not necessarily belongs to framework Roni: the metadata definition will be in the framework Mary: I'd have to check my notes, I'll take action to do that Mark: what is the "metadata" Roni: what we call data model Mary: all the information that has to be exchanges Marshall: I thought metadata was things like left vs. right channel; things most existing applications don't handle (like WebEx) Mark: people might contribute XML-like description; haven't seen any Stephen: I recall some reference (vaguely)=85 metadata-XML -- maybe cisco working on that Allyn: things have changed, but basically yes Mark: premature to get it to W3C Mary: do we need a separate ticket for detailing? Roni: we need to discuss on-list 1032 Mary: #5, Mark: discussed somewhat by Stephan Mary: will update with link to discussion Mark: need to discuss on-list to see what we agree on Mary: Stephan has made the proposal, should I thus close this ticket Marshall: it should be turned over to someone else, in other WGs they submerge in details, you may get 15 ticket changes in one day Mary: update to next-step WG discuss Roni: I think it's different -- how deeply we go into describing composed captures John: aren't different vendors going to do it differently anyway Stephen: think we need to discuss anyway, but limit the scope Allyn: some folks strongly want it to be (just) boolean Roni: point-to-point case; multipoint case=85 is this something we want to = discuss Mary: update: framework will be updated to reflect consensus 1040 Mary: #6 Roni: question arose whether this in in charter scope Jonathan: I'm mostly muted=85 I think this is necessary (confusion what ticket Jonathan is talking about) Mary: Paul & I will double-check ticket 6 Mary: 15 minutes left Roni: what about updates to other parts of the documents Allyn: hoping for next version by the end of next week=85 make it more acce= ssible Mark: keep the intent the same, explain better Allyn: end of next week should be possible Mark: that's the earliest Mary: latest is week of February 3rd Mark: for next week, will Mary/Paul send notice Mary: yes, by noon Monday=85 if no discussion, we might not hold it 1046 adjourn _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue= From mary.ietf.barnes@gmail.com Fri Jan 20 16:17:22 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A38E621F86EB for ; Fri, 20 Jan 2012 16:17:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.714 X-Spam-Level: X-Spam-Status: No, score=-103.714 tagged_above=-999 required=5 tests=[AWL=-0.115, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ELtcPAw4Un+4 for ; Fri, 20 Jan 2012 16:17:21 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6342C21F8587 for ; Fri, 20 Jan 2012 16:17:21 -0800 (PST) Received: by vbbfr13 with SMTP id fr13so854593vbb.31 for ; Fri, 20 Jan 2012 16:17:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=joso8TciY5M8yxyGHtm4ZbT/sANmb8kRPctmbxzv4tQ=; b=LUrNFBOAwEpBFSLhNEGKnDO3EHq8awTASoWgUGEXyKcOvnRRwJjKxPbslrKbRKQme1 LCmAjxhfi/zpZmm0Qogt98NOULTC6iiQnczbPeJ1Ytv4UUTcX0XWey5oE3tyEMfjABoM D8MYxfPPEdzQESX5DFkOhKE4r4E3x9H/nFBtA= MIME-Version: 1.0 Received: by 10.52.88.134 with SMTP id bg6mr15754903vdb.4.1327105040922; Fri, 20 Jan 2012 16:17:20 -0800 (PST) Received: by 10.52.108.196 with HTTP; Fri, 20 Jan 2012 16:17:20 -0800 (PST) In-Reply-To: References: Date: Fri, 20 Jan 2012 18:17:20 -0600 Message-ID: From: Mary Barnes To: Roni even Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: CLUE Subject: Re: [clue] Minutes: Design Team Meeting - Jan. 17th, 2012 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jan 2012 00:17:22 -0000 Correct. We'll be explicit in the text when we open the issue. Thanks, Mary. On Fri, Jan 20, 2012 at 5:28 PM, Roni even wrote: > Hi Mary, > The action item "Close Ticket #2, Open a new ticket for any changes to th= e framework > that may be necessary based on WG consensus [Chairs]" > My understanding is that the new ticket will be about getting consensus a= bout the compose attribute if it is a Boolean or a data structure describin= g the composed image. > > > Roni > > ________________________________________ > From: clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Mary Bar= nes [mary.ietf.barnes@gmail.com] > Sent: Saturday, January 21, 2012 0:15 > To: CLUE > Subject: [clue] Minutes: Design Team Meeting - Jan. 17th, 2012 > > Hi all, > > Below, please find the minutes from the design team meeting held on > Jan 17th, 2012. =A0 The minutes are also on the wiki. =A0Thanks to > Marshall and John Leslie for taking notes. > http://trac.tools.ietf.org/wg/clue/trac/wiki/Design-Team > > I will shortly forward Webex details for next Tuesday's call. > > Regards, > Mary. > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > > CLUE WG Design Team Call =A0 January 17th, 2012 > Chairs: Mary Barnes > > Attendees: > Stephen Botzko > Mark Duckworth > Marshall Eubanks > Roni Even > Jonathan Lennox > John Leslie > Andy Pepperell > Allyn Romanow > > > Summary of action items: > - Close Ticket #2, Open a new ticket for any changes to the framework > that may be necessary based on WG consensus [Chairs] > - Ticket #3. Assign Roni as the owner. [Chairs] > - Ticket #5. =A0Add link to Stephan's proposal: =A0 Update ticket to > reflect that the issue is eliciting WG feedback on the proposal. > [Chairs] > > Notes by Marshall Eubanks (starting at 10:14:42 EST): > > Administrivia. This call will repeat at the same time every Tuesday. > > The issue tracker link is in an email from Paul. > > Paul or Mary will edit the issue tracker, with links to relevant email po= sts. > > Ticket 2 : > > Roni : The open issue on "my" action > > Action item to the chair is to update the ticket to reflect that the > component is the framework document. > > Roni : Who is the owner ? > > Mary : The WG Chairs make the call. > > Mark would be the owner. > > Mark : If you do that, aren't you changing everything about the > ticket. Stephan Wenger won't be doing this. Can't you close this one > and open another? > > Mary : We can do that, to actually reflect the fact that there will a > change to the framework. > > Mark : And we would need a discussion about this on the ML. > > Mary : Ticket # 3 : Use case to feed into RTCWEB. > > Do we have a volunteer ? > > Roni : I can draft a statement, but I am not sure what is the point. > > Stephen : It might impact the signaling design? > > Roni : That would be dependent on the transport we chose. > > Stephen : You have a short use case and that implies requirements on > CLUE and RTCWEB. > > Roni : For the moment, all we can say is that it exists. I can't even > describe how RTCWEB =A0clients work. =A0I will draft something and send i= t > to the list. > > Stephen : Should it go to the RTCWEB list ? > > Mary : I would rather discuss it on the CLUE list first. > > Mary : Ticket 4 : We are going to identify all of the metadata used in cl= ue. > > Roni : That's the framework. That's the agreement as I understand it. > > ? : What is metadata ? > > Marshall : Data are things like bit rates, while metadata are things > like spatial relationships. things not in most existing systems. > > Roni : I was under the impression that this is being worked on in the > framework document. > > Mary : This is likely to be open for quite a while. > > Ticket 5 : > > Mark : There was discussions of this but I don't think that we came to > conclusions. =A0We need to go back to the group > > Mary : Stephan made the proposal and we need to decide what we are > going to do about it. > > Roni : This one is different - we need a proposal about what we are > going about it. > > First, is this just a Boolean or not ? If not, what is the data > structure we are going to give it. > > Allyn : I don't think that there is agreement as to whether or not > this is a Boolean. > > Ticket 6: [MB] > > Jonathan : I will send an email. This is necessary work for telepresence. > > Roni : It is connected to ticket 1, for which Jonathan is the owner. > He said that he would do that. > > Mary : I think we are done with the tickets. > > Roni : What about the editors who are supposed to rev the framework docum= ent. > > Allyn : I am hoping by end of next week. We are trying to make it more > accessible. > > Mark : Will Mary or Paul send out an agenda and a notice for the next cal= l ? > > Mary : Yes. > > Thanks everyone ! > > Call ended @ Tue Jan 17 10:46:58 EST 2012 > Notes by John Leslie: > > 1010 Marshall agreed to take notes > ? next call=85 every Tuesday, same time (potential conflict for Marshall) > Mary: we could re-do the doodle=85 > Mary: walk-through issue tracker, the WGCs will do any updates > Roni: issue #2 is done=85 we're not clear what belongs in use-cases vs fr= ameworks > Mary: action. get this into framework > Roni: not my action item anymore > Mary: WGC to update ticket to say belongs to framework document -- > action was initially for Roni to post > Mark: are you changing everything? if so, suggest close & open a new tick= et > Mary: we can close this and open a new one > Mark: discussion how framework handles use cases > Mary: #3, should have use case to feed into RTCWEB; we need a physical pe= rson > Roni: I can draft something about RTCWEB, but what's the difference > which client? > Stephen: if RTCWEB needs to be CLUE-aware, that's a difference: short > use-case implies requirements for both > Roni: I'll draft something and send it to the (CLUE) list > 1025 > Mary: #4, not necessarily belongs to framework > Roni: the metadata definition will be in the framework > Mary: I'd have to check my notes, I'll take action to do that > Mark: what is the "metadata" > Roni: what we call data model > Mary: all the information that has to be exchanges > Marshall: I thought metadata was things like left vs. right channel; > things most existing applications don't handle (like WebEx) > Mark: people might contribute XML-like description; haven't seen any > Stephen: I recall some reference (vaguely)=85 metadata-XML -- maybe > cisco working on that > Allyn: things have changed, but basically yes > Mark: premature to get it to W3C > Mary: do we need a separate ticket for detailing? > Roni: we need to discuss on-list > 1032 > Mary: #5, > Mark: discussed somewhat by Stephan > Mary: will update with link to discussion > Mark: need to discuss on-list to see what we agree on > Mary: Stephan has made the proposal, should I thus close this ticket > Marshall: it should be turned over to someone else, in other WGs they > submerge in details, you may get 15 ticket changes in one day > Mary: update to next-step WG discuss > Roni: I think it's different -- how deeply we go into describing > composed captures > John: aren't different vendors going to do it differently anyway > Stephen: think we need to discuss anyway, but limit the scope > Allyn: some folks strongly want it to be (just) boolean > Roni: point-to-point case; multipoint case=85 is this something we want t= o discuss > Mary: update: framework will be updated to reflect consensus > 1040 > Mary: #6 > Roni: question arose whether this in in charter scope > Jonathan: I'm mostly muted=85 I think this is necessary > (confusion what ticket Jonathan is talking about) > Mary: Paul & I will double-check ticket 6 > Mary: 15 minutes left > Roni: what about updates to other parts of the documents > Allyn: hoping for next version by the end of next week=85 make it more ac= cessible > Mark: keep the intent the same, explain better > Allyn: end of next week should be possible > Mark: that's the earliest > Mary: latest is week of February 3rd > Mark: for next week, will Mary/Paul send notice > Mary: yes, by noon Monday=85 if no discussion, we might not hold it > 1046 adjourn > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From trac+clue@trac.tools.ietf.org Mon Jan 23 14:12:17 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2634921F8518 for ; Mon, 23 Jan 2012 14:12:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OzsIsajIjLEG for ; Mon, 23 Jan 2012 14:12:16 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 92F6821F84E7 for ; Mon, 23 Jan 2012 14:12:16 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RpS7R-0005gg-Cs; Mon, 23 Jan 2012 17:12:05 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "clue issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: ron.even.tlv@gmail.com, mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Mon, 23 Jan 2012 22:12:04 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/2#comment:2 Message-ID: <078.d8d6722544c18ccbc51a6a291d3fd382@trac.tools.ietf.org> References: <063.9b81af3c175d186140d57829d721bd2b@trac.tools.ietf.org> X-Trac-Ticket-ID: 2 In-Reply-To: <063.9b81af3c175d186140d57829d721bd2b@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: ron.even.tlv@gmail.com, mary.ietf.barnes@gmail.com, Even.roni@huawei.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: clue@ietf.org Subject: Re: [clue] #2: Use cases for selecting composed captures X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 22:12:17 -0000 #2: Use cases for selecting composed captures Changes (by mary.ietf.barnes@…): * status: new => closed * resolution: => fixed Comment: Replying to [ticket:2 pkyzivat@…]: > Roni Even to post use cases for selecting composed captures, on the mailing list. Per Roni's comment, he posted an email with the use cases for selecting composed captures. Thus, this issue is closed. -- ------------------------------------+------------------------ Reporter: pkyzivat@… | Owner: Roni Even Type: task | Status: closed Priority: major | Milestone: Component: telepresence-use-cases | Version: Severity: Active WG Document | Resolution: fixed Keywords: | ------------------------------------+------------------------ Ticket URL: clue From trac+clue@trac.tools.ietf.org Mon Jan 23 14:15:50 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E59321F8735 for ; Mon, 23 Jan 2012 14:15:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fPFoX1EVf-Ol for ; Mon, 23 Jan 2012 14:15:49 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 6F10121F8709 for ; Mon, 23 Jan 2012 14:15:46 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RpSAv-0006fE-3H; Mon, 23 Jan 2012 17:15:41 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "clue issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-clue-framework@tools.ietf.org, mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Mon, 23 Jan 2012 22:15:41 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/7 Message-ID: <068.03e705c774d30abee11ba5026a664a26@trac.tools.ietf.org> X-Trac-Ticket-ID: 7 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-clue-framework@tools.ietf.org, mary.ietf.barnes@gmail.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120123221546.6F10121F8709@ietfa.amsl.com> Resent-Date: Mon, 23 Jan 2012 14:15:46 -0800 (PST) Resent-From: trac+clue@trac.tools.ietf.org Cc: clue@ietf.org Subject: [clue] #7: Is compose attribute a boolean or data structure X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 22:15:50 -0000 #7: Is compose attribute a boolean or data structure Need to determine WG consensus as to whether the composed attribute is a boolean (currently in the framework) or whether it should be a data structure describing the composed image. (Note: this ticket is a result of closing Issue #2). -- --------------------------------+----------------------------------------- Reporter: mary.ietf.barnes@… | Owner: draft-ietf-clue-framework@… Type: defect | Status: new Priority: major | Milestone: Component: framework | Version: Severity: Active WG Document | Keywords: --------------------------------+----------------------------------------- Ticket URL: clue From trac+clue@trac.tools.ietf.org Mon Jan 23 14:15:58 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F76E21F8729 for ; Mon, 23 Jan 2012 14:15:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M2Cc0EoGyp+e for ; Mon, 23 Jan 2012 14:15:58 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id ED66021F872D for ; Mon, 23 Jan 2012 14:15:57 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RpSBA-0006fs-FU; Mon, 23 Jan 2012 17:15:56 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "clue issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-clue-framework@tools.ietf.org, mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Mon, 23 Jan 2012 22:15:56 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/7#comment:1 Message-ID: <083.6853ec8d97dcdb1adcf1dba473d6d65f@trac.tools.ietf.org> References: <068.03e705c774d30abee11ba5026a664a26@trac.tools.ietf.org> X-Trac-Ticket-ID: 7 In-Reply-To: <068.03e705c774d30abee11ba5026a664a26@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-clue-framework@tools.ietf.org, mary.ietf.barnes@gmail.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120123221557.ED66021F872D@ietfa.amsl.com> Resent-Date: Mon, 23 Jan 2012 14:15:57 -0800 (PST) Resent-From: trac+clue@trac.tools.ietf.org Cc: clue@ietf.org Subject: Re: [clue] #7: Is composed attribute a boolean or data structure (was: Is compose attribute a boolean or data structure) X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 22:15:58 -0000 #7: Is composed attribute a boolean or data structure -- --------------------------------+------------------------------------------ Reporter: mary.ietf.barnes@… | Owner: draft-ietf-clue-framework@… Type: defect | Status: new Priority: major | Milestone: Component: framework | Version: Severity: Active WG Document | Resolution: Keywords: | --------------------------------+------------------------------------------ Ticket URL: clue From trac+clue@trac.tools.ietf.org Mon Jan 23 14:30:45 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45D0D21F85A1 for ; Mon, 23 Jan 2012 14:30:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z2zaH+JWXHs2 for ; Mon, 23 Jan 2012 14:30:44 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id C4FEB21F8577 for ; Mon, 23 Jan 2012 14:30:44 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RpSPP-0002CI-Vg; Mon, 23 Jan 2012 17:30:40 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "clue issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: even.roni@huawei.com, mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Mon, 23 Jan 2012 22:30:39 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/3#comment:1 Message-ID: <078.8d866fd2136658d13679d198c3139044@trac.tools.ietf.org> References: <063.989fef5c8859eb1ed5eaeeaac3cf1759@trac.tools.ietf.org> X-Trac-Ticket-ID: 3 In-Reply-To: <063.989fef5c8859eb1ed5eaeeaac3cf1759@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: even.roni@huawei.com, mary.ietf.barnes@gmail.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: clue@ietf.org Subject: Re: [clue] #3: Use case for an RTCWEB client X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 22:30:45 -0000 #3: Use case for an RTCWEB client Changes (by mary.ietf.barnes@…): * owner: draft-ietf-clue-telepresence-use-cases@… => even.roni@… -- ------------------------------------+-------------------------- Reporter: pkyzivat@… | Owner: even.roni@… Type: task | Status: new Priority: major | Milestone: Component: telepresence-use-cases | Version: Severity: Active WG Document | Resolution: Keywords: | ------------------------------------+-------------------------- Ticket URL: clue From trac+clue@trac.tools.ietf.org Mon Jan 23 14:38:12 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C05B21F8616 for ; Mon, 23 Jan 2012 14:38:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_41=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DXXaSY9++VvW for ; Mon, 23 Jan 2012 14:38:11 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 96CAE21F860E for ; Mon, 23 Jan 2012 14:38:11 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RpSWW-0003Oc-Bw; Mon, 23 Jan 2012 17:38:00 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "clue issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-clue-framework@tools.ietf.org, mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Mon, 23 Jan 2012 22:38:00 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/5#comment:1 Message-ID: <078.c80b37d9797a3c5ff70bdd97d19f4364@trac.tools.ietf.org> References: <063.a37bc5dd4fc60cc1fce0e69ad3a0e316@trac.tools.ietf.org> X-Trac-Ticket-ID: 5 In-Reply-To: <063.a37bc5dd4fc60cc1fce0e69ad3a0e316@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-clue-framework@tools.ietf.org, mary.ietf.barnes@gmail.com, Stephan@vidyo.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120123223811.96CAE21F860E@ietfa.amsl.com> Resent-Date: Mon, 23 Jan 2012 14:38:11 -0800 (PST) Resent-From: trac+clue@trac.tools.ietf.org Cc: Stephan@vidyo.com, clue@ietf.org Subject: Re: [clue] #5: Describing composed captures (was: Describe composed captures) X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 22:38:12 -0000 #5: Describing composed captures Description changed by mary.ietf.barnes@…: Old description: > Stephan Wenger to make proposal for describing composed captures, by mid > December, 2011. New description: Stephan Wenger to make proposal for describing composed captures, by mid December, 2011. Update: Stephan made the following proposal:http://www.ietf.org/mail- archive/web/clue/current/msg00765.html Need addt'l WG feedback on this proposal. -- -- --------------------------------+------------------------------------------ Reporter: pkyzivat@… | Owner: draft-ietf-clue-framework@… Type: task | Status: new Priority: major | Milestone: Component: framework | Version: Severity: Active WG Document | Resolution: Keywords: | --------------------------------+------------------------------------------ Ticket URL: clue From trac+clue@trac.tools.ietf.org Mon Jan 23 14:43:37 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AB2221F8604 for ; Mon, 23 Jan 2012 14:43:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pDp+jwVmh2dv for ; Mon, 23 Jan 2012 14:43:36 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id A8F2721F85FD for ; Mon, 23 Jan 2012 14:43:35 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RpSbn-0003WY-4I; Mon, 23 Jan 2012 17:43:27 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "clue issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-clue-framework@tools.ietf.org, mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Mon, 23 Jan 2012 22:43:27 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/7#comment:2 Message-ID: <083.e4945b5c72773c1362efdf7bb0443c4a@trac.tools.ietf.org> References: <068.03e705c774d30abee11ba5026a664a26@trac.tools.ietf.org> X-Trac-Ticket-ID: 7 In-Reply-To: <068.03e705c774d30abee11ba5026a664a26@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-clue-framework@tools.ietf.org, mary.ietf.barnes@gmail.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120123224336.A8F2721F85FD@ietfa.amsl.com> Resent-Date: Mon, 23 Jan 2012 14:43:35 -0800 (PST) Resent-From: trac+clue@trac.tools.ietf.org Cc: clue@ietf.org Subject: Re: [clue] #7: Is composed attribute a boolean or data structure X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 22:43:37 -0000 #7: Is composed attribute a boolean or data structure Changes (by mary.ietf.barnes@…): * type: defect => task -- --------------------------------+------------------------------------------ Reporter: mary.ietf.barnes@… | Owner: draft-ietf-clue-framework@… Type: task | Status: new Priority: major | Milestone: Component: framework | Version: Severity: Active WG Document | Resolution: Keywords: | --------------------------------+------------------------------------------ Ticket URL: clue From mary.ietf.barnes@gmail.com Mon Jan 23 14:47:17 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D445D21F84E7 for ; Mon, 23 Jan 2012 14:47:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.963 X-Spam-Level: X-Spam-Status: No, score=-103.963 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_05=-1.11, GB_I_INVITATION=-2, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A5f4on6kWk7j for ; Mon, 23 Jan 2012 14:47:16 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 716E421F84A3 for ; Mon, 23 Jan 2012 14:47:16 -0800 (PST) Received: by vcbfk14 with SMTP id fk14so2510885vcb.31 for ; Mon, 23 Jan 2012 14:47:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ULsBnvBPFoPRmvZMQDLgRE4eB97VX7jHoychOp6LkBU=; b=RgD6YdmIRSSwdMSs9qRKpnxM81M/suoZPVNSdnjtcAljdUpRV8Wv2H9xgKNDCujsZT hXR2Yoz9q7iHOebpmbpTNze0UPhGci2tOAs9Tji6+Dq3KcY2Q7GLRWEPcNKqIclzLUVl bMay8m1b3VytTZ0R5o0+zWAPfLep72FSqeCzM= MIME-Version: 1.0 Received: by 10.220.155.212 with SMTP id t20mr5729496vcw.8.1327358835787; Mon, 23 Jan 2012 14:47:15 -0800 (PST) Received: by 10.52.108.196 with HTTP; Mon, 23 Jan 2012 14:47:15 -0800 (PST) In-Reply-To: References: Date: Mon, 23 Jan 2012 16:47:15 -0600 Message-ID: From: Mary Barnes To: CLUE Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [clue] Meeting invitation: CLUE WG Design Team - Tuesday, Jan. 24, 2012 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 22:47:17 -0000 Hi all, Here's a proposed agenda for tomorrow's call: 1) Quick review of action items 2) Detailed discussion of Action item #7. Note, if anyone wants to put together a chart or two to support their views on Action item #7, if you could please send to me no later than 8:30 am central, so I can upload to the wiki. Thanks, Mary. On Fri, Jan 20, 2012 at 4:46 PM, Mary Barnes w= rote: > Hi all, > > Below are the details for the design team meeting next Tuesday. =A0I'll > post an agenda on the wiki by the end of the day on Monday. > > Thanks, > Mary. > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Hello , > > Clue Working Group invites you to attend this online meeting. > > Topic: CLUE WG Design Team > Date: Tuesday, January 24, 2012 > Time: 9:00 am, Central Standard Time (Chicago, GMT-06:00) > Meeting Number: 641 262 860 > Meeting Password: 1234 > > > ------------------------------------------------------- > To join the online meeting (Now from mobile devices!) > ------------------------------------------------------- > 1. Go to https://ietf.webex.com/ietf/j.php?ED=3D149179362&UID=3D123131588= 7&PW=3DNMWJhNWY5MGYy&RT=3DMiM3 > 2. If requested, enter your name and email address. > 3. If a password is required, enter the meeting password: 1234 > 4. Click "Join". > > To view in other time zones or languages, please click the link: > https://ietf.webex.com/ietf/j.php?ED=3D149179362&UID=3D1231315887&PW=3DNM= WJhNWY5MGYy&ORT=3DMiM3 > > ------------------------------------------------------- > To join the audio conference only > ------------------------------------------------------- > Call-in toll number (US/Canada): +1-408-600-3600 > > Access code:641 262 860 > > ------------------------------------------------------- > For assistance > ------------------------------------------------------- > 1. Go to https://ietf.webex.com/ietf/mc > 2. On the left navigation bar, click "Support". > > You can contact me at: > clue-chairs@tools.ietf.org > > > To add this meeting to your calendar program (for example Microsoft > Outlook), click this link: > https://ietf.webex.com/ietf/j.php?ED=3D149179362&UID=3D1231315887&ICS=3DM= I&LD=3D1&RD=3D2&ST=3D1&SHA2=3DVsxL2SCiDz7xhhGwFl-yID1SYElSbKF4ybfKEASWhZY= =3D&RT=3DMiM3 > > The playback of UCF (Universal Communications Format) rich media files > requires appropriate players. To view this type of rich media files in > the meeting, please check whether you have the players installed on > your computer by going to > https://ietf.webex.com/ietf/systemdiagnosis.php. > > Sign up for a free trial of WebEx > http://www.webex.com/go/mcemfreetrial > > http://www.webex.com > > CCP:+14086003600x641262860# > > IMPORTANT NOTICE: This WebEx service includes a feature that allows > audio and any documents and other materials exchanged or viewed during > the session to be recorded. By joining this session, you automatically > consent to such recordings. If you do not consent to the recording, > discuss your concerns with the meeting host prior to the start of the > recording or do not join the session. Please note that any such > recordings may be subject to discovery in the event of litigation. From Christian.Groves@nteczone.com Mon Jan 23 20:01:22 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2383421F8616 for ; Mon, 23 Jan 2012 20:01:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Aw37XOcmKPd for ; Mon, 23 Jan 2012 20:01:21 -0800 (PST) Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [150.101.137.143]) by ietfa.amsl.com (Postfix) with ESMTP id 1BE9321F85FD for ; Mon, 23 Jan 2012 20:01:20 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuQBAIYrHk920bSr/2dsb2JhbAAMNqxkhHsbJS4PFhgDAgECATcUDQgBAcBVjCYEp3k Received: from ppp118-209-180-171.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.180.171]) by ipmail05.adl6.internode.on.net with ESMTP; 24 Jan 2012 14:31:19 +1030 Message-ID: <4F1E2D0C.9030602@nteczone.com> Date: Tue, 24 Jan 2012 15:01:16 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: "clue@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [clue] Comments on v2 of the CLUE Framework X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 04:01:22 -0000 Hello Mark, all, I've reviewed draft-ietf-clue-framework-02.txt and have a few comments: Section 1: "Several appendices describe topics that are under discussion for adding to the document." There's only one Appendix, A. Section 5.3 4th bullet: Would it be better to say "...with the origin at a spot of the choosing." or was implementer used on purpose? Section 5.3 Additional: Would additional principles be that the origin is the same for any captures in a capture scene utilising spatial information? Also can the origin be changed during a session? I guess it should be static??? Section 5.4.4: With regards to the text "..Each media capture can have its own plane of interest, but the planes should intersect at the boundary between spatially related captures..." FYI, in the ITU-T Q.5/16 Telepresence System architecture document there is a room layout (section 9.1) that shows non intersecting plane. I can see that you'd probably want to keep the boundaries between captures parallel but I don't know that they should intersect? Section 5.6.2: "An optional attribute...", I guess its optional to include this as a MC may not have spatial information. However if there is spatial information is this mandatory or may a default be assumed? Also the heading of the section is "Area scale millimeters" seeing we don't have a boolean value any more we could remove "millimeters" from the name of the attribute. Section 6.2 4th paragraph: "...and capture the whole endpoint". Would it be better to say capture the entire "capture scene"? I guess its not showing a video of the device itself :-) Section 9 under 2nd bullet list: "Summary of video captures - 3 codecs,..." should this be "codecs" or "captures"? Section 9 "Area of capture" table: VC3 if I understand it correctly shows the loudest speaker. However the table gives the spatial co-ordinates for the entire scene. I can see some logic to say the speaker will come from somewhere in the capture scene, but is this assumption documented anywhere in the framework? Section 9 addition: As we've specified "Area of Scene" in 5.6.1 I think it would be good to indicate what it is in the example. Also where it says "This example uses a millimeter scale", to tie it back to the "Area Scale" attribute it may be better to say "An area scale of millimeters is used." Section 9 paragraph under Point of capture table: "This is the width of each area of capture for VC0, VC1, and VC2." I don't know if its worth saying "planar width" to make sure there's no confusion with width across the Cartesian axis. Regards, Christian From ron.even.tlv@gmail.com Tue Jan 24 01:35:25 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C53EA21F8567 for ; Tue, 24 Jan 2012 01:35:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5HZZ17OKkcaJ for ; Tue, 24 Jan 2012 01:35:25 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id BCAFC21F84EB for ; Tue, 24 Jan 2012 01:35:24 -0800 (PST) Received: by eaai13 with SMTP id i13so1673647eaa.31 for ; Tue, 24 Jan 2012 01:35:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=YiZwZicJCToMNN144vRXiy2S8lWNe4N8tGgT2AnjCTQ=; b=QE2DWkAz1UQgXw63SwsU/046GmOYpyqoOoAAMVMfO8RIsHXpGWLDuSX1vrsnEzQe62 qi+jXjfstrOPCKdXY39cnOxz6OHR1/3aErIid9X+Z2zM+xR/S46ehI6kbCy+VTLS3eAD Ir1XOLKv/0J5l26ceZ6J6U2QLKi51wGnyFZcQ= Received: by 10.213.102.9 with SMTP id e9mr2235294ebo.95.1327397723913; Tue, 24 Jan 2012 01:35:23 -0800 (PST) Received: from windows8d787f9 ([109.67.208.29]) by mx.google.com with ESMTPS id c16sm65464102eei.1.2012.01.24.01.35.17 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 24 Jan 2012 01:35:22 -0800 (PST) From: "Roni Even" To: References: <063.989fef5c8859eb1ed5eaeeaac3cf1759@trac.tools.ietf.org> <078.8d866fd2136658d13679d198c3139044@trac.tools.ietf.org> In-Reply-To: <078.8d866fd2136658d13679d198c3139044@trac.tools.ietf.org> Date: Tue, 24 Jan 2012 11:31:33 +0200 Message-ID: <4f1e7b5a.107f0e0a.3451.4be2@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AczaHqnT4mt9igFISFCbr2fYSee3pQAW/ybA Content-Language: en-us Subject: Re: [clue] #3: Use case for an RTCWEB client X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 09:35:25 -0000 Hi, This is my attempt to address this issue. Please review since I am not = the expert on RTCweb Roni Even The RTCweb overview document = http://tools.ietf.org/id/draft-ietf-rtcweb-overview-02.txt says that = "the model of real-time support for browser-based applications does not = envisage that the browser will contain all the functions that need to be = performed in order to have a function such as a telephone or a = videoconferencing unit; the vision is that the browser will have the = functions that are needed for a Web application, working in conjunction = with its backend servers, to implement these functions. =20 This means that two vital interfaces need specification: The protocols = that browsers talk to each other, without any intervening servers, and = the APIs that are offered for a Javascript application to take advantage = of the browser's functionality." The RTCweb based application with use the API to communicate through the = browser and the application server with the remote application for the = call signaling and media channel negotiation while the media channel = will flow end to end between both browsers (note =E2=80=93 my = understanding is that the RTP media is sent by the browser but I am not = sure how non video/audio channels content is sent end to end, is it done = by the browser or the application?)=20 The CLUE support for multistreams adds support for multiple media = streams of the same type by providing information about the content or = semantics of each stream based on the use cases in = http://tools.ietf.org/html/draft-ietf-clue-telepresence-use-cases-02 . A = typical example is a TP system with 3 cameras and 3 monitors = communicating with a similar system. In this use case the added = information to a simple video call may be the spatial information = describing the view provided by each camera with relations to the = conference room.=20 Note: Currently CLUE have not decided how to negotiate the CLUE data = over the wire, if done by SDP it will probably be handled like the rest = of the RTCweb API. If there will be a different transport, the CLUE = working group will add the requirements for the browser API to support = this transport. > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf = Of > clue issue tracker > Sent: Tuesday, January 24, 2012 12:31 AM > To: even.roni@huawei.com; mary.ietf.barnes@gmail.com > Cc: clue@ietf.org > Subject: Re: [clue] #3: Use case for an RTCWEB client >=20 > #3: Use case for an RTCWEB client >=20 > Changes (by mary.ietf.barnes@=E2=80=A6): >=20 > * owner: draft-ietf-clue-telepresence-use-cases@=E2=80=A6 =3D> = even.roni@=E2=80=A6 >=20 >=20 > -- > ------------------------------------+-------------------------- > Reporter: pkyzivat@=E2=80=A6 | Owner: = even.roni@=E2=80=A6 > Type: task | Status: new > Priority: major | Milestone: > Component: telepresence-use-cases | Version: > Severity: Active WG Document | Resolution: > Keywords: | > ------------------------------------+-------------------------- >=20 > Ticket URL: > > clue >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From pkyzivat@alum.mit.edu Tue Jan 24 08:08:57 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E8DD21F851E for ; Tue, 24 Jan 2012 08:08:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[AWL=-0.019, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qOqCu2luadXw for ; Tue, 24 Jan 2012 08:08:56 -0800 (PST) Received: from qmta01.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by ietfa.amsl.com (Postfix) with ESMTP id F332421F84D1 for ; Tue, 24 Jan 2012 08:08:55 -0800 (PST) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta01.westchester.pa.mail.comcast.net with comcast id RTEp1i0051ei1Bg51U8wj1; Tue, 24 Jan 2012 16:08:56 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta24.westchester.pa.mail.comcast.net with comcast id RU8w1i00i07duvL3kU8wxS; Tue, 24 Jan 2012 16:08:56 +0000 Message-ID: <4F1ED796.7070201@alum.mit.edu> Date: Tue, 24 Jan 2012 11:08:54 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: CLUE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [clue] describing composed streams X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 16:08:57 -0000 Based on what I have heard, I see the following possibilities: 1) there is no explicit indication of whether streams are composed or not. But still a composed stream will ideally indication the portion of the scene it covers, which would presumably be a union of those for the streams being composed. This could be nasty if that portion isn't a rectangle. (E.g. composition of left and right streams, but not the center screen.) It also is a problem if the streams being composed aren't part of the same scene. In that case it can't really describe the geometry of the composed scene at all. In the case of switching, such as active speaker, presumably the portion of the scene reported would be the union of all the potential speakers. 2) same as (1), but with a boolean indication for composed streams. IMO this doesn't add anything useful. 3) same as (1) but with addition of a free text description of what the stream contains. This isn't of any use for automated selection of streams to receive/display, but at least it can enable a user interface that can allow an end user in the receiving room to manually configure what streams should be displayed. Not ideal, but perhaps still useful for dealing with interop problems. 4) enumeration of the streams that are inputs to the composition of a composed stream. This is independent of the composition algorithm. stream that tiles the input streams would be described the same as one that switches among them. This would require that the streams that go into the composition also be (separately) described. This would be no issue if they are also available for independent selection. But if there are to be cases where the composition is available but the independent streams are not, then this would require more work. 5) description of how the composition is accomplished. It might be time or space multiplexing of the pixels. If time multiplexing, then the algorithm for doing so (active speaker, ...). If space multiplexing, then it could include which region of the composed stream contains each composed stream. There could also be a combination of time and space multiplexing. And this could also be hierarchical, if one or more of the input streams for composition are themselves composed. Thanks, Paul From marshall.eubanks@gmail.com Tue Jan 24 08:21:00 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F3AA21F85C4 for ; Tue, 24 Jan 2012 08:21:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.491 X-Spam-Level: X-Spam-Status: No, score=-103.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BH+CSJoz08Gr for ; Tue, 24 Jan 2012 08:20:59 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 40F5D21F8604 for ; Tue, 24 Jan 2012 08:20:59 -0800 (PST) Received: by obbwc12 with SMTP id wc12so5445571obb.31 for ; Tue, 24 Jan 2012 08:20:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=OhOX4arbo6FPM1Qj7qCw3WnEYQ6F35gT2xZ+SFxSnSg=; b=vWPBYu8aZIGMS9pn/XWfPRopxG7f4QsalnGn28EWr2au87ab+U8NndU66tvSaMinTW M4mlcOm1/XQjDP3msvL6ZMsRfC2jIIXXoSKOrA/N3Bhkglfm9hvbDvtOB8HlYp5PdFyX CGg+K/V1NLQNqelNpknaLpRlo2nIgb9ovESfc= MIME-Version: 1.0 Received: by 10.182.72.74 with SMTP id b10mr12270981obv.69.1327422058895; Tue, 24 Jan 2012 08:20:58 -0800 (PST) Received: by 10.182.79.102 with HTTP; Tue, 24 Jan 2012 08:20:58 -0800 (PST) In-Reply-To: <083.6853ec8d97dcdb1adcf1dba473d6d65f@trac.tools.ietf.org> References: <068.03e705c774d30abee11ba5026a664a26@trac.tools.ietf.org> <083.6853ec8d97dcdb1adcf1dba473d6d65f@trac.tools.ietf.org> Date: Tue, 24 Jan 2012 11:20:58 -0500 Message-ID: From: Marshall Eubanks To: clue issue tracker Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: draft-ietf-clue-framework@tools.ietf.org, clue@ietf.org Subject: Re: [clue] #7: Is composed attribute a boolean or data structure (was: Is compose attribute a boolean or data structure) X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 16:21:00 -0000 Here is a specific suggestion based on the discussion today : Composition is described by two (or more) booleans, and associated lists First boolean : Is the stream composed of other streams ? Yes, or no. Second boolean : Is this composed stream composed of other streams that the offerer is also offering. Associated List : A list of those streams. This second boolean has no meaning and MUST be ignored if the first boolean is missing or negative. So, suppose there is a 4 screen unit (with streams 1-4), which also offers - Stream 5 : a composition of screens 1 and 2 - Stream 6 : a composition of screens 3 and 4 - Stream 7 : a composition of screens 1, 2, 3 and 4 So, stream 5 might have a pseudocode description like composed=3Dtrue {composed_stream_set=3Dtrue {stream_set=3D"1,2"}} while stream 7 would be composed=3Dtrue {composed_stream_set=3Dtrue {stream_set=3D"1,2,3,4"}} I would strongly suggest that composed streams can be nested (as indeed they are frequently in practice). I would also suggest two "special characters" - call them D =3D=3D "data" and A =3D=3D "active speaker" So, a stream 8 with composed=3Dtrue {composed_stream_set=3Dtrue {stream_set=3D"7, A, D"}} would mean a composed combination of (a composition of all of the true streams) + the screen containing the active speaker + a data screen. It would be useful to allow for virtual streams (i.e., maybe in my example stream "7" only exists inside the unit and is not available to others). That would make description more straightforward. It is not clear to me whether or not virtual streams should have a virtual attribute, or whether or not that can conveyed within the existing framework. Of course, dependency loops MUST be avoided. The "A" attribute would be most useful for middle boxes. If a composition is really coming from a 4 screen unit, then "A" may be at some remote unit, so this would be not so useful. However, if a composition is actually coming from a middle box, then A can be the speaker, and having the attribute would be useful. I believe that this proposal would capture essentially all of the composition use cases that do not require detailed formatting information. Regards Marshall On Mon, Jan 23, 2012 at 5:15 PM, clue issue tracker wrote: > #7: Is composed attribute a boolean or data structure > > > -- > --------------------------------+----------------------------------------= -- > =A0Reporter: =A0mary.ietf.barnes@=85 =A0| =A0 =A0 =A0 Owner: =A0draft-iet= f-clue-framework@=85 > =A0 =A0 Type: =A0defect =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0Status: = =A0new > =A0Priority: =A0major =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 Milestone: > Component: =A0framework =A0 =A0 =A0 =A0 =A0 | =A0 =A0 Version: > =A0Severity: =A0Active WG Document =A0| =A0Resolution: > =A0Keywords: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| > --------------------------------+----------------------------------------= -- > > Ticket URL: > clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From pkyzivat@alum.mit.edu Tue Jan 24 08:46:25 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7186C21F8613 for ; Tue, 24 Jan 2012 08:46:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.616 X-Spam-Level: X-Spam-Status: No, score=-2.616 tagged_above=-999 required=5 tests=[AWL=-0.017, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8vb5fFkXuR8D for ; Tue, 24 Jan 2012 08:46:25 -0800 (PST) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by ietfa.amsl.com (Postfix) with ESMTP id B63DD21F85EC for ; Tue, 24 Jan 2012 08:46:24 -0800 (PST) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta06.westchester.pa.mail.comcast.net with comcast id RR5l1i0041uE5Es56UmR8u; Tue, 24 Jan 2012 16:46:25 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta16.westchester.pa.mail.comcast.net with comcast id RUmQ1i02W07duvL3cUmRwu; Tue, 24 Jan 2012 16:46:25 +0000 Message-ID: <4F1EE05F.3080508@alum.mit.edu> Date: Tue, 24 Jan 2012 11:46:23 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: clue@ietf.org References: <068.03e705c774d30abee11ba5026a664a26@trac.tools.ietf.org> In-Reply-To: <068.03e705c774d30abee11ba5026a664a26@trac.tools.ietf.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] #7: Is compose attribute a boolean or data structure X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 16:46:25 -0000 [resend, tying into the #7 thread] Based on what I have heard, I see the following possibilities: 1) there is no explicit indication of whether streams are composed or not. But still a composed stream will ideally indication the portion of the scene it covers, which would presumably be a union of those for the streams being composed. This could be nasty if that portion isn't a rectangle. (E.g. composition of left and right streams, but not the center screen.) It also is a problem if the streams being composed aren't part of the same scene. In that case it can't really describe the geometry of the composed scene at all. In the case of switching, such as active speaker, presumably the portion of the scene reported would be the union of all the potential speakers. 2) same as (1), but with a boolean indication for composed streams. IMO this doesn't add anything useful. 3) same as (1) but with addition of a free text description of what the stream contains. This isn't of any use for automated selection of streams to receive/display, but at least it can enable a user interface that can allow an end user in the receiving room to manually configure what streams should be displayed. Not ideal, but perhaps still useful for dealing with interop problems. 4) enumeration of the streams that are inputs to the composition of a composed stream. This is independent of the composition algorithm. stream that tiles the input streams would be described the same as one that switches among them. This would require that the streams that go into the composition also be (separately) described. This would be no issue if they are also available for independent selection. But if there are to be cases where the composition is available but the independent streams are not, then this would require more work. 5) description of how the composition is accomplished. It might be time or space multiplexing of the pixels. If time multiplexing, then the algorithm for doing so (active speaker, ...). If space multiplexing, then it could include which region of the composed stream contains each composed stream. There could also be a combination of time and space multiplexing. And this could also be hierarchical, if one or more of the input streams for composition are themselves composed. Thanks, Paul From marshall.eubanks@gmail.com Tue Jan 24 08:59:58 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4546521F860B for ; Tue, 24 Jan 2012 08:59:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.492 X-Spam-Level: X-Spam-Status: No, score=-103.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3vyeqX0v5T8g for ; Tue, 24 Jan 2012 08:59:57 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 362CE21F8602 for ; Tue, 24 Jan 2012 08:59:57 -0800 (PST) Received: by obbwc12 with SMTP id wc12so5496170obb.31 for ; Tue, 24 Jan 2012 08:59:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=kjNLOxmoNhED8A1kOKdDOlh1Wg7cVZtUhYXR6plNmCY=; b=Gk+10bQ9XvrY4rVmcK0d32U78Ph0sS6/7djccAc+W47igpJ+C+1/eEtZ5JO1Rcm5E8 uwPFDCgMfClTdFooLRXyCilSB0Cy9Bu9Rv7iWZB8GN1BJX5t3dBXXKHhKW8xvz0kEei/ XYaV2xgHzgp75w9wa85N39mKfhN39BCID+YvU= MIME-Version: 1.0 Received: by 10.182.47.10 with SMTP id z10mr12495960obm.19.1327424396812; Tue, 24 Jan 2012 08:59:56 -0800 (PST) Received: by 10.182.79.102 with HTTP; Tue, 24 Jan 2012 08:59:56 -0800 (PST) In-Reply-To: <4F1EE05F.3080508@alum.mit.edu> References: <068.03e705c774d30abee11ba5026a664a26@trac.tools.ietf.org> <4F1EE05F.3080508@alum.mit.edu> Date: Tue, 24 Jan 2012 11:59:56 -0500 Message-ID: From: Marshall Eubanks To: Paul Kyzivat Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: clue@ietf.org Subject: Re: [clue] #7: Is compose attribute a boolean or data structure X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 16:59:58 -0000 On Tue, Jan 24, 2012 at 11:46 AM, Paul Kyzivat wrot= e: > [resend, tying into the #7 thread] > > Based on what I have heard, I see the following possibilities: > > 1) there is no explicit indication of whether streams are composed or not= . > But still a composed stream will ideally indication the portion of the sc= ene > it covers, which would presumably be a union of those for the streams bei= ng > composed. This could be nasty if that portion isn't a rectangle. (E.g. > composition of left and right streams, but not the center screen.) It als= o > is a problem if the streams being composed aren't part of the same scene.= In > that case it can't really describe the geometry of the composed scene at > all. In the case of switching, such as active speaker, presumably the > portion of the scene reported would be the union of all the potential > speakers. > I don't like presuming things in this context. > 2) same as (1), but with a boolean indication for composed streams. IMO t= his > doesn't add anything useful. > I agree. > 3) same as (1) but with addition of a free text description of what the > stream contains. This isn't of any use for automated selection of streams= to > receive/display, but at least it can enable a user interface that can all= ow > an end user in the receiving room to manually configure what streams shou= ld > be displayed. Not ideal, but perhaps still useful for dealing with intero= p > problems. I think that text descriptions are both useful and not reliable. Any actual text is worthwhile, but as you cannot rely on it as - it may not be there or - it may not make sense or be relevant or - it may be "canned," from some default or some previous session, and thus not apply to current events. So, sure, allow for this, but it doesn't really solve any problems. > > 4) enumeration of the streams that are inputs to the composition of a > composed stream. This is independent of the composition algorithm. stream > that tiles the input streams would be described the same as one that > switches among them. This would require that the streams that go into the > composition also be (separately) described. This would be no issue if the= y > are also available for independent selection. But if there are to be case= s > where the composition is available but the independent streams are not, t= hen > this would require more work. I am going to paste MY proposal here, as it is for this case Composition is described by two (or more) booleans, and associated lists First boolean : Is the stream composed of other streams ? Yes, or no. Second boolean : Is this composed stream composed of other streams that the offerer is also offering. Associated List : A list of those streams. This second boolean has no meaning and MUST be ignored if the first boolean is missing or negative. So, suppose there is a 4 screen unit (with streams 1-4), which also offers - Stream 5 : a composition of screens 1 and 2 - Stream 6 : a composition of screens 3 and 4 - Stream 7 : a composition of screens 1, 2, 3 and 4 So, stream 5 might have a pseudocode description like composed=3Dtrue {composed_stream_set=3Dtrue {stream_set=3D"1,2"}} while stream 7 would be composed=3Dtrue {composed_stream_set=3Dtrue {stream_set=3D"1,2,3,4"}} I would strongly suggest that composed streams can be nested (as indeed they are frequently in practice). I would also suggest two "special characters" - call them D =3D=3D "data" and A =3D=3D "active speaker" So, a stream 8 with composed=3Dtrue {composed_stream_set=3Dtrue {stream_set=3D"7, A, D"}} would mean a composed combination of (a composition of all of the true streams) + the screen containing the active speaker + a data screen. It would be useful to allow for virtual streams (i.e., maybe in my example stream "7" only exists inside the unit and is not available to others). That would make description more straightforward. It is not clear to me whether or not virtual streams should have a virtual attribute, or whether or not that can conveyed within the existing framework. Of course, dependency loops MUST be avoided. The "A" attribute would be most useful for middle boxes. If a composition is really coming from a 4 screen unit, then "A" may be at some remote unit, so this would be not so useful. However, if a composition is actually coming from a middle box, then A can be the speaker, and having the attribute would be useful. I believe that this proposal would capture essentially all of the composition use cases that do not require detailed formatting information. > > 5) description of how the composition is accomplished. It might be time o= r > space multiplexing of the pixels. If time multiplexing, then the algorith= m > for doing so (active speaker, ...). If space multiplexing, then it could > include which region of the composed stream contains each composed stream= . > There could also be a combination of time and space multiplexing. And thi= s > could also be hierarchical, if one or more of the input streams for > composition are themselves composed. > I frankly think that this is too early, as this parameter space is vast, and we would need to know just what pieces of it to select. Regards Marshall > =A0 =A0 =A0 =A0Thanks, > =A0 =A0 =A0 =A0Paul > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From trac+clue@trac.tools.ietf.org Tue Jan 24 09:54:11 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0188421F861A for ; Tue, 24 Jan 2012 09:54:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VisH2iWYQHQQ for ; Tue, 24 Jan 2012 09:54:10 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 053FB21F8616 for ; Tue, 24 Jan 2012 09:54:08 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RpkZD-0007zW-Jt; Tue, 24 Jan 2012 12:53:59 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "clue issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: even.roni@huawei.com, mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Tue, 24 Jan 2012 17:53:58 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/3#comment:2 Message-ID: <078.4ed0aabff600cef82c3d6a935baff2a4@trac.tools.ietf.org> References: <063.989fef5c8859eb1ed5eaeeaac3cf1759@trac.tools.ietf.org> X-Trac-Ticket-ID: 3 In-Reply-To: <063.989fef5c8859eb1ed5eaeeaac3cf1759@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: even.roni@huawei.com, mary.ietf.barnes@gmail.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: clue@ietf.org Subject: Re: [clue] #3: Use case for an RTCWEB client X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 17:54:11 -0000 #3: Use case for an RTCWEB client Comment (by mary.ietf.barnes@…): Roni's proposal: http://www.ietf.org/mail- archive/web/clue/current/msg00976.html -- ------------------------------------+-------------------------- Reporter: pkyzivat@… | Owner: even.roni@… Type: task | Status: new Priority: major | Milestone: Component: telepresence-use-cases | Version: Severity: Active WG Document | Resolution: Keywords: | ------------------------------------+-------------------------- Ticket URL: clue From trac+clue@trac.tools.ietf.org Tue Jan 24 09:57:35 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB0EC21F865B for ; Tue, 24 Jan 2012 09:57:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cSOjqV8vxVBq for ; Tue, 24 Jan 2012 09:57:35 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 0BD6D21F865A for ; Tue, 24 Jan 2012 09:57:35 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1Rpkca-00081D-2k; Tue, 24 Jan 2012 12:57:28 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "clue issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: pkyzivat@alum.mit.edu, mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Tue, 24 Jan 2012 17:57:28 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/6#comment:2 Message-ID: <078.72d375b76c39675ef12ec54be172fe66@trac.tools.ietf.org> References: <063.a981a21c6f207209c3de907f8f4365d5@trac.tools.ietf.org> X-Trac-Ticket-ID: 6 In-Reply-To: <063.a981a21c6f207209c3de907f8f4365d5@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: pkyzivat@alum.mit.edu, mary.ietf.barnes@gmail.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: clue@ietf.org Subject: Re: [clue] #6: Ensure source selection is in scope of charter X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 17:57:36 -0000 #6: Ensure source selection is in scope of charter Changes (by mary.ietf.barnes@…): * status: new => closed * resolution: => fixed Comment: Chairs believe that source selection is in scope per this snippet of the charter: ...... This working group is chartered to specify the following information about media streams from one entity to another entity: .... - Which sources a receiver wants to receive. For example, it might want the source for the left camera, or might want the source chosen by VAD (Voice Activity Detection) -- ------------------------+------------------------ Reporter: pkyzivat@… | Owner: Paul/Mary Type: task | Status: closed Priority: minor | Milestone: Component: charter | Version: Severity: - | Resolution: fixed Keywords: | ------------------------+------------------------ Ticket URL: clue From stewe@stewe.org Tue Jan 24 16:00:04 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33FC611E80A2 for ; Tue, 24 Jan 2012 16:00:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.395 X-Spam-Level: X-Spam-Status: No, score=-1.395 tagged_above=-999 required=5 tests=[AWL=-0.193, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fAFPOTFYvBpi for ; Tue, 24 Jan 2012 16:00:03 -0800 (PST) Received: from stewe.org (stewe.org [85.214.122.234]) by ietfa.amsl.com (Postfix) with ESMTP id 3BC0F11E809D for ; Tue, 24 Jan 2012 16:00:02 -0800 (PST) Received: from [192.168.1.64] (unverified [71.202.147.60]) by stewe.org (SurgeMail 3.9e) with ESMTP id 16443-1743317 for ; Wed, 25 Jan 2012 01:00:01 +0100 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Tue, 24 Jan 2012 15:59:51 -0800 From: Stephan Wenger To: "clue@ietf.org" Message-ID: Thread-Topic: Something to consider Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3410265601_29932789" X-Originating-IP: 71.202.147.60 X-Authenticated-User: stewe@stewe.org X-ORBS-Stamp: Your IP (71.202.147.60) was found in the spamhaus database. http://www.spamhaus.net Subject: [clue] Something to consider X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 00:00:04 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3410265601_29932789 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi all, Dave Lindbergh made me aware of http://www.3dpresence.org/. It's a research project as of now, but I think we have to ensure that, as the minimum, a possible extension to the CLUE work done now would support such scenarios without great hacks. Regards, Stephan P.s.: my thoughts on composed streams probably tomorrow, or the latest over the weekend. --B_3410265601_29932789 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Hi all,
Dave Lindb= ergh made me aware of http://www.3= dpresence.org/.
It's a research project as of now, but I think= we have to ensure that, as the minimum, a possible extension to the CLUE wo= rk done now would support such scenarios without great hacks.
Rega= rds,
Stephan 

P.s.: my thoughts on c= omposed streams probably tomorrow, or the latest over the weekend.

--B_3410265601_29932789-- From mary.ietf.barnes@gmail.com Wed Jan 25 13:00:50 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C767111E80C4 for ; Wed, 25 Jan 2012 13:00:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.715 X-Spam-Level: X-Spam-Status: No, score=-103.715 tagged_above=-999 required=5 tests=[AWL=-0.116, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AKUZCp-Ou0tA for ; Wed, 25 Jan 2012 13:00:50 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id C609511E80B9 for ; Wed, 25 Jan 2012 13:00:49 -0800 (PST) Received: by vbbfr13 with SMTP id fr13so4295965vbb.31 for ; Wed, 25 Jan 2012 13:00:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=sUQ9KcZlEnquXfTIrUIotxQVGF4RH5GgR7pfo5fdahg=; b=oXkGn9K8d/vfkU9XFhl+3rboHZYXJpai+sHrvvng+l/7BQ7W56fPW7V2G9kW8i1VFR hUmHk7Ovd8owrWW7eX2GQSg9VH0Wp9xqS460UcSKC2q22csHYZ9bHnFi/iJ9hAnm6Vc0 ZpFoKkfMC6RIrdiERg84YiOQOXhxcDKsQ/87s= MIME-Version: 1.0 Received: by 10.52.35.13 with SMTP id d13mr10170917vdj.55.1327525249319; Wed, 25 Jan 2012 13:00:49 -0800 (PST) Received: by 10.52.108.196 with HTTP; Wed, 25 Jan 2012 13:00:49 -0800 (PST) Date: Wed, 25 Jan 2012 15:00:49 -0600 Message-ID: From: Mary Barnes To: CLUE Content-Type: text/plain; charset=ISO-8859-1 Subject: [clue] Minutes: Design Team Meeting - Jan. 24th, 2012 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 21:00:50 -0000 Hi all, Below, please find the minutes from the design team meeting held on Jan 24th, 2012. The minutes are also on the wiki. Thanks to John Leslie and Paul for taking notes. http://trac.tools.ietf.org/wg/clue/trac/wiki/Design-Team I'll send the agenda and Webex details for next Tuesday's call (Jan 31st) by Friday. Regards, Mary. ============================================ CLUE WG Design Team Call January 24th, 2012 Chairs: Mary Barnes, Paul Kyzivat Attendees: Espen Berger Stephane Cazeaux Spencer Dawkins Mark Duckworth Marshall Eubanks Roni Even Tom Kristensen Jonathan Lennox John Leslie Summary: Mary provided an update on the action items from the meeting last week - all of which were completed. The meeting discussion focused on Ticket #7, with the majority supporting the need for additional attributes in the case that the composed boolean is true. Additional WG discussion is required to define the additional attributes to describe the composed stream. Whether a boolean is needed if additional attributes are defined requires further discussion. Summary of action items: - Ticket #3. Update ticket to reflect Roni's email with regards to RTCWEB use case. [Chairs] Provide feedback on proposal. [WG] - Ticket #6. Chairs confirmed that source selection is in the charter, thus this ticket is to be closed. [Chairs] - Ticket #7. Post proposed attributes to the mailing list [Roni and others] Notes by Paul Kyzivat Start Time: 10:00 EST 24-jan-1012 End Time: 10:00 EST 24-jan-1012 Reviewed Active Tickets Agreed #6 is already in charter. Will close it out. Discussed description of composed stream. John Leslie said he thought complexity of describing composed stream to too great to make required. Roni says the issue on the table is whether we should be *able* to describe it. Whether its mandatory is a separate question. Mark asks if the description should be in the initial framework or left for a subsequent revision. Roni says if all we have is a boolean, then it is useless to offer more than one composed stream, because there is no basis to chose between them. Roni to post more info about composition algorithms. We didn't reach any conclusion about how much information should be included. Decision to take it to the list to discuss alternatives. Proposal that people use the remaining 15 minutes of meeting time to email something. Notes by John Leslie Mary Barnes @ 1005 John Leslie volunteered to take notes Mary: Roll Call: Roni, Marshall, Spencer, Stephane; Mary: Tickets: closed 2, opened 7 (want to talk about 7 today); #5 added link to Stephane proposal; #6 believe it is in-charter "which sources the receiver wants to receive", will close that one Mary: talk through issue #7; Roni posted a note to mailing-list, not sure everybody on same page. Spencer: trying to find that post... Mary: go to ticket #2 (link on ticket #7)... post shared... John: complexity of showing details of capture is to great to make it mandatory Roni: I described simple case (typical); question is whether we should address this and specify it; whether it is mandatory is a separate issue Mary: I think we need the boolean anyway Mark: I think Roni is saying we need description in initial version, not a later extension Roni: if we agree info, we should give a way Mary: question whether we can put off describing it to an extension Roni: I'm OK with any way to describe it, but we need some way, otherwise it's useless, I cannot differentiate switching mode Mark: Roni is correct, but he didn't answer Mary's question Roni: we don't have any data structure... Mary: think Roni is saying we shouldn't have a boolean and a later structure Roni: not saying that Mary: why wouldn't that work for you Roni: we need to discuss whether there's a way to describe composed Mark: if you have more than one composed screen, you can't distinguish them... leads people on... leap of faith on what the form of composed is (and how to display) Roni: what you do different is a huge issue... let's say author offers you a "composed" switch... as a consumer you can decide which to take if offered three different screens Mark?: suppose I only have only one screen, is "composed" a better choice? Marshall: you assume somebody put work into the "composed"... leap of faith Spencer: leap of faith may be reasonable for first pass Marshall: I would give more of screen to a "composed", lacking other info Mark: sounds to me as if people are saying there should be more info John: but we don't know what that info is Mark: I could imagine an enumerated cases from Roni's list John: any enumerated list would have to be extensible Marshall: most common case is composed includes some of the others -- that's useful Mark: for endpoint, that's useful, but not for middlebox Marshall: free-text allows end-user to choose Espen: question, extensible to express detail, how it's composed may not be needed... Mary: seems a couple of people perfectly happy with boolean, but perhaps we'd agree on some more info, but I don't hear consensus on what Marshall: free-text next level, list of parts second, geometry is more complex, temporal changes is yet another level, most-active-speaker is a common use case Roni: different switching mechanisms, don't see why enumerated list of modes isn't the right first-case Mary: can you post that to the mailing-list; throw that out and we'll discuss on-list Roni: people have interest in more information, I'll propose something on-list Mary: question of whether boolean is enough... "none" would be one of your enumerated cases Mark: this whole discussion applies to "auto-swithed" which is also a boolean, seems like that's where the enumerated list belongs Roni: disagree... (examples) Mark: auto-swithched was intended to tell nothing about how it's switched Mary: I think we've discussed this one enough on this call, anything else to discuss today 1045 adjourn From allyn@cisco.com Wed Jan 25 14:46:50 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0244F11E80B9 for ; Wed, 25 Jan 2012 14:46:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aQvynsTS8PNT for ; Wed, 25 Jan 2012 14:46:48 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id C44D511E807A for ; Wed, 25 Jan 2012 14:46:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=7004; q=dns/txt; s=iport; t=1327531608; x=1328741208; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=Q76xFDDrPzP9zNVp+W+LEbpYZAC8e3JcLr2GajgiVxw=; b=b4tUU2xso/HLgzgQxllq7aTgRzt6yfovV0KLVasYQY2FOphjcWX8XnBU VoO2VJisn6m6kN4Ee1tEcjzsAWLyFfF4XWRFIIqeSNXwM/SWCAhFYmPJ2 bofK5dDUUYRac48nN1E+KH5HmvA9yMKwa05JCjoAveyUyNq/iC4uniDZZ M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAI6FIE+rRDoH/2dsb2JhbABCgk2reIEFgXIBAQEEEgEJEQNZAgEIDgMEAQELBhcBBgFFCQgBAQQBEggaoTUBnjiJBgUBHwIBFwICBgoDBYJoBQQGCw4aDQQHDxMcAoJOYwSIP59R X-IronPort-AV: E=Sophos;i="4.71,570,1320624000"; d="scan'208,217";a="27164138" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 25 Jan 2012 22:46:48 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q0PMki5w000525; Wed, 25 Jan 2012 22:46:47 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 25 Jan 2012 14:46:46 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCDBB3.37320B49" Date: Wed, 25 Jan 2012 14:46:42 -0800 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC06A962AC@xmb-sjc-221.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] Something to consider Thread-Index: Acza9E6X9oG70ZeSREi5xYmR2pidiQAvhzaQ References: From: "Allyn Romanow (allyn)" To: "Stephan Wenger" , X-OriginalArrivalTime: 25 Jan 2012 22:46:46.0148 (UTC) FILETIME=[375EA440:01CCDBB3] Subject: Re: [clue] Something to consider X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 22:46:50 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCDBB3.37320B49 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Stephan, The Radvision researcher in this project was involved when we first started thinking of a multi-stream standard for telepresence. It's great that they are making good progress. =20 I agree that from a CLUE perspective we need to make sure that it is extensible. I feel it would be premature now to define any specific infrastructure for 3-D. =20 Regards, Allyn =20 From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Stephan Wenger Sent: Tuesday, January 24, 2012 4:00 PM To: clue@ietf.org Subject: [clue] Something to consider =20 Hi all, Dave Lindbergh made me aware of http://www.3dpresence.org/. It's a research project as of now, but I think we have to ensure that, as the minimum, a possible extension to the CLUE work done now would support such scenarios without great hacks. Regards, Stephan=20 =20 P.s.: my thoughts on composed streams probably tomorrow, or the latest over the weekend. =20 ------_=_NextPart_001_01CCDBB3.37320B49 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Stephan,

The Radvision researcher in this project was involved = when we first started thinking of a multi-stream standard for telepresence. = It’s great that they are making good progress.

 

I agree that from a CLUE perspective we need to make sure = that it is extensible. I feel it would be premature now to define any = specific infrastructure for 3-D.

 

Regards,

Allyn

 

From:= clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Stephan Wenger
Sent: Tuesday, January 24, 2012 4:00 PM
To: clue@ietf.org
Subject: [clue] Something to consider

 

Hi all,

Dave Lindbergh made me aware of http://www.3dpresence.org/.<= /o:p>

It's a research project as of now, but I think we have to = ensure that, as the minimum, a possible extension to the CLUE work done now = would support such scenarios without great hacks.

Regards,

Stephan 

 

P.s.: my thoughts on composed streams probably tomorrow, or = the latest over the weekend.

 

------_=_NextPart_001_01CCDBB3.37320B49-- From stewe@stewe.org Sat Jan 28 16:46:02 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87D3521F85C0 for ; Sat, 28 Jan 2012 16:46:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Q81paNdABsW for ; Sat, 28 Jan 2012 16:46:01 -0800 (PST) Received: from stewe.org (stewe.org [85.214.122.234]) by ietfa.amsl.com (Postfix) with ESMTP id A1E1C21F85EF for ; Sat, 28 Jan 2012 16:45:59 -0800 (PST) Received: from [172.17.37.82] (unverified [209.153.208.2]) by stewe.org (SurgeMail 3.9e) with ESMTP id 17653-1743317 for multiple; Sun, 29 Jan 2012 01:45:58 +0100 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Sat, 28 Jan 2012 16:45:51 -0800 From: Stephan Wenger To: "Allyn Romanow (allyn)" , Message-ID: Thread-Topic: [clue] Something to consider In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC06A962AC@xmb-sjc-221.amer.cisco.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3410613957_30091" X-Originating-IP: 209.153.208.2 X-Authenticated-User: stewe@stewe.org Subject: Re: [clue] Something to consider X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2012 00:46:02 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3410613957_30091 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Agreed. Stephan From: "Allyn Romanow (allyn)" Date: Wed, 25 Jan 2012 14:46:42 -0800 To: Stephan Wenger , Subject: RE: [clue] Something to consider Hi Stephan, The Radvision researcher in this project was involved when we first started thinking of a multi-stream standard for telepresence. It=B9s great that they are making good progress. =20 I agree that from a CLUE perspective we need to make sure that it is extensible. I feel it would be premature now to define any specific infrastructure for 3-D. =20 Regards, Allyn =20 From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Stephan Wenger Sent: Tuesday, January 24, 2012 4:00 PM To: clue@ietf.org Subject: [clue] Something to consider =20 Hi all, Dave Lindbergh made me aware of http://www.3dpresence.org/. It's a research project as of now, but I think we have to ensure that, as the minimum, a possible extension to the CLUE work done now would support such scenarios without great hacks. Regards, Stephan=20 =20 P.s.: my thoughts on composed streams probably tomorrow, or the latest over the weekend. =20 --B_3410613957_30091 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
Agreed.
Stephan

From: "Allyn Romanow (= allyn)" <allyn@cisco.com>
Date: Wed, 25 Jan 2012 14:46:42 -0800
= To: Stephan Wenger <stewe@stewe.org>, <clue@ietf.org>
Subject: = RE: [clue] Something to consider

Hi Stephan,

The Radvision researcher in this= project was involved when we first started thinking of a multi-stream standard for telepresence. It̵= 7;s great that they are making good progress.

 

I agree that from a CLUE perspective we need to make sure that it is extensible. I feel it would be premature now to define any specific i= nfrastructure for 3-D.

&nbs= p;

Regards,

Allyn

 

<= p class=3D"MsoNormal">From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf= Of Stephan Wenger
Sent: Tuesday, January 24, 2012 4:00 PM
To: clue@ietf.org
Subject: [clue] Somet= hing to consider

=  

Hi all,

Dave Lindbergh made me aware of = http://www.3dpresence.org/.

It's a research project = as of now, but I think we have to ensure that, as the minimum, a possible extension to the CLUE work done now would support such scenarios without great hacks.

Regards,

Stephan 

 

P.s.: my thoughts on composed streams probably tomorrow, or the latest over the weekend.

 

--B_3410613957_30091-- From ron.even.tlv@gmail.com Mon Jan 30 02:22:15 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1B2221F84B8 for ; Mon, 30 Jan 2012 02:22:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.036 X-Spam-Level: X-Spam-Status: No, score=-3.036 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Y1Q0SYTyKug for ; Mon, 30 Jan 2012 02:22:14 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 729EA21F8668 for ; Mon, 30 Jan 2012 02:22:07 -0800 (PST) Received: by eaai12 with SMTP id i12so744877eaa.31 for ; Mon, 30 Jan 2012 02:22:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; bh=qviZpS67Jr1ySKl623PVk78DmLyaRS42NCBwWMm7JeU=; b=bRX5J/88KqP6CavEmajGEzYgRTrJiyY3QPtv/1xOsK6lVXSsfpOyDpquEvAPQjArG+ 7MvhRVw9mmf/spsGJULDSKdbwDOspW4GGktaSMoesoISFfkI0I/Vwp1wNdzutWrHizzZ Av6xR0y0uaioQfsxdduiDEJoLH3/HdBMcmsiA= Received: by 10.213.113.138 with SMTP id a10mr1128694ebq.25.1327918926578; Mon, 30 Jan 2012 02:22:06 -0800 (PST) Received: from windows8d787f9 ([109.67.208.29]) by mx.google.com with ESMTPS id n56sm70847229eeh.6.2012.01.30.02.22.03 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 30 Jan 2012 02:22:04 -0800 (PST) From: "Roni Even" To: References: <068.03e705c774d30abee11ba5026a664a26@trac.tools.ietf.org> <083.e4945b5c72773c1362efdf7bb0443c4a@trac.tools.ietf.org> In-Reply-To: <083.e4945b5c72773c1362efdf7bb0443c4a@trac.tools.ietf.org> Date: Mon, 30 Jan 2012 12:18:14 +0200 Message-ID: <4f266f4c.d0770e0a.43c6.37fd@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AczaIHX5kbsR/L8BTXmfYvH+6pZxUwFEZeZQ Content-Language: en-us Subject: Re: [clue] #7: Is composed attribute a boolean or data structure X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 10:22:15 -0000 Hi, During the last call I volunteered to provide some input.=20 In current IETF work (XCON, Mediactrl WGs there is a video layout = element) http://tools.ietf.org/html/draft-ietf-mediactrl-mixer-control-package-14#= section-4.2.1.4.2.1 and=20 http://tools.ietf.org/html/draft-ietf-xcon-common-data-model-32#section-4= .2.7 (look at video-layout) I would like first to try to define the term "composed video" since it = looks to me like we have different views here, and provide my initial = view on what should be described. Composed video can describes both the layout and the selection algorithm = for composing the content of the sub-windows in the "mixed" video.=20 The video layout which just describes the geometry of the composed image = and I think that the above references provide good structure to define = this part of the composed video attribute. The other part is the algorithm by which the provider select the content = of each element in the layout. Since the content of each element may = change dynamically by the provider this attribute only address the = static information which is the algorithm and not the current content = (who we see now in each element) which will need to be conveyed also but = probably not using this attribute. Note that the information is valid = for point to point and multipoint so the current content should reflect = the TP end point and the specific VC used from it. The algorithms may be global or per element(or sub-window). The global = algorithms I see are site switch or segment switch. The per element may = be voice activated, round robin (switch every x seconds) and fixed (the = same VC is displayed there (may be changed by some control mechanism) Roni > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf = Of > clue issue tracker > Sent: Tuesday, January 24, 2012 12:43 AM > To: draft-ietf-clue-framework@tools.ietf.org; > mary.ietf.barnes@gmail.com > Cc: clue@ietf.org > Subject: Re: [clue] #7: Is composed attribute a boolean or data > structure >=20 > #7: Is composed attribute a boolean or data structure >=20 > Changes (by mary.ietf.barnes@=E2=80=A6): >=20 > * type: defect =3D> task >=20 >=20 > -- > = --------------------------------+-------------------------------------- > ---- > Reporter: mary.ietf.barnes@=E2=80=A6 | Owner: = draft-ietf-clue- > framework@=E2=80=A6 > Type: task | Status: new > Priority: major | Milestone: > Component: framework | Version: > Severity: Active WG Document | Resolution: > Keywords: | > = --------------------------------+-------------------------------------- > ---- >=20 > Ticket URL: > > clue >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From espeberg@cisco.com Mon Jan 30 06:17:11 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2C2721F85DD for ; Mon, 30 Jan 2012 06:17:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.399 X-Spam-Level: X-Spam-Status: No, score=-9.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_72=0.6, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NoLkjqUyqLWu for ; Mon, 30 Jan 2012 06:17:10 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 259CB21F854D for ; Mon, 30 Jan 2012 06:17:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=espeberg@cisco.com; l=7420; q=dns/txt; s=iport; t=1327933030; x=1329142630; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=Xwq3jPDcIVhJz0EWZoSPNuRtnsvVUUC3RLDjryP6P3g=; b=ZEH0rNErTKwcvUtwDVaZj2ARKBf4JyhbIh1vD/Q6yepTr2GrMwV8OUpv +PbuAd14lh4hhpcHJMcMrs2li134nLJnz8tASUpbyDYsCu6fJOKF5TpmL +ZeB6HcmgRnxXMUxOJ5Rm+95QbV3CfCVa/8GXYNqNZvCpCLTSAIYHnXxy E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAHKlJk+Q/khR/2dsb2JhbABDhQuoWHSBBYFyAQEBBAEBAQ8BEA0ENAYXBAIBCA4DBAEBAwIGBhcBAgICAQEfBh8JCAEBBAESCBqHY5oVAYxhkT2BL4cBBgEHAScDBDwDhDsCAQYLgh4zYwSgH4dN X-IronPort-AV: E=Sophos;i="4.71,592,1320624000"; d="scan'208";a="127998559" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 30 Jan 2012 14:17:07 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q0UEH7Sa030054; Mon, 30 Jan 2012 14:17:07 GMT Received: from xmb-ams-214.cisco.com ([144.254.75.25]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 30 Jan 2012 15:17:07 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Mon, 30 Jan 2012 15:17:06 +0100 Message-ID: <92DF9533227FC14F946C7321074B8C9EE48845@XMB-AMS-214.cisco.com> In-Reply-To: <4f266f4c.d0770e0a.43c6.37fd@mx.google.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] #7: Is composed attribute a boolean or data structure Thread-Index: AczaIHX5kbsR/L8BTXmfYvH+6pZxUwFEZeZQAAYsrwA= References: <068.03e705c774d30abee11ba5026a664a26@trac.tools.ietf.org><083.e4945b5c72773c1362efdf7bb0443c4a@trac.tools.ietf.org> <4f266f4c.d0770e0a.43c6.37fd@mx.google.com> From: "Espen Berger (espeberg)" To: "Roni Even" , X-OriginalArrivalTime: 30 Jan 2012 14:17:07.0732 (UTC) FILETIME=[D9476540:01CCDF59] Subject: Re: [clue] #7: Is composed attribute a boolean or data structure X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 14:17:11 -0000 DQpUbyBoZWxwIHdpdGggdGhlIGRpcmVjdGlvbiBvZiB0aGUgZGlzY3Vzc2lvbnMgSSB0aGluayBp dCdzIHVzZWZ1bCB0byBkaXZpZGUgdGhlIGRpc2N1c3Npb25zIGludG8gdGhyZWUgdXNlIGNhc2Vz IGZvciBjb21wb3NlZCBzdHJlYW1zLiANCiBhKSBIb3cgdG8gZXhwcmVzcyBpZiBhIGNhcHR1cmUg c3RyZWFtIGlzIGNvbXBvc2VkIG9yIG5vdCANCiBiKSBIb3cgdG8gZXhwcmVzcyBsYXlvdXQgY2hv aWNlcz8gKGUuZy4gd2l0aCBhIHZpZGVvLWxheW91dCBlbGVtZW50KSAgDQogYykgSG93IHRvIGV4 cHJlc3Mgd2hhdCdzIGluc2lkZSBhIGNvbXBvc2VkIHN0cmVhbSANCg0KRm9yIHVzZSBjYXNlIGEp IGEgY29tcG9zZWQgYXR0cmlidXRlIHNob3VsZCBiZSBzdWZmaWNpZW50LCB5b3UgZWl0aGVyIGFz ayBmb3IgdGhlIGNvbXBvc2VkIHN0cmVhbSBvciB5b3UgZG8gbm90LiANCkkgYWxzbyBiZWxpZXZl IHRoaXMgc2hvdWxkIGNvdmVyIHRoZSBpbnRlcm9wZXJhYmlsaXR5IHJlcXVpcmVtZW50IHdlIGhh dmUgYWNyb3NzIG11bHRpcGxlIHR5cGVzIG9mIGVuZHBvaW50cy4gDQoNCkZvciB1c2UgY2FzZSBi KSBib3RoIG1lZGlhY3RybCBhbmQgeGNvbiB1c2VzIGEgPHZpZGVvLWxheW91dD4gZWxlbWVudCB0 byBkZXNjcmliZSBwb3NzaWJsZSBsYXlvdXRzIGFuZCBhbHNvIHRvIHJlcXVlc3QgdGhlIHByZWZl cnJlZCBsYXlvdXQgYmFzZWQgb24gb3B0aW9ucy4gKGFzIGRlc2NyaWJlZCBpbiBSb25pJ3MgZW1h aWwpDQoNCkFuIGV4YW1wbGUgY291bGQgYmUgKGluc3BpcmVkIGJ5IG1lZGlhY3RybCBhbmQgeGNv biB1c2FnZSBvZiA8dmlkZW8tbGF5b3V0Pik6IA0KDQpDTFVFIEFkdmVydGlzZW1lbnQNCiAgQ2Fw dHVyZSBpZD0yIFB1cnBvc2U9cGVvcGxlIENvbXBvc2VkPWZhbHNlIA0KICBDYXB0dXJlIGlkPTMg UHVycG9zZT1wZW9wbGUgQ29tcG9zZWQ9ZmFsc2UgDQogIENhcHR1cmUgaWQ9NCBQdXJwb3NlPVBl b3BsZSBDb21wb3NlZD10cnVlICANCiAgICAgIFZpZGVvLWxheW91dD0iJ2F1dG9tYXRpYycsICdk dWFsLXZpZXcnLCAnIHNpbmdsZS12aWV3JyIgIA0KDQpDTFVFIGNvbmZpZ3VyZSAvLyBEZWZhdWx0 IGNvbXBvc2VkIHN0cmVhbSANCiAgQ2FwdHVyZSBpZD00IA0KDQovLyBPciBjb21wb3NlZCBzdHJl YW0gd2l0aCBsYXlvdXQgaGludHMNCiAgIENhcHR1cmUgaWQ9NCBWaWRlby1sYXlvdXQ9J2R1YWwt dmlldycgDQoNClRoZSB2aWRlby1sYXlvdXQgZWxlbWVudCBpcyBhIGxpc3Qgb2Ygc3RyaW5ncyBh bmQgZWFjaCBzdHJpbmcgaXMgYSBsYXlvdXQtaGludCB0aGF0IGNhbiBiZSByZXF1ZXN0ZWQuIFZp ZGVvLWxheW91dCBpcyBvcHRpb25hbC4gQSBsYXlvdXQgaGludHMgYWJvdXQgdGhlIHJlcXVlc3Rl ZCByZW5kZXJpbmcgYW5kIHRoZSBzb3VyY2UgaXMgZnJlZSB0byByZXBsYWNlIGFueSBzdHJlYW0g YXMgbG9uZyBhcyB0aGV5IGZpdCB0aGUgbGF5b3V0Lg0KDQpVc2UgY2FzZSBjKSBpcyBtb3JlIG9w ZW4gaW4gdGhlIHNlbnNlIHRoYXQgd2hhdCB5b3UgYWN0dWFsbHkgcmVjZWl2ZSBpbiBhIGNvbXBv c2VkIHN0cmVhbSBpcyBkZXBlbmRpbmcgb24gc3RhdHVzIG9mIGEgcm9vbSBvciB3aG8gaXMgaW4g YSBNQ1UgY29uZmVyZW5jZS4gRS5nLiBmcm9tIGEgcm9vbSB5b3UgY291bGQgZ2V0IGEgbWl4IG9m IGRpZmZlcmVudCBjYXB0dXJlIHN0cmVhbSByZXByZXNlbnRpbmcgY2FtZXJhcyBhbmQgZnJvbSBh IHRyYW5zY29kaW5nIE1DVSBpdCBjb3VsZCBiZSBkaWZmZXJlbnQgcm9vbSwgZGlmZmVyZW50IGNh bWVyYXMgb3IgYW5vdGhlciBtaXggb2YgcG9zc2libGUgaW5wdXQgdmlkZW8gc3RyZWFtcy4NCg0K SGF2aW5nIHN1cHBvcnQgZm9yIGJvdGggYikgYW5kIGMpIGNvdWxkIGJlIGEgZ29vZCB0ZXN0IGZv ciB0aGUgZXh0ZW5zaWJpbGl0eSBvZiBDTFVFLiBJZiB0aGUgYmFzaXMgb2YgQ0xVRSBvbmx5IGRv ZXMgdXNlIGNhc2UgYSkgdGhlcmUgc2hvdWxkIGJlIHJvb20gdG8gZXh0ZW5kIENMVUUgd2l0aCBz dXBwb3J0IGZvciBiKSBhbmQgYykgYXMgYSBDTFVFICsgbGF5b3V0IGRlc2NyaXB0aW9uIGV4dGVu c2lvbi4gDQoNCkNoZWVycyANCg0KLUVzcGVuIA0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IGNsdWUtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmNsdWUtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJvbmkgRXZlbg0KU2VudDogMzAuIGphbnVhciAyMDEyIDEx OjE4DQpUbzogY2x1ZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtjbHVlXSAjNzogSXMgY29tcG9z ZWQgYXR0cmlidXRlIGEgYm9vbGVhbiBvciBkYXRhIHN0cnVjdHVyZQ0KDQpIaSwNCkR1cmluZyB0 aGUgbGFzdCBjYWxsIEkgdm9sdW50ZWVyZWQgdG8gcHJvdmlkZSBzb21lIGlucHV0LiANCg0KSW4g Y3VycmVudCBJRVRGIHdvcmsgKFhDT04sIE1lZGlhY3RybCBXR3MgdGhlcmUgaXMgYSB2aWRlbyBs YXlvdXQgZWxlbWVudCkNCg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1t ZWRpYWN0cmwtbWl4ZXItY29udHJvbC1wYWNrYWdlLTE0I3NlY3Rpb24tNC4yLjEuNC4yLjENCg0K YW5kIA0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi14Y29uLWNvbW1vbi1k YXRhLW1vZGVsLTMyI3NlY3Rpb24tNC4yLjcgKGxvb2sgYXQgdmlkZW8tbGF5b3V0KQ0KDQpJIHdv dWxkIGxpa2UgZmlyc3QgdG8gdHJ5IHRvIGRlZmluZSB0aGUgdGVybSAiY29tcG9zZWQgdmlkZW8i IHNpbmNlIGl0IGxvb2tzIHRvIG1lIGxpa2Ugd2UgaGF2ZSBkaWZmZXJlbnQgdmlld3MgaGVyZSwg YW5kIHByb3ZpZGUgbXkgaW5pdGlhbCB2aWV3IG9uIHdoYXQgc2hvdWxkIGJlIGRlc2NyaWJlZC4N Cg0KQ29tcG9zZWQgdmlkZW8gY2FuIGRlc2NyaWJlcyBib3RoIHRoZSBsYXlvdXQgYW5kIHRoZSBz ZWxlY3Rpb24gYWxnb3JpdGhtIGZvciBjb21wb3NpbmcgdGhlICBjb250ZW50IG9mIHRoZSBzdWIt d2luZG93cyBpbiB0aGUgIm1peGVkIiB2aWRlby4gDQoNClRoZSB2aWRlbyBsYXlvdXQgd2hpY2gg anVzdCBkZXNjcmliZXMgdGhlIGdlb21ldHJ5IG9mIHRoZSBjb21wb3NlZCBpbWFnZSBhbmQgSSB0 aGluayB0aGF0IHRoZSBhYm92ZSByZWZlcmVuY2VzIHByb3ZpZGUgZ29vZCBzdHJ1Y3R1cmUgdG8g ZGVmaW5lIHRoaXMgcGFydCBvZiB0aGUgY29tcG9zZWQgdmlkZW8gYXR0cmlidXRlLg0KDQpUaGUg b3RoZXIgcGFydCBpcyB0aGUgYWxnb3JpdGhtIGJ5IHdoaWNoIHRoZSBwcm92aWRlciBzZWxlY3Qg dGhlIGNvbnRlbnQgb2YgZWFjaCBlbGVtZW50IGluIHRoZSBsYXlvdXQuIFNpbmNlIHRoZSBjb250 ZW50IG9mIGVhY2ggZWxlbWVudCBtYXkgY2hhbmdlIGR5bmFtaWNhbGx5IGJ5IHRoZSBwcm92aWRl ciB0aGlzIGF0dHJpYnV0ZSBvbmx5IGFkZHJlc3MgdGhlIHN0YXRpYyBpbmZvcm1hdGlvbiB3aGlj aCBpcyB0aGUgYWxnb3JpdGhtIGFuZCBub3QgdGhlIGN1cnJlbnQgY29udGVudCAod2hvIHdlIHNl ZSBub3cgaW4gZWFjaCBlbGVtZW50KSB3aGljaCB3aWxsIG5lZWQgdG8gYmUgY29udmV5ZWQgYWxz byBidXQgcHJvYmFibHkgbm90IHVzaW5nIHRoaXMgYXR0cmlidXRlLiBOb3RlIHRoYXQgdGhlIGlu Zm9ybWF0aW9uIGlzIHZhbGlkIGZvciBwb2ludCB0byBwb2ludCBhbmQgbXVsdGlwb2ludCBzbyB0 aGUgY3VycmVudCBjb250ZW50IHNob3VsZCByZWZsZWN0IHRoZSBUUCBlbmQgcG9pbnQgYW5kIHRo ZSBzcGVjaWZpYyBWQyB1c2VkIGZyb20gaXQuDQoNClRoZSBhbGdvcml0aG1zIG1heSBiZSBnbG9i YWwgb3IgcGVyIGVsZW1lbnQob3Igc3ViLXdpbmRvdykuIFRoZSBnbG9iYWwgYWxnb3JpdGhtcyBJ IHNlZSBhcmUgc2l0ZSBzd2l0Y2ggb3Igc2VnbWVudCBzd2l0Y2guIFRoZSBwZXIgZWxlbWVudCBt YXkgYmUgdm9pY2UgYWN0aXZhdGVkLCByb3VuZCByb2JpbiAoc3dpdGNoIGV2ZXJ5IHggc2Vjb25k cykgYW5kIGZpeGVkICh0aGUgc2FtZSBWQyBpcyBkaXNwbGF5ZWQgdGhlcmUgKG1heSBiZSBjaGFu Z2VkIGJ5IHNvbWUgY29udHJvbCBtZWNoYW5pc20pDQoNCg0KUm9uaQ0KDQo+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGNsdWUtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmNs dWUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mDQo+IGNsdWUgaXNzdWUgdHJhY2tlcg0K PiBTZW50OiBUdWVzZGF5LCBKYW51YXJ5IDI0LCAyMDEyIDEyOjQzIEFNDQo+IFRvOiBkcmFmdC1p ZXRmLWNsdWUtZnJhbWV3b3JrQHRvb2xzLmlldGYub3JnOw0KPiBtYXJ5LmlldGYuYmFybmVzQGdt YWlsLmNvbQ0KPiBDYzogY2x1ZUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW2NsdWVdICM3OiBJ cyBjb21wb3NlZCBhdHRyaWJ1dGUgYSBib29sZWFuIG9yIGRhdGENCj4gc3RydWN0dXJlDQo+IA0K PiAjNzogSXMgY29tcG9zZWQgYXR0cmlidXRlIGEgYm9vbGVhbiBvciBkYXRhIHN0cnVjdHVyZQ0K PiANCj4gQ2hhbmdlcyAoYnkgbWFyeS5pZXRmLmJhcm5lc0DigKYpOg0KPiANCj4gICogdHlwZTog IGRlZmVjdCA9PiB0YXNrDQo+IA0KPiANCj4gLS0NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gLS0tLQ0K PiAgUmVwb3J0ZXI6ICBtYXJ5LmlldGYuYmFybmVzQOKApiAgfCAgICAgICBPd25lcjogIGRyYWZ0 LWlldGYtY2x1ZS0NCj4gZnJhbWV3b3JrQOKApg0KPiAgICAgIFR5cGU6ICB0YXNrICAgICAgICAg ICAgICAgIHwgICAgICBTdGF0dXM6ICBuZXcNCj4gIFByaW9yaXR5OiAgbWFqb3IgICAgICAgICAg ICAgICB8ICAgTWlsZXN0b25lOg0KPiBDb21wb25lbnQ6ICBmcmFtZXdvcmsgICAgICAgICAgIHwg ICAgIFZlcnNpb246DQo+ICBTZXZlcml0eTogIEFjdGl2ZSBXRyBEb2N1bWVudCAgfCAgUmVzb2x1 dGlvbjoNCj4gIEtleXdvcmRzOiAgICAgICAgICAgICAgICAgICAgICB8DQo+IC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQo+IC0tLS0NCj4gDQo+IFRpY2tldCBVUkw6DQo+IDxodHRwOi8vdHJhYy50b29scy5pZXRm Lm9yZy93Zy9jbHVlL3RyYWMvdGlja2V0LzcjY29tbWVudDoyPg0KPiBjbHVlIDxodHRwOi8vdG9v bHMuaWV0Zi5vcmcvd2cvY2x1ZS8+DQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiBjbHVlIG1haWxpbmcgbGlzdA0KPiBjbHVlQGlldGYub3Jn DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2x1ZQ0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KY2x1ZSBtYWlsaW5nIGxp c3QNCmNsdWVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v Y2x1ZQ0K From ron.even.tlv@gmail.com Mon Jan 30 06:42:27 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37CD221F85D4 for ; Mon, 30 Jan 2012 06:42:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.032 X-Spam-Level: X-Spam-Status: No, score=-3.032 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HvVKhDe4F+78 for ; Mon, 30 Jan 2012 06:42:26 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id D1F2D21F84E6 for ; Mon, 30 Jan 2012 06:42:25 -0800 (PST) Received: by eekc1 with SMTP id c1so1414724eek.31 for ; Mon, 30 Jan 2012 06:42:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; bh=l/3B9oNyeEL7EB3dZt/KUYkJ7w0QAuqGpYzhKoJEgeU=; b=U00VB3pA8PzF3TenGFPT6tRsLFc6LhZPSLKq4h2A4R05AnpJZec+mj+EXSa3dxjT25 QDJFkguEzVF16FL04Cf1RSw+yei4J9RKL1cOusGJSpehSQ9dPRRDtm/JzmEuUss+ui0y rRJGO2d4zxE5V+ZHdfCCcYhMq9kwnFo0mX/7A= Received: by 10.14.99.132 with SMTP id x4mr5693887eef.74.1327934544869; Mon, 30 Jan 2012 06:42:24 -0800 (PST) Received: from windows8d787f9 ([109.67.208.29]) by mx.google.com with ESMTPS id n17sm73353921eei.3.2012.01.30.06.42.22 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 30 Jan 2012 06:42:23 -0800 (PST) From: "Roni Even" To: "'Espen Berger \(espeberg\)'" , References: <068.03e705c774d30abee11ba5026a664a26@trac.tools.ietf.org><083.e4945b5c72773c1362efdf7bb0443c4a@trac.tools.ietf.org> <4f266f4c.d0770e0a.43c6.37fd@mx.google.com> <92DF9533227FC14F946C7321074B8C9EE48845@XMB-AMS-214.cisco.com> In-Reply-To: <92DF9533227FC14F946C7321074B8C9EE48845@XMB-AMS-214.cisco.com> Date: Mon, 30 Jan 2012 16:38:32 +0200 Message-ID: <4f26ac4f.11840e0a.6db6.ffff9756@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AczaIHX5kbsR/L8BTXmfYvH+6pZxUwFEZeZQAAYsrwAABFxPgA== Content-Language: en-us Subject: Re: [clue] #7: Is composed attribute a boolean or data structure X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 14:42:27 -0000 Hi Espen, If you will look at the notes from the last call there was a support = that a) is not enough. Having just compose does not address even the use = cases I provided which are also based on the use case draft.=20 I am not sure what you mean by C since what in the composed stream can = be either which VC you see or what is the selection criteria for being = in a composed stream. If you meant the second, my view is that C and = also b should be in the basic framework and not in an extension. Roni Even > -----Original Message----- > From: Espen Berger (espeberg) [mailto:espeberg@cisco.com] > Sent: Monday, January 30, 2012 4:17 PM > To: Roni Even; clue@ietf.org > Subject: RE: [clue] #7: Is composed attribute a boolean or data > structure >=20 >=20 > To help with the direction of the discussions I think it's useful to > divide the discussions into three use cases for composed streams. > a) How to express if a capture stream is composed or not > b) How to express layout choices? (e.g. with a video-layout element) > c) How to express what's inside a composed stream >=20 > For use case a) a composed attribute should be sufficient, you either > ask for the composed stream or you do not. > I also believe this should cover the interoperability requirement we > have across multiple types of endpoints. >=20 > For use case b) both mediactrl and xcon uses a element > to describe possible layouts and also to request the preferred layout > based on options. (as described in Roni's email) >=20 > An example could be (inspired by mediactrl and xcon usage of layout>): >=20 > CLUE Advertisement > Capture id=3D2 Purpose=3Dpeople Composed=3Dfalse > Capture id=3D3 Purpose=3Dpeople Composed=3Dfalse > Capture id=3D4 Purpose=3DPeople Composed=3Dtrue > Video-layout=3D"'automatic', 'dual-view', ' single-view'" >=20 > CLUE configure // Default composed stream > Capture id=3D4 >=20 > // Or composed stream with layout hints > Capture id=3D4 Video-layout=3D'dual-view' >=20 > The video-layout element is a list of strings and each string is a > layout-hint that can be requested. Video-layout is optional. A layout > hints about the requested rendering and the source is free to replace > any stream as long as they fit the layout. >=20 > Use case c) is more open in the sense that what you actually receive = in > a composed stream is depending on status of a room or who is in a MCU > conference. E.g. from a room you could get a mix of different capture > stream representing cameras and from a transcoding MCU it could be > different room, different cameras or another mix of possible input > video streams. >=20 > Having support for both b) and c) could be a good test for the > extensibility of CLUE. If the basis of CLUE only does use case a) = there > should be room to extend CLUE with support for b) and c) as a CLUE + > layout description extension. >=20 > Cheers >=20 > -Espen >=20 >=20 >=20 > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf = Of > Roni Even > Sent: 30. januar 2012 11:18 > To: clue@ietf.org > Subject: Re: [clue] #7: Is composed attribute a boolean or data > structure >=20 > Hi, > During the last call I volunteered to provide some input. >=20 > In current IETF work (XCON, Mediactrl WGs there is a video layout > element) >=20 > http://tools.ietf.org/html/draft-ietf-mediactrl-mixer-control-package- > 14#section-4.2.1.4.2.1 >=20 > and > http://tools.ietf.org/html/draft-ietf-xcon-common-data-model- > 32#section-4.2.7 (look at video-layout) >=20 > I would like first to try to define the term "composed video" since it > looks to me like we have different views here, and provide my initial > view on what should be described. >=20 > Composed video can describes both the layout and the selection > algorithm for composing the content of the sub-windows in the "mixed" > video. >=20 > The video layout which just describes the geometry of the composed > image and I think that the above references provide good structure to > define this part of the composed video attribute. >=20 > The other part is the algorithm by which the provider select the > content of each element in the layout. Since the content of each > element may change dynamically by the provider this attribute only > address the static information which is the algorithm and not the > current content (who we see now in each element) which will need to be > conveyed also but probably not using this attribute. Note that the > information is valid for point to point and multipoint so the current > content should reflect the TP end point and the specific VC used from > it. >=20 > The algorithms may be global or per element(or sub-window). The global > algorithms I see are site switch or segment switch. The per element = may > be voice activated, round robin (switch every x seconds) and fixed = (the > same VC is displayed there (may be changed by some control mechanism) >=20 >=20 > Roni >=20 > > -----Original Message----- > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > > Of clue issue tracker > > Sent: Tuesday, January 24, 2012 12:43 AM > > To: draft-ietf-clue-framework@tools.ietf.org; > > mary.ietf.barnes@gmail.com > > Cc: clue@ietf.org > > Subject: Re: [clue] #7: Is composed attribute a boolean or data > > structure > > > > #7: Is composed attribute a boolean or data structure > > > > Changes (by mary.ietf.barnes@=E2=80=A6): > > > > * type: defect =3D> task > > > > > > -- > > = --------------------------------+------------------------------------ > - > > --------------------------------+- > > ---- > > Reporter: mary.ietf.barnes@=E2=80=A6 | Owner: = draft-ietf-clue- > > framework@=E2=80=A6 > > Type: task | Status: new > > Priority: major | Milestone: > > Component: framework | Version: > > Severity: Active WG Document | Resolution: > > Keywords: | > > = --------------------------------+------------------------------------ > - > > --------------------------------+- > > ---- > > > > Ticket URL: > > > > clue > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From espeberg@cisco.com Mon Jan 30 07:21:03 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06AA321F85FD for ; Mon, 30 Jan 2012 07:21:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.699 X-Spam-Level: X-Spam-Status: No, score=-9.699 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NY+FV1Hmmkpn for ; Mon, 30 Jan 2012 07:21:01 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 1DEF621F85F8 for ; Mon, 30 Jan 2012 07:20:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=espeberg@cisco.com; l=10124; q=dns/txt; s=iport; t=1327936860; x=1329146460; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=Xv0dvFpsiKJanTKf6WboctdjawBvMmCS4unnuWRWXfo=; b=aafXwt11iBUUt6D7GesRd2oBRGIldXgf62JqSRO+h3uFXZ2NWbFtW1a/ QAvalnlfvKwJoVK5bNClR8LhZgz8djbc+DOw8aQvsvp8nKordWUlSCJJ7 9e3adU8Fv819vUpDao3Q2K6q+JfGioVj1QOV+R5Qny3oI4QQIipWXCe0q g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAPm0Jk+Q/khN/2dsb2JhbABDhQuoWHSBBYFyAQEBBAEBAQ8BEA0ENAYXBAIBCA4DBAEBAwIGBhcBAgICAQEfBh8JCAEBBAESCBqHY5oOAYxhkUSBL4cBDgEnAwQ8A4Q7AgEGC4IeM2MEoB+HTQ X-IronPort-AV: E=Sophos;i="4.71,592,1320624000"; d="scan'208";a="64951778" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 30 Jan 2012 15:20:58 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q0UFKwIc030517; Mon, 30 Jan 2012 15:20:58 GMT Received: from xmb-ams-214.cisco.com ([144.254.75.25]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 30 Jan 2012 16:20:59 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Mon, 30 Jan 2012 16:20:58 +0100 Message-ID: <92DF9533227FC14F946C7321074B8C9EE48877@XMB-AMS-214.cisco.com> In-Reply-To: <4f26ac4f.11840e0a.6db6.ffff9756@mx.google.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] #7: Is composed attribute a boolean or data structure Thread-Index: AczaIHX5kbsR/L8BTXmfYvH+6pZxUwFEZeZQAAYsrwAABFxPgAABDkxw References: <068.03e705c774d30abee11ba5026a664a26@trac.tools.ietf.org><083.e4945b5c72773c1362efdf7bb0443c4a@trac.tools.ietf.org> <4f266f4c.d0770e0a.43c6.37fd@mx.google.com> <92DF9533227FC14F946C7321074B8C9EE48845@XMB-AMS-214.cisco.com> <4f26ac4f.11840e0a.6db6.ffff9756@mx.google.com> From: "Espen Berger (espeberg)" To: "Roni Even" , X-OriginalArrivalTime: 30 Jan 2012 15:20:59.0056 (UTC) FILETIME=[C4ED0B00:01CCDF62] Subject: Re: [clue] #7: Is composed attribute a boolean or data structure X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 15:21:03 -0000 SGkgUm9uaSANCg0KSWYgeW914oCZcmUgYSBwYXJ0aWN1bGFyIHVzZSBjYXNlcyByZXF1aXJlcyBj b250cm9sIG92ZXIgdGhlIGNvbXBvc2VkIGxheW91dHMgeW91IG5lZWQgYSkgYW5kIGIpLiBJbiBt eSBleGFtcGxlIEkgdXNlZCBhIHNpbmdsZSBhZHZlcnRpc2VtZW50IGNvbXBvc2VkIHN0cmVhbSB3 aXRoIG9wdGlvbmFsIG1ldGEtaW5mb3JtYXRpb24gYWJvdXQgcG9zc2libGUgbGF5b3V0IGNob2lj ZXMuIEEgcmVjZWl2ZXIgdGhhdCB3YW50cyB0aGUgZGVmYXVsdCBjb21wb3NlZCBsYXlvdXQgY2Fu IHJlcXVlc3QgdGhlIGNvbXBvc2VkIHN0cmVhbSBhbmQgc2tpcCB0aGUgb3B0aW9uYWwgdmlkZW8t bGF5b3V0IGluZm9ybWF0aW9uLiBPcHRpb25hbGx5IHlvdSBjb3VsZCByZXF1ZXN0IHRoZSBzYW1l IGNvbXBvc2VkIHN0cmVhbSB3aXRoIGxheW91dHMgaGludHMgZm9yIHRoZSByZWNlaXZlci4gDQoN CkZvciBtZSB1c2UgY2FzZSBjKSBkb2VzIG5vdCBpbmNsdWRlIHRoZSBzZWxlY3Rpb24gbWVjaGFu aXNtcywgb25seSB0aGUgY29udGVudCB5b3Ugc2VlIGluIHRoZSB2aWRlbyBzdHJlYW0uIA0KDQpD aGVlcnMgDQoNCi1Fc3BlbiANCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFJv bmkgRXZlbiBbbWFpbHRvOnJvbi5ldmVuLnRsdkBnbWFpbC5jb21dIA0KU2VudDogMzAuIGphbnVh ciAyMDEyIDE1OjM5DQpUbzogRXNwZW4gQmVyZ2VyIChlc3BlYmVyZyk7IGNsdWVAaWV0Zi5vcmcN ClN1YmplY3Q6IFJFOiBbY2x1ZV0gIzc6IElzIGNvbXBvc2VkIGF0dHJpYnV0ZSBhIGJvb2xlYW4g b3IgZGF0YSBzdHJ1Y3R1cmUNCg0KSGkgRXNwZW4sDQpJZiB5b3Ugd2lsbCBsb29rIGF0IHRoZSBu b3RlcyBmcm9tIHRoZSBsYXN0IGNhbGwgdGhlcmUgd2FzIGEgc3VwcG9ydCB0aGF0IGEpIGlzIG5v dCBlbm91Z2guIEhhdmluZyBqdXN0IGNvbXBvc2UgZG9lcyBub3QgYWRkcmVzcyBldmVuIHRoZSB1 c2UgY2FzZXMgSSBwcm92aWRlZCB3aGljaCBhcmUgYWxzbyBiYXNlZCBvbiB0aGUgdXNlIGNhc2Ug ZHJhZnQuIA0KDQoNCkkgYW0gbm90IHN1cmUgd2hhdCB5b3UgbWVhbiBieSBDIHNpbmNlIHdoYXQg aW4gdGhlIGNvbXBvc2VkIHN0cmVhbSBjYW4gYmUgZWl0aGVyIHdoaWNoIFZDIHlvdSBzZWUgb3Ig d2hhdCBpcyB0aGUgc2VsZWN0aW9uIGNyaXRlcmlhIGZvciBiZWluZyBpbiBhIGNvbXBvc2VkIHN0 cmVhbS4gSWYgeW91IG1lYW50IHRoZSBzZWNvbmQsIG15IHZpZXcgaXMgdGhhdCBDIGFuZCBhbHNv IGIgc2hvdWxkIGJlIGluIHRoZSBiYXNpYyBmcmFtZXdvcmsgYW5kIG5vdCBpbiBhbiBleHRlbnNp b24uDQoNClJvbmkgRXZlbg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206 IEVzcGVuIEJlcmdlciAoZXNwZWJlcmcpIFttYWlsdG86ZXNwZWJlcmdAY2lzY28uY29tXQ0KPiBT ZW50OiBNb25kYXksIEphbnVhcnkgMzAsIDIwMTIgNDoxNyBQTQ0KPiBUbzogUm9uaSBFdmVuOyBj bHVlQGlldGYub3JnDQo+IFN1YmplY3Q6IFJFOiBbY2x1ZV0gIzc6IElzIGNvbXBvc2VkIGF0dHJp YnV0ZSBhIGJvb2xlYW4gb3IgZGF0YQ0KPiBzdHJ1Y3R1cmUNCj4gDQo+IA0KPiBUbyBoZWxwIHdp dGggdGhlIGRpcmVjdGlvbiBvZiB0aGUgZGlzY3Vzc2lvbnMgSSB0aGluayBpdCdzIHVzZWZ1bCB0 bw0KPiBkaXZpZGUgdGhlIGRpc2N1c3Npb25zIGludG8gdGhyZWUgdXNlIGNhc2VzIGZvciBjb21w b3NlZCBzdHJlYW1zLg0KPiAgYSkgSG93IHRvIGV4cHJlc3MgaWYgYSBjYXB0dXJlIHN0cmVhbSBp cyBjb21wb3NlZCBvciBub3QNCj4gIGIpIEhvdyB0byBleHByZXNzIGxheW91dCBjaG9pY2VzPyAo ZS5nLiB3aXRoIGEgdmlkZW8tbGF5b3V0IGVsZW1lbnQpDQo+ICBjKSBIb3cgdG8gZXhwcmVzcyB3 aGF0J3MgaW5zaWRlIGEgY29tcG9zZWQgc3RyZWFtDQo+IA0KPiBGb3IgdXNlIGNhc2UgYSkgYSBj b21wb3NlZCBhdHRyaWJ1dGUgc2hvdWxkIGJlIHN1ZmZpY2llbnQsIHlvdSBlaXRoZXINCj4gYXNr IGZvciB0aGUgY29tcG9zZWQgc3RyZWFtIG9yIHlvdSBkbyBub3QuDQo+IEkgYWxzbyBiZWxpZXZl IHRoaXMgc2hvdWxkIGNvdmVyIHRoZSBpbnRlcm9wZXJhYmlsaXR5IHJlcXVpcmVtZW50IHdlDQo+ IGhhdmUgYWNyb3NzIG11bHRpcGxlIHR5cGVzIG9mIGVuZHBvaW50cy4NCj4gDQo+IEZvciB1c2Ug Y2FzZSBiKSBib3RoIG1lZGlhY3RybCBhbmQgeGNvbiB1c2VzIGEgPHZpZGVvLWxheW91dD4gZWxl bWVudA0KPiB0byBkZXNjcmliZSBwb3NzaWJsZSBsYXlvdXRzIGFuZCBhbHNvIHRvIHJlcXVlc3Qg dGhlIHByZWZlcnJlZCBsYXlvdXQNCj4gYmFzZWQgb24gb3B0aW9ucy4gKGFzIGRlc2NyaWJlZCBp biBSb25pJ3MgZW1haWwpDQo+IA0KPiBBbiBleGFtcGxlIGNvdWxkIGJlIChpbnNwaXJlZCBieSBt ZWRpYWN0cmwgYW5kIHhjb24gdXNhZ2Ugb2YgPHZpZGVvLQ0KPiBsYXlvdXQ+KToNCj4gDQo+IENM VUUgQWR2ZXJ0aXNlbWVudA0KPiAgIENhcHR1cmUgaWQ9MiBQdXJwb3NlPXBlb3BsZSBDb21wb3Nl ZD1mYWxzZQ0KPiAgIENhcHR1cmUgaWQ9MyBQdXJwb3NlPXBlb3BsZSBDb21wb3NlZD1mYWxzZQ0K PiAgIENhcHR1cmUgaWQ9NCBQdXJwb3NlPVBlb3BsZSBDb21wb3NlZD10cnVlDQo+ICAgICAgIFZp ZGVvLWxheW91dD0iJ2F1dG9tYXRpYycsICdkdWFsLXZpZXcnLCAnIHNpbmdsZS12aWV3JyINCj4g DQo+IENMVUUgY29uZmlndXJlIC8vIERlZmF1bHQgY29tcG9zZWQgc3RyZWFtDQo+ICAgQ2FwdHVy ZSBpZD00DQo+IA0KPiAvLyBPciBjb21wb3NlZCBzdHJlYW0gd2l0aCBsYXlvdXQgaGludHMNCj4g ICAgQ2FwdHVyZSBpZD00IFZpZGVvLWxheW91dD0nZHVhbC12aWV3Jw0KPiANCj4gVGhlIHZpZGVv LWxheW91dCBlbGVtZW50IGlzIGEgbGlzdCBvZiBzdHJpbmdzIGFuZCBlYWNoIHN0cmluZyBpcyBh DQo+IGxheW91dC1oaW50IHRoYXQgY2FuIGJlIHJlcXVlc3RlZC4gVmlkZW8tbGF5b3V0IGlzIG9w dGlvbmFsLiBBIGxheW91dA0KPiBoaW50cyBhYm91dCB0aGUgcmVxdWVzdGVkIHJlbmRlcmluZyBh bmQgdGhlIHNvdXJjZSBpcyBmcmVlIHRvIHJlcGxhY2UNCj4gYW55IHN0cmVhbSBhcyBsb25nIGFz IHRoZXkgZml0IHRoZSBsYXlvdXQuDQo+IA0KPiBVc2UgY2FzZSBjKSBpcyBtb3JlIG9wZW4gaW4g dGhlIHNlbnNlIHRoYXQgd2hhdCB5b3UgYWN0dWFsbHkgcmVjZWl2ZSBpbg0KPiBhIGNvbXBvc2Vk IHN0cmVhbSBpcyBkZXBlbmRpbmcgb24gc3RhdHVzIG9mIGEgcm9vbSBvciB3aG8gaXMgaW4gYSBN Q1UNCj4gY29uZmVyZW5jZS4gRS5nLiBmcm9tIGEgcm9vbSB5b3UgY291bGQgZ2V0IGEgbWl4IG9m IGRpZmZlcmVudCBjYXB0dXJlDQo+IHN0cmVhbSByZXByZXNlbnRpbmcgY2FtZXJhcyBhbmQgZnJv bSBhIHRyYW5zY29kaW5nIE1DVSBpdCBjb3VsZCBiZQ0KPiBkaWZmZXJlbnQgcm9vbSwgZGlmZmVy ZW50IGNhbWVyYXMgb3IgYW5vdGhlciBtaXggb2YgcG9zc2libGUgaW5wdXQNCj4gdmlkZW8gc3Ry ZWFtcy4NCj4gDQo+IEhhdmluZyBzdXBwb3J0IGZvciBib3RoIGIpIGFuZCBjKSBjb3VsZCBiZSBh IGdvb2QgdGVzdCBmb3IgdGhlDQo+IGV4dGVuc2liaWxpdHkgb2YgQ0xVRS4gSWYgdGhlIGJhc2lz IG9mIENMVUUgb25seSBkb2VzIHVzZSBjYXNlIGEpIHRoZXJlDQo+IHNob3VsZCBiZSByb29tIHRv IGV4dGVuZCBDTFVFIHdpdGggc3VwcG9ydCBmb3IgYikgYW5kIGMpIGFzIGEgQ0xVRSArDQo+IGxh eW91dCBkZXNjcmlwdGlvbiBleHRlbnNpb24uDQo+IA0KPiBDaGVlcnMNCj4gDQo+IC1Fc3Blbg0K PiANCj4gDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBjbHVlLWJv dW5jZXNAaWV0Zi5vcmcgW21haWx0bzpjbHVlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP Zg0KPiBSb25pIEV2ZW4NCj4gU2VudDogMzAuIGphbnVhciAyMDEyIDExOjE4DQo+IFRvOiBjbHVl QGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbY2x1ZV0gIzc6IElzIGNvbXBvc2VkIGF0dHJpYnV0 ZSBhIGJvb2xlYW4gb3IgZGF0YQ0KPiBzdHJ1Y3R1cmUNCj4gDQo+IEhpLA0KPiBEdXJpbmcgdGhl IGxhc3QgY2FsbCBJIHZvbHVudGVlcmVkIHRvIHByb3ZpZGUgc29tZSBpbnB1dC4NCj4gDQo+IElu IGN1cnJlbnQgSUVURiB3b3JrIChYQ09OLCBNZWRpYWN0cmwgV0dzIHRoZXJlIGlzIGEgdmlkZW8g bGF5b3V0DQo+IGVsZW1lbnQpDQo+IA0KPiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLW1lZGlhY3RybC1taXhlci1jb250cm9sLXBhY2thZ2UtDQo+IDE0I3NlY3Rpb24tNC4y LjEuNC4yLjENCj4gDQo+IGFuZA0KPiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLXhjb24tY29tbW9uLWRhdGEtbW9kZWwtDQo+IDMyI3NlY3Rpb24tNC4yLjcgKGxvb2sgYXQg dmlkZW8tbGF5b3V0KQ0KPiANCj4gSSB3b3VsZCBsaWtlIGZpcnN0IHRvIHRyeSB0byBkZWZpbmUg dGhlIHRlcm0gImNvbXBvc2VkIHZpZGVvIiBzaW5jZSBpdA0KPiBsb29rcyB0byBtZSBsaWtlIHdl IGhhdmUgZGlmZmVyZW50IHZpZXdzIGhlcmUsIGFuZCBwcm92aWRlIG15IGluaXRpYWwNCj4gdmll dyBvbiB3aGF0IHNob3VsZCBiZSBkZXNjcmliZWQuDQo+IA0KPiBDb21wb3NlZCB2aWRlbyBjYW4g ZGVzY3JpYmVzIGJvdGggdGhlIGxheW91dCBhbmQgdGhlIHNlbGVjdGlvbg0KPiBhbGdvcml0aG0g Zm9yIGNvbXBvc2luZyB0aGUgIGNvbnRlbnQgb2YgdGhlIHN1Yi13aW5kb3dzIGluIHRoZSAibWl4 ZWQiDQo+IHZpZGVvLg0KPiANCj4gVGhlIHZpZGVvIGxheW91dCB3aGljaCBqdXN0IGRlc2NyaWJl cyB0aGUgZ2VvbWV0cnkgb2YgdGhlIGNvbXBvc2VkDQo+IGltYWdlIGFuZCBJIHRoaW5rIHRoYXQg dGhlIGFib3ZlIHJlZmVyZW5jZXMgcHJvdmlkZSBnb29kIHN0cnVjdHVyZSB0bw0KPiBkZWZpbmUg dGhpcyBwYXJ0IG9mIHRoZSBjb21wb3NlZCB2aWRlbyBhdHRyaWJ1dGUuDQo+IA0KPiBUaGUgb3Ro ZXIgcGFydCBpcyB0aGUgYWxnb3JpdGhtIGJ5IHdoaWNoIHRoZSBwcm92aWRlciBzZWxlY3QgdGhl DQo+IGNvbnRlbnQgb2YgZWFjaCBlbGVtZW50IGluIHRoZSBsYXlvdXQuIFNpbmNlIHRoZSBjb250 ZW50IG9mIGVhY2gNCj4gZWxlbWVudCBtYXkgY2hhbmdlIGR5bmFtaWNhbGx5IGJ5IHRoZSBwcm92 aWRlciB0aGlzIGF0dHJpYnV0ZSBvbmx5DQo+IGFkZHJlc3MgdGhlIHN0YXRpYyBpbmZvcm1hdGlv biB3aGljaCBpcyB0aGUgYWxnb3JpdGhtIGFuZCBub3QgdGhlDQo+IGN1cnJlbnQgY29udGVudCAo d2hvIHdlIHNlZSBub3cgaW4gZWFjaCBlbGVtZW50KSB3aGljaCB3aWxsIG5lZWQgdG8gYmUNCj4g Y29udmV5ZWQgYWxzbyBidXQgcHJvYmFibHkgbm90IHVzaW5nIHRoaXMgYXR0cmlidXRlLiBOb3Rl IHRoYXQgdGhlDQo+IGluZm9ybWF0aW9uIGlzIHZhbGlkIGZvciBwb2ludCB0byBwb2ludCBhbmQg bXVsdGlwb2ludCBzbyB0aGUgY3VycmVudA0KPiBjb250ZW50IHNob3VsZCByZWZsZWN0IHRoZSBU UCBlbmQgcG9pbnQgYW5kIHRoZSBzcGVjaWZpYyBWQyB1c2VkIGZyb20NCj4gaXQuDQo+IA0KPiBU aGUgYWxnb3JpdGhtcyBtYXkgYmUgZ2xvYmFsIG9yIHBlciBlbGVtZW50KG9yIHN1Yi13aW5kb3cp LiBUaGUgZ2xvYmFsDQo+IGFsZ29yaXRobXMgSSBzZWUgYXJlIHNpdGUgc3dpdGNoIG9yIHNlZ21l bnQgc3dpdGNoLiBUaGUgcGVyIGVsZW1lbnQgbWF5DQo+IGJlIHZvaWNlIGFjdGl2YXRlZCwgcm91 bmQgcm9iaW4gKHN3aXRjaCBldmVyeSB4IHNlY29uZHMpIGFuZCBmaXhlZCAodGhlDQo+IHNhbWUg VkMgaXMgZGlzcGxheWVkIHRoZXJlIChtYXkgYmUgY2hhbmdlZCBieSBzb21lIGNvbnRyb2wgbWVj aGFuaXNtKQ0KPiANCj4gDQo+IFJvbmkNCj4gDQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4gPiBGcm9tOiBjbHVlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpjbHVlLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZg0KPiA+IE9mIGNsdWUgaXNzdWUgdHJhY2tlcg0KPiA+IFNlbnQ6 IFR1ZXNkYXksIEphbnVhcnkgMjQsIDIwMTIgMTI6NDMgQU0NCj4gPiBUbzogZHJhZnQtaWV0Zi1j bHVlLWZyYW1ld29ya0B0b29scy5pZXRmLm9yZzsNCj4gPiBtYXJ5LmlldGYuYmFybmVzQGdtYWls LmNvbQ0KPiA+IENjOiBjbHVlQGlldGYub3JnDQo+ID4gU3ViamVjdDogUmU6IFtjbHVlXSAjNzog SXMgY29tcG9zZWQgYXR0cmlidXRlIGEgYm9vbGVhbiBvciBkYXRhDQo+ID4gc3RydWN0dXJlDQo+ ID4NCj4gPiAjNzogSXMgY29tcG9zZWQgYXR0cmlidXRlIGEgYm9vbGVhbiBvciBkYXRhIHN0cnVj dHVyZQ0KPiA+DQo+ID4gQ2hhbmdlcyAoYnkgbWFyeS5pZXRmLmJhcm5lc0DigKYpOg0KPiA+DQo+ ID4gICogdHlwZTogIGRlZmVjdCA9PiB0YXNrDQo+ID4NCj4gPg0KPiA+IC0tDQo+ID4gLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQo+IC0NCj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstDQo+ID4g LS0tLQ0KPiA+ICBSZXBvcnRlcjogIG1hcnkuaWV0Zi5iYXJuZXNA4oCmICB8ICAgICAgIE93bmVy OiAgZHJhZnQtaWV0Zi1jbHVlLQ0KPiA+IGZyYW1ld29ya0DigKYNCj4gPiAgICAgIFR5cGU6ICB0 YXNrICAgICAgICAgICAgICAgIHwgICAgICBTdGF0dXM6ICBuZXcNCj4gPiAgUHJpb3JpdHk6ICBt YWpvciAgICAgICAgICAgICAgIHwgICBNaWxlc3RvbmU6DQo+ID4gQ29tcG9uZW50OiAgZnJhbWV3 b3JrICAgICAgICAgICB8ICAgICBWZXJzaW9uOg0KPiA+ICBTZXZlcml0eTogIEFjdGl2ZSBXRyBE b2N1bWVudCAgfCAgUmVzb2x1dGlvbjoNCj4gPiAgS2V5d29yZHM6ICAgICAgICAgICAgICAgICAg ICAgIHwNCj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gLQ0KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tKy0NCj4gPiAtLS0tDQo+ID4NCj4gPiBUaWNrZXQgVVJMOg0KPiA+IDxodHRwOi8v dHJhYy50b29scy5pZXRmLm9yZy93Zy9jbHVlL3RyYWMvdGlja2V0LzcjY29tbWVudDoyPg0KPiA+ IGNsdWUgPGh0dHA6Ly90b29scy5pZXRmLm9yZy93Zy9jbHVlLz4NCj4gPg0KPiA+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gY2x1ZSBtYWlsaW5n IGxpc3QNCj4gPiBjbHVlQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9jbHVlDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiBjbHVlIG1haWxpbmcgbGlzdA0KPiBjbHVlQGlldGYub3JnDQo+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2x1ZQ0KDQo= From mary.ietf.barnes@gmail.com Mon Jan 30 09:01:14 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 514A721F85A5 for ; Mon, 30 Jan 2012 09:01:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.647 X-Spam-Level: X-Spam-Status: No, score=-103.647 tagged_above=-999 required=5 tests=[AWL=-0.049, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y3lg7PDmSgBi for ; Mon, 30 Jan 2012 09:01:12 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 454F321F84F8 for ; Mon, 30 Jan 2012 09:01:12 -0800 (PST) Received: by vbbfr13 with SMTP id fr13so3142559vbb.31 for ; Mon, 30 Jan 2012 09:01:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=k/RhBHla+CdEFXWmQyD05i73oJm3GfJICG/RVHTwbWU=; b=O0RAuto2EHIBkL+QWYCQIcPvnmjupTs1k7Br/0tl6TKJ3lIwHoNJWG19LX/z1jTD0z FvnM/J0rR8QqRINd+eSZi+UqCYhtpa7pmap5DrsOvZiMFBCXz4suoi4wpAFdFUEsyzqG ljKDF4LjBUNqpgfkFhOJZHNHpN+afauxwE7oI= MIME-Version: 1.0 Received: by 10.52.35.13 with SMTP id d13mr8411612vdj.55.1327942870417; Mon, 30 Jan 2012 09:01:10 -0800 (PST) Received: by 10.52.108.196 with HTTP; Mon, 30 Jan 2012 09:01:10 -0800 (PST) Date: Mon, 30 Jan 2012 11:01:10 -0600 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/mixed; boundary=20cf307cfc6012bf4904b7c1cb8d Subject: [clue] CLUE WG Design Team Meeting - Jan. 31st X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 17:01:14 -0000 --20cf307cfc6012bf4904b7c1cb8d Content-Type: multipart/alternative; boundary=20cf307cfc6012bf4604b7c1cb8b --20cf307cfc6012bf4604b7c1cb8b Content-Type: text/plain; charset=ISO-8859-1 Hi all, Below, please find the details for this week's call. I propose that we discuss issue A.5 - (VAD (voice activity detection) tagging of audio streams) from the framework, which should also include some general discussion on audio handling. Regards, Mary and Paul. Note: I seem to have somehow set this up as a web seminar so there are two different links for joining. I think both will work, although one (attendee) may default you to being muted when you join. ** ** *From:* messenger@webex.com [mailto:messenger@webex.com] *Sent:* Friday, January 27, 2012 3:57 PM *To:* clue-chairs@tools.ietf.org *Subject:* Web seminar scheduled: CLUE WG Design Team**** ** ** **** Hello Clue Working Group, You scheduled the following Web seminar using WebEx. Topic: CLUE WG Design Team Date and Time: Tuesday, January 31, 2012 9:00 am, Central Standard Time (Chicago, GMT-06:00) Event number: 643 438 143 Event password: 1234 Event address for attendees: https://ietf.webex.com/ietf/onstage/g.php?d=643438143&t=a Event address for panelists: https://ietf.webex.com/ietf/onstage/g.php?d=643438143&t=p ------------------------------------------------------- To start the online event ------------------------------------------------------- At least 30 minutes before the starting time: 1. Go to https://ietf.webex.com/ietf/onstage/g.php?d=643438143&t=h 2. Log in to your host account if you have not yet done so. 3. On the Event Information page that appears, click "Start Now". ------------------------------------------------------- Teleconference information ------------------------------------------------------- Call-in toll number (US/Canada): +1-408-600-3600 Access code: 643 438 143 http://www.webex.com IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. You should inform all meeting attendees prior to recording if you intend to record the meeting. Please note that any such recordings may be subject to discovery in the event of litigation. **** **** --20cf307cfc6012bf4604b7c1cb8b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,=A0

Below, please find the details for this week&= #39;s call. =A0I propose that we discuss issue A.5 - (VAD (voice activity detection) tagging of audio streams) from= the framework, which should also include some general discussion on audio = handling.

Regards,
Mary and Paul.

Not= e: I seem to have somehow set this up as a web seminar so there are two dif= ferent links for joining. =A0I think both will work, although one (attendee= ) may default you to being muted when you join.

=A0=

From: messenger@webex.= com [mailto:me= ssenger@webex.com]
Sent: Friday, January 27, 2012 3:57 PM

<= br>To: clue-chairs@tools.ietf.org
Subject: Web seminar scheduled:= CLUE WG Design Team

=A0


Hello Clue Working Group,

Y= ou scheduled the following Web seminar using WebEx.

Topic: CLUE WG Design Team
Date and Time:
Tuesday, January 31, 20= 12 9:00 am, Central Standard Time (Chicago, GMT-06:00)
Event numbe= r: 643 438 143

Event password: 1234

Event address for attendees: https://ietf.we= bex.com/ietf/onstage/g.php?d=3D643438143&t=3Da
Event address for= panelists: https://ietf.webex.com/ietf/onstage/g.php?= d=3D643438143&t=3Dp


-------------------------------------------------------
To start= the online event
------------------------------------------------------= -
At least 30 minutes before the starting time:

1. Go to https://ietf.webex.com/ietf/onstage/g.php?d=3D643438143&= amp;t=3Dh
2. Log in to your host account if you have not yet done s= o.
3. On the Event Information page that appears, click "Start Now&= quot;.

-------------------------------------------------------
Teleconference information
---------------------------------------------= ----------
Call-in toll number (US/Canada): +1-408-600-3600
Access code: 643 438 143


http://www.webex= .com

IMPORTANT NOTICE: This WebEx service includes a feature tha= t allows audio and any documents and other materials exchanged or viewed du= ring the session to be recorded. You should inform all meeting attendees pr= ior to recording if you intend to record the meeting. Please note that any = such recordings may be subject to discovery in the event of litigation.


<= img border=3D"0" src=3D"https://ietf.webex.com/adm0306ld/siteadmin/html/img= /footer.gif">


--20cf307cfc6012bf4604b7c1cb8b-- --20cf307cfc6012bf4904b7c1cb8d Content-Type: application/octet-stream; name="CLUE WG Design Team.ics" Content-Disposition: attachment; filename="CLUE WG Design Team.ics" Content-Transfer-Encoding: base64 X-Attachment-Id: d43d4edc6930b717_0.1 QkVHSU46VkNBTEVOREFSClBST0RJRDotLy9NaWNyb3NvZnQgQ29ycG9yYXRpb24vL091dGxvb2sg MTAuMCBNSU1FRElSLy9FTgpWRVJTSU9OOjIuMApNRVRIT0Q6UkVRVUVTVApCRUdJTjpWVElNRVpP TkUKVFpJRDpDZW50cmFsIFRpbWUKQkVHSU46U1RBTkRBUkQKRFRTVEFSVDoyMDEwMTEwMVQwMjAw MDAKUlJVTEU6RlJFUT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0xU1U7QllNT05USD0xMQpUWk9G RlNFVEZST006LTA1MDAKVFpPRkZTRVRUTzotMDYwMApUWk5BTUU6U3RhbmRhcmQgVGltZQpFTkQ6 U1RBTkRBUkQKQkVHSU46REFZTElHSFQKRFRTVEFSVDoyMDEwMDMwMVQwMjAwMDAKUlJVTEU6RlJF UT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0yU1U7QllNT05USD0zClRaT0ZGU0VURlJPTTotMDYw MApUWk9GRlNFVFRPOi0wNTAwClRaTkFNRTpEYXlsaWdodCBTYXZpbmdzIFRpbWUKRU5EOkRBWUxJ R0hUCkVORDpWVElNRVpPTkUKQkVHSU46VkVWRU5UCkFUVEVOREVFO0NOPSJDbHVlIFdvcmtpbmcg R3JvdXAiO1JPTEU9UkVRLVBBUlRJQ0lQQU5UO1JTVlA9VFJVRTpNQUlMVE86Y2x1ZS1jaGFpcnNA dG9vbHMuaWV0Zi5vcmcKT1JHQU5JWkVSO0NOPSJDbHVlIFdvcmtpbmcgR3JvdXAiOk1BSUxUTzpj bHVlLWNoYWlyc0B0b29scy5pZXRmLm9yZwpEVFNUQVJUO1RaSUQ9IkNlbnRyYWwgVGltZSI6MjAx MjAxMzFUMDkwMDAwCkRURU5EO1RaSUQ9IkNlbnRyYWwgVGltZSI6MjAxMjAxMzFUMTAwMDAwCkxP Q0FUSU9OOmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9vbnN0YWdlL2cucGhwP2Q9NjQzNDM4 MTQzJnQ9YSAKVFJBTlNQOk9QQVFVRQpTRVFVRU5DRTowClVJRDpXRUJFWC1NRUVUSU5HIENFTlRF Ui02LjA0NTY2ODAtMTQ5NDEwNjAyCkRUU1RBTVA6MjAxMjAxMjdUMjE1NjQzWgpERVNDUklQVElP TjpIZWxsbyBDbHVlIFdvcmtpbmcgR3JvdXAsXG5cbllvdSBzY2hlZHVsZWQgdGhlIGZvbGxvd2lu ZyBXZWIgc2VtaW5hciB1c2luZyBXZWJFeC5cblxuVG9waWM6IENMVUUgV0cgRGVzaWduIFRlYW1c bkRhdGUgYW5kIFRpbWU6XG5UdWVzZGF5LCBKYW51YXJ5IDMxLCAyMDEyIDk6MDAgYW0sIENlbnRy YWwgU3RhbmRhcmQgVGltZSAoQ2hpY2FnbywgR01ULTA2OjAwKVxuRXZlbnQgbnVtYmVyOiA2NDMg NDM4IDE0M1xuRXZlbnQgcGFzc3dvcmQ6IDEyMzRcblBhbmVsaXN0IHBhc3N3b3JkOiBUaGUgRXZl bnQgaGFzIG5vIFBhbmVsaXN0IFBhc3N3b3JkXG5Ib3N0IGtleTogMTkwMTU0IChVc2UgdGhpcyB0 byByZWNsYWltIGhvc3QgcHJpdmlsZWdlcy4pXG5FdmVudCBhZGRyZXNzIGZvciBhdHRlbmRlZXM6 IGh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9vbnN0YWdlL2cucGhwP2Q9NjQzNDM4MTQzJnQ9 YVxuRXZlbnQgYWRkcmVzcyBmb3IgcGFuZWxpc3RzOiBodHRwczovL2lldGYud2ViZXguY29tL2ll dGYvb25zdGFnZS9nLnBocD9kPTY0MzQzODE0MyZ0PXBcblxuLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLVxuVG8gc3RhcnQgdGhlIG9ubGluZSBl dmVudFxuLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLVxuQXQgbGVhc3QgMzAgbWludXRlcyBiZWZvcmUgdGhlIHN0YXJ0aW5nIHRpbWU6XG5cbjEu IEdvIHRvIGh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9vbnN0YWdlL2cucGhwP2Q9NjQzNDM4 MTQzJnQ9aFxuMi4gTG9nIGluIHRvIHlvdXIgaG9zdCBhY2NvdW50IGlmIHlvdSBoYXZlIG5vdCB5 ZXQgZG9uZSBzby5cbjMuIE9uIHRoZSBFdmVudCBJbmZvcm1hdGlvbiBwYWdlIHRoYXQgYXBwZWFy cywgY2xpY2sgIlN0YXJ0IE5vdyIuXG5cbi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS1cblRlbGVjb25mZXJlbmNlIGluZm9ybWF0aW9uXG4tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tXG5DYWxs LWluIHRvbGwgbnVtYmVyIChVUy9DYW5hZGEpOiArMS00MDgtNjAwLTM2MDBcbkFjY2VzcyBjb2Rl OiA2NDMgNDM4IDE0M1xuXG5odHRwOi8vd3d3LndlYmV4LmNvbVxuXG5JTVBPUlRBTlQgTk9USUNF OiBUaGlzIFdlYkV4IHNlcnZpY2UgaW5jbHVkZXMgYSBmZWF0dXJlIHRoYXQgYWxsb3dzIGF1ZGlv IGFuZCBhbnkgZG9jdW1lbnRzIGFuZCBvdGhlciBtYXRlcmlhbHMgZXhjaGFuZ2VkIG9yIHZpZXdl ZCBkdXJpbmcgdGhlIHNlc3Npb24gdG8gYmUgcmVjb3JkZWQuIFlvdSBzaG91bGQgaW5mb3JtIGFs bCBtZWV0aW5nIGF0dGVuZGVlcyBwcmlvciB0byByZWNvcmRpbmcgaWYgeW91IGludGVuZCB0byBy ZWNvcmQgdGhlIG1lZXRpbmcuIFBsZWFzZSBub3RlIHRoYXQgYW55IHN1Y2ggcmVjb3JkaW5ncyBt YXkgYmUgc3ViamVjdCB0byBkaXNjb3ZlcnkgaW4gdGhlIGV2ZW50IG9mIGxpdGlnYXRpb24uIFxu ClNVTU1BUlk6Q0xVRSBXRyBEZXNpZ24gVGVhbQpQUklPUklUWTo1CkNMQVNTOlBVQkxJQwpFTkQ6 VkVWRU5UCkVORDpWQ0FMRU5EQVIK --20cf307cfc6012bf4904b7c1cb8d-- From marshall.eubanks@gmail.com Mon Jan 30 09:07:55 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC8B21F8624 for ; Mon, 30 Jan 2012 09:07:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.501 X-Spam-Level: X-Spam-Status: No, score=-103.501 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LaMx+qhFWUsr for ; Mon, 30 Jan 2012 09:07:54 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4F3CD21F8620 for ; Mon, 30 Jan 2012 09:07:54 -0800 (PST) Received: by ggnq2 with SMTP id q2so1682ggn.31 for ; Mon, 30 Jan 2012 09:07:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZE8Gvlo/JFYsYgjEAz60Vs71XoMb21+EgpPWKHidKPA=; b=oBsOzPmH7Eh/6IXE+vf6zMGCOYZs4Qf+3AvQRyqu2k6YXcF0Vwy03S71aWqVAOHEB/ 1lJuziv1RpfkfI7Pz8yQv/5Nmdt2TucXB/TDjSGgMgWb/4n7h9RUi4tw9f4C8MW7Svdp U8BGcSG41HGYw8DVFLvmjlQyqkgjVgz0l15QY= MIME-Version: 1.0 Received: by 10.182.41.5 with SMTP id b5mr29857044obl.79.1327943273722; Mon, 30 Jan 2012 09:07:53 -0800 (PST) Received: by 10.182.52.134 with HTTP; Mon, 30 Jan 2012 09:07:53 -0800 (PST) In-Reply-To: References: Date: Mon, 30 Jan 2012 12:07:53 -0500 Message-ID: From: Marshall Eubanks To: Mary Barnes Content-Type: multipart/alternative; boundary=f46d0445179b1cb51004b7c1e336 Cc: CLUE Subject: Re: [clue] CLUE WG Design Team Meeting - Jan. 31st X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 17:07:55 -0000 --f46d0445179b1cb51004b7c1e336 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jan 30, 2012 at 12:01 PM, Mary Barnes wrote: > Hi all, > > Below, please find the details for this week's call. I propose that we > discuss issue A.5 - (VAD (voice activity detection) tagging of audio > streams) from the framework, which should also include some general > discussion on audio handling. > > Regards, > Mary and Paul. > > Note: I seem to have somehow set this up as a web seminar so there are two > different links for joining. I think both will work, although one > (attendee) may default you to being muted when you join. > It would not let me join as a panelist but did not require a password Your e-mail address does not match any of panelist's e-mail address specified by the event host. Please re-enter or contact the event host. Marshall ** ** > > *From:* messenger@webex.com [mailto:messenger@webex.com] > *Sent:* Friday, January 27, 2012 3:57 PM > > *To:* clue-chairs@tools.ietf.org > *Subject:* Web seminar scheduled: CLUE WG Design Team**** > > ** ** > > **** > > > Hello Clue Working Group, > > You scheduled the following Web seminar using WebEx. > > Topic: CLUE WG Design Team > Date and Time: > Tuesday, January 31, 2012 9:00 am, Central Standard Time (Chicago, > GMT-06:00) > Event number: 643 438 143 > > Event password: 1234 > > Event address for attendees: > https://ietf.webex.com/ietf/onstage/g.php?d=643438143&t=a > Event address for panelists: > https://ietf.webex.com/ietf/onstage/g.php?d=643438143&t=p > > > ------------------------------------------------------- > To start the online event > ------------------------------------------------------- > At least 30 minutes before the starting time: > > 1. Go to https://ietf.webex.com/ietf/onstage/g.php?d=643438143&t=h > 2. Log in to your host account if you have not yet done so. > 3. On the Event Information page that appears, click "Start Now". > > ------------------------------------------------------- > Teleconference information > ------------------------------------------------------- > Call-in toll number (US/Canada): +1-408-600-3600 > Access code: 643 438 143 > > > http://www.webex.com > > IMPORTANT NOTICE: This WebEx service includes a feature that allows audio > and any documents and other materials exchanged or viewed during the > session to be recorded. You should inform all meeting attendees prior to > recording if you intend to record the meeting. Please note that any such > recordings may be subject to discovery in the event of litigation. > **** > > > **** > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > --f46d0445179b1cb51004b7c1e336 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Jan 30, 2012 at 12:01 PM, Mary B= arnes <m= ary.ietf.barnes@gmail.com> wrote:
Hi all,=A0

Below, please find the details for this week&= #39;s call. =A0I propose that we discuss issue A.5 - (VAD (voice activity = detection) tagging of audio streams) from the framework, which shoul= d also include some general discussion on audio handling.

Regards,
Mary and Paul.

Not= e: I seem to have somehow set this up as a web seminar so there are two dif= ferent links for joining. =A0I think both will work, although one (attendee= ) may default you to being muted when you join.

It would not let me join as a paneli= st but did not require a password
Your e-mail address does not match any of panelist'= s e-mail address specified by the event host. Please re-enter or contact th= e event host.


Marshall= =A0



=A0=

From: messenger@webex.= com [mailto:me= ssenger@webex.com]
Sent: Friday, January 27, 2012 3:57 PM


To:= clue-chair= s@tools.ietf.org
Subject: Web seminar scheduled: CLUE WG Desi= gn Team

=A0


Hello Clue Working Group,

You scheduled = the following Web seminar using WebEx.

Topic: CLUE WG Design Team
Date and Time:
Tuesday, January 31, 20= 12 9:00 am, Central Standard Time (Chicago, GMT-06:00)
Event numbe= r: 643 438 143

Event password: 1234

Event address for attendees: https://ietf.we= bex.com/ietf/onstage/g.php?d=3D643438143&t=3Da
Event address for= panelists: https://ietf.webex.com/ietf/onstage/g.php?= d=3D643438143&t=3Dp


-------------------------------------------------------
To start= the online event
------------------------------------------------------= -
At least 30 minutes before the starting time:

1. Go to https://ietf.webex.com/ietf/onstage/g.php?d=3D643438143&= amp;t=3Dh
2. Log in to your host account if you have not yet done so.
3. On t= he Event Information page that appears, click "Start Now".
-------------------------------------------------------
Teleconference information
---------------------------------------------= ----------
Call-in toll number (US/Canada): +1-408-600-3600
Access code: 643 438 143


http://www.webex= .com

IMPORTANT NOTICE: This WebEx service includes a feature tha= t allows audio and any documents and other materials exchanged or viewed du= ring the session to be recorded. You should inform all meeting attendees pr= ior to recording if you intend to record the meeting. Please note that any = such recordings may be subject to discovery in the event of litigation.


<= img border=3D"0">



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


--f46d0445179b1cb51004b7c1e336-- From mary.ietf.barnes@gmail.com Mon Jan 30 09:11:56 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7014F21F8629 for ; Mon, 30 Jan 2012 09:11:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.645 X-Spam-Level: X-Spam-Status: No, score=-103.645 tagged_above=-999 required=5 tests=[AWL=-0.047, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0z8ftw+39WGn for ; Mon, 30 Jan 2012 09:11:55 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 959A121F8624 for ; Mon, 30 Jan 2012 09:11:54 -0800 (PST) Received: by vcbfk14 with SMTP id fk14so3187021vcb.31 for ; Mon, 30 Jan 2012 09:11:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EqGqv0blOXFGJy4AbIZR6MLALXVBmfWi408xZGbqVO4=; b=QXqIBwvHYAuEvSoQ6ntjIEWHp18tL81aDCOVPJ7K/X7d1mGlTw4+8zawzlDchvfkRX MTHNfoE7RKcMRzPJJAGGfIHKJA3mKcF63RvV1XwYpLav8YqN4YTuKIfaxi8kP1YfSk7Q UWEv5qvDlvbuV1xxT8ltrSB5+EeTsrMCCVvgY= MIME-Version: 1.0 Received: by 10.52.35.148 with SMTP id h20mr8445418vdj.21.1327943514085; Mon, 30 Jan 2012 09:11:54 -0800 (PST) Received: by 10.52.108.196 with HTTP; Mon, 30 Jan 2012 09:11:54 -0800 (PST) In-Reply-To: References: Date: Mon, 30 Jan 2012 11:11:54 -0600 Message-ID: From: Mary Barnes To: Marshall Eubanks Content-Type: multipart/alternative; boundary=20cf3079b6cc70581904b7c1f1c3 Cc: CLUE Subject: Re: [clue] CLUE WG Design Team Meeting - Jan. 31st X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 17:11:56 -0000 --20cf3079b6cc70581904b7c1f1c3 Content-Type: text/plain; charset=ISO-8859-1 Please try the attendee one then. If that doesn't work, we'll have to try to reschedule again - it's just weird because I got a whole lot more options it seemed when scheduling this time (I did try twice - the first one required that one register prior to joining. Mary. On Mon, Jan 30, 2012 at 11:07 AM, Marshall Eubanks < marshall.eubanks@gmail.com> wrote: > > > On Mon, Jan 30, 2012 at 12:01 PM, Mary Barnes wrote: > >> Hi all, >> >> Below, please find the details for this week's call. I propose that we >> discuss issue A.5 - (VAD (voice activity detection) tagging of audio >> streams) from the framework, which should also include some general >> discussion on audio handling. >> >> Regards, >> Mary and Paul. >> >> Note: I seem to have somehow set this up as a web seminar so there are >> two different links for joining. I think both will work, although one >> (attendee) may default you to being muted when you join. >> > > It would not let me join as a panelist but did not require a password > Your e-mail address does not match any of panelist's e-mail address > specified by the event host. Please re-enter or contact the event host. > > > Marshall > > > > ** ** >> >> *From:* messenger@webex.com [mailto:messenger@webex.com] >> *Sent:* Friday, January 27, 2012 3:57 PM >> >> *To:* clue-chairs@tools.ietf.org >> *Subject:* Web seminar scheduled: CLUE WG Design Team**** >> >> ** ** >> >> **** >> >> >> Hello Clue Working Group, >> >> You scheduled the following Web seminar using WebEx. >> >> Topic: CLUE WG Design Team >> Date and Time: >> Tuesday, January 31, 2012 9:00 am, Central Standard Time (Chicago, >> GMT-06:00) >> Event number: 643 438 143 >> >> Event password: 1234 >> >> Event address for attendees: >> https://ietf.webex.com/ietf/onstage/g.php?d=643438143&t=a >> Event address for panelists: >> https://ietf.webex.com/ietf/onstage/g.php?d=643438143&t=p >> >> >> ------------------------------------------------------- >> To start the online event >> ------------------------------------------------------- >> At least 30 minutes before the starting time: >> >> 1. Go to https://ietf.webex.com/ietf/onstage/g.php?d=643438143&t=h >> 2. Log in to your host account if you have not yet done so. >> 3. On the Event Information page that appears, click "Start Now". >> >> ------------------------------------------------------- >> Teleconference information >> ------------------------------------------------------- >> Call-in toll number (US/Canada): +1-408-600-3600 >> Access code: 643 438 143 >> >> >> http://www.webex.com >> >> IMPORTANT NOTICE: This WebEx service includes a feature that allows audio >> and any documents and other materials exchanged or viewed during the >> session to be recorded. You should inform all meeting attendees prior to >> recording if you intend to record the meeting. Please note that any such >> recordings may be subject to discovery in the event of litigation. >> **** >> >> >> **** >> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> >> > --20cf3079b6cc70581904b7c1f1c3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Please try the attendee one then. If that doesn't work, we'll have = to try to reschedule again - it's just weird because I got a whole lot = more options it seemed when scheduling this time (I did try twice - the fir= st one required that one register prior to joining.

Mary.

On Mon, Jan 30, 2012= at 11:07 AM, Marshall Eubanks <marshall.eubanks@gmail.com> wrote:


On Mon, Jan 30, 2012 a= t 12:01 PM, Mary Barnes <mary.ietf.barnes@gmail.com> wrote:
Hi all,=A0

Below, please find the details for this week&= #39;s call. =A0I propose that we discuss issue A.5 - (VAD (voice activity = detection) tagging of audio streams) from the framework, which shoul= d also include some general discussion on audio handling.

Regards,
Mary and Paul.

Not= e: I seem to have somehow set this up as a web seminar so there are two dif= ferent links for joining. =A0I think both will work, although one (attendee= ) may default you to being muted when you join.

It would not let me join as a = panelist but did not require a password
Your e-mail address does not match any of panelist'= s e-mail address specified by the event host. Please re-enter or contact th= e event host.


Marshall= =A0



=A0=

From: messenger@webex.= com [mailto:me= ssenger@webex.com]
Sent: Friday, January 27, 2012 3:57 PM


To:= clue-chair= s@tools.ietf.org
Subject: Web seminar scheduled: CLUE WG Desi= gn Team

=A0


Hello Clue Working Group,

You scheduled = the following Web seminar using WebEx.

Topic: CLUE WG Design Team
Date and Time:
Tuesday, January 31, 20= 12 9:00 am, Central Standard Time (Chicago, GMT-06:00)
Event numbe= r: 643 438 143

Event password: 1234

Event address for attendees: https://ietf.we= bex.com/ietf/onstage/g.php?d=3D643438143&t=3Da
Event address for= panelists: https://ietf.webex.com/ietf/onstage/g.php?= d=3D643438143&t=3Dp


-------------------------------------------------------
To start= the online event
------------------------------------------------------= -
At least 30 minutes before the starting time:

1. Go to https://ietf.webex.com/ietf/onstage/g.php?d=3D643438143&= amp;t=3Dh
2. Log in to your host account if you have not yet done so.
3. On t= he Event Information page that appears, click "Start Now".
-------------------------------------------------------
Teleconference information
---------------------------------------------= ----------
Call-in toll number (US/Canada): +1-408-600-3600
Access code: 643 438 143


http://www.webex= .com

IMPORTANT NOTICE: This WebEx service includes a feature tha= t allows audio and any documents and other materials exchanged or viewed du= ring the session to be recorded. You should inform all meeting attendees pr= ior to recording if you intend to record the meeting. Please note that any = such recordings may be subject to discovery in the event of litigation.


<= img border=3D"0">



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



--20cf3079b6cc70581904b7c1f1c3-- From marshall.eubanks@gmail.com Mon Jan 30 09:18:57 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 375F821F8716 for ; Mon, 30 Jan 2012 09:18:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.501 X-Spam-Level: X-Spam-Status: No, score=-103.501 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eeze9y0nqnJe for ; Mon, 30 Jan 2012 09:18:56 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 01E9321F8714 for ; Mon, 30 Jan 2012 09:18:55 -0800 (PST) Received: by ggnq2 with SMTP id q2so10996ggn.31 for ; Mon, 30 Jan 2012 09:18:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zulFu2U+Q71qO48gaKiTXW56TNtOKCjOuEA0hiY7Nm4=; b=AH7DCvNruLclU6o2k/nqGQiWk4KrBimSb3JGQ35a3L4EJk+45B+jZF1zLKNB13xAtv TyMTs4ObNsWMVBK9OyRjGXo9qU0R8ULglp7+x6SGrgpzgZSGCm1S0XsXHdvD2lDasszC YssRWCFCoUIEF8UWjMWFbU1OMBskO6JPRi0VU= MIME-Version: 1.0 Received: by 10.182.72.74 with SMTP id b10mr29870444obv.69.1327943935345; Mon, 30 Jan 2012 09:18:55 -0800 (PST) Received: by 10.182.52.134 with HTTP; Mon, 30 Jan 2012 09:18:55 -0800 (PST) In-Reply-To: References: Date: Mon, 30 Jan 2012 12:18:55 -0500 Message-ID: From: Marshall Eubanks To: Mary Barnes Content-Type: multipart/alternative; boundary=f46d0447a08f8c439904b7c20a83 Cc: CLUE Subject: Re: [clue] CLUE WG Design Team Meeting - Jan. 31st X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 17:18:57 -0000 --f46d0447a08f8c439904b7c20a83 Content-Type: text/plain; charset=ISO-8859-1 I can't try attendees, as it says the meeting hasn't started. This is the IETF WEBEX, right ? I could ask around... Marshall On Mon, Jan 30, 2012 at 12:11 PM, Mary Barnes wrote: > Please try the attendee one then. If that doesn't work, we'll have to try > to reschedule again - it's just weird because I got a whole lot more > options it seemed when scheduling this time (I did try twice - the first > one required that one register prior to joining. > > Mary. > > > On Mon, Jan 30, 2012 at 11:07 AM, Marshall Eubanks < > marshall.eubanks@gmail.com> wrote: > >> >> >> On Mon, Jan 30, 2012 at 12:01 PM, Mary Barnes > > wrote: >> >>> Hi all, >>> >>> Below, please find the details for this week's call. I propose that we >>> discuss issue A.5 - (VAD (voice activity detection) tagging of audio >>> streams) from the framework, which should also include some general >>> discussion on audio handling. >>> >>> Regards, >>> Mary and Paul. >>> >>> Note: I seem to have somehow set this up as a web seminar so there are >>> two different links for joining. I think both will work, although one >>> (attendee) may default you to being muted when you join. >>> >> >> It would not let me join as a panelist but did not require a password >> Your e-mail address does not match any of panelist's e-mail address >> specified by the event host. Please re-enter or contact the event host. >> >> >> Marshall >> >> >> >> ** ** >>> >>> *From:* messenger@webex.com [mailto:messenger@webex.com] >>> *Sent:* Friday, January 27, 2012 3:57 PM >>> >>> *To:* clue-chairs@tools.ietf.org >>> *Subject:* Web seminar scheduled: CLUE WG Design Team**** >>> >>> ** ** >>> >>> **** >>> >>> >>> Hello Clue Working Group, >>> >>> You scheduled the following Web seminar using WebEx. >>> >>> Topic: CLUE WG Design Team >>> Date and Time: >>> Tuesday, January 31, 2012 9:00 am, Central Standard Time (Chicago, >>> GMT-06:00) >>> Event number: 643 438 143 >>> >>> Event password: 1234 >>> >>> Event address for attendees: >>> https://ietf.webex.com/ietf/onstage/g.php?d=643438143&t=a >>> Event address for panelists: >>> https://ietf.webex.com/ietf/onstage/g.php?d=643438143&t=p >>> >>> >>> ------------------------------------------------------- >>> To start the online event >>> ------------------------------------------------------- >>> At least 30 minutes before the starting time: >>> >>> 1. Go to https://ietf.webex.com/ietf/onstage/g.php?d=643438143&t=h >>> 2. Log in to your host account if you have not yet done so. >>> 3. On the Event Information page that appears, click "Start Now". >>> >>> ------------------------------------------------------- >>> Teleconference information >>> ------------------------------------------------------- >>> Call-in toll number (US/Canada): +1-408-600-3600 >>> Access code: 643 438 143 >>> >>> >>> http://www.webex.com >>> >>> IMPORTANT NOTICE: This WebEx service includes a feature that allows >>> audio and any documents and other materials exchanged or viewed during the >>> session to be recorded. You should inform all meeting attendees prior to >>> recording if you intend to record the meeting. Please note that any such >>> recordings may be subject to discovery in the event of litigation. >>> **** >>> >>> >>> **** >>> >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >>> >> > --f46d0447a08f8c439904b7c20a83 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I can't try attendees, as it says the meeting hasn't started.=A0
This is the IETF WEBEX, right ? I could ask around...

Marshall=A0

On Mon, = Jan 30, 2012 at 12:11 PM, Mary Barnes <mary.ietf.barnes@gmail.com> wr= ote:
Please try the attendee one then. If that do= esn't work, we'll have to try to reschedule again - it's just w= eird because I got a whole lot more options it seemed when scheduling this = time (I did try twice - the first one required that one register prior to j= oining.

Mary.


On Mon, Jan 30, 2012 at 11:07 AM, Marshall Eubanks <= ;marshall.e= ubanks@gmail.com> wrote:


On Mon, Jan 30, 2012 at 12:01 PM, M= ary Barnes <mary.ietf.barnes@gmail.com> wrote:
Hi all,=A0

Below, please find the details for this week&= #39;s call. =A0I propose that we discuss issue A.5 - (VAD (voice activity = detection) tagging of audio streams) from the framework, which shoul= d also include some general discussion on audio handling.

Regards,
Mary and Paul.

Not= e: I seem to have somehow set this up as a web seminar so there are two dif= ferent links for joining. =A0I think both will work, although one (attendee= ) may default you to being muted when you join.

It would not let me join as a = panelist but did not require a password
Your e-mail address does not match any of panelist'= s e-mail address specified by the event host. Please re-enter or contact th= e event host.


Marshall= =A0



=A0=

From: messenger@webex.= com [mailto:me= ssenger@webex.com]
Sent: Friday, January 27, 2012 3:57 PM


To:= clue-chair= s@tools.ietf.org
Subject: Web seminar scheduled: CLUE WG Desi= gn Team

=A0


Hello Clue Working Group,

You scheduled = the following Web seminar using WebEx.

Topic: CLUE WG Design Team
Date and Time:
Tuesday, January 31, 20= 12 9:00 am, Central Standard Time (Chicago, GMT-06:00)
Event numbe= r: 643 438 143

Event password: 1234

Event address for attendees: https://ietf.we= bex.com/ietf/onstage/g.php?d=3D643438143&t=3Da
Event address for= panelists: https://ietf.webex.com/ietf/onstage/g.php?= d=3D643438143&t=3Dp


-------------------------------------------------------
To start= the online event
------------------------------------------------------= -
At least 30 minutes before the starting time:

1. Go to https://ietf.webex.com/ietf/onstage/g.php?d=3D643438143&= amp;t=3Dh
2. Log in to your host account if you have not yet done so.
3. On t= he Event Information page that appears, click "Start Now".
-------------------------------------------------------
Teleconference information
---------------------------------------------= ----------
Call-in toll number (US/Canada): +1-408-600-3600
Access code: 643 438 143


http://www.webex= .com

IMPORTANT NOTICE: This WebEx service includes a feature tha= t allows audio and any documents and other materials exchanged or viewed du= ring the session to be recorded. You should inform all meeting attendees pr= ior to recording if you intend to record the meeting. Please note that any = such recordings may be subject to discovery in the event of litigation.


<= img border=3D"0">



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




--f46d0447a08f8c439904b7c20a83-- From mary.ietf.barnes@gmail.com Mon Jan 30 09:21:03 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 014E521F8717 for ; Mon, 30 Jan 2012 09:21:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.643 X-Spam-Level: X-Spam-Status: No, score=-103.643 tagged_above=-999 required=5 tests=[AWL=-0.045, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6zCCZxD3e2MD for ; Mon, 30 Jan 2012 09:21:02 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id E577A21F8713 for ; Mon, 30 Jan 2012 09:21:01 -0800 (PST) Received: by vcbfk14 with SMTP id fk14so3196262vcb.31 for ; Mon, 30 Jan 2012 09:21:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sfV6QfVofFqPu2RhiEdeCQjOG9vQeglxANQ2ZMMgv8I=; b=kPDxoOB4gJSv871yEDAKSDZXObq9EDLpDQzAebBbMz9G2Niw5wQh4teTQiFEeVsA/e gj8Bg9bVYGmfJa4X8Cvu1Is5vDQlLqfX8nT3Xri7wemeYLxKmMDuGmVYvnz5n4LZbm3u 9spqEsYJm4tGcsvlZIa9rRNl72TnuNZrOnBDo= MIME-Version: 1.0 Received: by 10.220.148.138 with SMTP id p10mr9959119vcv.28.1327944061303; Mon, 30 Jan 2012 09:21:01 -0800 (PST) Received: by 10.52.108.196 with HTTP; Mon, 30 Jan 2012 09:21:01 -0800 (PST) In-Reply-To: References: Date: Mon, 30 Jan 2012 11:21:01 -0600 Message-ID: From: Mary Barnes To: Marshall Eubanks Content-Type: multipart/alternative; boundary=f46d043892910e3ab304b7c2121b Cc: CLUE Subject: Re: [clue] CLUE WG Design Team Meeting - Jan. 31st X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 17:21:03 -0000 --f46d043892910e3ab304b7c2121b Content-Type: text/plain; charset=ISO-8859-1 We'll try again. This is the IETF Webex that the secretariat allocated for CLUE. It worked just fine last week, it may be operator error on my part. Thanks, Mary. On Mon, Jan 30, 2012 at 11:18 AM, Marshall Eubanks < marshall.eubanks@gmail.com> wrote: > I can't try attendees, as it says the meeting hasn't started. > > This is the IETF WEBEX, right ? I could ask around... > > Marshall > > > On Mon, Jan 30, 2012 at 12:11 PM, Mary Barnes wrote: > >> Please try the attendee one then. If that doesn't work, we'll have to try >> to reschedule again - it's just weird because I got a whole lot more >> options it seemed when scheduling this time (I did try twice - the first >> one required that one register prior to joining. >> >> Mary. >> >> >> On Mon, Jan 30, 2012 at 11:07 AM, Marshall Eubanks < >> marshall.eubanks@gmail.com> wrote: >> >>> >>> >>> On Mon, Jan 30, 2012 at 12:01 PM, Mary Barnes < >>> mary.ietf.barnes@gmail.com> wrote: >>> >>>> Hi all, >>>> >>>> Below, please find the details for this week's call. I propose that we >>>> discuss issue A.5 - (VAD (voice activity detection) tagging of audio >>>> streams) from the framework, which should also include some general >>>> discussion on audio handling. >>>> >>>> Regards, >>>> Mary and Paul. >>>> >>>> Note: I seem to have somehow set this up as a web seminar so there are >>>> two different links for joining. I think both will work, although one >>>> (attendee) may default you to being muted when you join. >>>> >>> >>> It would not let me join as a panelist but did not require a password >>> Your e-mail address does not match any of panelist's e-mail address >>> specified by the event host. Please re-enter or contact the event host. >>> >>> >>> Marshall >>> >>> >>> >>> ** ** >>>> >>>> *From:* messenger@webex.com [mailto:messenger@webex.com] >>>> *Sent:* Friday, January 27, 2012 3:57 PM >>>> >>>> *To:* clue-chairs@tools.ietf.org >>>> *Subject:* Web seminar scheduled: CLUE WG Design Team**** >>>> >>>> ** ** >>>> >>>> **** >>>> >>>> >>>> Hello Clue Working Group, >>>> >>>> You scheduled the following Web seminar using WebEx. >>>> >>>> Topic: CLUE WG Design Team >>>> Date and Time: >>>> Tuesday, January 31, 2012 9:00 am, Central Standard Time (Chicago, >>>> GMT-06:00) >>>> Event number: 643 438 143 >>>> >>>> Event password: 1234 >>>> >>>> Event address for attendees: >>>> https://ietf.webex.com/ietf/onstage/g.php?d=643438143&t=a >>>> Event address for panelists: >>>> https://ietf.webex.com/ietf/onstage/g.php?d=643438143&t=p >>>> >>>> >>>> ------------------------------------------------------- >>>> To start the online event >>>> ------------------------------------------------------- >>>> At least 30 minutes before the starting time: >>>> >>>> 1. Go to https://ietf.webex.com/ietf/onstage/g.php?d=643438143&t=h >>>> 2. Log in to your host account if you have not yet done so. >>>> 3. On the Event Information page that appears, click "Start Now". >>>> >>>> ------------------------------------------------------- >>>> Teleconference information >>>> ------------------------------------------------------- >>>> Call-in toll number (US/Canada): +1-408-600-3600 >>>> Access code: 643 438 143 >>>> >>>> >>>> http://www.webex.com >>>> >>>> IMPORTANT NOTICE: This WebEx service includes a feature that allows >>>> audio and any documents and other materials exchanged or viewed during the >>>> session to be recorded. You should inform all meeting attendees prior to >>>> recording if you intend to record the meeting. Please note that any such >>>> recordings may be subject to discovery in the event of litigation. >>>> **** >>>> >>>> >>>> **** >>>> >>>> >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>>> >>>> >>> >> > --f46d043892910e3ab304b7c2121b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable We'll try again. =A0This is the IETF Webex that the secretariat allocat= ed for CLUE. It worked just fine last week, it may be operator error on my = part. =A0

Thanks,
Mary.=A0

On Mon, Jan 30, 2012 at 11:18 AM, Marshall Eubanks <marshall.eubanks@gmail.com&= gt; wrote:
I can't try attendees, as it says the meeting hasn't started.=A0
This is the IETF WEBEX, right ? I could ask around...

Marshall=A0


On Mon, Jan 30, 2012 a= t 12:11 PM, Mary Barnes <mary.ietf.barnes@gmail.com> wrote:
Please try the attendee one then. If that do= esn't work, we'll have to try to reschedule again - it's just w= eird because I got a whole lot more options it seemed when scheduling this = time (I did try twice - the first one required that one register prior to j= oining.

Mary.


On Mon, Jan 30, 2012 at 11:= 07 AM, Marshall Eubanks <marshall.eubanks@gmail.com> wrote:


On Mon, Jan 30, 2012 at 12:01 PM, M= ary Barnes <mary.ietf.barnes@gmail.com> wrote:
Hi all,=A0

Below, please find the details for this week&= #39;s call. =A0I propose that we discuss issue A.5 - (VAD (voice activity = detection) tagging of audio streams) from the framework, which shoul= d also include some general discussion on audio handling.

Regards,
Mary and Paul.

Not= e: I seem to have somehow set this up as a web seminar so there are two dif= ferent links for joining. =A0I think both will work, although one (attendee= ) may default you to being muted when you join.

It would not let me join as a = panelist but did not require a password
Your e-mail address does not match any of panelist'= s e-mail address specified by the event host. Please re-enter or contact th= e event host.


Marshall= =A0



=A0=

From: messenger@webex.= com [mailto:me= ssenger@webex.com]
Sent: Friday, January 27, 2012 3:57 PM


To:= clue-chair= s@tools.ietf.org
Subject: Web seminar scheduled: CLUE WG Desi= gn Team

=A0


Hello Clue Working Group,

You scheduled = the following Web seminar using WebEx.

Topic: CLUE WG Design Team
Date and Time:
Tuesday, January 31, 20= 12 9:00 am, Central Standard Time (Chicago, GMT-06:00)
Event numbe= r: 643 438 143

Event password: 1234

Event address for attendees: https://ietf.we= bex.com/ietf/onstage/g.php?d=3D643438143&t=3Da
Event address for= panelists: https://ietf.webex.com/ietf/onstage/g.php?= d=3D643438143&t=3Dp


-------------------------------------------------------
To start= the online event
------------------------------------------------------= -
At least 30 minutes before the starting time:

1. Go to https://ietf.webex.com/ietf/onstage/g.php?d=3D643438143&= amp;t=3Dh
2. Log in to your host account if you have not yet done so.
3. On t= he Event Information page that appears, click "Start Now".
-------------------------------------------------------
Teleconference information
---------------------------------------------= ----------
Call-in toll number (US/Canada): +1-408-600-3600
Access code: 643 438 143


http://www.webex= .com

IMPORTANT NOTICE: This WebEx service includes a feature tha= t allows audio and any documents and other materials exchanged or viewed du= ring the session to be recorded. You should inform all meeting attendees pr= ior to recording if you intend to record the meeting. Please note that any = such recordings may be subject to discovery in the event of litigation.


<= img border=3D"0">



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





--f46d043892910e3ab304b7c2121b-- From pkyzivat@alum.mit.edu Mon Jan 30 11:14:19 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1A0011E8099 for ; Mon, 30 Jan 2012 11:14:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CyxjUi-6WtC0 for ; Mon, 30 Jan 2012 11:14:19 -0800 (PST) Received: from qmta01.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by ietfa.amsl.com (Postfix) with ESMTP id EBFBE11E8081 for ; Mon, 30 Jan 2012 11:14:18 -0800 (PST) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta01.westchester.pa.mail.comcast.net with comcast id Tut71i00316LCl051vEKe8; Mon, 30 Jan 2012 19:14:19 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta06.westchester.pa.mail.comcast.net with comcast id TvEJ1i01m07duvL3SvEKRP; Mon, 30 Jan 2012 19:14:19 +0000 Message-ID: <4F26EC09.8000504@alum.mit.edu> Date: Mon, 30 Jan 2012 14:14:17 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: CLUE References: <244633145.1327950641237.JavaMail.nobody@jva2wl006.webex.com> In-Reply-To: <244633145.1327950641237.JavaMail.nobody@jva2wl006.webex.com> X-Forwarded-Message-Id: <244633145.1327950641237.JavaMail.nobody@jva2wl006.webex.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [clue] Fwd: Meeting rescheduled: CLUE WG design team X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 19:14:20 -0000 Since we were having trouble with the way the meeting was set up, I recreated it. This one seems to be more "normal" than the last one. So please disregard prior meeting info and use this instead. Thanks, Paul -------- Original Message -------- Subject: Meeting rescheduled: CLUE WG design team Date: Mon, 30 Jan 2012 19:10:41 +0000 (GMT) From: Clue Working Group Reply-To: clue-chairs@tools.ietf.org To: clue-chairs@tools.ietf.org Hello Clue Working Group, Clue Working Group changed the time for this online meeting. Topic: CLUE WG design team Date: Tuesday, January 31, 2012 Time: 9:00 am, Central Standard Time (Chicago, GMT-06:00) Meeting Number: 646 813 366 Meeting Password: 1234 ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://ietf.webex.com/ietf/j.php?ED=149458212&UID=1232762747&PW=NZTMxM2M5NTY4&RT=MiM3 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: 1234 4. Click "Join". To view in other time zones or languages, please click the link: https://ietf.webex.com/ietf/j.php?ED=149458212&UID=1232762747&PW=NZTMxM2M5NTY4&ORT=MiM3 ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- Call-in toll number (US/Canada): +1-408-600-3600 Access code:646 813 366 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://ietf.webex.com/ietf/mc 2. On the left navigation bar, click "Support". You can contact me at: clue-chairs@tools.ietf.org To update this meeting to your calendar program (for example Microsoft Outlook), click this link: https://ietf.webex.com/ietf/j.php?ED=149458212&UID=1232762747&ICS=MRS3&LD=1&RD=2&ST=1&SHA2=fj0QH5rHXvBURuzOPc2LdjC4C0hMV7l6VxyGnTV4m2w=&RT=MiM3 WebEx will automatically setup Meeting Manager for Windows the first time you join a meeting. To save time, you can setup prior to the meeting by clicking this link: https://ietf.webex.com/ietf/meetingcenter/mcsetup.php The playback of UCF (Universal Communications Format) rich media files requires appropriate players. To view this type of rich media files in the meeting, please check whether you have the players installed on your computer by going to https://ietf.webex.com/ietf/systemdiagnosis.php. Sign up for a free trial of WebEx http://www.webex.com/go/mcemfreetrial http://www.webex.com CCP:+14086003600x646813366# IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation. From ron.even.tlv@gmail.com Mon Jan 30 15:10:06 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9718221F8748 for ; Mon, 30 Jan 2012 15:10:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.729 X-Spam-Level: X-Spam-Status: No, score=-2.729 tagged_above=-999 required=5 tests=[AWL=-0.330, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g3itLDhUxnAr for ; Mon, 30 Jan 2012 15:10:05 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id CFCBD21F8749 for ; Mon, 30 Jan 2012 15:10:03 -0800 (PST) Received: by eaai12 with SMTP id i12so972759eaa.31 for ; Mon, 30 Jan 2012 15:09:59 -0800 (PST) Received-SPF: pass (google.com: domain of ron.even.tlv@gmail.com designates 10.213.9.76 as permitted sender) client-ip=10.213.9.76; Authentication-Results: mr.google.com; spf=pass (google.com: domain of ron.even.tlv@gmail.com designates 10.213.9.76 as permitted sender) smtp.mail=ron.even.tlv@gmail.com; dkim=pass header.i=ron.even.tlv@gmail.com Received: from mr.google.com ([10.213.9.76]) by 10.213.9.76 with SMTP id k12mr4080180ebk.40.1327964999590 (num_hops = 1); Mon, 30 Jan 2012 15:09:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; bh=ofah/0bQ0uJYEnJ4EmxuhoBNP1EzILwLxBA3bwKyYOY=; b=dbGYWio5GYDtDvdKvdi9ZaSbW7mlwWH8Eksl79REW0NeswSQDj/z5iW+5gTP4ngd8n ZMtvt5K6/gfRbITy+ids+Nq23w3GN+4VYryZZdMUkKxWKjFY8m+4tQxE0cmwzYgCnXJh RcKcjFChO46fBRF87w6Z6gcIeP4CbA3nj9mX0= Received: by 10.213.9.76 with SMTP id k12mr3113074ebk.40.1327964997888; Mon, 30 Jan 2012 15:09:57 -0800 (PST) Received: from windows8d787f9 ([109.67.208.29]) by mx.google.com with ESMTPS id b3sm27462438een.2.2012.01.30.15.09.55 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 30 Jan 2012 15:09:56 -0800 (PST) From: "Roni Even" To: "'Espen Berger \(espeberg\)'" , References: <068.03e705c774d30abee11ba5026a664a26@trac.tools.ietf.org><083.e4945b5c72773c1362efdf7bb0443c4a@trac.tools.ietf.org> <4f266f4c.d0770e0a.43c6.37fd@mx.google.com> <92DF9533227FC14F946C7321074B8C9EE48845@XMB-AMS-214.cisco.com> <4f26ac4f.11840e0a.6db6.ffff9756@mx.google.com> <92DF9533227FC14F946C7321074B8C9EE48877@XMB-AMS-214.cisco.com> In-Reply-To: <92DF9533227FC14F946C7321074B8C9EE48877@XMB-AMS-214.cisco.com> Date: Tue, 31 Jan 2012 01:06:04 +0200 Message-ID: <4f272344.03bd0e0a.6983.3d7e@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AczaIHX5kbsR/L8BTXmfYvH+6pZxUwFEZeZQAAYsrwAABFxPgAABDkxwABCDGPA= Content-Language: en-us Subject: Re: [clue] #7: Is composed attribute a boolean or data structure X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 23:10:06 -0000 Hi Espen, If the provider wants to offer site switch and segment switch option to = the consumer he cannot do it just with A. this is a basic use case. In general, your option does not provide any interoperability since both = sides may have different views what composed means. In the framework = example of a PIP as composed image it is an assumption that if the = provider offers this composed offer, the consumer can understand that it = is a PIP mix but there is nothing in the offer that will indicate that = it is. Roni=20 > -----Original Message----- > From: Espen Berger (espeberg) [mailto:espeberg@cisco.com] > Sent: Monday, January 30, 2012 5:21 PM > To: Roni Even; clue@ietf.org > Subject: RE: [clue] #7: Is composed attribute a boolean or data > structure >=20 > Hi Roni >=20 > If you=E2=80=99re a particular use cases requires control over the = composed > layouts you need a) and b). In my example I used a single = advertisement > composed stream with optional meta-information about possible layout > choices. A receiver that wants the default composed layout can request > the composed stream and skip the optional video-layout information. > Optionally you could request the same composed stream with layouts > hints for the receiver. >=20 > For me use case c) does not include the selection mechanisms, only the > content you see in the video stream. >=20 > Cheers >=20 > -Espen >=20 > -----Original Message----- > From: Roni Even [mailto:ron.even.tlv@gmail.com] > Sent: 30. januar 2012 15:39 > To: Espen Berger (espeberg); clue@ietf.org > Subject: RE: [clue] #7: Is composed attribute a boolean or data > structure >=20 > Hi Espen, > If you will look at the notes from the last call there was a support > that a) is not enough. Having just compose does not address even the > use cases I provided which are also based on the use case draft. >=20 >=20 > I am not sure what you mean by C since what in the composed stream can > be either which VC you see or what is the selection criteria for being > in a composed stream. If you meant the second, my view is that C and > also b should be in the basic framework and not in an extension. >=20 > Roni Even >=20 > > -----Original Message----- > > From: Espen Berger (espeberg) [mailto:espeberg@cisco.com] > > Sent: Monday, January 30, 2012 4:17 PM > > To: Roni Even; clue@ietf.org > > Subject: RE: [clue] #7: Is composed attribute a boolean or data > > structure > > > > > > To help with the direction of the discussions I think it's useful to > > divide the discussions into three use cases for composed streams. > > a) How to express if a capture stream is composed or not > > b) How to express layout choices? (e.g. with a video-layout = element) > > c) How to express what's inside a composed stream > > > > For use case a) a composed attribute should be sufficient, you = either > > ask for the composed stream or you do not. > > I also believe this should cover the interoperability requirement we > > have across multiple types of endpoints. > > > > For use case b) both mediactrl and xcon uses a = element > > to describe possible layouts and also to request the preferred = layout > > based on options. (as described in Roni's email) > > > > An example could be (inspired by mediactrl and xcon usage of > layout>): > > > > CLUE Advertisement > > Capture id=3D2 Purpose=3Dpeople Composed=3Dfalse > > Capture id=3D3 Purpose=3Dpeople Composed=3Dfalse > > Capture id=3D4 Purpose=3DPeople Composed=3Dtrue > > Video-layout=3D"'automatic', 'dual-view', ' single-view'" > > > > CLUE configure // Default composed stream > > Capture id=3D4 > > > > // Or composed stream with layout hints > > Capture id=3D4 Video-layout=3D'dual-view' > > > > The video-layout element is a list of strings and each string is a > > layout-hint that can be requested. Video-layout is optional. A = layout > > hints about the requested rendering and the source is free to = replace > > any stream as long as they fit the layout. > > > > Use case c) is more open in the sense that what you actually receive > > in a composed stream is depending on status of a room or who is in a > > MCU conference. E.g. from a room you could get a mix of different > > capture stream representing cameras and from a transcoding MCU it > > could be different room, different cameras or another mix of = possible > > input video streams. > > > > Having support for both b) and c) could be a good test for the > > extensibility of CLUE. If the basis of CLUE only does use case a) > > there should be room to extend CLUE with support for b) and c) as a > > CLUE + layout description extension. > > > > Cheers > > > > -Espen > > > > > > > > -----Original Message----- > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > > Of Roni Even > > Sent: 30. januar 2012 11:18 > > To: clue@ietf.org > > Subject: Re: [clue] #7: Is composed attribute a boolean or data > > structure > > > > Hi, > > During the last call I volunteered to provide some input. > > > > In current IETF work (XCON, Mediactrl WGs there is a video layout > > element) > > > > http://tools.ietf.org/html/draft-ietf-mediactrl-mixer-control- > package- > > 14#section-4.2.1.4.2.1 > > > > and > > http://tools.ietf.org/html/draft-ietf-xcon-common-data-model- > > 32#section-4.2.7 (look at video-layout) > > > > I would like first to try to define the term "composed video" since > it > > looks to me like we have different views here, and provide my = initial > > view on what should be described. > > > > Composed video can describes both the layout and the selection > > algorithm for composing the content of the sub-windows in the > "mixed" > > video. > > > > The video layout which just describes the geometry of the composed > > image and I think that the above references provide good structure = to > > define this part of the composed video attribute. > > > > The other part is the algorithm by which the provider select the > > content of each element in the layout. Since the content of each > > element may change dynamically by the provider this attribute only > > address the static information which is the algorithm and not the > > current content (who we see now in each element) which will need to > be > > conveyed also but probably not using this attribute. Note that the > > information is valid for point to point and multipoint so the = current > > content should reflect the TP end point and the specific VC used = from > > it. > > > > The algorithms may be global or per element(or sub-window). The > global > > algorithms I see are site switch or segment switch. The per element > > may be voice activated, round robin (switch every x seconds) and > fixed > > (the same VC is displayed there (may be changed by some control > > mechanism) > > > > > > Roni > > > > > -----Original Message----- > > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > Behalf > > > Of clue issue tracker > > > Sent: Tuesday, January 24, 2012 12:43 AM > > > To: draft-ietf-clue-framework@tools.ietf.org; > > > mary.ietf.barnes@gmail.com > > > Cc: clue@ietf.org > > > Subject: Re: [clue] #7: Is composed attribute a boolean or data > > > structure > > > > > > #7: Is composed attribute a boolean or data structure > > > > > > Changes (by mary.ietf.barnes@=E2=80=A6): > > > > > > * type: defect =3D> task > > > > > > > > > -- > > > = --------------------------------+---------------------------------- > - > > > --------------------------------+- > > - > > > --------------------------------+- > > > ---- > > > Reporter: mary.ietf.barnes@=E2=80=A6 | Owner: = draft-ietf-clue- > > > framework@=E2=80=A6 > > > Type: task | Status: new > > > Priority: major | Milestone: > > > Component: framework | Version: > > > Severity: Active WG Document | Resolution: > > > Keywords: | > > > = --------------------------------+---------------------------------- > - > > > --------------------------------+- > > - > > > --------------------------------+- > > > ---- > > > > > > Ticket URL: > > > > > > clue > > > > > > _______________________________________________ > > > clue mailing list > > > clue@ietf.org > > > https://www.ietf.org/mailman/listinfo/clue > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue From espeberg@cisco.com Tue Jan 31 07:38:04 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A8E911E80AA for ; Tue, 31 Jan 2012 07:38:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.549 X-Spam-Level: X-Spam-Status: No, score=-9.549 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6DbyGLmmla+I for ; Tue, 31 Jan 2012 07:38:03 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id B00BD11E80A4 for ; Tue, 31 Jan 2012 07:38:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=espeberg@cisco.com; l=12842; q=dns/txt; s=iport; t=1328024282; x=1329233882; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=dWlliEmljIK+j6Cw0V2vTZXHKpkkLbwaW5wiO+eEz6c=; b=WHb/1Px3eqTy77vUtYDOUbXrlVgw4k/2EvIaGzZTSHEwIQd6ukgaxDId 2RDOmXevqsxRiukq5MkG7WTy1v85KeqDC18Ygczw9ZGH/LGkuS40G8Oyb xJ8gV8BiDuJUxhmizs6ZkLEykdkyxYpvc0FzrsiM+upGa+RyDLTPflZLO A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFACgKKE+Q/khM/2dsb2JhbABDhQuoZm+BBYFyAQEBBAEBAQ8BEA0ENAYXBAIBCA4DBAEBAwIGBhcBAgICAQEfBh8JCAIEARIIGodjmiQBjGORfIEviVYNASkGAS0MAoQyDQIKAoInM2MEoCeHTg X-IronPort-AV: E=Sophos;i="4.71,596,1320624000"; d="scan'208";a="65053633" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 31 Jan 2012 15:37:59 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q0VFbxDt002378; Tue, 31 Jan 2012 15:37:59 GMT Received: from xmb-ams-214.cisco.com ([144.254.75.25]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 31 Jan 2012 16:37:59 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Tue, 31 Jan 2012 16:37:57 +0100 Message-ID: <92DF9533227FC14F946C7321074B8C9EE48A3C@XMB-AMS-214.cisco.com> In-Reply-To: <4f272344.03bd0e0a.6983.3d7e@mx.google.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] #7: Is composed attribute a boolean or data structure Thread-Index: AczaIHX5kbsR/L8BTXmfYvH+6pZxUwFEZeZQAAYsrwAABFxPgAABDkxwABCDGPAAIryQAA== References: <068.03e705c774d30abee11ba5026a664a26@trac.tools.ietf.org><083.e4945b5c72773c1362efdf7bb0443c4a@trac.tools.ietf.org> <4f266f4c.d0770e0a.43c6.37fd@mx.google.com> <92DF9533227FC14F946C7321074B8C9EE48845@XMB-AMS-214.cisco.com> <4f26ac4f.11840e0a.6db6.ffff9756@mx.google.com> <92DF9533227FC14F946C7321074B8C9EE48877@XMB-AMS-214.cisco.com> <4f272344.03bd0e0a.6983.3d7e@mx.google.com> From: "Espen Berger (espeberg)" To: "Roni Even" , X-OriginalArrivalTime: 31 Jan 2012 15:37:59.0082 (UTC) FILETIME=[4F5268A0:01CCE02E] Subject: Re: [clue] #7: Is composed attribute a boolean or data structure X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 15:38:04 -0000 SGkgUm9ueSANCg0KVG8gY2hvb3NlIGJldHdlZW4gc2l0ZSBhbmQgc2VnbWVudCBzd2l0Y2ggaXMg bW9yZSBhIHBvbGljeSB0aGFuIGEgPHZpZGVvLWxheW91dD4sIHNvIGluIHRoYXQgY2FzZSBJIHdv dWxkIGFyZ3VlIHRoYXQgeW91IGNvdWxkIG9mZmVyIGEgQ2FwdHVyZSBzdHJlYW0gd2l0aCBhIHN3 aXRjaC1wb2xpY3kgPSB7c2l0ZSwgc2VnbWVudH0NCg0KTXkgcG9pbnQgYWJvdXQgaW50ZXJvcGVy YWJpbGl0eSBpcyB0aGF0IGEgc2luZ2xlIGNvbXBvc2VkIHN0cmVhbSB3aXRoIGFsdGVybmF0aXZl IGxheW91dHMgYXJlIGVhc2llciB0byB1bmRlcnN0YW5kLCB0aGFuIG11bHRpcGxlIGNhcHR1cmUg c3RyZWFtcyB3aXRoIGFsdGVybmF0aXZlIGNvbmZpZ3VyYXRpb25zLiBUaGUgbGFzdCByZXF1aXJl cyB0byBwaWNrIHRoZSBmaXJzdCBvbmUgb3IgcmVxdWlyZXMgc29tZSBzb3J0IG9mIGRlZmF1bHQg bWFya2luZy4gIA0KDQpDaGVlcnMgDQoNCi1Fc3BlbiANCg0KDQotLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KRnJvbTogUm9uaSBFdmVuIFttYWlsdG86cm9uLmV2ZW4udGx2QGdtYWlsLmNvbV0g DQpTZW50OiAzMS4gamFudWFyIDIwMTIgMDA6MDYNClRvOiBFc3BlbiBCZXJnZXIgKGVzcGViZXJn KTsgY2x1ZUBpZXRmLm9yZw0KU3ViamVjdDogUkU6IFtjbHVlXSAjNzogSXMgY29tcG9zZWQgYXR0 cmlidXRlIGEgYm9vbGVhbiBvciBkYXRhIHN0cnVjdHVyZQ0KDQpIaSBFc3BlbiwNCklmIHRoZSBw cm92aWRlciB3YW50cyB0byBvZmZlciBzaXRlIHN3aXRjaCBhbmQgc2VnbWVudCBzd2l0Y2ggb3B0 aW9uIHRvIHRoZSBjb25zdW1lciBoZSBjYW5ub3QgZG8gaXQganVzdCB3aXRoIEEuIHRoaXMgaXMg YSBiYXNpYyB1c2UgY2FzZS4NCg0KSW4gZ2VuZXJhbCwgeW91ciBvcHRpb24gZG9lcyBub3QgcHJv dmlkZSBhbnkgaW50ZXJvcGVyYWJpbGl0eSBzaW5jZSBib3RoIHNpZGVzIG1heSBoYXZlIGRpZmZl cmVudCB2aWV3cyB3aGF0IGNvbXBvc2VkIG1lYW5zLiBJbiB0aGUgZnJhbWV3b3JrIGV4YW1wbGUg b2YgYSBQSVAgYXMgY29tcG9zZWQgaW1hZ2UgaXQgaXMgYW4gYXNzdW1wdGlvbiB0aGF0IGlmIHRo ZSBwcm92aWRlciBvZmZlcnMgdGhpcyBjb21wb3NlZCBvZmZlciwgdGhlIGNvbnN1bWVyIGNhbiB1 bmRlcnN0YW5kIHRoYXQgaXQgaXMgYSBQSVAgbWl4IGJ1dCB0aGVyZSBpcyBub3RoaW5nIGluIHRo ZSBvZmZlciB0aGF0IHdpbGwgaW5kaWNhdGUgdGhhdCBpdCBpcy4NCg0KUm9uaSANCg0KPiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBFc3BlbiBCZXJnZXIgKGVzcGViZXJnKSBb bWFpbHRvOmVzcGViZXJnQGNpc2NvLmNvbV0NCj4gU2VudDogTW9uZGF5LCBKYW51YXJ5IDMwLCAy MDEyIDU6MjEgUE0NCj4gVG86IFJvbmkgRXZlbjsgY2x1ZUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBS RTogW2NsdWVdICM3OiBJcyBjb21wb3NlZCBhdHRyaWJ1dGUgYSBib29sZWFuIG9yIGRhdGENCj4g c3RydWN0dXJlDQo+IA0KPiBIaSBSb25pDQo+IA0KPiBJZiB5b3XigJlyZSBhIHBhcnRpY3VsYXIg dXNlIGNhc2VzIHJlcXVpcmVzIGNvbnRyb2wgb3ZlciB0aGUgY29tcG9zZWQNCj4gbGF5b3V0cyB5 b3UgbmVlZCBhKSBhbmQgYikuIEluIG15IGV4YW1wbGUgSSB1c2VkIGEgc2luZ2xlIGFkdmVydGlz ZW1lbnQNCj4gY29tcG9zZWQgc3RyZWFtIHdpdGggb3B0aW9uYWwgbWV0YS1pbmZvcm1hdGlvbiBh Ym91dCBwb3NzaWJsZSBsYXlvdXQNCj4gY2hvaWNlcy4gQSByZWNlaXZlciB0aGF0IHdhbnRzIHRo ZSBkZWZhdWx0IGNvbXBvc2VkIGxheW91dCBjYW4gcmVxdWVzdA0KPiB0aGUgY29tcG9zZWQgc3Ry ZWFtIGFuZCBza2lwIHRoZSBvcHRpb25hbCB2aWRlby1sYXlvdXQgaW5mb3JtYXRpb24uDQo+IE9w dGlvbmFsbHkgeW91IGNvdWxkIHJlcXVlc3QgdGhlIHNhbWUgY29tcG9zZWQgc3RyZWFtIHdpdGgg bGF5b3V0cw0KPiBoaW50cyBmb3IgdGhlIHJlY2VpdmVyLg0KPiANCj4gRm9yIG1lIHVzZSBjYXNl IGMpIGRvZXMgbm90IGluY2x1ZGUgdGhlIHNlbGVjdGlvbiBtZWNoYW5pc21zLCBvbmx5IHRoZQ0K PiBjb250ZW50IHlvdSBzZWUgaW4gdGhlIHZpZGVvIHN0cmVhbS4NCj4gDQo+IENoZWVycw0KPiAN Cj4gLUVzcGVuDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBSb25p IEV2ZW4gW21haWx0bzpyb24uZXZlbi50bHZAZ21haWwuY29tXQ0KPiBTZW50OiAzMC4gamFudWFy IDIwMTIgMTU6MzkNCj4gVG86IEVzcGVuIEJlcmdlciAoZXNwZWJlcmcpOyBjbHVlQGlldGYub3Jn DQo+IFN1YmplY3Q6IFJFOiBbY2x1ZV0gIzc6IElzIGNvbXBvc2VkIGF0dHJpYnV0ZSBhIGJvb2xl YW4gb3IgZGF0YQ0KPiBzdHJ1Y3R1cmUNCj4gDQo+IEhpIEVzcGVuLA0KPiBJZiB5b3Ugd2lsbCBs b29rIGF0IHRoZSBub3RlcyBmcm9tIHRoZSBsYXN0IGNhbGwgdGhlcmUgd2FzIGEgc3VwcG9ydA0K PiB0aGF0IGEpIGlzIG5vdCBlbm91Z2guIEhhdmluZyBqdXN0IGNvbXBvc2UgZG9lcyBub3QgYWRk cmVzcyBldmVuIHRoZQ0KPiB1c2UgY2FzZXMgSSBwcm92aWRlZCB3aGljaCBhcmUgYWxzbyBiYXNl ZCBvbiB0aGUgdXNlIGNhc2UgZHJhZnQuDQo+IA0KPiANCj4gSSBhbSBub3Qgc3VyZSB3aGF0IHlv dSBtZWFuIGJ5IEMgc2luY2Ugd2hhdCBpbiB0aGUgY29tcG9zZWQgc3RyZWFtIGNhbg0KPiBiZSBl aXRoZXIgd2hpY2ggVkMgeW91IHNlZSBvciB3aGF0IGlzIHRoZSBzZWxlY3Rpb24gY3JpdGVyaWEg Zm9yIGJlaW5nDQo+IGluIGEgY29tcG9zZWQgc3RyZWFtLiBJZiB5b3UgbWVhbnQgdGhlIHNlY29u ZCwgbXkgdmlldyBpcyB0aGF0IEMgYW5kDQo+IGFsc28gYiBzaG91bGQgYmUgaW4gdGhlIGJhc2lj IGZyYW1ld29yayBhbmQgbm90IGluIGFuIGV4dGVuc2lvbi4NCj4gDQo+IFJvbmkgRXZlbg0KPiAN Cj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IEVzcGVuIEJlcmdlciAo ZXNwZWJlcmcpIFttYWlsdG86ZXNwZWJlcmdAY2lzY28uY29tXQ0KPiA+IFNlbnQ6IE1vbmRheSwg SmFudWFyeSAzMCwgMjAxMiA0OjE3IFBNDQo+ID4gVG86IFJvbmkgRXZlbjsgY2x1ZUBpZXRmLm9y Zw0KPiA+IFN1YmplY3Q6IFJFOiBbY2x1ZV0gIzc6IElzIGNvbXBvc2VkIGF0dHJpYnV0ZSBhIGJv b2xlYW4gb3IgZGF0YQ0KPiA+IHN0cnVjdHVyZQ0KPiA+DQo+ID4NCj4gPiBUbyBoZWxwIHdpdGgg dGhlIGRpcmVjdGlvbiBvZiB0aGUgZGlzY3Vzc2lvbnMgSSB0aGluayBpdCdzIHVzZWZ1bCB0bw0K PiA+IGRpdmlkZSB0aGUgZGlzY3Vzc2lvbnMgaW50byB0aHJlZSB1c2UgY2FzZXMgZm9yIGNvbXBv c2VkIHN0cmVhbXMuDQo+ID4gIGEpIEhvdyB0byBleHByZXNzIGlmIGEgY2FwdHVyZSBzdHJlYW0g aXMgY29tcG9zZWQgb3Igbm90DQo+ID4gIGIpIEhvdyB0byBleHByZXNzIGxheW91dCBjaG9pY2Vz PyAoZS5nLiB3aXRoIGEgdmlkZW8tbGF5b3V0IGVsZW1lbnQpDQo+ID4gIGMpIEhvdyB0byBleHBy ZXNzIHdoYXQncyBpbnNpZGUgYSBjb21wb3NlZCBzdHJlYW0NCj4gPg0KPiA+IEZvciB1c2UgY2Fz ZSBhKSBhIGNvbXBvc2VkIGF0dHJpYnV0ZSBzaG91bGQgYmUgc3VmZmljaWVudCwgeW91IGVpdGhl cg0KPiA+IGFzayBmb3IgdGhlIGNvbXBvc2VkIHN0cmVhbSBvciB5b3UgZG8gbm90Lg0KPiA+IEkg YWxzbyBiZWxpZXZlIHRoaXMgc2hvdWxkIGNvdmVyIHRoZSBpbnRlcm9wZXJhYmlsaXR5IHJlcXVp cmVtZW50IHdlDQo+ID4gaGF2ZSBhY3Jvc3MgbXVsdGlwbGUgdHlwZXMgb2YgZW5kcG9pbnRzLg0K PiA+DQo+ID4gRm9yIHVzZSBjYXNlIGIpIGJvdGggbWVkaWFjdHJsIGFuZCB4Y29uIHVzZXMgYSA8 dmlkZW8tbGF5b3V0PiBlbGVtZW50DQo+ID4gdG8gZGVzY3JpYmUgcG9zc2libGUgbGF5b3V0cyBh bmQgYWxzbyB0byByZXF1ZXN0IHRoZSBwcmVmZXJyZWQgbGF5b3V0DQo+ID4gYmFzZWQgb24gb3B0 aW9ucy4gKGFzIGRlc2NyaWJlZCBpbiBSb25pJ3MgZW1haWwpDQo+ID4NCj4gPiBBbiBleGFtcGxl IGNvdWxkIGJlIChpbnNwaXJlZCBieSBtZWRpYWN0cmwgYW5kIHhjb24gdXNhZ2Ugb2YgPHZpZGVv LQ0KPiA+IGxheW91dD4pOg0KPiA+DQo+ID4gQ0xVRSBBZHZlcnRpc2VtZW50DQo+ID4gICBDYXB0 dXJlIGlkPTIgUHVycG9zZT1wZW9wbGUgQ29tcG9zZWQ9ZmFsc2UNCj4gPiAgIENhcHR1cmUgaWQ9 MyBQdXJwb3NlPXBlb3BsZSBDb21wb3NlZD1mYWxzZQ0KPiA+ICAgQ2FwdHVyZSBpZD00IFB1cnBv c2U9UGVvcGxlIENvbXBvc2VkPXRydWUNCj4gPiAgICAgICBWaWRlby1sYXlvdXQ9IidhdXRvbWF0 aWMnLCAnZHVhbC12aWV3JywgJyBzaW5nbGUtdmlldyciDQo+ID4NCj4gPiBDTFVFIGNvbmZpZ3Vy ZSAvLyBEZWZhdWx0IGNvbXBvc2VkIHN0cmVhbQ0KPiA+ICAgQ2FwdHVyZSBpZD00DQo+ID4NCj4g PiAvLyBPciBjb21wb3NlZCBzdHJlYW0gd2l0aCBsYXlvdXQgaGludHMNCj4gPiAgICBDYXB0dXJl IGlkPTQgVmlkZW8tbGF5b3V0PSdkdWFsLXZpZXcnDQo+ID4NCj4gPiBUaGUgdmlkZW8tbGF5b3V0 IGVsZW1lbnQgaXMgYSBsaXN0IG9mIHN0cmluZ3MgYW5kIGVhY2ggc3RyaW5nIGlzIGENCj4gPiBs YXlvdXQtaGludCB0aGF0IGNhbiBiZSByZXF1ZXN0ZWQuIFZpZGVvLWxheW91dCBpcyBvcHRpb25h bC4gQSBsYXlvdXQNCj4gPiBoaW50cyBhYm91dCB0aGUgcmVxdWVzdGVkIHJlbmRlcmluZyBhbmQg dGhlIHNvdXJjZSBpcyBmcmVlIHRvIHJlcGxhY2UNCj4gPiBhbnkgc3RyZWFtIGFzIGxvbmcgYXMg dGhleSBmaXQgdGhlIGxheW91dC4NCj4gPg0KPiA+IFVzZSBjYXNlIGMpIGlzIG1vcmUgb3BlbiBp biB0aGUgc2Vuc2UgdGhhdCB3aGF0IHlvdSBhY3R1YWxseSByZWNlaXZlDQo+ID4gaW4gYSBjb21w b3NlZCBzdHJlYW0gaXMgZGVwZW5kaW5nIG9uIHN0YXR1cyBvZiBhIHJvb20gb3Igd2hvIGlzIGlu IGENCj4gPiBNQ1UgY29uZmVyZW5jZS4gRS5nLiBmcm9tIGEgcm9vbSB5b3UgY291bGQgZ2V0IGEg bWl4IG9mIGRpZmZlcmVudA0KPiA+IGNhcHR1cmUgc3RyZWFtIHJlcHJlc2VudGluZyBjYW1lcmFz IGFuZCBmcm9tIGEgdHJhbnNjb2RpbmcgTUNVIGl0DQo+ID4gY291bGQgYmUgZGlmZmVyZW50IHJv b20sIGRpZmZlcmVudCBjYW1lcmFzIG9yIGFub3RoZXIgbWl4IG9mIHBvc3NpYmxlDQo+ID4gaW5w dXQgdmlkZW8gc3RyZWFtcy4NCj4gPg0KPiA+IEhhdmluZyBzdXBwb3J0IGZvciBib3RoIGIpIGFu ZCBjKSBjb3VsZCBiZSBhIGdvb2QgdGVzdCBmb3IgdGhlDQo+ID4gZXh0ZW5zaWJpbGl0eSBvZiBD TFVFLiBJZiB0aGUgYmFzaXMgb2YgQ0xVRSBvbmx5IGRvZXMgdXNlIGNhc2UgYSkNCj4gPiB0aGVy ZSBzaG91bGQgYmUgcm9vbSB0byBleHRlbmQgQ0xVRSB3aXRoIHN1cHBvcnQgZm9yIGIpIGFuZCBj KSBhcyBhDQo+ID4gQ0xVRSArIGxheW91dCBkZXNjcmlwdGlvbiBleHRlbnNpb24uDQo+ID4NCj4g PiBDaGVlcnMNCj4gPg0KPiA+IC1Fc3Blbg0KPiA+DQo+ID4NCj4gPg0KPiA+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogY2x1ZS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86 Y2x1ZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj4gPiBPZiBSb25pIEV2ZW4NCj4gPiBT ZW50OiAzMC4gamFudWFyIDIwMTIgMTE6MTgNCj4gPiBUbzogY2x1ZUBpZXRmLm9yZw0KPiA+IFN1 YmplY3Q6IFJlOiBbY2x1ZV0gIzc6IElzIGNvbXBvc2VkIGF0dHJpYnV0ZSBhIGJvb2xlYW4gb3Ig ZGF0YQ0KPiA+IHN0cnVjdHVyZQ0KPiA+DQo+ID4gSGksDQo+ID4gRHVyaW5nIHRoZSBsYXN0IGNh bGwgSSB2b2x1bnRlZXJlZCB0byBwcm92aWRlIHNvbWUgaW5wdXQuDQo+ID4NCj4gPiBJbiBjdXJy ZW50IElFVEYgd29yayAoWENPTiwgTWVkaWFjdHJsIFdHcyB0aGVyZSBpcyBhIHZpZGVvIGxheW91 dA0KPiA+IGVsZW1lbnQpDQo+ID4NCj4gPiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLW1lZGlhY3RybC1taXhlci1jb250cm9sLQ0KPiBwYWNrYWdlLQ0KPiA+IDE0I3NlY3Rp b24tNC4yLjEuNC4yLjENCj4gPg0KPiA+IGFuZA0KPiA+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWlldGYteGNvbi1jb21tb24tZGF0YS1tb2RlbC0NCj4gPiAzMiNzZWN0aW9uLTQu Mi43IChsb29rIGF0IHZpZGVvLWxheW91dCkNCj4gPg0KPiA+IEkgd291bGQgbGlrZSBmaXJzdCB0 byB0cnkgdG8gZGVmaW5lIHRoZSB0ZXJtICJjb21wb3NlZCB2aWRlbyIgc2luY2UNCj4gaXQNCj4g PiBsb29rcyB0byBtZSBsaWtlIHdlIGhhdmUgZGlmZmVyZW50IHZpZXdzIGhlcmUsIGFuZCBwcm92 aWRlIG15IGluaXRpYWwNCj4gPiB2aWV3IG9uIHdoYXQgc2hvdWxkIGJlIGRlc2NyaWJlZC4NCj4g Pg0KPiA+IENvbXBvc2VkIHZpZGVvIGNhbiBkZXNjcmliZXMgYm90aCB0aGUgbGF5b3V0IGFuZCB0 aGUgc2VsZWN0aW9uDQo+ID4gYWxnb3JpdGhtIGZvciBjb21wb3NpbmcgdGhlICBjb250ZW50IG9m IHRoZSBzdWItd2luZG93cyBpbiB0aGUNCj4gIm1peGVkIg0KPiA+IHZpZGVvLg0KPiA+DQo+ID4g VGhlIHZpZGVvIGxheW91dCB3aGljaCBqdXN0IGRlc2NyaWJlcyB0aGUgZ2VvbWV0cnkgb2YgdGhl IGNvbXBvc2VkDQo+ID4gaW1hZ2UgYW5kIEkgdGhpbmsgdGhhdCB0aGUgYWJvdmUgcmVmZXJlbmNl cyBwcm92aWRlIGdvb2Qgc3RydWN0dXJlIHRvDQo+ID4gZGVmaW5lIHRoaXMgcGFydCBvZiB0aGUg Y29tcG9zZWQgdmlkZW8gYXR0cmlidXRlLg0KPiA+DQo+ID4gVGhlIG90aGVyIHBhcnQgaXMgdGhl IGFsZ29yaXRobSBieSB3aGljaCB0aGUgcHJvdmlkZXIgc2VsZWN0IHRoZQ0KPiA+IGNvbnRlbnQg b2YgZWFjaCBlbGVtZW50IGluIHRoZSBsYXlvdXQuIFNpbmNlIHRoZSBjb250ZW50IG9mIGVhY2gN Cj4gPiBlbGVtZW50IG1heSBjaGFuZ2UgZHluYW1pY2FsbHkgYnkgdGhlIHByb3ZpZGVyIHRoaXMg YXR0cmlidXRlIG9ubHkNCj4gPiBhZGRyZXNzIHRoZSBzdGF0aWMgaW5mb3JtYXRpb24gd2hpY2gg aXMgdGhlIGFsZ29yaXRobSBhbmQgbm90IHRoZQ0KPiA+IGN1cnJlbnQgY29udGVudCAod2hvIHdl IHNlZSBub3cgaW4gZWFjaCBlbGVtZW50KSB3aGljaCB3aWxsIG5lZWQgdG8NCj4gYmUNCj4gPiBj b252ZXllZCBhbHNvIGJ1dCBwcm9iYWJseSBub3QgdXNpbmcgdGhpcyBhdHRyaWJ1dGUuIE5vdGUg dGhhdCB0aGUNCj4gPiBpbmZvcm1hdGlvbiBpcyB2YWxpZCBmb3IgcG9pbnQgdG8gcG9pbnQgYW5k IG11bHRpcG9pbnQgc28gdGhlIGN1cnJlbnQNCj4gPiBjb250ZW50IHNob3VsZCByZWZsZWN0IHRo ZSBUUCBlbmQgcG9pbnQgYW5kIHRoZSBzcGVjaWZpYyBWQyB1c2VkIGZyb20NCj4gPiBpdC4NCj4g Pg0KPiA+IFRoZSBhbGdvcml0aG1zIG1heSBiZSBnbG9iYWwgb3IgcGVyIGVsZW1lbnQob3Igc3Vi LXdpbmRvdykuIFRoZQ0KPiBnbG9iYWwNCj4gPiBhbGdvcml0aG1zIEkgc2VlIGFyZSBzaXRlIHN3 aXRjaCBvciBzZWdtZW50IHN3aXRjaC4gVGhlIHBlciBlbGVtZW50DQo+ID4gbWF5IGJlIHZvaWNl IGFjdGl2YXRlZCwgcm91bmQgcm9iaW4gKHN3aXRjaCBldmVyeSB4IHNlY29uZHMpIGFuZA0KPiBm aXhlZA0KPiA+ICh0aGUgc2FtZSBWQyBpcyBkaXNwbGF5ZWQgdGhlcmUgKG1heSBiZSBjaGFuZ2Vk IGJ5IHNvbWUgY29udHJvbA0KPiA+IG1lY2hhbmlzbSkNCj4gPg0KPiA+DQo+ID4gUm9uaQ0KPiA+ DQo+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gRnJvbTogY2x1ZS1ib3Vu Y2VzQGlldGYub3JnIFttYWlsdG86Y2x1ZS1ib3VuY2VzQGlldGYub3JnXSBPbg0KPiBCZWhhbGYN Cj4gPiA+IE9mIGNsdWUgaXNzdWUgdHJhY2tlcg0KPiA+ID4gU2VudDogVHVlc2RheSwgSmFudWFy eSAyNCwgMjAxMiAxMjo0MyBBTQ0KPiA+ID4gVG86IGRyYWZ0LWlldGYtY2x1ZS1mcmFtZXdvcmtA dG9vbHMuaWV0Zi5vcmc7DQo+ID4gPiBtYXJ5LmlldGYuYmFybmVzQGdtYWlsLmNvbQ0KPiA+ID4g Q2M6IGNsdWVAaWV0Zi5vcmcNCj4gPiA+IFN1YmplY3Q6IFJlOiBbY2x1ZV0gIzc6IElzIGNvbXBv c2VkIGF0dHJpYnV0ZSBhIGJvb2xlYW4gb3IgZGF0YQ0KPiA+ID4gc3RydWN0dXJlDQo+ID4gPg0K PiA+ID4gIzc6IElzIGNvbXBvc2VkIGF0dHJpYnV0ZSBhIGJvb2xlYW4gb3IgZGF0YSBzdHJ1Y3R1 cmUNCj4gPiA+DQo+ID4gPiBDaGFuZ2VzIChieSBtYXJ5LmlldGYuYmFybmVzQOKApik6DQo+ID4g Pg0KPiA+ID4gICogdHlwZTogIGRlZmVjdCA9PiB0YXNrDQo+ID4gPg0KPiA+ID4NCj4gPiA+IC0t DQo+ID4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQo+IC0NCj4gPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tKy0NCj4gPiAtDQo+ID4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSst DQo+ID4gPiAtLS0tDQo+ID4gPiAgUmVwb3J0ZXI6ICBtYXJ5LmlldGYuYmFybmVzQOKApiAgfCAg ICAgICBPd25lcjogIGRyYWZ0LWlldGYtY2x1ZS0NCj4gPiA+IGZyYW1ld29ya0DigKYNCj4gPiA+ ICAgICAgVHlwZTogIHRhc2sgICAgICAgICAgICAgICAgfCAgICAgIFN0YXR1czogIG5ldw0KPiA+ ID4gIFByaW9yaXR5OiAgbWFqb3IgICAgICAgICAgICAgICB8ICAgTWlsZXN0b25lOg0KPiA+ID4g Q29tcG9uZW50OiAgZnJhbWV3b3JrICAgICAgICAgICB8ICAgICBWZXJzaW9uOg0KPiA+ID4gIFNl dmVyaXR5OiAgQWN0aXZlIFdHIERvY3VtZW50ICB8ICBSZXNvbHV0aW9uOg0KPiA+ID4gIEtleXdv cmRzOiAgICAgICAgICAgICAgICAgICAgICB8DQo+ID4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IC0NCj4gPiA+ IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0NCj4gPiAtDQo+ID4gPiAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstDQo+ID4gPiAtLS0tDQo+ID4gPg0KPiA+ID4gVGlj a2V0IFVSTDoNCj4gPiA+IDxodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy93Zy9jbHVlL3RyYWMv dGlja2V0LzcjY29tbWVudDoyPg0KPiA+ID4gY2x1ZSA8aHR0cDovL3Rvb2xzLmlldGYub3JnL3dn L2NsdWUvPg0KPiA+ID4NCj4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+ID4gPiBjbHVlIG1haWxpbmcgbGlzdA0KPiA+ID4gY2x1ZUBpZXRmLm9y Zw0KPiA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jbHVlDQo+ID4N Cj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ IGNsdWUgbWFpbGluZyBsaXN0DQo+ID4gY2x1ZUBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vY2x1ZQ0KDQoNCg== From marshall.eubanks@gmail.com Tue Jan 31 09:17:40 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E28F21F85CF for ; Tue, 31 Jan 2012 09:17:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.514 X-Spam-Level: X-Spam-Status: No, score=-103.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pJaSdWpe01ZP for ; Tue, 31 Jan 2012 09:17:39 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id AD54521F85C6 for ; Tue, 31 Jan 2012 09:17:39 -0800 (PST) Received: by obbwd15 with SMTP id wd15so219074obb.31 for ; Tue, 31 Jan 2012 09:17:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=4aA7x3xzBPLNrvt7f16+qo6QDSDk96GuVPOHj0Wpur4=; b=aU+DhGGnzEjKMPX+IM964bNoJtqoSrxh9YHCSuaTt9ywqfsxZaOyAvs3H5IMQDha10 0EzVLPpqGEsSVkGHMU1ytjljT/P6kEUPS+2uQqv2uKbsDdeeCdZ6p4ypkrYNVVytNQ+g Qe/m5ieUnOJsTDFDScGJT8h8hu2qBQHXAe2R0= MIME-Version: 1.0 Received: by 10.182.75.102 with SMTP id b6mr21791787obw.9.1328030259358; Tue, 31 Jan 2012 09:17:39 -0800 (PST) Received: by 10.182.52.134 with HTTP; Tue, 31 Jan 2012 09:17:39 -0800 (PST) In-Reply-To: <4F26EC09.8000504@alum.mit.edu> References: <244633145.1327950641237.JavaMail.nobody@jva2wl006.webex.com> <4F26EC09.8000504@alum.mit.edu> Date: Tue, 31 Jan 2012 12:17:39 -0500 Message-ID: From: Marshall Eubanks To: Paul Kyzivat Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: CLUE Subject: Re: [clue] Fwd: Meeting rescheduled: CLUE WG design team X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 17:17:40 -0000 I am sorry I missed this. Somehow in the rescheduling I lost my iCal notification, and so worked through it. I have taken steps to make sure that doesn't happen again. Looking forward to the minutes... Marshall On Mon, Jan 30, 2012 at 2:14 PM, Paul Kyzivat wrote= : > Since we were having trouble with the way the meeting was set up, > I recreated it. This one seems to be more "normal" than the last one. > > So please disregard prior meeting info and use this instead. > > =A0 =A0 =A0 =A0Thanks, > =A0 =A0 =A0 =A0Paul > > -------- Original Message -------- > Subject: =A0 =A0 =A0 =A0Meeting rescheduled: CLUE WG design team > Date: =A0 Mon, 30 Jan 2012 19:10:41 +0000 (GMT) > From: =A0 Clue Working Group > Reply-To: =A0 =A0 =A0 clue-chairs@tools.ietf.org > To: =A0 =A0 clue-chairs@tools.ietf.org > > > > > Hello Clue Working Group, > > Clue Working Group changed the time for this online meeting. > > Topic: CLUE WG design team > Date: Tuesday, January 31, 2012 > Time: 9:00 am, Central Standard Time (Chicago, GMT-06:00) > Meeting Number: 646 813 366 > Meeting Password: 1234 > > > ------------------------------------------------------- > To join the online meeting (Now from mobile devices!) > ------------------------------------------------------- > 1. Go to > https://ietf.webex.com/ietf/j.php?ED=3D149458212&UID=3D1232762747&PW=3DNZ= TMxM2M5NTY4&RT=3DMiM3 > > > 2. If requested, enter your name and email address. > 3. If a password is required, enter the meeting password: 1234 > 4. Click "Join". > > To view in other time zones or languages, please click the link: > https://ietf.webex.com/ietf/j.php?ED=3D149458212&UID=3D1232762747&PW=3DNZ= TMxM2M5NTY4&ORT=3DMiM3 > > > > ------------------------------------------------------- > To join the audio conference only > ------------------------------------------------------- > Call-in toll number (US/Canada): +1-408-600-3600 > > Access code:646 813 366 > > ------------------------------------------------------- > For assistance > ------------------------------------------------------- > 1. Go to https://ietf.webex.com/ietf/mc > 2. On the left navigation bar, click "Support". > > You can contact me at: > clue-chairs@tools.ietf.org > > > To update this meeting to your calendar program (for example Microsoft > Outlook), click this link: > https://ietf.webex.com/ietf/j.php?ED=3D149458212&UID=3D1232762747&ICS=3DM= RS3&LD=3D1&RD=3D2&ST=3D1&SHA2=3Dfj0QH5rHXvBURuzOPc2LdjC4C0hMV7l6VxyGnTV4m2w= =3D&RT=3DMiM3 > > > > > WebEx will automatically setup Meeting Manager for Windows the first > time you join a meeting. To save time, you can setup prior to the > meeting by clicking this link: > https://ietf.webex.com/ietf/meetingcenter/mcsetup.php > > > The playback of UCF (Universal Communications Format) rich media files > requires appropriate players. To view this type of rich media files in > the meeting, please check whether you have the players installed on your > computer by going to https://ietf.webex.com/ietf/systemdiagnosis.php. > > Sign up for a free trial of WebEx > http://www.webex.com/go/mcemfreetrial > > http://www.webex.com > > CCP:+14086003600x646813366# > > IMPORTANT NOTICE: This WebEx service includes a feature that allows > audio and any documents and other materials exchanged or viewed during > the session to be recorded. By joining this session, you automatically > consent to such recordings. If you do not consent to the recording, > discuss your concerns with the meeting host prior to the start of the > recording or do not join the session. Please note that any such > recordings may be subject to discovery in the event of litigation. > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue