Lousy internet connection=97let's see whether this gets through=85

Roni, without any changes, y reading of the text proposed is that ther= e is no axis of capture knowledge unless both point and axis of capture are= specified. No inference of the axis of capture from the field of cap= ture is implied.

I think I support this proposal. It is trivial to calculate a po= int of capture even if point of capture is identical with the center of the= field of capture coordinates. The signaling may be unnecessary if w= e were mandating a condition as you implicitly propose it, but bits on this level ought to be cheap. Suggest we be = explicit and say either point of capture is specified, or no one knows.

Stephan

From: Roni Even <ron.even.tlv@gmail.com>
Date: Monday, 2 July, 2012 12:46 To: 'Mary Barnes' <mary.ietf.barnes@gmail.com>, 'CLUE'= <clue@ietf.org>
Subject: Re: [clue] Concensus call:= Text for "Axis of Capture"

Hi,

In general I am OK with the text I am just wondering about<= o:p>

=93If the Axis of Capture Point is not specified=
, it means the consumer should not assume anything about the axis of captur=
e of the capturing device.=94

Is this the assumption or should the consumer as=
sume that the axis of capture is perpendicular to the center of the area of=
 capture. If the above sentence is specified I am wondering what is the val=
ue in providing the point of capture.

Thanks

Roni

From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Mary Barnes
Sent: 02 July, 2012 7:58 PM
To: CLUE
Subject: [clue] Concensus call: Text for "Axis of Capture"=

Per the design team call last week, we want to do a = consensus call for the text to cover the "Axis of capture". = ;There were several suggested updates to Stephan's original text:

http://www.ietf.org/mail-archive/web/clue/current/m= sg01583.html

Thus, we would like folks to respond as to whether t= hey are okay with the following text being added to section 6.1.1 (relative to draft-ietf-clue-f= ramework-05 - after the two paragraphs of "point of capture" - middle of page 11):

   Axis of Capture Point: {(X, =
Y, Z)} A field with a single Cartesian

   (X, Y, Z) point value (virtu=
al or physical) which describes a position

   in space of a second point o=
n the axis of capture of the capturing

   device; the first point bein=
g the Point of Capture (see above).

   The axis of capture point MUST NOT be specified if the Point =
of Capture

   is not present for this capture device.  
   When the Axis of Capture Point attribute is specified, it mus=
t include X,
   Y and Z coordinates.  T=
hese coordinates MUST not be identical to the 
 
   Point of Capture coordinates=
. 
   If the Axis of Capture Point is not specified, it
   means the consumer should no=
t assume anything about the axis of
 
   capture of the capturing dev=
ice.  

 


 


So, please respond "Yes&quo=
t; if you think the text if fine, "Maybe" if you think it needs t=
weaking (and include the suggested


tweaks). Note, we agreed to add =
this at the interim meeting, thus if you answer "No", you must in=
clude 


a compelling reason why this sho=
uld not be added in some form.


 


Regards,


Mary


CLUE WG co-chair

--_000_CC17D4C0889DCstewesteweorg_-- From stewe@stewe.org Mon Jul 2 13:53:47 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 19E2011E80BA for ; Mon, 2 Jul 2012 13:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.786 X-Spam-Level: X-Spam-Status: No, score=-3.786 tagged_above=-999 required=5 tests=[AWL=-0.188, 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 P8wGpXGI8oSB for ; Mon, 2 Jul 2012 13:53:46 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe001.messaging.microsoft.com [216.32.180.11]) by ietfa.amsl.com (Postfix) with ESMTP id 26A6C21F859B for ; Mon, 2 Jul 2012 13:53:46 -0700 (PDT) Received: from mail207-va3-R.bigfish.com (10.7.14.254) by VA3EHSOBE007.bigfish.com (10.7.40.11) with Microsoft SMTP Server id 14.1.225.23; Mon, 2 Jul 2012 20:51:54 +0000 Received: from mail207-va3 (localhost [127.0.0.1]) by mail207-va3-R.bigfish.com (Postfix) with ESMTP id E3514401A2; Mon, 2 Jul 2012 20:51:53 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.133; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0710HT001.namprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -14 X-BigFish: PS-14(zzc85ehzz1202h1082kzz1033IL8275bh8275dhz2fh2a8h668h839he5bhf0ahbe3k) Received-SPF: pass (mail207-va3: domain of stewe.org designates 157.56.240.133 as permitted sender) client-ip=157.56.240.133; envelope-from=stewe@stewe.org; helo=BL2PRD0710HT001.namprd07.prod.outlook.com ; .outlook.com ; Received: from mail207-va3 (localhost.localdomain [127.0.0.1]) by mail207-va3 (MessageSwitch) id 1341262311596809_17273; Mon, 2 Jul 2012 20:51:51 +0000 (UTC) Received: from VA3EHSMHS001.bigfish.com (unknown [10.7.14.240]) by mail207-va3.bigfish.com (Postfix) with ESMTP id 8609C2C004A; Mon, 2 Jul 2012 20:51:51 +0000 (UTC) Received: from BL2PRD0710HT001.namprd07.prod.outlook.com (157.56.240.133) by VA3EHSMHS001.bigfish.com (10.7.99.11) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 2 Jul 2012 20:51:50 +0000 Received: from BL2PRD0710MB349.namprd07.prod.outlook.com ([169.254.1.88]) by BL2PRD0710HT001.namprd07.prod.outlook.com ([10.255.102.36]) with mapi id 14.16.0164.004; Mon, 2 Jul 2012 20:53:47 +0000 From: Stephan Wenger To: Mary Barnes , CLUE Thread-Topic: [clue] Concensus call: Text for "Axis of Capture" Thread-Index: AQHNWHxI34qTJcK9ukK23IKhHJJttZcWmhaA Date: Mon, 2 Jul 2012 20:53:47 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.102.5] Content-Type: multipart/alternative; boundary="_000_CC17D6BB889EDstewesteweorg_" MIME-Version: 1.0 X-OriginatorOrg: stewe.org Subject: Re: [clue] Concensus call: Text for "Axis of Capture" 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, 02 Jul 2012 20:53:47 -0000 --_000_CC17D6BB889EDstewesteweorg_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Not sure this will make it=97let's try. I will not be able to join any cal= l over the next two weeks. I'm fine with the text proposed re axis of capt= ure. Stephan From: Mary Barnes > Date: Monday, 2 July, 2012 10:58 To: CLUE > Subject: [clue] Concensus call: Text for "Axis of Capture" Per the design team call last week, we want to do a consensus call for the = text to cover the "Axis of capture". There were several suggested updates = to Stephan's original text: http://www.ietf.org/mail-archive/web/clue/current/msg01583.html Thus, we would like folks to respond as to whether they are okay with the f= ollowing text being added to section 6.1.1 (relative to draft-ietf-clue-fra= mework-05 - after the two paragraphs of "point of capture" - middle of page= 11): Axis of Capture Point: {(X, Y, Z)} A field with a single Cartesian (X, Y, Z) point value (virtual or physical) which describes a position in space of a second point on the axis of capture of the capturing device; the first point being the Point of Capture (see above). The axis of capture point MUST NOT be specified if the Point of Capture is not present for this capture device. When the Axis of Capture Point attribute is specified, it must include X= , Y and Z coordinates. These coordinates MUST not be identical to the Point of Capture coordinates. If the Axis of Capture Point is not specified, it means the consumer should not assume anything about the axis of capture of the capturing device. So, please respond "Yes" if you think the text if fine, "Maybe" if you thin= k it needs tweaking (and include the suggested tweaks). Note, we agreed to add this at the interim meeting, thus if you an= swer "No", you must include a compelling reason why this should not be added in some form. Regards, Mary CLUE WG co-chair --_000_CC17D6BB889EDstewesteweorg_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable

Not sure this will make it=97let's try. I will not be able to jo= in any call over the next two weeks. I'm fine with the text proposed = re axis of capture.

Stephan

From: Mary Barnes <mary.ietf.barnes@gmail.com>
Date: Monday, 2 July, 2012 10:58 To: CLUE <clue@ietf.org>
Subject: [clue] Concensus call: Tex= t for "Axis of Capture"

Per the design team call last week, we want to do a consensus call for= the text to cover the "Axis of capture". There were severa= l suggested updates to Stephan's original text:

http://www.ietf.org/mail-archive/web/clue/current/msg01583.html

Thus, we would like folks to respond as to whether they are okay with = the following text being added to section 6.1.1 (relative to draft-ietf-clue= -framework-05 - after the two paragraphs of "point of capture" - middle of page 11):

<= br>

   Axis of Capture Point: {(X, Y, Z)} A field with=
 a single Cartesian

   (X, Y, Z) point value (virtual or physical) whi=
ch describes a position

   in space of a second point on the axis of captu=
re of the capturing

   device; the first point being the Point of Capt=
ure (see above).

   The axis of capture point MUST NOT be specified=
 if the Point of Capture

   is not present for this capture device.  <=
/pre>
   When the Axis of Capture Point attribute is spe=
cified, it must include X,
   Y and Z coordinates.  These coordinates MUST not be identical to th=
e 
   Point of Capture coordinates. 
   If the Axis of Capture Point is not specified, =
it
   means the consumer should not assume anything about the axis of
   capture of the capturing device.  






So, please respond "Yes" if you think the text if fine, &quo=
t;Maybe" if you think it needs tweaking (and include the suggested
tweaks). Note, we agreed to add this at the interim meeting, thus if y=
ou answer "No", you must include 
a compelling reason why this should not be added in some form.



Regards,
Mary
CLUE WG co-chair

--_000_CC17D6BB889EDstewesteweorg_-- From Mark.Duckworth@polycom.com Mon Jul 2 14:12:21 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 E9EAD21F8638 for ; Mon, 2 Jul 2012 14:12:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.165 X-Spam-Level: X-Spam-Status: No, score=-6.165 tagged_above=-999 required=5 tests=[AWL=0.433, 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 l4AD7pKN8s7Y for ; Mon, 2 Jul 2012 14:12:21 -0700 (PDT) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id DF52421F85DB for ; Mon, 2 Jul 2012 14:12:20 -0700 (PDT) Received: from Crpmboxprd01.polycom.com ([fe80::ad68:5a0:c919:66b6]) by Crpehubprd01.polycom.com ([fe80::5efe:10.236.0.158%14]) with mapi; Mon, 2 Jul 2012 14:12:26 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Mon, 2 Jul 2012 14:12:24 -0700 Thread-Topic: Framework scene description attribute update Thread-Index: Ac1YlqyH76Ozm5WWRAu8SRcjxNlBiQ== Message-ID: <44C6B6B2D0CF424AA90B6055548D7A6102FE035F38@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_44C6B6B2D0CF424AA90B6055548D7A6102FE035F38CRPMBOXPRD01p_" MIME-Version: 1.0 Subject: [clue] Framework scene description attribute update 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, 02 Jul 2012 21:12:22 -0000 --_000_44C6B6B2D0CF424AA90B6055548D7A6102FE035F38CRPMBOXPRD01p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Based on the decision at the interim meeting to support multiple descriptio= n strings, each in a different language, here is my proposed updated text f= or the framework document. I also addressed Christians comments http://ww= w.ietf.org/mail-archive/web/clue/current/msg01522.html Please review this change. Description attribute The optional description attribute is a list of human readable text strings which describes the capture scene. If there is more than one string in the list, then each string in the list should contain the same description, but in a different language. A provider that advertises multiple capture scenes may use different descriptions to differentiate between them. This attribute can contain text in any number of languages. Description Language attribute This attribute is a list of language tags, to identify the language of the corresponding description attribute text. The number of language tags in this list must be the same as the number of strings in the description list. The possible values for a language tag are the values of the 'Subtag' column for the "Type: language" entries in the "Language Subtag Registry" at [IANA-Lan] originally defined in [RFC5646]. Regards, Mark --_000_44C6B6B2D0CF424AA90B6055548D7A6102FE035F38CRPMBOXPRD01p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Based on the dec= ision at the interim meeting to support multiple description strings, each = in a different language, here is my proposed updated text for the framework= document. I also addressed Christians comments http://www.iet= f.org/mail-archive/web/clue/current/msg01522.html

Please review this = change.

Description attribute

The optional de= scription attribute is a list of human readable text

strings which describes the capture scene. = If there is more than one

s= tring in the list, then each string in the list should contain the

same description, but in a differen= t language. A provider that

= advertises multiple capture scenes may use different descriptions to=

differentiate between them= . This attribute can contain text in any

number of languages.

Description Languag= e attribute

This attribute is a list of language tags, to id= entify the language

of the = corresponding description attribute text. The number of

language tags in this list must be the s= ame as the number of strings

= ; in the description list. The possible values for a language tag are=

the values of the 'Subtag'= column for the "Type: language" entries in

the "Language Subtag Registry" at [IAN= A-Lan] originally defined in

= ; [RFC5646].

Regards,

Mark<= /p>

= --_000_44C6B6B2D0CF424AA90B6055548D7A6102FE035F38CRPMBOXPRD01p_-- From pkyzivat@alum.mit.edu Mon Jul 2 14:20: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 3B05E21F875B for ; Mon, 2 Jul 2012 14:20:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.038 X-Spam-Level: X-Spam-Status: No, score=-1.038 tagged_above=-999 required=5 tests=[AWL=-0.601, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.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 UzT2p-91Gsdd for ; Mon, 2 Jul 2012 14:20:48 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id 883E121F8760 for ; Mon, 2 Jul 2012 14:20:48 -0700 (PDT) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta01.westchester.pa.mail.comcast.net with comcast id VWcM1j00516LCl051ZLwYr; Mon, 02 Jul 2012 21:20:56 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id VZLr1j00B3ZTu2S3SZLrPc; Mon, 02 Jul 2012 21:20:51 +0000 Message-ID: <4FF210B4.2040809@alum.mit.edu> Date: Mon, 02 Jul 2012 17:20:52 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: clue@ietf.org References: <44C6B6B2D0CF424AA90B6055548D7A6102FE035F38@CRPMBOXPRD01.polycom.com> In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A6102FE035F38@CRPMBOXPRD01.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] Framework scene description attribute update 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, 02 Jul 2012 21:20:49 -0000 Mark, So you are proposing one list of descriptions, and a separate but parallel list of languages? That seems clumsy, unnatural, and error prone. Why not a list of pairs of (description, language)? And I'd be inclined to specify that a particular language value MUST NOT be specified more than once. Thanks, Paul On 7/2/12 5:12 PM, Duckworth, Mark wrote: > Based on the decision at the interim meeting to support multiple > description strings, each in a different language, here is my proposed > updated text for the framework document. I also addressed Christians > comments http://www.ietf.org/mail-archive/web/clue/current/msg01522.html > > Please review this change. > > Description attribute > > The optional description attribute is a list of human readable text > > strings which describes the capture scene. If there is more than one > > string in the list, then each string in the list should contain the > > same description, but in a different language. A provider that > > advertises multiple capture scenes may use different descriptions to > > differentiate between them. This attribute can contain text in any > > number of languages. > > Description Language attribute > > This attribute is a list of language tags, to identify the language > > of the corresponding description attribute text. The number of > > language tags in this list must be the same as the number of strings > > in the description list. The possible values for a language tag are > > the values of the 'Subtag' column for the "Type: language" entries in > > the "Language Subtag Registry" at [IANA-Lan] originally defined in > > [RFC5646]. > > Regards, > > Mark > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From espeberg@cisco.com Mon Jul 2 14:37:51 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 5F05121F850B for ; Mon, 2 Jul 2012 14:37:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 nJlE7qhEqxx0 for ; Mon, 2 Jul 2012 14:37:50 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 543B221F8505 for ; Mon, 2 Jul 2012 14:37:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=espeberg@cisco.com; l=2407; q=dns/txt; s=iport; t=1341265076; x=1342474676; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=p4r7UOAIl2xCWV6XWBTrynv19j06B9fYBpmg1kFwjd0=; b=NCbkjNOwJe8L3z/gCNnIRGr/dM6Q6f+0rL+aCLCrlhcPmUUVyxRItB08 ZAGDMbtJfUaiVBv/oFfj53XaxqDxFdDdPvWcUBv2Hs08MmZINJubwwTrg DGU4UWGPbKLdSpLgIgecykBY29iXRiiknrz3mAlGeM7jhgK3OjIzxND39 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAK0T8k+tJV2b/2dsb2JhbAA7Cg62V4EHghgBAQEEAQEBDwEnNBsCAQgYHhAnCyUBAQQBEgkZh2kLmlugSYs5EAqFIGADlTSOHYFmgiY5gV8 X-IronPort-AV: E=Sophos;i="4.77,512,1336348800"; d="scan'208";a="98128749" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-4.cisco.com with ESMTP; 02 Jul 2012 21:37:56 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q62Lbueu004081 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 2 Jul 2012 21:37:56 GMT Received: from xmb-rcd-x11.cisco.com ([169.254.1.20]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0298.004; Mon, 2 Jul 2012 16:37:55 -0500 From: "Espen Berger (espeberg)" To: "pkyzivat@alum.mit.edu" , "clue@ietf.org" Thread-Topic: [clue] Framework scene description attribute update Thread-Index: Ac1YlqyH76Ozm5WWRAu8SRcjxNlBiQAK8s8A//+w8s0= Date: Mon, 2 Jul 2012 21:37:55 +0000 Message-ID: <46BEBF31-9F4F-435D-AEDA-B7A0759DF1FE@cisco.com> References: <44C6B6B2D0CF424AA90B6055548D7A6102FE035F38@CRPMBOXPRD01.polycom.com>, <4FF210B4.2040809@alum.mit.edu> In-Reply-To: <4FF210B4.2040809@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19014.000 x-tm-as-result: No--48.126800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [clue] Framework scene description attribute update 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, 02 Jul 2012 21:37:51 -0000 In xml it would typically be modelled as capture of audience If multiple descriptions elements are added, add more description elements. -Espen ----- Reply message ----- Fra: "Paul Kyzivat" Til: "clue@ietf.org" Emne: [clue] Framework scene description attribute update Dato: man., juli 2, 2012 23:21 Mark, So you are proposing one list of descriptions, and a separate but parallel list of languages? That seems clumsy, unnatural, and error prone. Why not a list of pairs of (description, language)? And I'd be inclined to specify that a particular language value MUST NOT be specified more than once. Thanks, Paul On 7/2/12 5:12 PM, Duckworth, Mark wrote: > Based on the decision at the interim meeting to support multiple > description strings, each in a different language, here is my proposed > updated text for the framework document. I also addressed Christians > comments http://www.ietf.org/mail-archive/web/clue/current/msg01522.html > > Please review this change. > > Description attribute > > The optional description attribute is a list of human readable text > > strings which describes the capture scene. If there is more than one > > string in the list, then each string in the list should contain the > > same description, but in a different language. A provider that > > advertises multiple capture scenes may use different descriptions to > > differentiate between them. This attribute can contain text in any > > number of languages. > > Description Language attribute > > This attribute is a list of language tags, to identify the language > > of the corresponding description attribute text. The number of > > language tags in this list must be the same as the number of strings > > in the description list. The possible values for a language tag are > > the values of the 'Subtag' column for the "Type: language" entries in > > the "Language Subtag Registry" at [IANA-Lan] originally defined in > > [RFC5646]. > > Regards, > > Mark > > > > _______________________________________________ > 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 allyn@cisco.com Mon Jul 2 14:42:08 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 4626721F85C2 for ; Mon, 2 Jul 2012 14:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 hX8BOf7Touf0 for ; Mon, 2 Jul 2012 14:42:07 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 2CFC021F850B for ; Mon, 2 Jul 2012 14:42:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=10981; q=dns/txt; s=iport; t=1341265333; x=1342474933; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=WDJgVT8Kump67+nH2VNhvd2j1h3REvTCjxfMw9sKjd8=; b=XcpsaX4zGuMBQ7LAHTX/1UEgFxvET+DI+UZRILTyTWtRXdn1yAEEnx3X RXvqSQXIGdrZJoZbezROaJ1Q1pGDmaOS7YcyslY6SELizBSGBUywRMXAk lT7Yh72YUgyS/eX4OtZ/ub7Yc9tMk19RE35zq9gefntivG3VII7iqUa3M I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAJ4U8k+tJV2Y/2dsb2JhbABFgkW0IIEHghgBAQEEEgEKEFwCAQgRBAEBCx0HMhQJCAIEARIIARmHaQuaXaBJizkahSBgA6NRgWaCX4Ff X-IronPort-AV: E=Sophos;i="4.77,512,1336348800"; d="scan'208,217";a="98078864" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-2.cisco.com with ESMTP; 02 Jul 2012 21:42:13 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q62LgCOj011993 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 2 Jul 2012 21:42:13 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.100]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0298.004; Mon, 2 Jul 2012 16:42:12 -0500 From: "Allyn Romanow (allyn)" To: Mary Barnes , CLUE Thread-Topic: [clue] Concensus call: Text for "Axis of Capture" Thread-Index: AQHNWHxF14+jFS1MFkmrTddOeFddDJcWhgzA Date: Mon, 2 Jul 2012 21:42:11 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.151.124] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19014.000 x-tm-as-result: No--33.965800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_FD433719B54BFE41A70641D06F516F13020602xmbalnx02ciscocom_" MIME-Version: 1.0 Subject: Re: [clue] Concensus call: Text for "Axis of Capture" 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, 02 Jul 2012 21:42:08 -0000 --_000_FD433719B54BFE41A70641D06F516F13020602xmbalnx02ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable yes From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Mar= y Barnes Sent: Monday, July 02, 2012 10:58 AM To: CLUE Subject: [clue] Concensus call: Text for "Axis of Capture" Per the design team call last week, we want to do a consensus call for the = text to cover the "Axis of capture". There were several suggested updates = to Stephan's original text: http://www.ietf.org/mail-archive/web/clue/current/msg01583.html Thus, we would like folks to respond as to whether they are okay with the f= ollowing text being added to section 6.1.1 (relative to draft-ietf-clue-fra= mework-05 - after the two paragraphs of "point of capture" - middle of page= 11): Axis of Capture Point: {(X, Y, Z)} A field with a single Cartesian (X, Y, Z) point value (virtual or physical) which describes a position in space of a second point on the axis of capture of the capturing device; the first point being the Point of Capture (see above). The axis of capture point MUST NOT be specified if the Point of Capture is not present for this capture device. When the Axis of Capture Point attribute is specified, it must include X= , Y and Z coordinates. These coordinates MUST not be identical to the Point of Capture coordinates. If the Axis of Capture Point is not specified, it means the consumer should not assume anything about the axis of capture of the capturing device. So, please respond "Yes" if you think the text if fine, "Maybe" if you thin= k it needs tweaking (and include the suggested tweaks). Note, we agreed to add this at the interim meeting, thus if you an= swer "No", you must include a compelling reason why this should not be added in some form. Regards, Mary CLUE WG co-chair --_000_FD433719B54BFE41A70641D06F516F13020602xmbalnx02ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

yes

<= /p>

From: clue-bou= nces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Mary Barnes
Sent: Monday, July 02, 2012 10:58 AM
To: CLUE
Subject: [clue] Concensus call: Text for "Axis of Capture"=

Per the design team call last week, we want to do a = consensus call for the text to cover the "Axis of capture". = ;There were several suggested updates to Stephan's original text:

http://www.ietf.org/mail-archive/web/clue/current/m= sg01583.html

Thus, we would like folks to respond as to whether t= hey are okay with the following text being added to section 6.1.1 (relative = to draft-ietf-clue-framework-05 - after the two paragraphs of "point of capture" - middle of page 11):

   Axis of Capture Point: {(X, =
Y, Z)} A field with a single Cartesian

   (X, Y, Z) point value (virtu=
al or physical) which describes a position

   in space of a second point o=
n the axis of capture of the capturing

   device; the first point bein=
g the Point of Capture (see above).

   The axis of capture point MUST NOT be specified if the Point =
of Capture

   is not present for this capture device.  
   When the Axis of Capture Point attribute is specified, it mus=
t include X,
   Y and Z coordinates.  T=
hese coordinates MUST not be identical to the 
 
   Point of Capture coordinates=
. 
   If the Axis of Capture Point is not specified, it
   means the consumer should no=
t assume anything about the axis of
 
   capture of the capturing dev=
ice.  

 <=
/o:p>


 <=
/o:p>


So, please r=
espond "Yes" if you think the text if fine, "Maybe" if =
you think it needs tweaking (and include the suggested


tweaks). Not=
e, we agreed to add this at the interim meeting, thus if you answer "N=
o", you must include 


a compelling=
 reason why this should not be added in some form.


 <=
/o:p>


Regards,


Mary


CLUE WG co-c=
hair

--_000_FD433719B54BFE41A70641D06F516F13020602xmbalnx02ciscocom_-- From allyn@cisco.com Mon Jul 2 14:42: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 2834621F85CD for ; Mon, 2 Jul 2012 14:42:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, 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 TgIa0W6ZjBqI for ; Mon, 2 Jul 2012 14:42:38 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 98FB821F8514 for ; Mon, 2 Jul 2012 14:42:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=2020; q=dns/txt; s=iport; t=1341265364; x=1342474964; h=from:to:cc:subject:date:message-id:mime-version; bh=nunDdOjleCl/RsLlpc0bOiXSAC388gNxVjH0D2mafpI=; b=m2p5eFADjhwmZ/QAoKb2wfSZr+BwHMOnqADzDEOdnDaI41ezEPpYX1nL o/gfMvN72ZPoWRCbOCYNQ/JLxrfj4D2AEvvGmuts76CIONoGk3UWC0amM 81bCUFrTzgb+XNVS8VTX91xLTZh1qL4+7petrWDsjsfcWHuhz+OaU1R0R M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av47ABAV8k+tJXHB/2dsb2JhbABFgXcBTbMGgRqBB4IUBgEEEgEGFEwSAQwBHVYmAQQODRqFJweCJBeaaaBJkHNgA6NRgWaCXw X-IronPort-AV: E=Sophos;i="4.77,512,1336348800"; d="scan'208,217";a="98096003" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-5.cisco.com with ESMTP; 02 Jul 2012 21:42:44 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q62LgibW025678 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 2 Jul 2012 21:42:44 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.100]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0298.004; Mon, 2 Jul 2012 16:42:44 -0500 From: "Allyn Romanow (allyn)" To: "Mary Barnes (mary.ietf.barnes@gmail.com)" Thread-Topic: is there a meeting Tues? thanks Thread-Index: Ac1Ym5xI8dB7mYfAQjOv6Q5wlY3kkA== Date: Mon, 2 Jul 2012 21:42:43 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.151.124] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19014.000 x-tm-as-result: No--25.290800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_FD433719B54BFE41A70641D06F516F1302061Exmbalnx02ciscocom_" MIME-Version: 1.0 Cc: "CLUE \(clue@ietf.org\)" Subject: [clue] is there a meeting Tues? thanks 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, 02 Jul 2012 21:42:39 -0000 --_000_FD433719B54BFE41A70641D06F516F1302061Exmbalnx02ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable --_000_FD433719B54BFE41A70641D06F516F1302061Exmbalnx02ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

--_000_FD433719B54BFE41A70641D06F516F1302061Exmbalnx02ciscocom_-- From pkyzivat@alum.mit.edu Mon Jul 2 14:49:26 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 BCCE121F84C2 for ; Mon, 2 Jul 2012 14:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.963 X-Spam-Level: X-Spam-Status: No, score=-0.963 tagged_above=-999 required=5 tests=[AWL=-0.526, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.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 9VoKg5j2ipWm for ; Mon, 2 Jul 2012 14:49:26 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 3CFD421F84A1 for ; Mon, 2 Jul 2012 14:49:26 -0700 (PDT) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta02.westchester.pa.mail.comcast.net with comcast id VNmT1j00316LCl051ZpZKW; Mon, 02 Jul 2012 21:49:33 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id VZpV1j00C3ZTu2S3SZpVnv; Mon, 02 Jul 2012 21:49:29 +0000 Message-ID: <4FF2176B.6020005@alum.mit.edu> Date: Mon, 02 Jul 2012 17:49:31 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: clue@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] is there a meeting Tues? thanks 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, 02 Jul 2012 21:49:26 -0000 I haven't spoken with Mary about it. But given the US holiday I presume not. Thanks, Paul From Mark.Duckworth@polycom.com Mon Jul 2 15:23: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 8947921F84FC for ; Mon, 2 Jul 2012 15:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.274 X-Spam-Level: X-Spam-Status: No, score=-6.274 tagged_above=-999 required=5 tests=[AWL=0.325, 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 cm+9aTsrcNHp for ; Mon, 2 Jul 2012 15:23:24 -0700 (PDT) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id A0E5121F852D for ; Mon, 2 Jul 2012 15:23:23 -0700 (PDT) Received: from Crpmboxprd01.polycom.com ([fe80::ad68:5a0:c919:66b6]) by Crpehubprd01.polycom.com ([fe80::5efe:10.236.0.158%14]) with mapi; Mon, 2 Jul 2012 15:23:29 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Mon, 2 Jul 2012 15:23:27 -0700 Thread-Topic: [clue] Framework scene description attribute update Thread-Index: Ac1YmJOqWzOgkqBqREql3C9GFzQolQACJOpQ Message-ID: <44C6B6B2D0CF424AA90B6055548D7A6102FE035F86@CRPMBOXPRD01.polycom.com> References: <44C6B6B2D0CF424AA90B6055548D7A6102FE035F38@CRPMBOXPRD01.polycom.com> <4FF210B4.2040809@alum.mit.edu> In-Reply-To: <4FF210B4.2040809@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 Subject: Re: [clue] Framework scene description attribute update 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, 02 Jul 2012 22:23:26 -0000 Hi Paul, I thought of your way too, which is also fine with me. I can reword the te= xt to do it that way if people prefer. Mark > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: Monday, July 02, 2012 5:21 PM > To: clue@ietf.org > Subject: Re: [clue] Framework scene description attribute update >=20 > Mark, >=20 > So you are proposing one list of descriptions, and a separate but paralle= l list > of languages? >=20 > That seems clumsy, unnatural, and error prone. Why not a list of pairs of > (description, language)? And I'd be inclined to specify that a particular > language value MUST NOT be specified more than once. >=20 > Thanks, > Paul >=20 > On 7/2/12 5:12 PM, Duckworth, Mark wrote: > > Based on the decision at the interim meeting to support multiple > > description strings, each in a different language, here is my proposed > > updated text for the framework document. I also addressed Christians > > comments > > http://www.ietf.org/mail-archive/web/clue/current/msg01522.html > > > > Please review this change. > > > > Description attribute > > > > The optional description attribute is a list of human readable text > > > > strings which describes the capture scene. If there is more than one > > > > string in the list, then each string in the list should contain the > > > > same description, but in a different language. A provider that > > > > advertises multiple capture scenes may use different descriptions to > > > > differentiate between them. This attribute can contain text in any > > > > number of languages. > > > > Description Language attribute > > > > This attribute is a list of language tags, to identify the language > > > > of the corresponding description attribute text. The number of > > > > language tags in this list must be the same as the number of strings > > > > in the description list. The possible values for a language tag are > > > > the values of the 'Subtag' column for the "Type: language" entries in > > > > the "Language Subtag Registry" at [IANA-Lan] originally defined in > > > > [RFC5646]. > > > > Regards, > > > > Mark > > > > > > > > _______________________________________________ > > 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 pkyzivat@alum.mit.edu Mon Jul 2 15:57: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 57D5C11E8080 for ; Mon, 2 Jul 2012 15:57:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.985 X-Spam-Level: X-Spam-Status: No, score=-1.985 tagged_above=-999 required=5 tests=[AWL=0.614, 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 jl4doVwxFFMS for ; Mon, 2 Jul 2012 15:57:05 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by ietfa.amsl.com (Postfix) with ESMTP id 8D33E21F85FD for ; Mon, 2 Jul 2012 15:57:05 -0700 (PDT) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta13.westchester.pa.mail.comcast.net with comcast id VPRN1j0010SCNGk5DaxDrU; Mon, 02 Jul 2012 22:57:13 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta09.westchester.pa.mail.comcast.net with comcast id VaxF1j00D3ZTu2S3VaxFv5; Mon, 02 Jul 2012 22:57:15 +0000 Message-ID: <4FF22746.2090909@alum.mit.edu> Date: Mon, 02 Jul 2012 18:57:10 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: clue@ietf.org References: <44C6B6B2D0CF424AA90B6055548D7A6102FE035F38@CRPMBOXPRD01.polycom.com> <4FF210B4.2040809@alum.mit.edu> <44C6B6B2D0CF424AA90B6055548D7A6102FE035F86@CRPMBOXPRD01.polycom.com> In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A6102FE035F86@CRPMBOXPRD01.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] Framework scene description attribute update 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, 02 Jul 2012 22:57:06 -0000 On 7/2/12 6:23 PM, Duckworth, Mark wrote: > Hi Paul, > I thought of your way too, which is also fine with me. I can reword the text to do it that way if people prefer. > Mark In practice I think we want to end up with what Espen commented. But you have to get down into the xml to describe that. The model is too high level to talk about it that way. So what I said, or anything else that can clearly map to what Espen said works for me. Thanks, Paul >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >> Paul Kyzivat >> Sent: Monday, July 02, 2012 5:21 PM >> To: clue@ietf.org >> Subject: Re: [clue] Framework scene description attribute update >> >> Mark, >> >> So you are proposing one list of descriptions, and a separate but parallel list >> of languages? >> >> That seems clumsy, unnatural, and error prone. Why not a list of pairs of >> (description, language)? And I'd be inclined to specify that a particular >> language value MUST NOT be specified more than once. >> >> Thanks, >> Paul >> >> On 7/2/12 5:12 PM, Duckworth, Mark wrote: >>> Based on the decision at the interim meeting to support multiple >>> description strings, each in a different language, here is my proposed >>> updated text for the framework document. I also addressed Christians >>> comments >>> http://www.ietf.org/mail-archive/web/clue/current/msg01522.html >>> >>> Please review this change. >>> >>> Description attribute >>> >>> The optional description attribute is a list of human readable text >>> >>> strings which describes the capture scene. If there is more than one >>> >>> string in the list, then each string in the list should contain the >>> >>> same description, but in a different language. A provider that >>> >>> advertises multiple capture scenes may use different descriptions to >>> >>> differentiate between them. This attribute can contain text in any >>> >>> number of languages. >>> >>> Description Language attribute >>> >>> This attribute is a list of language tags, to identify the language >>> >>> of the corresponding description attribute text. The number of >>> >>> language tags in this list must be the same as the number of strings >>> >>> in the description list. The possible values for a language tag are >>> >>> the values of the 'Subtag' column for the "Type: language" entries in >>> >>> the "Language Subtag Registry" at [IANA-Lan] originally defined in >>> >>> [RFC5646]. >>> >>> Regards, >>> >>> Mark >>> >>> >>> >>> _______________________________________________ >>> 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 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From mary.ietf.barnes@gmail.com Mon Jul 2 17:29:32 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 B4EF111E80E3 for ; Mon, 2 Jul 2012 17:29:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.799 X-Spam-Level: X-Spam-Status: No, score=-102.799 tagged_above=-999 required=5 tests=[AWL=-0.867, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, 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 UrERwzI6ZKs6 for ; Mon, 2 Jul 2012 17:29:32 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1CB5311E80BD for ; Mon, 2 Jul 2012 17:29:32 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so10333408obb.31 for ; Mon, 02 Jul 2012 17:29:38 -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=VmzMe8FGutu9yAkMOok8tFkoCPPU8sCETzGVqqq1h80=; b=DDSqLPkgkKbgcH8jaY6i8JVfZBBUpj2cVXzSZG64upaUhf2lDh7OHxRT9ti2ZwQO4e qgPMSektQVp9639zlbOx1t3I6Ifddz0RqIFJdPOUlxD+GHJs/HnD/pf2JFP5zwz29FNB u99V7yLGz1TQawT/zyeuyrThvNBzFqQY+oCKoQSlbjRk5xKXKP/zRPdAv3VPI6Ej5mSM Z4bBCAa5NhTF23JYTwp5tY9m3bjj2oQnq/91FN35Kc9o8RSdUumsSiGExXZAnS7CiadI k/WwFXt5+C2zMZhd0OQn9X0QfDDquqTnZQli3MplvAn97SJiZaGj1RpruxAfzWzh9yRL pSpw== MIME-Version: 1.0 Received: by 10.182.164.8 with SMTP id ym8mr10482102obb.51.1341275378286; Mon, 02 Jul 2012 17:29:38 -0700 (PDT) Received: by 10.182.147.1 with HTTP; Mon, 2 Jul 2012 17:29:38 -0700 (PDT) In-Reply-To: <4FF2176B.6020005@alum.mit.edu> References: <4FF2176B.6020005@alum.mit.edu> Date: Mon, 2 Jul 2012 19:29:38 -0500 Message-ID: From: Mary Barnes To: Paul Kyzivat Content-Type: multipart/alternative; boundary=e89a8f646a0778002904c3e2022b Cc: clue@ietf.org Subject: Re: [clue] is there a meeting Tues? thanks 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, 03 Jul 2012 00:29:32 -0000 --e89a8f646a0778002904c3e2022b Content-Type: text/plain; charset=ISO-8859-1 We probably don't need a meeting. Not really due to US holiday, but rather there hasn't been much mailing list discussion. Also, folks likely need to be focusing on updating drafts and prepping materials for the tutorial. Note that there is less than one week before the -00 deadline and two weeks before the final deadline. We will have a meeting next week to go through what folks have for the tutorial. Please note that I don't think a whole lot of new stuff needs to be put together. There are materials from the first presentation in DISPATCH and various WG meetings. Of course, pictures/diagrams are always good. Really, I think the key is to consider what 3 things should the attendees know for each of the areas. Thanks, Mary. On Mon, Jul 2, 2012 at 4:49 PM, Paul Kyzivat wrote: > I haven't spoken with Mary about it. But given the US holiday I presume > not. > > Thanks, > Paul > ______________________________**_________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/**listinfo/clue > --e89a8f646a0778002904c3e2022b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable We probably don't need a meeting. =A0Not really due to US holiday, but = rather there hasn't been much mailing list discussion. =A0 Also, folks = likely need to be focusing on updating drafts and prepping materials for th= e tutorial. =A0

Note that there is less than one week before the -00 deadlin= e and two weeks before the final deadline. =A0We will have a meeting next w= eek to go through what folks have for the tutorial. =A0Please note that I d= on't think a whole lot of new stuff needs to be put together. =A0There = are materials from the first presentation in DISPATCH and various WG meetin= gs. =A0Of course, pictures/diagrams are always good. =A0Really, I think the= key is to consider what 3 things should the attendees know for each of the= areas. =A0

Thanks,

Mary.=A0

On Mon, Jul 2, 2012 at 4:49 PM, Paul Kyzivat <pkyziv= at@alum.mit.edu> wrote:

I haven't spoken with Mary about it. But= given the US holiday I presume not.

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

--e89a8f646a0778002904c3e2022b-- From allyn@cisco.com Mon Jul 2 20:23: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 EFB4C11E811A for ; Mon, 2 Jul 2012 20:23:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, 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 RLAT2EcQoRXo for ; Mon, 2 Jul 2012 20:23:44 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id AB24811E8119 for ; Mon, 2 Jul 2012 20:23:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=10005; q=dns/txt; s=iport; t=1341285831; x=1342495431; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=os8ZJpI8+3C96EQvp7Z/necT2/6ryfcllnF+VZXczzQ=; b=ED2F+jy4URzQcJQOLsevJpPiyn2QLH3e7ESboqCpi0HFSlZ+ndWy56Ex Zd8Fw5IxcnQGgs0yNlaWAJ799rkW0mGSdrTIkMmrbEn1qJEfR1BxSL7bL XjrcfeWi5RUDGWrFhG3EZXO2g32SVuu4CpP/YblD25vGJXAiLwQJvNs76 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAIRl8k+tJV2c/2dsb2JhbAA8CbZogQeCGAEBAQQBAQEPAScuBgkOBgEIEQQBAQsUCS4LFAgBCQEEARIIEweHaQuaWqBIBIs5EYUpYAOLJ5BPh1uBZoJf X-IronPort-AV: E=Sophos;i="4.77,514,1336348800"; d="scan'208";a="98148680" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 03 Jul 2012 03:23:51 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q633Npvf003998 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Jul 2012 03:23:51 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.100]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0298.004; Mon, 2 Jul 2012 22:23:50 -0500 From: "Allyn Romanow (allyn)" To: Roni even , "clue@ietf.org" Thread-Topic: [clue] FW: New Version Notification for draft-even-clue-swithed-use-cases-00.txt Thread-Index: Ac1Yy0DRcMMsBwLYQdydMw8rv0ya0Q== Date: Tue, 3 Jul 2012 03:23:49 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.79.41] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19014.000 x-tm-as-result: No--43.831600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [clue] FW: New Version Notification for draft-even-clue-swithed-use-cases-00.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, 03 Jul 2012 03:23:46 -0000 Hi Roni, I mentioned during the weekly call that I had some comments. Thanks for you= r patience in getting them to you. Best, Allyn I think your draft is really useful and well put. I just have two comments = which I'll illustrate in comments on Section 3. 1. You are including both composition and switched captures as if they are = similar or can be treated similarly. I don't think that's the case. 2. I feel that sometimes a solution is included in the description of the i= ssue and I think it is preferable that the use cases are just the descripti= on of the issue, and possible solutions can be stated separately. Section 3 I think the statement of the issue is quite good and well put - the consume= r wants to have better control over what it is sent. Similarly your bulleted examples are also helpful and descriptive. Here are my specific comments on the use case list - The above examples represent part of the possible cases where the consumer wants control over the content of the media captures and of cases where the consumer provides more information to the provider about his hardware and software capabilities. I think the wording is a bit too specific. It's not only that the consumer = "wants control over the content of the media captures", it's more that the = consumer wants to specify which media captures are offered - which I think = is a bit different. So I would say something more like =20 the consumer wants more control over the captures it receives The statement "consumer provides more information to the provider about his= hardware and software capabilities" is a bit too narrow. Perhaps the consu= mer wants to specify its layout. Also, this is a more a statement of a solu= tion - for the consumer to provide more information about his abilities is = a solution to a problem, rather than a statement of the problem. I would su= ggest not including this sentence. 1. The provider offers multiple mixed captures. Currently the only attribute has a Boolean value. The provider would like to provide more information about the mixes content allowing the consumer to select a relevant one. I think the problem is stated, but so is the solution - the problem is that= the consumer wants to select among multiple offered mixed captures. A mech= anism is needed. "The provider would like to provide more information about= the mixes content" is a particular solution. For example, another particul= ar solution is that the provider chooses; another is that the provider send= s a ranking number for each offered composition.. There are countless appro= aches in addition to the one offered here. So, I would suggest leaving out = this sentence. 2. The provider would like to offer only media captures that are useful to the consumer. The simple case is based on the number of available monitors for main video. Why does the provider want to offer only media captures that are useful to = the consumer? This isn't how the model thus far is specified. Rather, the p= rovider wants to offer what it can, and leave it up to the consumer to take= what it wants. Maybe you were referring to a desire to optimize the announ= cement? When and why? I'm not so sure what the second sentence means, but I think it means that y= ou want the provider to make its offer based on the number of monitors that= the consumer has? But that wouldn't make sense..since the consumer can use= more streams than it has monitors, so I guess I don't know what it means?= ? 3. The consumer will provide more information about his preferences for example the total number of monitors that can be used dynamically for all types of media (number of speakers, number of monitors for main or presentation video, the number of simultaneous video streams that the consumer can decode ...). The provider will advertise relevant CSEs that he can support to address these preferences. It may be more than one option. This item is a proposal for a solution to the issues being described. As su= ch I don't think it should be in this document as it currently describes it= self as a description of use cases. 4. The MCU will offer mixed media captures (one or more) in one or more CSEs. The consumer want to select how many sources are in each mixed capture and how the layout should look. This will allow each consumer to create a personal layout if the MCU allows this functionality. The MCU is doing the actual mix in the case. By "mixed media captures", do you mean composed captures? If so, I believe = that there has been a decision in the WG, discussed most recently during th= e interim meeting, not to work on the topic of compositions in detail - the= process of composing and decomposing. I think that your second sentence re= lates to compositions and how they are formed. So, I think this item should not be included in this document.=20 5. The MCU will offer multiple media captures in one or more CSEs. The consumer want to select who will be seen in each mixed capture knowing the number of maximum media streams that can compose the mix. This use cases adds to the previous one the ability to control the policy by which streams are added or removed from a mix. As in #4, I think it was decided not delve into the process of composing an= d decomposing mixes. I believe this is work that does not need to be done i= n CLUE, and someone could start the work somewhere else if desired. Thus, this item should be removed from the list. 6. The MCU will offer multiple switched media captures in one or more CSEs. The consumer wants to define a switching policy for each of the switched streams. Point of clarification what is a switching policy for each switched stream?= You mean a policy like VAD, for example? We haven't discussed yet how the= policy for choosing switched content happens. Up to now it's the provider = who decides. Now, are you suggesting that the consumer wants to specify the= basis for choosing content of a switched capture? 7. The MCU will offer multiple switched and mixed media captures in one or more CSEs. The consumer would like to define the layouts topology. I think this is a restatement - if there is a switched capture the consumer= needs to know where to put it. If there is more than one composed capture, there needs to be a way of sele= cting between them. Again, I think that saying the "consumer would like to define the layouts t= opology" is going too far toward a solution in a description of the use cas= es. Very likely this is a possible solution, but there are others. So I think this item could be removed, or restated.=20 Again, the consumer defining the layouts topology is a solution to a proble= m, not the use case. 9. The consumer would like to get multiple media captures and create his own views. The media capture may be a switched stream. The information available to the consumer should include the identity of the stream and its spatial information (example left camera from TPRoom1). The information should be available when a switch occurs. What do mean by identity of the stream? Roster info? I thought that roster = info was considered conference control and not being handled by CLUE? Otherwise, this item seems like this is more a less a statement of the iss= ue of switched captures not having enough spatial information for rendering= . As such, it could be dstate like that, as a description of an issue, and = moved further up in the list? 10. The consumer would like to define layouts to the provider to be used for the media captures. The consumer accepts a mixed or switched stream in each sub-window. The maximum number of switched streams will be the number of sub-windows. The consumer will need to know who is the current stream in a mixed capture including his spatial information. I'm not clear what this is saying, and whether it's use case, problem state= ment or solution proposal. -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Ron= i even Sent: Monday, June 11, 2012 7:20 AM To: clue@ietf.org Subject: [clue] FW: New Version Notification for draft-even-clue-swithed-us= e-cases-00.txt Hi, I submitted a document that list some use cases where using the switched an= d mixed attributes for media capture will not provide enough information. This was my action item from the Interim meeting in Stockholm.=20 I noticed a typo in the document name after I submitted it Thanks Roni Even ________________________________________ From: internet-drafts@ietf.org [internet-drafts@ietf.org] Sent: Monday, June 11, 2012 17:13 To: Roni even Subject: New Version Notification for draft-even-clue-swithed-use-cases-00.= txt A new version of I-D, draft-even-clue-swithed-use-cases-00.txt has been suc= cessfully submitted by Roni Even and posted to the IETF repository. Filename: draft-even-clue-swithed-use-cases Revision: 00 Title: CLUE switched and mixed captures use cases Creation date: 2012-06-11 WG ID: Individual Submission Number of pages: 7 Abstract: This document describes multi stream use cases using switched and mixed streams. This document present the cases when using the switched and mixed attributes with Boolean values may not provide the best results. The IETF Secretariat _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From Christian.Groves@nteczone.com Mon Jul 2 23:48:47 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 3745411E813E for ; Mon, 2 Jul 2012 23:48:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 duAkCbjfdiLK for ; Mon, 2 Jul 2012 23:48:46 -0700 (PDT) Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:4]) by ietfa.amsl.com (Postfix) with ESMTP id 086ED11E8134 for ; Mon, 2 Jul 2012 23:48:45 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBABCV8k920X8k/2dsb2JhbAANOLoLAQEBBAEBARoVAQUbGwoRCxEDAQEBAQkWCAcJAwIBAgEPBh8JCBMGAgEBBYd0AxaxTQ2JTopSZhqGAAOgOIdxgU0 Received: from ppp118-209-127-36.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.127.36]) by ipmail04.adl6.internode.on.net with ESMTP; 03 Jul 2012 16:18:51 +0930 Message-ID: <4FF295CE.2070903@nteczone.com> Date: Tue, 03 Jul 2012 16:48:46 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: clue@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [clue] Concensus call: Text for "Axis of Capture" 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, 03 Jul 2012 06:48:47 -0000 I'm getting confused.... my understanding is the following: - If the "point of capture" is included and the "axis of capture point" is not included then the axis is assumed to be perpendicular to the centre of the capture area. - if the "point of capture" is included and the "axis of capture point" is included it describes a position in space of a second point on the axis of capture of the capturing device;*** - If the "point of capture" is not included then "axis of capture point" is not used. Is this the desired behaviour? With regards to the *** above, an axis (line) travels in two directions. I wonder if it is beneficial to specify that the axis of capture point must lie between the capture area and the point of capture. Might help avoid some confusion if someone defines a point behind the capture point. I'm also wondering if it is better to call this "line of capture" or "optical axis" or similar? Mathematically speaking what we're defining by two points is a line or optically speaking its an optical axis. Regards, Christian On 3/07/2012 6:51 AM, Stephan Wenger wrote: > Lousy internet connection�let's see whether this gets through� > Roni, without any changes, y reading of the text proposed is that > there is no axis of capture knowledge unless both point and axis of > capture are specified. No inference of the axis of capture from the > field of capture is implied. > I think I support this proposal. It is trivial to calculate a point of > capture even if point of capture is identical with the center of the > field of capture coordinates. The signaling may be unnecessary if we > were mandating a condition as you implicitly propose it, but bits on > this level ought to be cheap. Suggest we be explicit and say either > point of capture is specified, or no one knows. > Stephan > > > From: Roni Even > > Date: Monday, 2 July, 2012 12:46 > To: 'Mary Barnes' >, 'CLUE' > > Subject: Re: [clue] Concensus call: Text for "Axis of Capture" > > Hi, > > In general I am OK with the text I am just wondering about > > �If the Axis of Capture Point is not specified, it means the consumer should not assume anything about the axis of capture of the capturing device.� > > Is this the assumption or should the consumer assume that the axis of capture is perpendicular to the center of the area of capture. If the above sentence is specified I am wondering what is the value in providing the point of capture. > Thanks > Roni > > *From:*clue-bounces@ietf.org > [mailto:clue-bounces@ietf.org] *On Behalf Of *Mary Barnes > *Sent:* 02 July, 2012 7:58 PM > *To:* CLUE > *Subject:* [clue] Concensus call: Text for "Axis of Capture" > > Per the design team call last week, we want to do a consensus call for > the text to cover the "Axis of capture". There were several suggested > updates to Stephan's original text: > > http://www.ietf.org/mail-archive/web/clue/current/msg01583.html > > Thus, we would like folks to respond as to whether they are okay with > the following text being added to section 6.1.1(relative to > draft-ietf-clue-framework-05 - after the two paragraphs of "point of > capture" - middle of page 11): > > > Axis of Capture Point: {(X, Y, Z)} A field with a single Cartesian > > (X, Y, Z) point value (virtual or physical) which describes a position > > in space of a second point on the axis of capture of the capturing > > device; the first point being the Point of Capture (see above). > > > The axis of capture point MUST NOT be specified if the Point of Capture > is not present for this capture device. > When the Axis of Capture Point attribute is specified, it must include X, > Y and Z coordinates. These coordinates MUST not be identical to the > > Point of Capture coordinates. > If the Axis of Capture Point is not specified, it > means the consumer should not assume anything about the axis of > > capture of the capturing device. > > So, please respond "Yes" if you think the text if fine, "Maybe" if you > think it needs tweaking (and include the suggested > > tweaks). Note, we agreed to add this at the interim meeting, thus if > you answer "No", you must include > > a compelling reason why this should not be added in some form. > > Regards, > > Mary > > CLUE WG co-chair > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From Christian.Groves@nteczone.com Mon Jul 2 23:53: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 1FB1621F8534 for ; Mon, 2 Jul 2012 23:53:03 -0700 (PDT) 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 aYBBcRRU72PL for ; Mon, 2 Jul 2012 23:53:02 -0700 (PDT) Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:4]) by ietfa.amsl.com (Postfix) with ESMTP id 3E9EF21F8550 for ; Mon, 2 Jul 2012 23:53:01 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBADmW8k920X8k/2dsb2JhbAANLgq6CwEBAQQBAQE1GxsKDQQLEQQBAQEJFggHCQMCAQIBFR8JCBMGAgEBBYgNuy2LOBAKgmSDHAOoKYFN Received: from ppp118-209-127-36.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.127.36]) by ipmail04.adl6.internode.on.net with ESMTP; 03 Jul 2012 16:23:08 +0930 Message-ID: <4FF296D0.6020606@nteczone.com> Date: Tue, 03 Jul 2012 16:53:04 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: clue@ietf.org References: <44C6B6B2D0CF424AA90B6055548D7A6102FE035F38@CRPMBOXPRD01.polycom.com> <4FF210B4.2040809@alum.mit.edu> <44C6B6B2D0CF424AA90B6055548D7A6102FE035F86@CRPMBOXPRD01.polycom.com> In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A6102FE035F86@CRPMBOXPRD01.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] Framework scene description attribute update 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, 03 Jul 2012 06:53:03 -0000 Hello Mark, Having the language tag with the text as Paul suggests seems more natural to me. Regards, Christian On 3/07/2012 8:23 AM, Duckworth, Mark wrote: > Hi Paul, > I thought of your way too, which is also fine with me. I can reword the text to do it that way if people prefer. > Mark > >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >> Paul Kyzivat >> Sent: Monday, July 02, 2012 5:21 PM >> To: clue@ietf.org >> Subject: Re: [clue] Framework scene description attribute update >> >> Mark, >> >> So you are proposing one list of descriptions, and a separate but parallel list >> of languages? >> >> That seems clumsy, unnatural, and error prone. Why not a list of pairs of >> (description, language)? And I'd be inclined to specify that a particular >> language value MUST NOT be specified more than once. >> >> Thanks, >> Paul >> >> On 7/2/12 5:12 PM, Duckworth, Mark wrote: >>> Based on the decision at the interim meeting to support multiple >>> description strings, each in a different language, here is my proposed >>> updated text for the framework document. I also addressed Christians >>> comments >>> http://www.ietf.org/mail-archive/web/clue/current/msg01522.html >>> >>> Please review this change. >>> >>> Description attribute >>> >>> The optional description attribute is a list of human readable text >>> >>> strings which describes the capture scene. If there is more than one >>> >>> string in the list, then each string in the list should contain the >>> >>> same description, but in a different language. A provider that >>> >>> advertises multiple capture scenes may use different descriptions to >>> >>> differentiate between them. This attribute can contain text in any >>> >>> number of languages. >>> >>> Description Language attribute >>> >>> This attribute is a list of language tags, to identify the language >>> >>> of the corresponding description attribute text. The number of >>> >>> language tags in this list must be the same as the number of strings >>> >>> in the description list. The possible values for a language tag are >>> >>> the values of the 'Subtag' column for the "Type: language" entries in >>> >>> the "Language Subtag Registry" at [IANA-Lan] originally defined in >>> >>> [RFC5646]. >>> >>> Regards, >>> >>> Mark >>> >>> >>> >>> _______________________________________________ >>> 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 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From Mark.Duckworth@polycom.com Tue Jul 3 06:19:52 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 07ADA21F87EE for ; Tue, 3 Jul 2012 06:19:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.339 X-Spam-Level: X-Spam-Status: No, score=-6.339 tagged_above=-999 required=5 tests=[AWL=0.260, 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 zFYRC0IKWmGV for ; Tue, 3 Jul 2012 06:19:51 -0700 (PDT) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 3635C21F86A6 for ; Tue, 3 Jul 2012 06:19:50 -0700 (PDT) Received: from Crpmboxprd01.polycom.com ([fe80::ad68:5a0:c919:66b6]) by Crpehubprd01.polycom.com ([fe80::5efe:10.236.0.158%14]) with mapi; Tue, 3 Jul 2012 06:19:58 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Tue, 3 Jul 2012 06:19:56 -0700 Thread-Topic: [clue] Framework scene description attribute update Thread-Index: Ac1YpgdkCboiOtirR+WbcCXCfpZJNQAd7ijw Message-ID: <44C6B6B2D0CF424AA90B6055548D7A6102FE03605E@CRPMBOXPRD01.polycom.com> References: <44C6B6B2D0CF424AA90B6055548D7A6102FE035F38@CRPMBOXPRD01.polycom.com> <4FF210B4.2040809@alum.mit.edu> <44C6B6B2D0CF424AA90B6055548D7A6102FE035F86@CRPMBOXPRD01.polycom.com> <4FF22746.2090909@alum.mit.edu> In-Reply-To: <4FF22746.2090909@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 Subject: Re: [clue] Framework scene description attribute update 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, 03 Jul 2012 13:19:52 -0000 Okay, how about this text for the scene description attribute: Description attribute - list of {, } The optional description attribute is a list of human readable text strings which describe the capture scene. If there is more than one string in the list, then each string in the list should contain the same description, but in a different language. A provider that advertises multiple capture scenes may use different descriptions to differentiate between them. This attribute can contain text in any number of languages. The language tag identifies the language of the corresponding description text. The possible values for a language tag are the values of the 'Subtag' column for the "Type: language" entries in the "Language Subtag Registry" at [IANA-Lan] originally defined in [RFC5646]. A particular language tag value MUST NOT be used more than once in the description attribute list. Mark > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: Monday, July 02, 2012 6:57 PM > To: clue@ietf.org > Subject: Re: [clue] Framework scene description attribute update >=20 > On 7/2/12 6:23 PM, Duckworth, Mark wrote: > > Hi Paul, > > I thought of your way too, which is also fine with me. I can reword th= e text > to do it that way if people prefer. > > Mark >=20 > In practice I think we want to end up with what Espen commented. > But you have to get down into the xml to describe that. The model is too = high > level to talk about it that way. So what I said, or anything else that ca= n clearly > map to what Espen said works for me. >=20 > Thanks, > Paul >=20 > >> -----Original Message----- > >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > >> Of Paul Kyzivat > >> Sent: Monday, July 02, 2012 5:21 PM > >> To: clue@ietf.org > >> Subject: Re: [clue] Framework scene description attribute update > >> > >> Mark, > >> > >> So you are proposing one list of descriptions, and a separate but > >> parallel list of languages? > >> > >> That seems clumsy, unnatural, and error prone. Why not a list of > >> pairs of (description, language)? And I'd be inclined to specify that > >> a particular language value MUST NOT be specified more than once. > >> > >> Thanks, > >> Paul > >> > >> On 7/2/12 5:12 PM, Duckworth, Mark wrote: > >>> Based on the decision at the interim meeting to support multiple > >>> description strings, each in a different language, here is my > >>> proposed updated text for the framework document. I also addressed > >>> Christians comments > >>> http://www.ietf.org/mail-archive/web/clue/current/msg01522.html > >>> > >>> Please review this change. > >>> > >>> Description attribute > >>> > >>> The optional description attribute is a list of human readable text > >>> strings which describes the capture scene. If there is more than one > >>> string in the list, then each string in the list should contain the > >>> same description, but in a different language. A provider that > >>> advertises multiple capture scenes may use different descriptions to > >>> differentiate between them. This attribute can contain text in any > >>> number of languages. > >>> > >>> Description Language attribute > >>> > >>> This attribute is a list of language tags, to identify the language > >>> of the corresponding description attribute text. The number of > >>> language tags in this list must be the same as the number of strings > >>> in the description list. The possible values for a language tag are > >>> the values of the 'Subtag' column for the "Type: language" entries > >>> in > >>> the "Language Subtag Registry" at [IANA-Lan] originally defined in > >>> [RFC5646]. > >>> > >>> Regards, > >>> > >>> Mark From Mark.Duckworth@polycom.com Tue Jul 3 07:47: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 6A1DB21F86B4 for ; Tue, 3 Jul 2012 07:47:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.382 X-Spam-Level: X-Spam-Status: No, score=-6.382 tagged_above=-999 required=5 tests=[AWL=0.216, 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 OePSAr9GZRxN for ; Tue, 3 Jul 2012 07:47:44 -0700 (PDT) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id BBDE321F8628 for ; Tue, 3 Jul 2012 07:47:44 -0700 (PDT) Received: from Crpmboxprd01.polycom.com ([fe80::ad68:5a0:c919:66b6]) by crpehubprd02.polycom.com ([fe80::5efe:10.236.0.154%12]) with mapi; Tue, 3 Jul 2012 07:47:51 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Tue, 3 Jul 2012 07:47:49 -0700 Thread-Topic: Is there anything else to change in the framework right now? Thread-Index: Ac1ZKohwPIkhNB1TS/2FqJ6Z1asGQg== Message-ID: <44C6B6B2D0CF424AA90B6055548D7A6102FE0360D2@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_44C6B6B2D0CF424AA90B6055548D7A6102FE0360D2CRPMBOXPRD01p_" MIME-Version: 1.0 Subject: [clue] Is there anything else to change in the framework right now? 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, 03 Jul 2012 14:47:45 -0000 --_000_44C6B6B2D0CF424AA90B6055548D7A6102FE0360D2CRPMBOXPRD01p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Here is the list I have of changes going into the next version of the frame= work: 1. Capture scene description attribute is a list of text strings, each in a different language, rather than just a single string. 2. Add new Axis of Capture Point attribute. 3. Remove appendices A.1 through A.6. 4. Clarify that the provider must use the same coordinate system with same scale and origin for all coordinates within the same capture scene. This is all I know about that has consensus to change. Am I missing anythi= ng? Thanks, Mark --_000_44C6B6B2D0CF424AA90B6055548D7A6102FE0360D2CRPMBOXPRD01p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Here is the list= I have of changes going into the next version of the framework:=

&n= bsp; 1. Capture scene description attribute is a list of text strings= ,

e= ach in a different language, rather than just a single string.

&nbs= p; 2. Add new Axis of Capture Point attribute.

3. = ; Remove appendices A.1 through A.6.

4. Clarify that t= he provider must use the same coordinate system

with same scale and origin for= all coordinates within the same

&= nbsp; capture scene.

This is all I know about tha= t has consensus to change. Am I missing anything?

Thanks,

Mark

= --_000_44C6B6B2D0CF424AA90B6055548D7A6102FE0360D2CRPMBOXPRD01p_-- From john@jlc.net Tue Jul 3 10:50: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 073E311E8191 for ; Tue, 3 Jul 2012 10:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.56 X-Spam-Level: X-Spam-Status: No, score=-106.56 tagged_above=-999 required=5 tests=[AWL=0.039, 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 iz-Aw1UvkEWt for ; Tue, 3 Jul 2012 10:50:47 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id A5C7311E80A4 for ; Tue, 3 Jul 2012 10:50:46 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id A5F5B33C26; Tue, 3 Jul 2012 13:50:54 -0400 (EDT) Date: Tue, 3 Jul 2012 13:50:54 -0400 From: John Leslie To: Christian Groves Message-ID: <20120703175054.GA63837@verdi> References: <4FF295CE.2070903@nteczone.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FF295CE.2070903@nteczone.com> User-Agent: Mutt/1.4.1i Cc: clue@ietf.org Subject: Re: [clue] Concensus call: Text for "Axis of Capture" 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, 03 Jul 2012 17:50:49 -0000 Christian Groves wrote: > > I'm getting confused.... my understanding is the following: > > - If the "point of capture" is included and the "axis of capture point" > is not included then the axis is assumed to be perpendicular to the > centre of the capture area. That's enough to confuse me! I went back to the text of draft-ietf-clue-framework-05, section 6.1.1: ]... ] Point of Capture: {(X, Y, Z)} A field with a single Cartesian (X, Y, ] Z) point value which describes the spatial location, virtual or ] physical, of the capturing device (such as camera). ] ] When the Point of Capture attribute is specified, it must include X, ] Y and Z coordinates. If the point of capture is not specified, it ] means the consumer should not assume anything about the spatial ] location of the capturing device. Even if the provider specifies an ] area of capture attribute, it does not need to specify the point of ] capture. That last sentence is enough to confuse anybody, IMHO. :^( But I don't see how you're entitled to assume "perpendicular" to the plane of the Area of Capture. IMHO, failure to include Point of Capture is distinctly not-nice, and leaves you no good way to associate pixel positions with physical positions. It's certainly possible that the provider would fail to include Point of Capture because s/he's providing a processed piece, possibly stiched together from parts of different cameras. (I don't consider that nice either!) > - if the "point of capture" is included and the "axis of capture point" > is included it describes a position in space of a second point on the > axis of capture of the capturing device;*** Refer to the proposed text: ] ] Axis of Capture Point: {(X, Y, Z)} A field with a single Cartesian ] (X, Y, Z) point value (virtual or physical) which describes a position ] in space of a second point on the axis of capture of the capturing ] device; the first point being the Point of Capture (see above). ] ] The axis of capture point MUST NOT be specified if the Capture Point ] is not present for this capture device. ] ] When the Axis of Capture Point attribute is specified, it must include X, ] Y and Z coordinates. If the Axis of Capture point is not specified, it ] means the consumer should not assume anything about the axis of ] Capture of the capturing device. Your statement seems correct, though not 100% implied. I wonder why we don't specify that the Axis of Capture Point is a point within the plane of the Area of Capture (when possible). > - If the "point of capture" is not included then "axis of capture point" > is not used. That much is clear. > Is this the desired behaviour? > > With regards to the *** above, an axis (line) travels in two directions. Quite correct. > I wonder if it is beneficial to specify that the axis of capture point > must lie between the capture area and the point of capture. You mean Area of Capture, no doubt? > Might help avoid some confusion if someone defines a point behind the > capture point. If someone can't handle that, we have worse problems! Nonetheless, ISTM that one will need to calculate the intersection of that line with the Area of Capture (unless the Axis of Capture Point is defined to be that intersection already). This introduces rounding errors which could possibly be significant. > I'm also wondering if it is better to call this "line of capture" or > "optical axis" or similar? Mathematically speaking what we're defining > by two points is a line or optically speaking its an optical axis. It might indeed be easier to understand (though I must admit the _value_ is a single XYZ point)... -- John Leslie From pkyzivat@alum.mit.edu Tue Jul 3 10:55:23 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 7C27C11E8096 for ; Tue, 3 Jul 2012 10:55:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[AWL=0.502, 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 GnLCa7dOZ0Nu for ; Tue, 3 Jul 2012 10:55:22 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [76.96.59.228]) by ietfa.amsl.com (Postfix) with ESMTP id 90D6F11E8073 for ; Tue, 3 Jul 2012 10:55:20 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta15.westchester.pa.mail.comcast.net with comcast id VoR91j0041ap0As5FtvZTa; Tue, 03 Jul 2012 17:55:33 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta22.westchester.pa.mail.comcast.net with comcast id Vtvb1j00d3ZTu2S3itvc5s; Tue, 03 Jul 2012 17:55:36 +0000 Message-ID: <4FF3320F.5010809@alum.mit.edu> Date: Tue, 03 Jul 2012 13:55:27 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: clue@ietf.org References: <44C6B6B2D0CF424AA90B6055548D7A6102FE0360D2@CRPMBOXPRD01.polycom.com> In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A6102FE0360D2@CRPMBOXPRD01.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] Is there anything else to change in the framework right now? 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, 03 Jul 2012 17:55:23 -0000 On 7/3/12 10:47 AM, Duckworth, Mark wrote: > 4. Clarify that the provider must use the same coordinate system > with same scale and origin for all coordinates within the same > capture scene. This is inescapable if the coordinate system scale and origin are only specifiable as attributes of the capture scene, because there is no way to violate this. Thanks, Paul From pkyzivat@alum.mit.edu Tue Jul 3 11:40: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 29BF211E81BB for ; Tue, 3 Jul 2012 11:40:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[AWL=0.425, 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 O7u15CaToSLm for ; Tue, 3 Jul 2012 11:40:24 -0700 (PDT) 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 23EAB11E81B2 for ; Tue, 3 Jul 2012 11:40:23 -0700 (PDT) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by QMTA11.westchester.pa.mail.comcast.net with comcast id Vudy1j0040bG4ec5BugaWu; Tue, 03 Jul 2012 18:40:34 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta03.westchester.pa.mail.comcast.net with comcast id VugW1j01d3ZTu2S3PugXAC; Tue, 03 Jul 2012 18:40:34 +0000 Message-ID: <4FF33C9C.3020503@alum.mit.edu> Date: Tue, 03 Jul 2012 14:40:28 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: clue@ietf.org References: <4FF295CE.2070903@nteczone.com> <20120703175054.GA63837@verdi> In-Reply-To: <20120703175054.GA63837@verdi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] Concensus call: Text for "Axis of Capture" 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, 03 Jul 2012 18:40:25 -0000 Interesting discussion. I'm known for probing corner cases, and I'm going to do some of that here. On 7/3/12 1:50 PM, John Leslie wrote: > Christian Groves wrote: >> >> I'm getting confused.... my understanding is the following: >> >> - If the "point of capture" is included and the "axis of capture point" >> is not included then the axis is assumed to be perpendicular to the >> centre of the capture area. > > That's enough to confuse me! > > I went back to the text of draft-ietf-clue-framework-05, section 6.1.1: > ]... > ] Point of Capture: {(X, Y, Z)} A field with a single Cartesian (X, Y, > ] Z) point value which describes the spatial location, virtual or > ] physical, of the capturing device (such as camera). > ] > ] When the Point of Capture attribute is specified, it must include X, > ] Y and Z coordinates. If the point of capture is not specified, it > ] means the consumer should not assume anything about the spatial > ] location of the capturing device. Even if the provider specifies an > ] area of capture attribute, it does not need to specify the point of > ] capture. > > That last sentence is enough to confuse anybody, IMHO. :^( What is confusing? > But I don't see how you're entitled to assume "perpendicular" to the > plane of the Area of Capture. IMHO, failure to include Point of Capture > is distinctly not-nice, and leaves you no good way to associate pixel > positions with physical positions. Is there any requirement that the point of capture be *in front* of the area of capture? Couldn't it be behind? If so, wouldn't that have great impact on how you interpret the video? > It's certainly possible that the provider would fail to include Point > of Capture because s/he's providing a processed piece, possibly stiched > together from parts of different cameras. (I don't consider that nice > either!) Again, without a point of capture, how do you know the orientation of the display? >> - if the "point of capture" is included and the "axis of capture point" >> is included it describes a position in space of a second point on the >> axis of capture of the capturing device;*** > > Refer to the proposed text: > ] > ] Axis of Capture Point: {(X, Y, Z)} A field with a single Cartesian > ] (X, Y, Z) point value (virtual or physical) which describes a position > ] in space of a second point on the axis of capture of the capturing > ] device; the first point being the Point of Capture (see above). > ] > ] The axis of capture point MUST NOT be specified if the Capture Point > ] is not present for this capture device. > ] > ] When the Axis of Capture Point attribute is specified, it must include X, > ] Y and Z coordinates. If the Axis of Capture point is not specified, it > ] means the consumer should not assume anything about the axis of > ] Capture of the capturing device. > > Your statement seems correct, though not 100% implied. I wonder why > we don't specify that the Axis of Capture Point is a point within the > plane of the Area of Capture (when possible). I suppose it should always be possible. But by requiring it you open up issues when rounding errors cause it to be "not quite" in the plane. We don't want to have errors just because people use differing precision for their arithmetic. Thanks, Paul >> - If the "point of capture" is not included then "axis of capture point" >> is not used. > > That much is clear. > >> Is this the desired behaviour? >> >> With regards to the *** above, an axis (line) travels in two directions. > > Quite correct. > >> I wonder if it is beneficial to specify that the axis of capture point >> must lie between the capture area and the point of capture. > > You mean Area of Capture, no doubt? > >> Might help avoid some confusion if someone defines a point behind the >> capture point. > > If someone can't handle that, we have worse problems! > > Nonetheless, ISTM that one will need to calculate the intersection > of that line with the Area of Capture (unless the Axis of Capture Point > is defined to be that intersection already). This introduces rounding > errors which could possibly be significant. > >> I'm also wondering if it is better to call this "line of capture" or >> "optical axis" or similar? Mathematically speaking what we're defining >> by two points is a line or optically speaking its an optical axis. > > It might indeed be easier to understand (though I must admit the > _value_ is a single XYZ point)... > > -- > John Leslie > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From Mark.Duckworth@polycom.com Tue Jul 3 12:36:13 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 9B3E511E81DA for ; Tue, 3 Jul 2012 12:36:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.413 X-Spam-Level: X-Spam-Status: No, score=-6.413 tagged_above=-999 required=5 tests=[AWL=0.186, 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 rZ-vBUlbbTz2 for ; Tue, 3 Jul 2012 12:36:13 -0700 (PDT) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id EE20611E81B0 for ; Tue, 3 Jul 2012 12:36:12 -0700 (PDT) Received: from Crpmboxprd01.polycom.com ([fe80::ad68:5a0:c919:66b6]) by crpehubprd02.polycom.com ([fe80::5efe:10.236.0.154%12]) with mapi; Tue, 3 Jul 2012 12:36:20 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Tue, 3 Jul 2012 12:36:19 -0700 Thread-Topic: [clue] Is there anything else to change in the framework right now? Thread-Index: Ac1ZRQw7boqWoOY5SJuLwoFoDjPESAADbWJg Message-ID: <44C6B6B2D0CF424AA90B6055548D7A6102FE143875@CRPMBOXPRD01.polycom.com> References: <44C6B6B2D0CF424AA90B6055548D7A6102FE0360D2@CRPMBOXPRD01.polycom.com> <4FF3320F.5010809@alum.mit.edu> In-Reply-To: <4FF3320F.5010809@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 Subject: Re: [clue] Is there anything else to change in the framework right now? 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, 03 Jul 2012 19:36:13 -0000 Hi Paul, You are correct about the scale, but the origin is not specified by an attr= ibute. I think that was the point of the clarification, which Roni pointed= out some time ago but I forgot to add it in the previous version. Mark > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: Tuesday, July 03, 2012 1:55 PM > To: clue@ietf.org > Subject: Re: [clue] Is there anything else to change in the framework rig= ht > now? >=20 > On 7/3/12 10:47 AM, Duckworth, Mark wrote: >=20 > > 4. Clarify that the provider must use the same coordinate system with > > same scale and origin for all coordinates within the same capture > > scene. >=20 > This is inescapable if the coordinate system scale and origin are only > specifiable as attributes of the capture scene, because there is no way t= o > violate this. >=20 > Thanks, > Paul > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From pkyzivat@alum.mit.edu Tue Jul 3 13:29: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 3CB5911E80F1 for ; Tue, 3 Jul 2012 13:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.231 X-Spam-Level: X-Spam-Status: No, score=-2.231 tagged_above=-999 required=5 tests=[AWL=0.368, 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 5Ecfc59VPOY7 for ; Tue, 3 Jul 2012 13:29:39 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by ietfa.amsl.com (Postfix) with ESMTP id 9893111E80A2 for ; Tue, 3 Jul 2012 13:29:39 -0700 (PDT) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta05.westchester.pa.mail.comcast.net with comcast id Vrpd1j00617dt5G55wVqPT; Tue, 03 Jul 2012 20:29:50 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta13.westchester.pa.mail.comcast.net with comcast id VwVv1j00A3ZTu2S3ZwVvp3; Tue, 03 Jul 2012 20:29:55 +0000 Message-ID: <4FF3563B.4020302@alum.mit.edu> Date: Tue, 03 Jul 2012 16:29:47 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: clue@ietf.org References: <44C6B6B2D0CF424AA90B6055548D7A6102FE0360D2@CRPMBOXPRD01.polycom.com> <4FF3320F.5010809@alum.mit.edu> <44C6B6B2D0CF424AA90B6055548D7A6102FE143875@CRPMBOXPRD01.polycom.com> In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A6102FE143875@CRPMBOXPRD01.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] Is there anything else to change in the framework right now? 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, 03 Jul 2012 20:29:40 -0000 On 7/3/12 3:36 PM, Duckworth, Mark wrote: > Hi Paul, > > You are correct about the scale, but the origin is not specified by an attribute. I think that was the point of the clarification, which Roni pointed out some time ago but I forgot to add it in the previous version. Then lets make sure that the origin is also an attribute of the scene. Thanks, Paul > Mark > >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >> Paul Kyzivat >> Sent: Tuesday, July 03, 2012 1:55 PM >> To: clue@ietf.org >> Subject: Re: [clue] Is there anything else to change in the framework right >> now? >> >> On 7/3/12 10:47 AM, Duckworth, Mark wrote: >> >>> 4. Clarify that the provider must use the same coordinate system with >>> same scale and origin for all coordinates within the same capture >>> scene. >> >> This is inescapable if the coordinate system scale and origin are only >> specifiable as attributes of the capture scene, because there is no way to >> violate this. >> >> Thanks, >> Paul >> _______________________________________________ >> 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 Jul 3 13:35: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 B62D721F86CA for ; Tue, 3 Jul 2012 13:35:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.436 X-Spam-Level: X-Spam-Status: No, score=-6.436 tagged_above=-999 required=5 tests=[AWL=0.163, 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 SC4+kEFLX28u for ; Tue, 3 Jul 2012 13:35:00 -0700 (PDT) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 381AF21F864A for ; Tue, 3 Jul 2012 13:35:00 -0700 (PDT) Received: from Crpmboxprd01.polycom.com ([fe80::ad68:5a0:c919:66b6]) by crpehubprd02.polycom.com ([fe80::5efe:10.236.0.154%12]) with mapi; Tue, 3 Jul 2012 13:35:08 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Tue, 3 Jul 2012 13:35:06 -0700 Thread-Topic: origin attribute? Thread-Index: Ac1ZW0Ph+TqO4V2OQ0alZ3+oC3hO1Q== Message-ID: <44C6B6B2D0CF424AA90B6055548D7A6102FE1438B6@CRPMBOXPRD01.polycom.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: [clue] origin attribute? 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, 03 Jul 2012 20:35:00 -0000 Hi Paul, I thought the group had this conversation before, with the conclusion that = we do not want to have the provider try to indicate anything about the orig= in of the coordinate system. I don't know how it is possible to specify an= origin as an attribute. Do you have a suggestion? Mark > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: Tuesday, July 03, 2012 4:30 PM > To: clue@ietf.org > Subject: Re: [clue] Is there anything else to change in the framework rig= ht > now? >=20 > On 7/3/12 3:36 PM, Duckworth, Mark wrote: > > Hi Paul, > > > > You are correct about the scale, but the origin is not specified by an > attribute. I think that was the point of the clarification, which Roni p= ointed > out some time ago but I forgot to add it in the previous version. >=20 > Then lets make sure that the origin is also an attribute of the scene. >=20 > Thanks, > Paul >=20 > > Mark > > > >> -----Original Message----- > >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > >> Of Paul Kyzivat > >> Sent: Tuesday, July 03, 2012 1:55 PM > >> To: clue@ietf.org > >> Subject: Re: [clue] Is there anything else to change in the framework > >> right now? > >> > >> On 7/3/12 10:47 AM, Duckworth, Mark wrote: > >> > >>> 4. Clarify that the provider must use the same coordinate system > >>> with same scale and origin for all coordinates within the same > >>> capture scene. > >> > >> This is inescapable if the coordinate system scale and origin are > >> only specifiable as attributes of the capture scene, because there is > >> no way to violate this. > >> > >> Thanks, > >> Paul > >> _______________________________________________ > >> 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 > > >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From pkyzivat@alum.mit.edu Tue Jul 3 13:58:28 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 DC89B21F870A for ; Tue, 3 Jul 2012 13:58:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.254 X-Spam-Level: X-Spam-Status: No, score=-2.254 tagged_above=-999 required=5 tests=[AWL=0.345, 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 HqlvePW1iood for ; Tue, 3 Jul 2012 13:58:28 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by ietfa.amsl.com (Postfix) with ESMTP id C0F4E21F8705 for ; Tue, 3 Jul 2012 13:58:27 -0700 (PDT) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta10.westchester.pa.mail.comcast.net with comcast id Vwr41j0020ldTLk5Awyet4; Tue, 03 Jul 2012 20:58:38 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta04.westchester.pa.mail.comcast.net with comcast id Vwyb1j00J3ZTu2S3QwybPo; Tue, 03 Jul 2012 20:58:35 +0000 Message-ID: <4FF35CFB.5000702@alum.mit.edu> Date: Tue, 03 Jul 2012 16:58:35 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: clue@ietf.org References: <44C6B6B2D0CF424AA90B6055548D7A6102FE1438B6@CRPMBOXPRD01.polycom.com> In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A6102FE1438B6@CRPMBOXPRD01.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] origin attribute? 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, 03 Jul 2012 20:58:29 -0000 On 7/3/12 4:35 PM, Duckworth, Mark wrote: > Hi Paul, > I thought the group had this conversation before, with the conclusion that we do not want to have the provider try to indicate anything about the origin of the coordinate system. I don't know how it is possible to specify an origin as an attribute. Do you have a suggestion? Hmm. OK - I guess you are right that we had this. The scene has a single coordinate system. By a reasonable definition the origin is (0,0,0) and so need not be stated. All the coordinates used within the scene are relative to that. But the effect is the same. But it doesn't hurt to emphasize that all coordinates are with respect to a single coordinate system associated with the scene. (And unrelated to coordinates in any other scene.) Thanks, Paul > Mark > >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >> Paul Kyzivat >> Sent: Tuesday, July 03, 2012 4:30 PM >> To: clue@ietf.org >> Subject: Re: [clue] Is there anything else to change in the framework right >> now? >> >> On 7/3/12 3:36 PM, Duckworth, Mark wrote: >>> Hi Paul, >>> >>> You are correct about the scale, but the origin is not specified by an >> attribute. I think that was the point of the clarification, which Roni pointed >> out some time ago but I forgot to add it in the previous version. >> >> Then lets make sure that the origin is also an attribute of the scene. >> >> Thanks, >> Paul >> >>> Mark >>> >>>> -----Original Message----- >>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >>>> Of Paul Kyzivat >>>> Sent: Tuesday, July 03, 2012 1:55 PM >>>> To: clue@ietf.org >>>> Subject: Re: [clue] Is there anything else to change in the framework >>>> right now? >>>> >>>> On 7/3/12 10:47 AM, Duckworth, Mark wrote: >>>> >>>>> 4. Clarify that the provider must use the same coordinate system >>>>> with same scale and origin for all coordinates within the same >>>>> capture scene. >>>> >>>> This is inescapable if the coordinate system scale and origin are >>>> only specifiable as attributes of the capture scene, because there is >>>> no way to violate this. >>>> >>>> Thanks, >>>> Paul >>>> _______________________________________________ >>>> 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 >>> >> >> _______________________________________________ >> 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 john@jlc.net Tue Jul 3 17:34:28 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 24FCB11E80E7 for ; Tue, 3 Jul 2012 17:34:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.562 X-Spam-Level: X-Spam-Status: No, score=-106.562 tagged_above=-999 required=5 tests=[AWL=0.037, 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 4DAue2m76utB for ; Tue, 3 Jul 2012 17:34:27 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 8EE3211E80D9 for ; Tue, 3 Jul 2012 17:34:27 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id EA9DF33C2E; Tue, 3 Jul 2012 20:34:36 -0400 (EDT) Date: Tue, 3 Jul 2012 20:34:36 -0400 From: John Leslie To: Paul Kyzivat Message-ID: <20120704003436.GB63837@verdi> References: <4FF295CE.2070903@nteczone.com> <20120703175054.GA63837@verdi> <4FF33C9C.3020503@alum.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FF33C9C.3020503@alum.mit.edu> User-Agent: Mutt/1.4.1i Cc: clue@ietf.org Subject: Re: [clue] Concensus call: Text for "Axis of Capture" 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, 04 Jul 2012 00:34:28 -0000 Paul Kyzivat wrote: > On 7/3/12 1:50 PM, John Leslie wrote: >>Christian Groves wrote: >>> >>>I'm getting confused.... my understanding is the following: >>>... >> >> I went back to the text of draft-ietf-clue-framework-05, section 6.1.1: >>]... >>] Even if the provider specifies an >>] area of capture attribute, it does not need to specify the point of >>] capture. >> >> That last sentence is enough to confuse anybody, IMHO. :^( > > What is confusing? "does not need" (It's hard to come up with a fully legitimate case where the point of capture could reasonably be omitted. Until you do, this sentence only confuses the reader.) >> It's certainly possible that the provider would fail to include Point >> of Capture because s/he's providing a processed piece, possibly stiched >> together from parts of different cameras. (I don't consider that nice >> either!) (That's my "fully legitimate" case...) > Again, without a point of capture, how do you know the orientation of > the display? You don't. (But someone could look at it and guess. ;^) >>... I wonder why >> we don't specify that the Axis of Capture Point is a point within the >> plane of the Area of Capture (when possible). > > I suppose it should always be possible. But by requiring it you open up > issues when rounding errors cause it to be "not quite" in the plane. We > don't want to have errors just because people use differing precision > for their arithmetic. The rounding error is "nicer" here than different rounding by the receivers. (Besides, I did say "if possible"...) -- John Leslie From Christian.Groves@nteczone.com Tue Jul 3 18:49: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 E4CC111E80D9 for ; Tue, 3 Jul 2012 18:49:25 -0700 (PDT) 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 2y3L2JOeQoRR for ; Tue, 3 Jul 2012 18:49:25 -0700 (PDT) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:6]) by ietfa.amsl.com (Postfix) with ESMTP id 1765411E80AE for ; Tue, 3 Jul 2012 18:49:23 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAEyg80920ZWs/2dsb2JhbAANOLo1AQEBAwE4DwwlARALGAkWDwkDAgECAUUGDQEFAgEBiAKrIo9IizeGNwOoKQ Received: from ppp118-209-149-172.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.149.172]) by ipmail06.adl6.internode.on.net with ESMTP; 04 Jul 2012 11:19:31 +0930 Message-ID: <4FF3A126.3060707@nteczone.com> Date: Wed, 04 Jul 2012 11:49:26 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: John Leslie References: <4FF295CE.2070903@nteczone.com> <20120703175054.GA63837@verdi> In-Reply-To: <20120703175054.GA63837@verdi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: clue@ietf.org Subject: Re: [clue] Concensus call: Text for "Axis of Capture" 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, 04 Jul 2012 01:49:26 -0000 Hello John, Please see my responses below marked [CNG]. Regards, Christian On 4/07/2012 3:50 AM, John Leslie wrote: > Christian Groves wrote: >> I'm getting confused.... my understanding is the following: >> >> - If the "point of capture" is included and the "axis of capture point" >> is not included then the axis is assumed to be perpendicular to the >> centre of the capture area. > That's enough to confuse me! [CNG] Good to know I'm in company :-). > > I went back to the text of draft-ietf-clue-framework-05, section 6.1.1: > ]... > ] Point of Capture: {(X, Y, Z)} A field with a single Cartesian (X, Y, > ] Z) point value which describes the spatial location, virtual or > ] physical, of the capturing device (such as camera). > ] > ] When the Point of Capture attribute is specified, it must include X, > ] Y and Z coordinates. If the point of capture is not specified, it > ] means the consumer should not assume anything about the spatial > ] location of the capturing device. Even if the provider specifies an > ] area of capture attribute, it does not need to specify the point of > ] capture. > > That last sentence is enough to confuse anybody, IMHO. :^( > > But I don't see how you're entitled to assume "perpendicular" to the > plane of the Area of Capture. IMHO, failure to include Point of Capture > is distinctly not-nice, and leaves you no good way to associate pixel > positions with physical positions. [CNG] I was trying to clarify what Roni was getting at in his original reply on this thread where he mentioned this perpendicular aspect. Previous to this discussion there was no concept of a second point to define an "axis of capture". Therefore there must have been an assumption about the axis... > > It's certainly possible that the provider would fail to include Point > of Capture because s/he's providing a processed piece, possibly stiched > together from parts of different cameras. (I don't consider that nice > either!) > >> - if the "point of capture" is included and the "axis of capture point" >> is included it describes a position in space of a second point on the >> axis of capture of the capturing device;*** > Refer to the proposed text: > ] > ] Axis of Capture Point: {(X, Y, Z)} A field with a single Cartesian > ] (X, Y, Z) point value (virtual or physical) which describes a position > ] in space of a second point on the axis of capture of the capturing > ] device; the first point being the Point of Capture (see above). > ] > ] The axis of capture point MUST NOT be specified if the Capture Point > ] is not present for this capture device. > ] > ] When the Axis of Capture Point attribute is specified, it must include X, > ] Y and Z coordinates. If the Axis of Capture point is not specified, it > ] means the consumer should not assume anything about the axis of > ] Capture of the capturing device. > > Your statement seems correct, though not 100% implied. I wonder why > we don't specify that the Axis of Capture Point is a point within the > plane of the Area of Capture (when possible). [CNG] We could do that. I think that at least the axis of capture point should be in the direction of the capture point to the area of capture. The point could lie before or beyond the area of capture plane. > >> - If the "point of capture" is not included then "axis of capture point" >> is not used. > That much is clear. > >> Is this the desired behaviour? >> >> With regards to the *** above, an axis (line) travels in two directions. > Quite correct. > >> I wonder if it is beneficial to specify that the axis of capture point >> must lie between the capture area and the point of capture. > You mean Area of Capture, no doubt? [CNG] Yes, area of capture > >> Might help avoid some confusion if someone defines a point behind the >> capture point. > If someone can't handle that, we have worse problems! [CNG] I think you've been around on these lists long enough to know that it will be a problem for someone :-). > > Nonetheless, ISTM that one will need to calculate the intersection > of that line with the Area of Capture (unless the Axis of Capture Point > is defined to be that intersection already). This introduces rounding > errors which could possibly be significant. > >> I'm also wondering if it is better to call this "line of capture" or >> "optical axis" or similar? Mathematically speaking what we're defining >> by two points is a line or optically speaking its an optical axis. > It might indeed be easier to understand (though I must admit the > _value_ is a single XYZ point)... [CNG] WRT to single XYZ point I agree its inconsistent, however "Second point defining the optical axis" whilst precise is a little long winded. > > -- > John Leslie > From christer.holmberg@ericsson.com Tue Jul 3 23:37:54 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 5E31421F86E1 for ; Tue, 3 Jul 2012 23:37:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.223 X-Spam-Level: X-Spam-Status: No, score=-6.223 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 CadHz5Kuoo6s for ; Tue, 3 Jul 2012 23:37:53 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 360FB21F854B for ; Tue, 3 Jul 2012 23:37:52 -0700 (PDT) X-AuditID: c1b4fb25-b7fc16d000005db2-72-4ff3e4cac299 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 63.1A.23986.AC4E3FF4; Wed, 4 Jul 2012 08:38:02 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.237]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Wed, 4 Jul 2012 08:38:01 +0200 From: Christer Holmberg To: "Duckworth, Mark" , "clue@ietf.org" Date: Wed, 4 Jul 2012 08:38:01 +0200 Thread-Topic: [clue] Framework scene description attribute update Thread-Index: Ac1YpgdkCboiOtirR+WbcCXCfpZJNQAd7ijwACQ9ASA= Message-ID: <7F2072F1E0DE894DA4B517B93C6A05853405AF417B@ESESSCMS0356.eemea.ericsson.se> References: <44C6B6B2D0CF424AA90B6055548D7A6102FE035F38@CRPMBOXPRD01.polycom.com> <4FF210B4.2040809@alum.mit.edu> <44C6B6B2D0CF424AA90B6055548D7A6102FE035F86@CRPMBOXPRD01.polycom.com> <4FF22746.2090909@alum.mit.edu> <44C6B6B2D0CF424AA90B6055548D7A6102FE03605E@CRPMBOXPRD01.polycom.com> In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A6102FE03605E@CRPMBOXPRD01.polycom.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNLMWRmVeSWpSXmKPExsUyM+Jvre6pJ5/9Dd7/F7LYf+oys8W6I0+Z HZg8liz5yeTx4oFSAFMUl01Kak5mWWqRvl0CV8bvF5fYCq6qVWxYdZilgfGxXBcjJ4eEgInE 8Qs/mSFsMYkL99azdTFycQgJnGKU+L2vkwnCWcAo0XGijb2LkYODTcBCovufNkiDiECoxOqZ m1hAbBYBFYlTh66CDRIWcJBYt2I/C0SNo0RDy3RGCNtKYvm6bSwgY3gFwiVuLiuHGL+USWL5 77+sIDWcAkESz++dA5vDCHTQ91NrmEBsZgFxiVtP5jNBHCogsWTPeaijRSVePv7HClEvKnGn fT0jRL2exI2pU9ggbG2JZQtfg9XzCghKnJz5hGUCo+gsJGNnIWmZhaRlFpKWBYwsqxiFcxMz c9LLjfRSizKTi4vz8/SKUzcxAiPk4JbfqjsY75wTOcQozcGiJM5rvXWPv5BAemJJanZqakFq UXxRaU5q8SFGJg5OqQbG6vhreT9mV3vMNvyQriO73VPSK1G8u2tFvLL97NUpUn+Mm7pkVs7I OafBPuXxIYH4b0Z8njXRBunLg3Zv3J1WYlbzsXX52rnuVbzbA3V+8cUaiMgZT6zICOpZfX3x p0d7TR7ub3XbvG2++K6dHTxNv6yrVboZvtesPLpphtuza1IxRlLFCfZKLMUZiYZazEXFiQB/ 5XYEXgIAAA== Subject: Re: [clue] Framework scene description attribute update 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, 04 Jul 2012 06:37:54 -0000 Hi, Are the following sentences really needed? "If there is more than one string in the list, then each string in the= list should contain the same description, but in a different language." "This attribute can contain text in any number of languages." In addition, I would suggest to modify: "A provider that advertises multiple capture scenes may use different d= escriptions to differentiate between them." ...to: "A provider that adertises multiple capture scenes can provide descripti= ons for each of them" Regards, Christer -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Duc= kworth, Mark Sent: 3. hein=E4kuuta 2012 16:20 To: clue@ietf.org Subject: Re: [clue] Framework scene description attribute update Okay, how about this text for the scene description attribute: Description attribute - list of {, } The optional description attribute is a list of human readable text strings which describe the capture scene. If there is more than one string in the list, then each string in the list should contain the same description, but in a different language. A provider that advertises multiple capture scenes may use different descriptions to differentiate between them. This attribute can contain text in any number of languages. The language tag identifies the language of the corresponding description text. The possible values for a language tag are the values of the 'Subtag' column for the "Type: language" entries in the "Language Subtag Registry" at [IANA-Lan] originally defined in [RFC5646]. A particular language tag value MUST NOT be used more than once in the description attribute list. Mark > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf=20 > Of Paul Kyzivat > Sent: Monday, July 02, 2012 6:57 PM > To: clue@ietf.org > Subject: Re: [clue] Framework scene description attribute update >=20 > On 7/2/12 6:23 PM, Duckworth, Mark wrote: > > Hi Paul, > > I thought of your way too, which is also fine with me. I can reword=20 > > the text > to do it that way if people prefer. > > Mark >=20 > In practice I think we want to end up with what Espen commented. > But you have to get down into the xml to describe that. The model is=20 > too high level to talk about it that way. So what I said, or anything=20 > else that can clearly map to what Espen said works for me. >=20 > Thanks, > Paul >=20 > >> -----Original Message----- > >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On=20 > >> Behalf Of Paul Kyzivat > >> Sent: Monday, July 02, 2012 5:21 PM > >> To: clue@ietf.org > >> Subject: Re: [clue] Framework scene description attribute update > >> > >> Mark, > >> > >> So you are proposing one list of descriptions, and a separate but=20 > >> parallel list of languages? > >> > >> That seems clumsy, unnatural, and error prone. Why not a list of=20 > >> pairs of (description, language)? And I'd be inclined to specify=20 > >> that a particular language value MUST NOT be specified more than once. > >> > >> Thanks, > >> Paul > >> > >> On 7/2/12 5:12 PM, Duckworth, Mark wrote: > >>> Based on the decision at the interim meeting to support multiple=20 > >>> description strings, each in a different language, here is my=20 > >>> proposed updated text for the framework document. I also addressed=20 > >>> Christians comments=20 > >>> http://www.ietf.org/mail-archive/web/clue/current/msg01522.html > >>> > >>> Please review this change. > >>> > >>> Description attribute > >>> > >>> The optional description attribute is a list of human readable=20 > >>> text strings which describes the capture scene. If there is more=20 > >>> than one string in the list, then each string in the list should=20 > >>> contain the same description, but in a different language. A=20 > >>> provider that advertises multiple capture scenes may use different=20 > >>> descriptions to differentiate between them. This attribute can=20 > >>> contain text in any number of languages. > >>> > >>> Description Language attribute > >>> > >>> This attribute is a list of language tags, to identify the=20 > >>> language of the corresponding description attribute text. The=20 > >>> number of language tags in this list must be the same as the=20 > >>> number of strings in the description list. The possible values for=20 > >>> a language tag are the values of the 'Subtag' column for the=20 > >>> "Type: language" entries in the "Language Subtag Registry" at=20 > >>> [IANA-Lan] originally defined in [RFC5646]. > >>> > >>> Regards, > >>> > >>> Mark _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue= From Mark.Duckworth@polycom.com Thu Jul 5 05:52:54 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 1F4D621F8512 for ; Thu, 5 Jul 2012 05:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.454 X-Spam-Level: X-Spam-Status: No, score=-6.454 tagged_above=-999 required=5 tests=[AWL=0.145, 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 aXL0ygDg+8Y6 for ; Thu, 5 Jul 2012 05:52:53 -0700 (PDT) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 6A85D21F850B for ; Thu, 5 Jul 2012 05:52:53 -0700 (PDT) Received: from Crpmboxprd01.polycom.com ([fe80::ad68:5a0:c919:66b6]) by Crpehubprd01.polycom.com ([fe80::5efe:10.236.0.158%14]) with mapi; Thu, 5 Jul 2012 05:53:05 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Thu, 5 Jul 2012 05:53:04 -0700 Thread-Topic: [clue] Framework scene description attribute update Thread-Index: Ac1YpgdkCboiOtirR+WbcCXCfpZJNQAd7ijwACQ9ASAAP3/MYA== Message-ID: <44C6B6B2D0CF424AA90B6055548D7A6102FE1439A9@CRPMBOXPRD01.polycom.com> References: <44C6B6B2D0CF424AA90B6055548D7A6102FE035F38@CRPMBOXPRD01.polycom.com> <4FF210B4.2040809@alum.mit.edu> <44C6B6B2D0CF424AA90B6055548D7A6102FE035F86@CRPMBOXPRD01.polycom.com> <4FF22746.2090909@alum.mit.edu> <44C6B6B2D0CF424AA90B6055548D7A6102FE03605E@CRPMBOXPRD01.polycom.com> <7F2072F1E0DE894DA4B517B93C6A05853405AF417B@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05853405AF417B@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [clue] Framework scene description attribute update X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence