HI all,

Unfortunately, we've had a = number of people that are not able to attend a f2f meeting due to lack of t= ravel funding, time commitments and personal conflicts. =A0I do want to tha= nk Simon et al for their willingness to host a f2f meeting and I still inte= nd to get to Naples somehow in the near future ;)

So, Paul and I have chatted and we are proposing a virt= ual interim meeting instead. =A0As we discussed one of the benefits of a f2= f is getting everyone in one place since we do have a timezone split across= the group that makes it difficult to get everyone on a call at the same ti= me. =A0So, we'd really like to get 100% participation from our key cont= ributors (i.e., document authors and reviewers). =A0As a compromise, we are= proposing a 3pm Eastern meeting start for a 2 hour meeting. =A0I know this= is quite late for Europe & Israel and quite early for folks in Asia an= d Australia. =A0But, hopefully, folks can make the sacrifice this one time = - I realize that's very easy for me say given my timezone ;) =A0

So, here's the doodle: =A0

http://doodle.com/b5qtvb3ar5t25xad

= Please consider using the yellow if it's not an optimal time but if you= 're willing to make the sacrifice for that time. =A0=A0

Please respond to the doodle no later than Wednesday, A= pril 2nd at noon Eastern, so that we can make a decision.

Thanks,

Mary

=A0

--e89a8f3bac59d5f78d04f586d714-- From nobody Wed Mar 26 12:22:34 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E4561A03F7 for ; Wed, 26 Mar 2014 12:22:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3wFO7t4XUA0i for ; Wed, 26 Mar 2014 12:22:32 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id A71651A03F3 for ; Wed, 26 Mar 2014 12:22:31 -0700 (PDT) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta15.westchester.pa.mail.comcast.net with comcast id iHv11n00E16LCl05FKNWbN; Wed, 26 Mar 2014 19:22:30 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id iKNV1n00L3ZTu2S3SKNVoS; Wed, 26 Mar 2014 19:22:30 +0000 Message-ID: <533328F5.1070306@alum.mit.edu> Date: Wed, 26 Mar 2014 15:22:29 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: clue@ietf.org References: <49E45C59CA48264997FEBFB29B6BC2D60C9CF16009@CRPMBOXPRD07.polycom.com> <52DC8BFC.6050705@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D60C9D2FB1BE@CRPMBOXPRD07.polycom.com> <52F42FC4.5070104@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D617AC5365DF@CRPMBOXPRD07.polycom.com> <20140326001139.GD99797@verdi> <53329AE2.4050302@unina.it> <49E45C59CA48264997FEBFB29B6BC2D617ACF1ACE8@CRPMBOXPRD07.polycom.com> <53330844.9040705@unina.it> <49E45C59CA48264997FEBFB29B6BC2D617ACF1ADBF@CRPMBOXPRD07.polycom.com> <20140326183424.GF99797@verdi> In-Reply-To: <20140326183424.GF99797@verdi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1395861750; bh=MTkWyTTd1Xcda6mpvUfU2tKqbYQeNwxeN5pFcOgpiuU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Sfhq6GvdcjYGLuKZ6MkMZJLiVGsYsxhoAsLZf6ueJE1HZXZ8R+7/bmghoXz7bFNBU FE3xnxr6DRHIxQjvXmJxNVTuisbbRS9rXDDoZJ+uZxRaK3/S3J3JWn4xfjgBj/nL5A NlsYz/z2A+mX7HN9Qubgb7Tnxxo//Q9yuOjCWfUQ0MRX1Q8X6engdNzgznVsCtBJTl nf1q5+VgYflV3wtdeUtVLxSr8bhgsDAq50lPlXZjhb8Lbbo6hgf8X93VrQk8XCF+fK aecl2gQz7FjYBpG2kd7+1R78UCieY5Ahoxj/78WNNNb0yRjiqhZ8yXXZs7hKhVZ9xw I2hdB5wsCNcPg== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/_FNZ0I6O7DUfUOXY-RPGGX1t-Ro Subject: Re: [clue] should be optional X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 26 Mar 2014 19:22:33 -0000 On 3/26/14 2:34 PM, John Leslie wrote: > I'm still struggling to understand what a > instance without a _means_ ... I have a little trouble with this too, though it may be that I don't conceptualize this correctly. We have area of capture, but that is a planar region. I keep wanting to think of that as an "area of display" that is ideal to render the capture. But to use that, I need to know which side of the display should be the front. Without a capture point, I don't know that. I suspect that there is an implicit assumption that the "front" of the area of capture will always be the side that puts the smallest X coordinate to the left of the larger X coordinate. I don't think we should assume such things. Thanks, Paul > Duckworth, Mark wrote: >> From: Roberta Presta [mailto:roberta.presta@unina.it] >>> >>> For the case you have proposed, the ADV could be the following: >>> >>> capture scene A: captures coming from room A >>> capture scene B: captures coming from room B >>> capture scene C: captures coming from room C > > Three quite independent captures... I get this part... > >>> capture scene D: >>> MCC A (from room A's captures) - to be rendered on the left, >>> MCC B (from room B's captures) - to be rendered on the centre, >>> MCC C (from room C's capture) - to be rendered on the right > > I'm struggling here. "To be rendered..." seems to be a suggestion > to the receiver, with (AFAICT) no spatial relationship to anything in > Capture Scene A, B, C, or D. > > Why is an appropriate tool for this advice? > >>> where the "to be rendered" information are represented by means of the >>> within the tag associated to the MCCs. > > has always bothered me, because it is a two-dimensional > quantity, while we interact in three-dimensional space. I suppose I should > have objected to including it at all in ; but until > now I thought we understood it to be defining space in a plane within > our three-dimensional interaction space (and therefore a three-dimensional > space from to the ). > > I find the idea of collapsing into dimensionless space > a bit too confusing. In particular, I am cringing in fear that someone > will try to use this anti-physical concept to describe audio... > > -- > John Leslie > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Wed Mar 26 12:27:29 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E806D1A03A3 for ; Wed, 26 Mar 2014 12:27:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.819 X-Spam-Level: X-Spam-Status: No, score=-1.819 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1M5F-120yt6B for ; Wed, 26 Mar 2014 12:27:25 -0700 (PDT) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.110]) by ietfa.amsl.com (Postfix) with ESMTP id 506B51A03C8 for ; Wed, 26 Mar 2014 12:27:25 -0700 (PDT) Received: from [216.82.254.19:12051] by server-14.bemta-7.messagelabs.com id 90/29-25548-B1A23335; Wed, 26 Mar 2014 19:27:23 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-14.tower-96.messagelabs.com!1395862039!2790511!3 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.11.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4077 invoked from network); 26 Mar 2014 19:27:22 -0000 Received: from crpehubprd01.polycom.com (HELO crpehubprd02.polycom.com) (140.242.64.158) by server-14.tower-96.messagelabs.com with AES128-SHA encrypted SMTP; 26 Mar 2014 19:27:22 -0000 Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by crpehubprd02.polycom.com ([fe80::5efe:10.236.0.154%12]) with mapi; Wed, 26 Mar 2014 12:26:11 -0700 From: "Duckworth, Mark" To: Roberta Presta , "clue@ietf.org" Date: Wed, 26 Mar 2014 12:26:10 -0700 Thread-Topic: in data model Thread-Index: Ac9I1sQDFa6nIJJ8SEGiXW0oVUJMygAUEhfQ Message-ID: <49E45C59CA48264997FEBFB29B6BC2D617ACF1AE9A@CRPMBOXPRD07.polycom.com> References: <49E45C59CA48264997FEBFB29B6BC2D617AC536624@CRPMBOXPRD07.polycom.com> <53329F6C.3070600@unina.it> In-Reply-To: <53329F6C.3070600@unina.it> 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_49E45C59CA48264997FEBFB29B6BC2D617ACF1AE9ACRPMBOXPRD07p_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/HU_jAjXzQxn5kVy_YXWVxthSzeU Subject: Re: [clue] in data model X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 26 Mar 2014 19:27:28 -0000 --_000_49E45C59CA48264997FEBFB29B6BC2D617ACF1AE9ACRPMBOXPRD07p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Roberta, Initially, I was thinking the same thing as you, and that is how I presente= d it on the list and at London. Then at London I changed my mind as a few = people agreed that using only CSEs better matches the meaning of the global= list. I think Christian first mentioned in email on the list why it would be better= to use only CSEs within the global CSE list rather than also including ind= ividual captures: "I'm also not too sure about GCEs listing individual captures. What does an= individual capture mean at that level? The CSEs indicate what captures rep= resent a scene. Why would a provider indicate that you need a set of captur= es and then contradict itself by suggesting another set of captures." The semantic meaning of an item in the global CSE list is that it represent= s the entire advertisement. So we thought it didn't make sense to specify = individual captures which themselves weren't even a representation of a com= plete scene. So by including only CSEs, and not individual captures, it he= lps enforce this meaning. Mark From: Roberta Presta [mailto:roberta.presta@unina.it] Sent: Wednesday, March 26, 2014 5:36 AM To: Duckworth, Mark; clue@ietf.org Subject: Re: in data model Hi Mark, there is of course a typo in the definition, sorry. In my presentation in London I tried to highlight commonalities when dealin= g with "content lists" in simultaneous sets, multiple content captures and = global capture entries. I proposed to use for global capture entries the same content format of sim= ultaneous sets and multiple content captures: "The content can be specified in terms of: 1.A list of (homogeneous) media capture identifiers 2.A list of (homogeneous) capture Scene Entry identifiers (used as shortcut= s)" As far as I remember, there were no objections to that. It does not seem to be in contrast with discussion on the mailing list. Is there any reason why we should not include references to media captures = within GCEs? Roberta Il 25/03/2014 20:47, Duckworth, Mark ha scritto: I think in London we agreed that a single item in the new Global CSE List w= ould consist of a set of one or more CSEs. We don't want to include direct= references to Media Captures. If I'm remembering correctly, then in secti= on 18 we should remove this part: I think there is a typo in the first sentence: " represents a set of captures of the same media time..= ." should be: " represents a set of captures of the same media *type*= ..." and then I suggest change to clarify it is built from CSEs: " represents a set of Capture Scene Entries of the same= media *type*..." I'm in process of adding "Global CSE List" to the framework document. Regards, Mark --_000_49E45C59CA48264997FEBFB29B6BC2D617ACF1AE9ACRPMBOXPRD07p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Hi Roberta,

Initially, I was thinking the sa= me thing as you, and that is how I presented it on the list and at London.&= nbsp; Then at London I changed my mind as a few people agreed that using on= ly CSEs better matches the meaning of the global list. I think Christ= ian first mentioned in email on the list why it would be better to use= only CSEs within the global CSE list rather than also including individual= captures:

“I'm also not too sure about GCEs = listing individual captures. What does an individual capture mean at that l= evel? The CSEs indicate what captures represent a scene. Why would a provid= er indicate that you need a set of captures and then contradict itself by s= uggesting another set of captures.”

The semantic meaning of an item = in the global CSE list is that it represents the entire advertisement. = ; So we thought it didn’t make sense to specify individual captures w= hich themselves weren’t even a representation of a complete scene.&nb= sp; So by including only CSEs, and not individual captures, it helps enforc= e this meaning.

Mark

From: Roberta Presta [mailt= o:roberta.presta@unina.it]
Sent: Wednesday, March 26, 2014 5:36 = AM
To: Duckworth, Mark; clue@ietf.org
Subject: Re: <= globalCaptureEntry> in data model

Hi Mark,
=
there is of course a typo in the definition, sorry.
In my presentati= on in London I tried to highlight commonalities when dealing with "con= tent lists" in simultaneous sets, multiple content captures and global= capture entries.
I proposed to use for global capture entries the same = content format of simultaneous sets and multiple content captures:

&= quot;The content can be specified in terms of:
1.A list of (homogeneous)= media capture identifiers
2.A list of (homogeneous) capture Scene Entry= identifiers (used as shortcuts)"

As far as I remember, there w= ere no objections to that.
It does not seem to be in contrast with discu= ssion on the mailing list.
Is there any reason why we should not include= references to media captures within GCEs?

Roberta

Il 25/= 03/2014 20:47, Duckworth, Mark ha scritto:

I think= in London we agreed that a single item in the new Global CSE List would co= nsist of a set of one or more CSEs. We don’t want to include di= rect references to Media Captures. If I’m remembering correctly= , then in section 18 we should remove this part:
<xs:element name=3D"captureIDREF" type=3D&quo= t;xs:IDREF"
minOccurs=3D"0" maxOccurs=3D= "unbounded"/>
=
I think there is a typo in the first se= ntence:
“<globalCaptureEntry>= ; represents a set of captures of the same media time...”<= /p>
should be:
̶= 0;<globalCaptureEntry> represents a set of captures of the same media= *type*...”
and then I suggest cha= nge to clarify it is built from CSEs:
&#= 8220;<globalCaptureEntry> represents a set of Capture Scene Entries o= f the same media *type*...”
=
I’m in process of adding “G= lobal CSE List” to the framework document.

Regards,
<= p class=3DMsoNormal>Mark

&= nbsp;

= --_000_49E45C59CA48264997FEBFB29B6BC2D617ACF1AE9ACRPMBOXPRD07p_-- From nobody Wed Mar 26 13:45:06 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CCEE1A03C2 for ; Wed, 26 Mar 2014 13:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fL-HPjQKXKfo for ; Wed, 26 Mar 2014 13:45:01 -0700 (PDT) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.209]) by ietfa.amsl.com (Postfix) with ESMTP id 12FE61A03C1 for ; Wed, 26 Mar 2014 13:45:00 -0700 (PDT) Received: from [216.82.241.100:17745] by server-17.bemta-8.messagelabs.com id 17/20-26511-B4C33335; Wed, 26 Mar 2014 20:44:59 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-16.tower-220.messagelabs.com!1395866697!2196559!1 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.11.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23884 invoked from network); 26 Mar 2014 20:44:58 -0000 Received: from crpehubprd01.polycom.com (HELO crpehubprd02.polycom.com) (140.242.64.158) by server-16.tower-220.messagelabs.com with AES128-SHA encrypted SMTP; 26 Mar 2014 20:44:58 -0000 Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by crpehubprd02.polycom.com ([fe80::5efe:10.236.0.154%12]) with mapi; Wed, 26 Mar 2014 13:44:00 -0700 From: "Duckworth, Mark" To: Paul Kyzivat , "clue@ietf.org" , John Leslie Date: Wed, 26 Mar 2014 13:43:58 -0700 Thread-Topic: [clue] should be optional Thread-Index: Ac9JKL8ecbeNKMHnT9adqNFwlg56SgACOs+g Message-ID: <49E45C59CA48264997FEBFB29B6BC2D617ACF1AF30@CRPMBOXPRD07.polycom.com> References: <49E45C59CA48264997FEBFB29B6BC2D60C9CF16009@CRPMBOXPRD07.polycom.com> <52DC8BFC.6050705@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D60C9D2FB1BE@CRPMBOXPRD07.polycom.com> <52F42FC4.5070104@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D617AC5365DF@CRPMBOXPRD07.polycom.com> <20140326001139.GD99797@verdi> <53329AE2.4050302@unina.it> <49E45C59CA48264997FEBFB29B6BC2D617ACF1ACE8@CRPMBOXPRD07.polycom.com> <53330844.9040705@unina.it> <49E45C59CA48264997FEBFB29B6BC2D617ACF1ADBF@CRPMBOXPRD07.polycom.com> <20140326183424.GF99797@verdi> <533328F5.1070306@alum.mit.edu> In-Reply-To: <533328F5.1070306@alum.mit.edu> 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 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/ylwucwpT2xldHZ0NpI6GOnghzns Subject: Re: [clue] should be optional X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 26 Mar 2014 20:45:03 -0000 Hi John and Paul, comments inline. Mark > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Wednesday, March 26, 2014 3:22 PM > To: clue@ietf.org > Subject: Re: [clue] should be optional >=20 > On 3/26/14 2:34 PM, John Leslie wrote: > > I'm still struggling to understand what a > > instance without a _means_ ... [Duckworth, Mark] It means the captures within the scene have some spatial = relation, and the capturePoint is either not known or not applicable. For = composed video captures I think the capturePoint would be not applicable, b= ecause there is no single capture point. >=20 > I have a little trouble with this too, though it may be that I don't > conceptualize this correctly. >=20 > We have area of capture, but that is a planar region. I keep wanting to t= hink > of that as an "area of display" that is ideal to render the capture. But = to use > that, I need to know which side of the display should be the front. Witho= ut a > capture point, I don't know that. [Duckworth, Mark] Yes, I think you do know that because the capture area ha= s named coordinates bottomLeft, bottomRight, etc. If the camera was locate= d at the back of the room, then the left X coordinate would be greater than= the right X coordinate. Maybe this is an assumption that the left and rig= ht here are from the point of view of the camera, but I think that is easy = to make explicit in the data model. This is a little odd, given the statem= ent "X increases from Camera-Left to Camera-Right", but if you have cameras= pointing in opposite directions within the same scene then one of them has= to be reversed with respect to the coordinate system. >=20 > I suspect that there is an implicit assumption that the "front" of the ar= ea of > capture will always be the side that puts the smallest X coordinate to th= e left > of the larger X coordinate. I don't think we should assume such things. [Duckworth, Mark] Don't have to assume it if we understand the named coord= inates of capture area as I suggest. The front is the side where the viewe= r would see the named left coordinates to the left of the named right coord= inates, regardless of the X values. >=20 > Thanks, > Paul >=20 > > Duckworth, Mark wrote: > >> From: Roberta Presta [mailto:roberta.presta@unina.it] > >>> > >>> For the case you have proposed, the ADV could be the following: > >>> > >>> capture scene A: captures coming from room A capture scene B: > >>> captures coming from room B capture scene C: captures coming from > >>> room C > > > > Three quite independent captures... I get this part... > > > >>> capture scene D: > >>> MCC A (from room A's captures) - to be rendered on the left, > >>> MCC B (from room B's captures) - to be rendered on the centre, > >>> MCC C (from room C's capture) - to be rendered on the right > > > > I'm struggling here. "To be rendered..." seems to be a suggestion > > to the receiver, with (AFAICT) no spatial relationship to anything in > > Capture Scene A, B, C, or D. > > > > Why is an appropriate tool for this advice? > > > >>> where the "to be rendered" information are represented by means of > >>> the within the tag associated to > the MCCs. > > > > has always bothered me, because it is a > > two-dimensional quantity, while we interact in three-dimensional > > space. I suppose I should have objected to including it at all in > > ; but until now I thought we understood it to be > > defining space in a plane within our three-dimensional interaction > > space (and therefore a three-dimensional space from to > the ). > > > > I find the idea of collapsing into dimensionless > > space a bit too confusing. In particular, I am cringing in fear that > > someone will try to use this anti-physical concept to describe audio... > > > > -- > > John Leslie > > > > _______________________________________________ > > 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 nobody Wed Mar 26 15:50:21 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95BE01A03ED for ; Wed, 26 Mar 2014 15:50:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mVJafZm5PRyi for ; Wed, 26 Mar 2014 15:50:06 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC76B1A03DC for ; Wed, 26 Mar 2014 15:50:05 -0700 (PDT) Received: from ppp118-209-170-234.lns20.mel6.internode.on.net ([118.209.170.234]:50930 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WSwe2-0005ae-8l for clue@ietf.org; Thu, 27 Mar 2014 09:50:02 +1100 Message-ID: <53335996.5010608@nteczone.com> Date: Thu, 27 Mar 2014 09:49:58 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: clue@ietf.org References: <49E45C59CA48264997FEBFB29B6BC2D617AC536624@CRPMBOXPRD07.polycom.com> <53329F6C.3070600@unina.it> <49E45C59CA48264997FEBFB29B6BC2D617ACF1AE9A@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D617ACF1AE9A@CRPMBOXPRD07.polycom.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/MkXjQ1wRdVY7ZmmdfqQnrzqYHtI Subject: Re: [clue] in data model X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 26 Mar 2014 22:50:08 -0000 Hello Roberta, I think Mark has captured my concern about individual captures being used in a GCSE. Regards, Christian On 27/03/2014 6:26 AM, Duckworth, Mark wrote: > > Hi Roberta, > > Initially, I was thinking the same thing as you, and that is how I > presented it on the list and at London. Then at London I changed my > mind as a few people agreed that using only CSEs better matches the > meaning of the global list. I think Christian first mentioned in email > on the list > why > it would be better to use only CSEs within the global CSE list rather > than also including individual captures: > > “I'm also not too sure about GCEs listing individual captures. What > does an individual capture mean at that level? The CSEs indicate what > captures represent a scene. Why would a provider indicate that you > need a set of captures and then contradict itself by suggesting > another set of captures.” > > The semantic meaning of an item in the global CSE list is that it > represents the entire advertisement. So we thought it didn’t make > sense to specify individual captures which themselves weren’t even a > representation of a complete scene. So by including only CSEs, and not > individual captures, it helps enforce this meaning. > > Mark > > *From:*Roberta Presta [mailto:roberta.presta@unina.it] > *Sent:* Wednesday, March 26, 2014 5:36 AM > *To:* Duckworth, Mark; clue@ietf.org > *Subject:* Re: in data model > > Hi Mark, > > there is of course a typo in the definition, sorry. > In my presentation in London I tried to highlight commonalities when > dealing with "content lists" in simultaneous sets, multiple content > captures and global capture entries. > I proposed to use for global capture entries the same content format > of simultaneous sets and multiple content captures: > > "The content can be specified in terms of: > 1.A list of (homogeneous) media capture identifiers > 2.A list of (homogeneous) capture Scene Entry identifiers (used as > shortcuts)" > > As far as I remember, there were no objections to that. > It does not seem to be in contrast with discussion on the mailing list. > Is there any reason why we should not include references to media > captures within GCEs? > > Roberta > > > Il 25/03/2014 20:47, Duckworth, Mark ha scritto: > > I think in London we agreed that a single item in the new Global > CSE List would consist of a set of one or more CSEs. We don’t want > to include direct references to Media Captures. If I’m remembering > correctly, then in section 18 we should remove this part: > > > minOccurs="0" maxOccurs="unbounded"/> > > I think there is a typo in the first sentence: > > “ represents a set of captures of the same > media time...” > > should be: > > “ represents a set of captures of the same > media *type*...” > > and then I suggest change to clarify it is built from CSEs: > > “ represents a set of Capture Scene Entries of > the same media *type*...” > > I’m in process of adding “Global CSE List” to the framework document. > > Regards, > > Mark > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Thu Mar 27 08:02:14 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BCB01A02DB for ; Thu, 27 Mar 2014 08:02:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VW2gLelGyMYA for ; Thu, 27 Mar 2014 08:02:04 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 8CE721A0754 for ; Thu, 27 Mar 2014 08:02:04 -0700 (PDT) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta03.westchester.pa.mail.comcast.net with comcast id ibCe1n0020Fqzac53f22Pz; Thu, 27 Mar 2014 15:02:02 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta08.westchester.pa.mail.comcast.net with comcast id if221n00Y3ZTu2S3Uf22Mx; Thu, 27 Mar 2014 15:02:02 +0000 Message-ID: <53343D6A.7000402@alum.mit.edu> Date: Thu, 27 Mar 2014 11:02:02 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "Duckworth, Mark" , "clue@ietf.org" , John Leslie References: <49E45C59CA48264997FEBFB29B6BC2D60C9CF16009@CRPMBOXPRD07.polycom.com> <52DC8BFC.6050705@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D60C9D2FB1BE@CRPMBOXPRD07.polycom.com> <52F42FC4.5070104@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D617AC5365DF@CRPMBOXPRD07.polycom.com> <20140326001139.GD99797@verdi> <53329AE2.4050302@unina.it> <49E45C59CA48264997FEBFB29B6BC2D617ACF1ACE8@CRPMBOXPRD07.polycom.com> <53330844.9040705@unina.it> <49E45C59CA48264997FEBFB29B6BC2D617ACF1ADBF@CRPMBOXPRD07.polycom.com> <20140326183424.GF99797@verdi> <533328F5.1070306@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D617ACF1AF30@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D617ACF1AF30@CRPMBOXPRD07.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1395932522; bh=e0cJt0JY/YAg998vvgDh8y+E8U4T+Lj9lhh6Kqxn3kc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=KvpAatvtfg+4GNkQ6Jcg0MfHsGwk2aiXbhU+zXXILhPVdDkcOVxm3bh04I/29Gs9p JvYoQFuYTgfzVGVPdTTAS/Ta0EVYW6FX/FkfJcdMyf0EnNSpuGH5ob72gnSWNUoPG3 /CVDOLOariSodLWm7i6WYrC9TMV03AOovz9hj1vPELmK1Qa8rUT8wAZ3hNQIHUFYea jRyd2cGZWOtAlogxdyxi1/pxr8BS4dlQqR/rqFfytjU6PGOHu/l+EtmMKEIK23i3di 9CRmgklpPhAc9NSrTelxvwcQKe53yC5aJIqWvGAuWxrkjHK8eOYvOtGddQiZl4rdpB ZMtBXzpIsn4+Q== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/VGDR6VbQAsNjuGVz8wNJo3ElRZ0 Subject: Re: [clue] should be optional X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 27 Mar 2014 15:02:06 -0000 On 3/26/14 4:43 PM, Duckworth, Mark wrote: > Hi John and Paul, comments inline. > Mark > >> -----Original Message----- >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: Wednesday, March 26, 2014 3:22 PM >> To: clue@ietf.org >> Subject: Re: [clue] should be optional >> >> On 3/26/14 2:34 PM, John Leslie wrote: >>> I'm still struggling to understand what a >>> instance without a _means_ ... > > [Duckworth, Mark] It means the captures within the scene have some spatial relation, and the capturePoint is either not known or not applicable. For composed video captures I think the capturePoint would be not applicable, because there is no single capture point. > >> >> I have a little trouble with this too, though it may be that I don't >> conceptualize this correctly. >> >> We have area of capture, but that is a planar region. I keep wanting to think >> of that as an "area of display" that is ideal to render the capture. But to use >> that, I need to know which side of the display should be the front. Without a >> capture point, I don't know that. > > [Duckworth, Mark] Yes, I think you do know that because the capture area has named coordinates bottomLeft, bottomRight, etc. If the camera was located at the back of the room, then the left X coordinate would be greater than the right X coordinate. Maybe this is an assumption that the left and right here are from the point of view of the camera, but I think that is easy to make explicit in the data model. This is a little odd, given the statement "X increases from Camera-Left to Camera-Right", but if you have cameras pointing in opposite directions within the same scene then one of them has to be reversed with respect to the coordinate system. OK, I accept that. (I didn't have in my head that the corners were named that way.) >> I suspect that there is an implicit assumption that the "front" of the area of >> capture will always be the side that puts the smallest X coordinate to the left >> of the larger X coordinate. I don't think we should assume such things. > > [Duckworth, Mark] Don't have to assume it if we understand the named coordinates of capture area as I suggest. The front is the side where the viewer would see the named left coordinates to the left of the named right coordinates, regardless of the X values. OK. Sorry, Paul >> Thanks, >> Paul >> >>> Duckworth, Mark wrote: >>>> From: Roberta Presta [mailto:roberta.presta@unina.it] >>>>> >>>>> For the case you have proposed, the ADV could be the following: >>>>> >>>>> capture scene A: captures coming from room A capture scene B: >>>>> captures coming from room B capture scene C: captures coming from >>>>> room C >>> >>> Three quite independent captures... I get this part... >>> >>>>> capture scene D: >>>>> MCC A (from room A's captures) - to be rendered on the left, >>>>> MCC B (from room B's captures) - to be rendered on the centre, >>>>> MCC C (from room C's capture) - to be rendered on the right >>> >>> I'm struggling here. "To be rendered..." seems to be a suggestion >>> to the receiver, with (AFAICT) no spatial relationship to anything in >>> Capture Scene A, B, C, or D. >>> >>> Why is an appropriate tool for this advice? >>> >>>>> where the "to be rendered" information are represented by means of >>>>> the within the tag associated to >> the MCCs. >>> >>> has always bothered me, because it is a >>> two-dimensional quantity, while we interact in three-dimensional >>> space. I suppose I should have objected to including it at all in >>> ; but until now I thought we understood it to be >>> defining space in a plane within our three-dimensional interaction >>> space (and therefore a three-dimensional space from to >> the ). >>> >>> I find the idea of collapsing into dimensionless >>> space a bit too confusing. In particular, I am cringing in fear that >>> someone will try to use this anti-physical concept to describe audio... >>> >>> -- >>> John Leslie >>> >>> _______________________________________________ >>> 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 nobody Thu Mar 27 10:11:12 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4488A1A06A3 for ; Thu, 27 Mar 2014 10:11:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.119 X-Spam-Level: X-Spam-Status: No, score=-1.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BSEmgh0o0Hua for ; Thu, 27 Mar 2014 10:11:07 -0700 (PDT) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.201]) by ietfa.amsl.com (Postfix) with ESMTP id AC78F1A0349 for ; Thu, 27 Mar 2014 10:11:06 -0700 (PDT) Received: from [216.82.241.100:44185] by server-9.bemta-8.messagelabs.com id 07/F9-11188-8AB54335; Thu, 27 Mar 2014 17:11:04 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-3.tower-220.messagelabs.com!1395940261!2480134!3 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.11.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16237 invoked from network); 27 Mar 2014 17:11:04 -0000 Received: from crpehubprd01.polycom.com (HELO crpehubprd02.polycom.com) (140.242.64.158) by server-3.tower-220.messagelabs.com with AES128-SHA encrypted SMTP; 27 Mar 2014 17:11:04 -0000 Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by crpehubprd02.polycom.com ([fe80::5efe:10.236.0.154%12]) with mapi; Thu, 27 Mar 2014 10:10:12 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Thu, 27 Mar 2014 10:10:10 -0700 Thread-Topic: Global CSE List in framework Thread-Index: Ac9J3s1Qg52RDQ8/QIa0GrvCwhI/QA== Message-ID: <49E45C59CA48264997FEBFB29B6BC2D617ACF1B213@CRPMBOXPRD07.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_49E45C59CA48264997FEBFB29B6BC2D617ACF1B213CRPMBOXPRD07p_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/qgwx7aUzjcAYoym4582hJHUCtGk Subject: [clue] Global CSE List in framework X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 27 Mar 2014 17:11:09 -0000 --_000_49E45C59CA48264997FEBFB29B6BC2D617ACF1B213CRPMBOXPRD07p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Here is a new section I'm adding to the framework. Please send any comment= s or suggestions. =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 7.3.3. Global Capture Scene Entry List An Advertisement can include an optional global Capture Scene Entry list, f= or each media type. Each item in this list is a set of one or more Capture= Scene Entries. Each set of CSEs in the list is a suggestion from the Prov= ider to the Consumer for which CSEs represent the entire advertisement, acr= oss multiple scenes. The Provider can include multiple sets, to accommodat= e different Consumers with varying capability to receive multiple encodings= . This is very similar to how each CSE represents a particular scene. As an example, suppose an advertisement has three scenes, and each scene ha= s three CSEs, ranging from one to three video captures in each CSE. The pr= ovider is advertising a total of nine video captures across three scenes. = The provider can use the Global CSE list to suggest alternatives for consum= ers that can't receive all nine video captures. For accommodating a consum= er that wants to receive three video captures, a provider might suggest a s= ingle CSE with three captures and nothing from the other two scenes. Or a = provider might suggest three different CSEs, one from each scene, with a si= ngle video capture in each. The choice of how to make these suggestions in= the Global CSE list for what represents the entire advertisement is up to = the provider. Some additional rules: * The ordering of items (sets of CSEs) in the global CSE list i= s not important. * The ordering of CSEs within each set is not important. * The Provider must be capable of encoding and sending all Capt= ures within the CSEs of a given set simultaneously. =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 I also added a statement in 7.3 saying a CSE has an advertisement unique id= entity. I also plan to add an example in 12.3 for Global CSE List, taken from my IE= TF89 slides. Mark --_000_49E45C59CA48264997FEBFB29B6BC2D617ACF1B213CRPMBOXPRD07p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Here is a new se= ction I’m adding to the framework. Please send any comments or = suggestions.

=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

7.3.3. Gl= obal Capture Scene Entry List

= ;

An Advertisement can include an optional gl= obal Capture Scene Entry list, for each media type. Each item in this= list is a set of one or more Capture Scene Entries. Each set of CSEs= in the list is a suggestion from the Provider to the Consumer for which CS= Es represent the entire advertisement, across multiple scenes. The Pr= ovider can include multiple sets, to accommodate different Consumers with v= arying capability to receive multiple encodings. This is very similar= to how each CSE represents a particular scene.

As an example, suppose an= advertisement has three scenes, and each scene has three CSEs, ranging fro= m one to three video captures in each CSE. The provider is advertisin= g a total of nine video captures across three scenes. The provider ca= n use the Global CSE list to suggest alternatives for consumers that can't = receive all nine video captures. For accommodating a consumer that wa= nts to receive three video captures, a provider might suggest a single CSE = with three captures and nothing from the other two scenes. Or a provi= der might suggest three different CSEs, one from each scene, with a single = video capture in each. The choice of how to make these suggestions in= the Global CSE list for what represents the entire advertisement is up to = the provider.

Some additional rules:

&= #8226; &nb= sp; The ordering of items (sets of CSEs) in the global CSE list is not impo= rtant.

• &n= bsp; The ordering of CSEs within = each set is not important.

• = The Prov= ider must be capable of encoding and sending all Captures within the CSEs o= f a given set simultaneously.

=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

I also added a statement in 7.3 saying a CSE has an advertisement = unique identity.

I also plan to add an example in 12.3 for Global CSE Lis= t, taken from my IETF89 slides.

&nb= sp;

Mark

= --_000_49E45C59CA48264997FEBFB29B6BC2D617ACF1B213CRPMBOXPRD07p_-- From nobody Thu Mar 27 11:38:57 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F7471A0133 for ; Thu, 27 Mar 2014 11:38:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bfO1P57GiIQt for ; Thu, 27 Mar 2014 11:38:54 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 252B31A0182 for ; Thu, 27 Mar 2014 11:38:54 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 41E65C94A8; Thu, 27 Mar 2014 14:38:50 -0400 (EDT) Date: Thu, 27 Mar 2014 14:38:50 -0400 From: John Leslie To: Mary Barnes Message-ID: <20140327183850.GB87785@verdi> References: <1073194987.31242.1395857956833.POLL_ADMIN_PARTICIPATELINK.doodle@worker1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/clue/I9zu6XYJUtgUy69vzj6MU9dnt7c Cc: CLUE Subject: Re: [clue] Fwd: Doodle: Link for poll "CLUE Virtual Interim" X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 27 Mar 2014 18:38:55 -0000 Mary Barnes wrote: > > So, Paul and I have chatted and we are proposing a virtual interim meeting > instead... > > So, here's the doodle: > http://doodle.com/b5qtvb3ar5t25xad Mary should own up to the same problem Alissa and I have with 2:00 pm eastern time (IESG formal telechats alternate Thursdays, usually but not always finished by 2:00 pm). -- John Leslie From nobody Thu Mar 27 11:44:33 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C91F21A01D1 for ; Thu, 27 Mar 2014 11:44:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pJ12m3_1uTdx for ; Thu, 27 Mar 2014 11:44:28 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) by ietfa.amsl.com (Postfix) with ESMTP id EB8D71A0182 for ; Thu, 27 Mar 2014 11:44:27 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id d1so6314445wiv.1 for ; Thu, 27 Mar 2014 11:44:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cYfQ/qCpsbcvcBYzsb0Iuu5XKlTZ+9WU1kNzSHxNvcw=; b=jj8HCs8axPqMmz6/+i/nLGPQlxsnO2piYpExbr/Nhpjs0MA5qi43Bp+lxjTf3bKngH LaaOYNvdr/sU8CGhKj7D0ph497aASDMRgl1UDWbZwElHjgUOra/8WSlek4Wqtpc1Z6kx 7rU+dTRGyUSfigZ2hLp74JWXMjk/N4g9/95P66ZHL2gYZOSdaYf46woKuyNqiPS01gbC +dkEzmY8YfIO/eO/BfpG9d4nPpJ5tVTEKkt+oEbxEI3wgZYcQm0QYOgn2r4wUu+sV5N0 LwdiLyAPp/THmozAy17nCD1m3UfMBNaVDPfcAYKFptv0s40kmRYGfEmpckUvwYixa+GM hnSQ== MIME-Version: 1.0 X-Received: by 10.180.19.69 with SMTP id c5mr7117689wie.7.1395945865502; Thu, 27 Mar 2014 11:44:25 -0700 (PDT) Received: by 10.216.10.6 with HTTP; Thu, 27 Mar 2014 11:44:25 -0700 (PDT) In-Reply-To: <20140327183850.GB87785@verdi> References: <1073194987.31242.1395857956833.POLL_ADMIN_PARTICIPATELINK.doodle@worker1> <20140327183850.GB87785@verdi> Date: Thu, 27 Mar 2014 13:44:25 -0500 Message-ID: From: Mary Barnes To: John Leslie Content-Type: multipart/alternative; boundary=bcaec53d5a8b7064a004f59af932 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/QMZX_-FK7W-cbzuQF7ZuIBMFYuQ Cc: CLUE Subject: Re: [clue] Fwd: Doodle: Link for poll "CLUE Virtual Interim" X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 27 Mar 2014 18:44:30 -0000 --bcaec53d5a8b7064a004f59af932 Content-Type: text/plain; charset=ISO-8859-1 Thanks for the reminder. Clearly, IESG was clearly not on my mind yesterday morning ;) On Thu, Mar 27, 2014 at 1:38 PM, John Leslie wrote: > Mary Barnes wrote: > > > > So, Paul and I have chatted and we are proposing a virtual interim > meeting > > instead... > > > > So, here's the doodle: > > http://doodle.com/b5qtvb3ar5t25xad > > Mary should own up to the same problem Alissa and I have with 2:00 pm > eastern time (IESG formal telechats alternate Thursdays, usually but not > always finished by 2:00 pm). > > -- > John Leslie > --bcaec53d5a8b7064a004f59af932 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Thanks for the reminder. Clearly, IESG was clearly not on = my mind yesterday morning ;) =A0

On Thu, Mar 27, 2014 at 1:38 PM, John Leslie <john@jlc= .net> wrote:

Mary Barnes <mary.ietf.barnes@gmail.com> wrote:=
>
> So, Paul and I have chatted and we are proposing a virtual interim mee= ting

> instead...

>
> So, here's the doodle:
> http:= //doodle.com/b5qtvb3ar5t25xad

=A0 =A0 Mary should own up to the same problem Alissa and I have with= 2:00 pm
eastern time (IESG formal telechats alternate Thursdays, usually but not always finished by 2:00 pm).

--
John Leslie <john@jlc.net>

X &= nbsp; Definition of media feature tag g.sip.clue

X &nb= sp; Definition of media feature tag g.sip.clue